Yeah, I’m not going to say too much here, to keep the thread reasonable, other than in Tattoo, there will be only two major classes of objects, so if we want to keep MODx and what I’m doing in tune, we need to consider what is happening to the data structures in this way; there is no reason this same structure would not work for MODx in a PHP4/5-MySQL only setting:
Resources -- these are equivalent to the idea of a web resource, identified with a uniform resource locator (URL). To start off, there are only two types of Resources that can be created, a PageResource and a LinkResource (equivalent to the site_content records)
Elements -- these are any class of object that make up the definition of a Resource and are broken down as follows in the object model...
- Element: a simple element type, equivalent to a template or a chunk, and consisting of simple HTML content and/or ElementTags (see below)
- ScriptElement extends Element: a simple element type that consists of script content (equivalent to Snippet)
- PluginElement extends ScriptElement: these are elements based on ScriptElements, that offer the additional behaviors associated with Plugins (e.g. triggering based on system or custom events); this is in no way limited to the manager context, since moving forward, the manager and front-end interfaces will be defined and constructed in the same manner
- ModuleElement extends ScriptElement: this may or may not be needed; I’m trying to justify simply making ModuleElements equivalent to ScriptElements; any thoughts on why we would need any distinction between these, especially if we have a separate package installation mechanism that allowed any combination of resources and/or elements to be grouped and packaged as a set of related site components
- ContentElement extends Element: similarly, trying to justify the distinction between chunks/templates/TV’s where ContentElement would represent the same thing as TV’s do currently, but I think I may be able to treat any Element in the manner of a TV
In this model, all Elements can be related by GUID as the various Module elements would be to allow the concept of installation packages, and all Elements can define custom input and output (aka transform) classes in the way that Display Widgets are applied to TV’s now. Finally, each Element type can define how it processes it’s content, including handling processing of
ElementTags within the content or even nested in the tags.
New Elements and Resources could easily be defined in this sturcture, extending the capabilities of the system greatly. For instance, consider an AjaxResource setup for the purpose of handling Ajax requests that require data from our API’s, or advanced DocumentResources that might allow the storage of images or other complex document formats in the databases.
I do not see any relationship between Plugins and Modules, and do not agree they are ONLY manager context related. Modules and Snippets are the same in the current system for their respective contexts in most aspects, especially if you remove the dependent relationships capabilities in Modules and externalize those as a package installation system that can be applied to any set of related Resources and/or Elements.
Now, if these structures are going to be rejected, I really need to know now. In that case I will make alternative plans for developing and building my OO version of MODx as a project independent of MODx and Tattoo. I see no reason to even keep these related if we can not come up with a common and consistent vision for the development paths.
MODX Staff
MODX Staff
