Lingo-ology

The Future of MODx
MODx is an Internet Content Management Framework (CMF). This means it’s an extended web Content Management System (CMS) that developers use to quickly build custom websites and web applications.

MODx  includes support for the latest “Web 2.0” technologies and trends including AJAX (Asynchronous JAvascript exchange), tagging, blogging, RSS feeds, and robust Web Standards (i.e. XHTML/CSS layouts) support.

It’s “Manager” site administration system also works seamlessly in the “big three” browsers: IE Windows, FireFox and Safari.


The Core Concepts
Content
Anything part of the MODx experience when browsing sites is “content” — a web page, a Javascript file, a CSS file, Flash, a link to an offsite location, a downloadable file, an RSS feed and so on. 


Templates
Content is displayed through a template. Templates can apply to entire pages, or to just parts of pages (like “blocks” in other CMSes).


Widgets
This is the mojo that makes MODx a dynamic system for custom site and web application development. Widgets are little chunks or objects that serve a pretty specific purpose, and they come in two flavors: static and dynamic. Static widgets are non-changing HTML, XML, text, Javascript, CSS or  other similar content. Dynamic Widgets contain PHP code with logic, database calls, or pretty much anything you can dream up. Widgets are called by using the [[name-here]] convention or by listening to system events (covered in advanced technology, below).




Getting Started
Manager
This is the primary control center for all MODx content and configuration parameters. It works just fine, thank you, in Windows IE, Firefox, Safari and Opera. (Safari currently doesn’t work with “WYSIWYG” Rich Text Editors (RTEs), but there are no limitations in the ability to actually edit the content and configurations.)


Content Fields
This is where text, links or files are stored in MODx. There are no real limits  to the number of content fields per page in Tattoo/MODx. Content Fields can be simple text fields, WYSIWYG text editors for complex data entry (via Rich Text Editors, or RTEs), pop-up lists, radio button options, etc. Content Fields are called via the [*name-here*] convention, and “[*content*]” is an undeletable default Content Field for every page every page and cannot be deleted.


Links
Internal pages are linked together by referencing a unique ID number that is automatically assigned to each page. Links are called via [~ID~].




Intermediate Concepts
Templates
Designers and Developers assign Templates to Pages, and the Templates almost always contain one or more Content Fields and/or Widgets. Templates set defaults attributes for pages inside MODx, too. These attributes include things like:

• content type (text, html, pdf, xml, etc.)
• disposition (send to screen or initiate a download)
• meta-content (keywords, descriptions, tags, etc.)
• ability to search pages using the template
• ability to cache the pages using the template
• and so forth

Default attributes automatically apply to every page created with the Template, but can be overridden on a per-page basis. Pages can also be reset to their default attribute states.


Static Widgets
These are simply blocks of text, HTML or code that do not contain application logic. They can have parameters passed into them which are simply returned to the browser (think of these as sub-templates, if you will). Static Widgets are typically used multiple times in a site, for example a site footer or copyright line with links.




Advanced Technologies
Dynamic Widgets
These are blocks of PHP code with application logic. These can be used for simple things like conditional display of Static Widgets based on a user’s input in a form, or creating dynamic navigation menus as pages are added to a site.

(Note: please put on your propeller beanie here…) Dynamic Widgets can also be tied to specific system events used by the document parser. These events allow you to trap the default behavior of the system and alter it in some way. This is how the Rich Text Editors convert a text area into a RTE instance. This is also how you can override core system functionality without changing the core system code. An example here is synchronizing user logins between multiple disparate programs.

There are no feasible limits on the number or type of parameters usable by Widgets, and you pass them in with the [[widget? &param1=`foo` &param2=`bar`]] convention.


@bindings
(Note: pocket-protector required…) These are powerful ways to dynamically attach various data sources to the Content Fields. Content Fields contain a default value that can be overridden on a page-by-page basis as well as input options. @bindings can be applied at either location. @bindings currently work with text files stored on the filesystem, Widgets, Documents, database queries, and PHP code. Future @bindings will include RSS feeds, XML, SOAP, XML-HTTP requests and recursive @bindings.


Formatting Widgets
Formatting Widgets are specialized Dynamic Widgets that are applied directly to Content Fields. Think of them as 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 or button builders.


Placeholders
These are system resources that are generated on the fly by code (or by system configuration settings) to represent various pieces of data. Placeholders are useful for use in Static Widgets to separate the design of things like forms or pages, from the complex application logic used to construct the output. Placeholders are called via [+name-here+] and can have special modifiers to indicate different sources. For example, calling the main admin account email would be done by [+cms:site_email+].


Modules
These are packages of Templates, database structures, Widgets and Content that can perform functions like altering the way the core system behaves (can be as simple as a single file performing a very specific override to a manager API call with no interface) or as complex as a full-blown integration with a third party application.

Ok...based on what Ryan wrote up and what Raymond mentions, here’s what I’m seeing it as. I can live with the name "widgets". Makes sense if we separate templates and widgets in two different sections...even if templates and widgets are being shared within the core itself.

So perhaps the different sections in Resources could be this:

• Templates - Categorized by type to make it easier to differentiate a "page" template from other forms of templates
• Widgets - Dynamic and Static types (includes what was originally chunks, plugins, and snippets
• Content Fields - What was originally called Template Variables

We’d probably still need to think about what to call the existing "widgets" part of the Template Variables if we use the term "widgets" elsewhere. Hmm...more thoughts on this I’m sure.

The above is not definitive and might change based on what Raymond and I have been chatting about. We think we might be able to make the parser consist of one recursive preg_match (or whatever) on (even possibly nested!) [[ tags with a case statement inside based on the following syntax. This would allow for things like [[widget? &color=`[[*colors]]` ]] to work:



The following modifiers are what makes fair game sense to use:


The following don’t to me due to logic/code/html associations/implications:


The # is obviously used by QuickEdit, which needs to be considered in the switch handling, obviously.

Victor supplied some perl code that we could use for logic to match the [[ pairs.

here’s a tiny perl script, cut/paste this and run it from a terminal window. the array @match contains [[, [[*, [[%, whatever as individual elements

It will need some sort of dispatch method to handle the nested parameters, and I now know (but do not know what it means ) that for optimal speed, it sould not be done in a switch statment, but in a "function callback" according to Victor.

I s’pose I’ll point him over here to discuss this further.

Quote from: Bravado at Nov 10, 2005, 11:07 AM

We’d probably still need to think about what to call the existing "widgets" part of the Template Variables if we use the term "widgets" elsewhere.  Hmm...more thoughts on this I’m sure. 

That’s the formatting widgets part in the advanced technologies section.

And we do need a "MODx-legacy-translation/explanation", too. You’re right on there!

I just burned about 45 minutes on this and I’d like to offer up as my professional opinion that it’s fairly impossible to do a recursive parser as a single regexp. It certainly wasn’t from a lack of trying though

So in an non-single regex world, what’s the optimal way it, especially given how the manager/includes/document.parser.inc.php file handles it now starting around lines 846 and 886 (I think).

Taking for granted that there are not going to be issues with implmenting this in the parser, whether it takes one pass or multiple, anyone have other issues with the summary above?

Well...one thing I thought of that we can do before committing the summary as final is to create a sort-of wireframe diagram of the current structure of all parts of the CMS as it is viewed in the manager. We can start with one that illustrates how everything is organized as it appears now in 0.9.0 and create another based on the summary of how we want it to be along with the new names of everything. Regardless of how it will all work within the core of the code, I think a full illustration of this will help everyone developing it on clearly seeing how all the pieces will fit together. I’ll see if I can get a start on a diagram of how the manager is currently organized and the flow of all the parts and I’ll see if I can quickly put something together based on the summary of everything we’ve discussed here. I just think that a simple summary really doesn’t show much...but a clear wireframe diagram probably will. Just a thought.

The wireframe sounds cool Jeff

Re: Tags,

Well I guess we have to decide on whether or not we use the new tag format or stick with the old ones. After looking at it again I’m thinking the old ones are much clearer to identify within a page but it’s just that they will have to be parsed separately and will not be able to take advantage of the inline [!!] non-cache methods

Can we get some other ideas on this?