Lingo-ology

Want to revisit this again internally before we push it back out... lots of good stuff was said starting here about the complexity we’re experiencing in describing MODx/Tattoo. I’ll summarize where we might think about going here, then post a couple more thoughts that affect the table structures making a few more complex, but elliminating a lot. I also REALLY want to break any possible legacy associations with Eto... I think that could wind up imposing a too-limiting perception of what MODx/Tattoo is really capable of... not likely, but if it only does it for a few key individuals, then it’s too many!

Tattoo 101
Control Panel
Where you control content and configuration of the entire software install. Target for rewriting this without frames 0.9.5 before end of ’05.

Templates
The centerpiece of MODx around which most things associated with pages revolve. The central gatekeeper almost with the exception of special applications. We should move several items to be template-focused, rather than page-focused as it is currently. This could include things like content type/disposition, and default states for meta-content, searchable, cachable, etc. Defaults should be automatically inherrited by each new page, but should also be overridable on a per-page basis in an advanced settings tab for each page.

There also needs to be a simple and direct way for people to quickly create different types of content, like a shopping cart products page, a blog, etc. Do we need sub-templates, or content templates, or content settings?

Content
What end users interact with in Tattoo/MODx, typically a web page. This can also be a CSS file, a javascript include, downloadable document, etc.

[*Content Fields*]
You can have as few or as many content fields associated with a page in Tattoo/MODx as you’d like. They can be simple text fields, WYSIWYG text editors for complex data entry, pop-up lists, radio button options, etc. [*content*] is automatically defined for every page that is created in Tattoo/MODx.

Intermediate Tattoo
[[Plugins]] (Snippets + Chunks + Plugins)
Blocks of text, HTML or code that may contain application logic, that are typically reused multiple times in a site. These are "plugged into" a page when and where needed. For example, a Plugin can be the static footer on a website, or a dynamic block of code that generates the site navigation menu as pages are added, moved or removed. Plugins can also optionally be tied to specific events.

Plugins should have developer-defined controls such as the events that are applicable, a flag for being "static" HTML only (chunk), a flag for always being non-cachable (eliminates the "[!" calls), and other things to put more control in the hands of the developers, while making it less error-prone for new users.

We might even consider implementing an optional "structured" header format (most likely XML-like) that when copying/pasting snippets in and pressing the magic button, applies all these settings for end-users automatically (name, description, copyrights, events, etc). Other thoughts:

• I’d also like to see the configuration parameters header inlcude to set in an advanced Plugin insertion section
• categories for plugins (for easier organization on the now-snippet tab which could be tag-based in fact)
• a "show in menu" equivalent
• Consider an import from file upload button as a "mini-installer"

Widgets
Small extensions/behaviors that take a piece of text or data and transforms it into (typically) more complex elements with dynamic interaction. For example, Rich Text Editors, pop-up list input boxes, display grids, button builders, and more.

It might be really cool to use a way to define Widget behavior, and the recently introduced Front End Editing, with a modifier on content fields. That way they could even be chained. For example: [*content:editalbe,datagrid*]. This is similar in context to how scriptaculous handles chained effects.

Tattoo Grad School
[+Placeholders+]
Undefined system resources that are generated on the fly by code to represent various pieces of data. Need an easy to understand example here. This also could include Adam’s idea of mergin system settings to this as well.

Modules
Alter or extend the way the core system behaves across the board. Can be as simple as a single file performing a very spefic override to a manager API call (with no interface) or as complex as a full-blown application integration with an integrated management interface.

Here’s my take on this:

Control Panel should be called Content Manager (hence /manager)

Plugins -> Plugins

Chunks/Snippets -> Snippets

LOL... Raymond you were the one that originally suggested merging plugins with chunks/snippets!!! See here for a quick refresher.

I do think it makes sense even more so now. It’s simply extending the table a bit, or using an external event table when the "act on events" checkbox is checked. There’s otherwise lots of overlap between chunks/snippets/plugins.

I’m totally happy to live with Manager btw, it makes sense. Although you’re really managing more than just the content... it’s really the entire configuration that controls how the system and pages behave (hence "control panel"). Certanly no sticking point for me here though.

Regarding tempaltes... The more I think about it, the more I think merging them into the context of chunks as Adam suggested also makes sense. It would then allow us to call other templates as needed for little blocks of formatting for instance (as is frequently done with chunks+placeholders now), and templates would more or less become a categorized subset view of the available plugins. This would give us 4 different "contexts" for Plugins: static (chunk), dynamic/logic (snippet), formatting (template), event-dependent (plugins).

I also really want to get away from "snippets", as does Adam. I would say "great minds think alike", but that would be an insult to Adam!

Plugins are not snippet. Remember that I first started out with event driven snippets then you said separate them?

* Plugins (behaves like DLLs)
* Snippets (behaves like dynamic scripts)
* Templates (behaves like HTML)
* Modules (behaves like applications)
* Documents (aka content)

The way I see it. Templates and Chunks are virtually the same thing, they just need to be categorized differently to be user friendly. But that doesn’t mean we can’t combine them in the code.

I also see snippets and plugins as being very similar, more so that chunks and snippets are similar IMHO. Most snippets output content to the frontend, but not all (eg don’t log page hit, which should actually be converted to a plugin). Pluins can output content to the frontend but they can also output content to the manager or perform any other taks. In actuallity, we could just get rid of snippets altogether today, and convert all of the snippets to plugins. (it would be a pain in the neck for each plugin to replace it’s own snippet tag on render, but possbile).

So, what if we were to ditch snippets and add an onTagRender psuedo-event that is checked by default. The onTagRender would allow a plugin to output to the frontend the same way a normal snippet would.

What do you think?

Quote from: xwisdom at Nov 08, 2005, 09:18 AM

Plugins are not snippet. Remember that I first started out with event driven snippets then you said separate them?

Yep, I do recall, but that’s before I had my super-easy-to-understand explanation and interface to the combined concept.

* Plugins (behaves like DLLs)

Not everyone lives in a MS world. And many that do don’t even know what the heck DLLs are! lol

Quote from: aNoble at Nov 08, 2005, 09:27 AM

The way I see it. Templates and Chunks are virtually the same thing, they just need to be categorized differently to be user friendly. But that doesn’t mean we can’t combine them in the code.

100% agreement here.

I also see snippets and plugins as being very similar, more so that chunks and snippets are similar IMHO. Most snippets output content to the frontend, but not all (eg don’t log page hit, which should actually be converted to a plugin).

It’s now a checkbox on each page... no longer need the plugin/snippet, right Raymond?

Pluins can output content to the frontend but they can also output content to the manager or perform any other taks. In actuallity, we could just get rid of snippets altogether today, and convert all of the snippets to plugins. (it would be a pain in the neck for each plugin to replace it’s own snippet tag on render, but possbile).

So, what if we were to ditch snippets and add an onTagRender psuedo-event that is checked by default. The onTagRender would allow a plugin to output to the frontend the same way a normal snippet would.

What do you think?

I’m not totally clear on how this would impact things, but I’m all for reducing queries and parser passes given the opportunity.

It’s all posible but not an easy tasks consider that we already have an installation base of over 5000+ (I should think). So we would have to test to make sure that it works.

This I think we will should vote for.

Who’s for merging Snippets, Chunk and plugins? This will make plugins function the same way a snippet does but also be able to work with existing events.

example:

PHP based plugins
[[MyPlugin? &color=`red`]] - This would invoke the OnWebPageTagRender event

PHP based plugins when used inside the manager
[[MyManagerPlugin? &color=`red`]] - This would invoke the OnManagerPageTagRender event. This also means that plugins/snippets/etc can be used inside the manager theme (skin, etc).

HTML based plugins
[[MyHTML? &color=`red`]] - This plugin would not have any events. it would functions as a chunk that supports parameters.

Quote from: xwisdom at Nov 08, 2005, 09:53 AM

It’s all posible but not an easy tasks consider that we already have an installation base of over 5000+ (I should think). So we would have to test to make sure that it works.

The right thing is not always easy, or pain free at first. However the longer we let the wrong way go, the harder it gets to make it right later.

This I think we will should vote for.

Who’s for merging Snippets, Chunk and plugins? This will make plugins function the same way a snippet does but also be able to work with existing events.

Given the above statement, much less my persistent "less is more" mantra, I think you know my vote! (100% in favor)

example:

PHP based plugins
[[MyPlugin? &color=`red`]] - This would invoke the OnWebPageTagRender event

PHP based plugins when used inside the manager
[[MyManagerPlugin? &color=`red`]] - This would invoke the OnManagerPageTagRender event. This also means that plugins/snippets/etc can be used inside the manager theme (skin, etc).

HTML based plugins
[[MyHTML? &color=`red`]] - This plugin would not have any events. it would functions as a chunk that supports parameters.

Sounds very cool to me, espcially the chunk with passable paramters. These should be able to take placeholders as a parameter I think, btw.