Consider the following question posed by a hypothetical new user. "I just want to create a new ______ page...", where ______ is catalog, press release, news item, bio, documentation, page, etc. This brings to mind our frequently visited concept of "content templates" or some other sort of added jargon (I’m against that! lol). Now, let’s examine how that’s done, and if it can be improved upon or simplified, or just call things a little differently so they make more sense.
Here’s the way (I’m *thinking* anyway) pages are structured heirarchically, and how/what the pieces can include, with respect to how they pass through the parser:
template
? static text, HTML, JS, CSS, etc.
? [*content*]
? [[snippets]]
? {{chunks}}
? [+placeholders+]
? [*TVs*]
[*content*]
? static text, HTML, JS, CSS, etc.
? [[snippets]]
? {{chunks}}
? [*TVs*]
[*TVs*]
? input options
? ? input option values (always visible/never changes based on selection)
? ? ? @bindings
? default values
? ? @bindings
? ? static text, HTML, JS, CSS, etc.
? ? [[snippets]]
? ? {{chunks}}
? ? [*TVs*]
? widgets/display controls
Two other concepts might come into play also:
? Plugins--special code that modifies, intercepts, extends or otherwise alters the default system behavior, function or output based on certain event-points in the parser
? Modules--a collection of database structures, templates, pages, plugins, CSS files, JS files, etc.
Now from an outsiders perspective, I should be able to select a "new page type" button/select-list and it automatically does the following for me. This could be considered to be controlled by a "meta-template" or "page template" perhaps:
1) navigate to the correct parent
2) create a new document
3) select the appropriate template
4) set the page option flags appropriately (cacheable, searchable, don’t register a hit, meta content, etc.)
5) select the appropriate TV input options, as appropriate
6) opens the page for editing
One thing that is confusing to me (and probably to others) is a logical explanation of the difference between the [*content*] and any other TV. [*content*] just seems like a forced TV on every page, with fewer options like input controls, display controls and default values. Why force me to have a huge text-area block on every manager page? It makes no sense from a usability standpoint, and that’s what the users see.
I also don’t understand the difference between a chunk and a placeholder. They’re both just "placeholders" for chunks of content that contain no logic.
So, perhaps the following syntax would make more sense and be more intuitive ( new name -- orignal name / discussion ):
Template -- Template :) no change!
? static text, images, html, etc. -- :) no change!
? [*variables*] -- TVs + content, with [*content*] being a non-optional global variable established for every page
? [] -- snippets
? {{placeholders}} -- chunks + placeholders
<br /><br />And our affiliated part:? <br />? ? Packages -- Modules ("packages" more accurately describes a collection)<br /><br />You might be wondering what happened to the plugins...? they’re still there, just folded into the packages, because they’re to be handled as part of the package installer/upgrade system internal to the manager. More of an advanced topic I think, but could definitely be part of the base level system.<br /><br />Seems like a heck of a lot less stuff to get into folks’ heads to me. The reason being is because you can cleanly keep the discussion of how the system works to one main level for the simpler version at the bottom, vs. having to exaplain the caveats and intricacies of the difference between content and tvs, including why content doesn’t have all the cool options the TVs do. ’Cause it’s just another piece of content, right? ;) <br /><br />You can even keep the discussion of the system very simple, and all of the sudden the system starts to sound really easy for newcomers: <br />[quote]<br />Pages are based on "templates". Templates can contain some, multiple or all of the following:<br />[*] non-editable or static parts<br />[*] one or more editable variables: [*variables*]<br />[*] code from developers to perform special functions like building the menu from all the differnt pages in the site: [[ code]]<br />[*] pieces of static content used in more than one place, like a copyright line at the bottom of a web page: {{placeholders}}<br />[/quote]<br /><br />Then you can explain to developers how they can have sophisticated control using the same structures:<br />[quote]<br />For developers with complex logic needs, you can do more sophisticated things using simple syntax and normal PHP code like:<br />[list]<br />[*] calling other variables and placholders from each other<br />[*] setting default options and input methods for variables using "input widgets", such as pop-up lists, radio buttons or more<br />[*] use built-in data transforming "output widgets" to build data into the formats that otherwise would take a long time to achieve such as data grids, dynamic scrolling tickers and so on<br />[*] bind different data sources (such as text files, databases or other variables) to default input values or input widgets using "@bindings" <br />[*] override default API, manager and parsing behaviors using plugins<br />[*] combine templates, pages, database files, [[ code]], {{placeholders}} into "packges" for one-click install by end users<br />[*] combine all the above, even recursively, to create powerful solutions limited only by your imagination<br />[/list]<br />[/quote]<br /><br />What are your thoughts on this topic?
MODX Staff
MODX Staff