Lingo-ology

Quote from: rthrash at Nov 09, 2005, 07:33 AM

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 {{.

I see no problem here, it’s just a matter of providing an additional parsing level (hopefully through plugins) for each legacy support issue. E.g. add prefix config_ to all things like [(site_start)] so they become [+config_site_start+] and then have a plugin translate all the old tags to the new ones?

Exactly Jason.

Quote from: rthrash at Nov 09, 2005, 12:02 PM

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 [(.

Agreed Ryan; to me, plugins are really just a type of template; we could call them all LEGO pieces if you want, but it’s still just a building block for the site no matter how it is implemented into the site, and their are many types of blocks (template, chunk, snippet, plugin, and maybe more later, who knows).

This simplifies the templating language of our CMS for users when creating dynamic sites, and that’s good!

BTW, are we still going to support a run-time marker for cached vs. uncached calls? [! !] ?

I think as much as possible we need to try to separate what we should do (as coders) with MODx and what makes sense to newbie.

Let’s focus first on doing the right thing as far as the code is concerned. As long as we build enough flexibility into it we can make the interface anyway we want. The end users don’t have to know that Templates are actually plugins or anythnig else we don’t want them to know. Not only does the interface not HAVE to reflect the underlying code structure, I don’t think it should.

This is a very common problem with programming in general, you need to separate your presentation from your code not just physically but mentally.

Quote from: OpenGeek at Nov 09, 2005, 12:21 PM

...we could call them all LEGO pieces if you want, but it’s still just a building block for the site no matter how it is implemented into the site, and their are many types of blocks (template, chunk, snippet, plugin, and maybe more later, who knows).

This simplifies the templating language of our CMS for users when creating dynamic sites, and that’s good!

Hmm...blocks....perhaps that could be the name of the section: "Blocks" You could have a "Blocks Library" as sort of a repository for unused templates, chunks, snippets, plugins and such...just a nice way to hide unused items from view...which is more or less the same thing you do when you disable a plugin. One thing I will say, if we are going to pull it all together into one place I really think there needs to be a couple of different ways to sort and filter the different types of "blocks". Color coding of the names helps. And the ability to show only certain types of "blocks" would be important too.

From a parser point of view, if pulling templates, chunk, snippets, plugins, and whatnot makes it easier and faster for the parser then I’m all for it. And eliminating some of the sections under "Managing Resources" would be good and will cutdown on confusion for sure. Looking at that section now, I can envision the "Meta Keywords" section being a plugin and going elsewhere. That way just about everything would be encapsulated onto one page...and without the need for tabs since everything could be filtered down anyways with simple dropdown menus. Not sure if "Managing Modules" would need to go in there too....might wanna think about that.

So...on that note, how about we call them "blocks" and change the menu name to "Managing Blocks" instead?

I’m not a big fan of "blocks." To me a block is a sidebar area like the we have to the right of the forums here. And people coming from a *Nuke background will think the same thing. We could call them "Building Blocks" maybe and then use "Blocks" for short. That would probably clear up any confusion.

But I don’t like resources either. Personally I think I prefer "Components."

I could live with Components, or just Templates myself, but am definitely not a fan of calling them blocks.

"Components" is good. And, yeah, perhaps the term "blocks" would really refer to something else. So the name could possibly be "Manage Components" which probably fits the description a bit better since any given plugin, template, chunk, snippet, or the like is really more or less a "component" of the CMS itself. Good call!

Quote from: Bravado at Nov 09, 2005, 02:09 PM

So the name could possibly be "Manage Components"

Manage Components

Let’s get rid of all of the Manage prefixes in the Manager. It’s the Manager we know we’re managing.

Personally I think that:

• Components
• Users
• Modules

Reads much better than:

• Manage Components
• Manage Users
• Manage Modules

P.S. Not jumping on your or anything Jeff, just saw a chance to make a point

Hey, no offense taken! I agree completely! The shorter, the better when it comes to menu names.