Lingo-ology

Quote from: OpenGeek at Nov 08, 2005, 11:09 AM

Was thinking all the settings accessible via [( )] would become placeholders...some of them might need to be renamed to avoid conflicts with common placeholders like [+email_address+]

Like [+cms_email_address+]

Quote from: xwisdom at Nov 08, 2005, 11:06 AM

So as it relates to tags calls:

[[Plugins]]
[+Placeholders+]
[*ContentFields*]
[~DocumentIDs~]

I’m for this with the possible exception off merging the syntax of CFs into the same plugin call syntax.

[[Plugin]] or [[Template/Sub-template]] or [[Content Field]]
[~Page ID~] (links)
[+Placeholders+] (persistent, dynamic chunks)

This would mean namespace becomes more critical, but that’s OK by me.

What would happen if we merged plugins and templates into one being? Hierarchical plugins and templates identified by a plugin or template type. Just a thought...

OK, and in summary then, it seems like the major development conventions for future MODx/Tattoo releases will be:

[[Plugin]] – combined snippets/chunks/plugins/templates
[~ID~] – links to pages
[*ContentField*] – page content "variables"
[+Placeholders+] – dynamically defined "variables" used in Plugins

Some of the cleanup that will be done will also include better categorization via tags (or other such methods) so we can better organize our views (think of templates as nothing more than a rebranded chunk). Categorization can be done in a heirarchical manner (ala the document tree and parent IDs for everything) or in a freeform fashion via tags depending on what works best.

Each Plugin will also be able to be "hidden" from the Plugins tab (currently the snippets tab) as appropriate. The Plugins tab may also provide better usage example or insertion abilities.

Caching will be automated so we lower our support "cost" with end users. To create the ability to emulate the current [! or [[ call methods, duplicate your snippets and uncheck the caching (and use a slightly altered name).

Does that about sum up this thread?

I think we should still keep [()] as we might run into problems where placeholder values will conflict with system seetings.

We will still have to support {{}}

Personally I’m for dropping [()] and registering only the commonly used settings as placeholders. The settings tas are rarely used (from what I’v seen) as are placeholders, so I don’t think we’ll run into many problems. Plus we could always provide a backwards compatability plugin to support {{}} [()] and maybe throw some errors to the error log when they’re used, in order to give people some time to move away form using them. Any potential naming conflicts could also be logged.

The way I see it the settings tags really are placeholders.

The more I sleep on it, the more I like using placeholder syntax for system settings. To me it just makes sense as that’s effectively what they are. System settings, like the manager class/ID names, should be prepended with something like "cms_", so naming conflicts should be minimal.

I like the idea of logging the "errors" to the event log too when using a compatibility plugin. It would make for an easier to use new users (which I predict will grossly out number the exsiting user base within 6 months). The compatibility plugin could also regex the {{ and [( calls at runtime to accomodate existing/legacy sites.

And if I’m not mistaken, when turning off the compatibility/legacy plugin, a properly updated site should run considerably faster: fewer DB queries and fewer passes through different parser functions. That sounds pretty cool, too!

As soon as we reach a general consensus here, I’d like to kick this down to the BlueSky forum for general feedback. Outstanding issue remains the compatibility/legacy function part, I think, which would include supporting [( and {{.

Here’s some of my thoughts while reading this entire post:

Regarding the name of the manager: Control Panel? Content Manager? Hmm...how about Site Manager? After all, the term ’site’ could refer not just to the content but how the overall site works (both the front-end and back-end).

I like the idea of merging chunks and templates together; that makes a whole lot of sense...though I think it would be nice to have some sort of classification system for it. The idea is that when you create a new template you can define what kind of template it is: page, chunk, etc. We’ll need to think about what types we’d like. Now, this idea won’t really do anything other than making it easier for the user to select various templates. Templates could then be color-coded, sorted, and/or filtered based on type, thus making it much easier to manage templates all from one place.

The same could be said about snippets and plugins if they are merged. However, adding a classification for a snippet or plugin may not just be for sorting and stuff. It may go further to help the parser decide how to parse a particular piece of code. That way, if you decide to classify an entry as a "snippet" (or whatever name we want to call it!) then the parser could run it using whatever default event is used for that particular type.

So...now that I’m at the end of this post, I see this:



Hmm...I might need to sit on this for a few and brainstorm on how it might all fit together. I tend to lean more on the idea that chunks and templates belong together on their own as a way of defining logical "sections" for a given site. Again, there could be different types of templates for different reasons: page, chunk, tag, label, whatever....any any template could of course include a call to a plugin, content field, placeholder, or whatever from within any given template.

The main thing to think about in terms of where things go and what to call them is how a novice user would see it. Is a template really a plugin? Not really. I tend to think of templates the same way I think of macros...they’re just a way to encapsulate chunks of code or sets of commands into logical sections, whether it be for an entire page or just a little section on a sidebar. Not the sort of thing I would define as a "plugin".

I’m still unsure about what placeholders would really do...err...any clarification on that? The name, to me, would imply something similar to chunks but more dynamic. Heck, now that I think about it, the name "placeholder" could be another name for chunks altogether.

More thoughts to come as they gel. Heh heh!

I think we should stick with just "manager". It makes semantic, concise sense.

As discussed here and elsewere also, a chunk and a snippet really only differ in that one is executable/contains logic, the other is/does not. Take a peek at the table structures, which are almost identical if memory serves me correctly. They could be merged quite easily and could potentially eliminate significant DB query overhead. Set a checkbox to trigger the doc parser to execute the logic and we get the distinction back.

Likewise, a plugin differs from a snippet in that it can be attached to events. Same reasoning applies here.

And finally, templates would become simply a filtered view of the plugins... they really are nothing more than fancy chunks anyway. Templates in fact really don’t need to exist other than as an organizational paradigm, that might also happen to set some page defaults when applied to our content (mime-type, disposition, caching, page hits, etc.)...

It’s my opinion that a novice user will be able to grasp the one [[ calling method much more quickly than trying to figure out when to use [[, [!, or {{. Similarly, placeholders and site settings mergining elminates the potential for confusion/obscurity between [+ and [(.