OK, time for a marathon post... but one with substantial implications on MODx’s future. Please keep all discussions of this (project BlueWater) underwraps, particularly the implmentation details. Once we get a good solid gut check that this is going to be the future, we’ll pitch the non-implmentation details to the public side of the forums.
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 And XML), 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
Templates are the lens through which users see your Content. Templates can apply to entire pages, or to just parts of pages (like “blocks” in other CMSes).
Widgets
Widgets make MODx a dynamic system for custom website and web application development. Widgets are little chunks or objects that serve a specific purpose. 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 virtually anything you imagine.
Getting Started
Manager
The Manager serves as the command-and-control center for all MODx content and configuration parameters. It also works well in most modern browsers including Windows IE, Firefox, Safari and Opera. (Safari currently doesn’t render “WYSIWYG” Rich Text Editors (RTEs). However, there are no limitations Safari’s ability to actually edit content and configurations, as it falls back to a regular text area and source code for RTE instances.)
Content Fields
This is where "blocks" of text, links or files are stored in MODx. MODx also has no feasible limits on the number of Content Fields per page. Content Fields can be simple text fields, WYSIWYG editors for complex data entry (via Rich Text Editors, or RTEs), pop-up lists, radio button options, etc.
Links
MODx pages are identified by an automatically assigned unique ID number. You can link pages together in the system by referencing this ID number in HTML <a href> tags.
Intermediate Concepts
Templates
In addition to containing the Content Fields and serving as a "page lens", Templates also set defaults attributes for pages inside MODx. These attributes control how the page is presented to users, 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
- default user group and access settings
- 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
MODx refers to blocks of text, HTML or code that do not contain application logic as Static Widgets. As with all Widgets, they can have parameters passed into them which are simply returned to the browser (as opposed to Dynamic Widgets which can use and/or manipulate passed in parameters programatically). Designers and developers typically use Static Widgets multiple times in a site, for example a site footer or copyright line with links.
Advanced Technologies
Dynamic Widgets
MODx refers to blocks of PHP code with application logic as Dynamic Widgets. Dynamic Widgets can be simple or quite complex; for example, they could simply conditionally display a value based on a user’s input in a form. A more complex example would be the dynamic menu-building code that is used to build navigation bars and site maps, and automatically updates when a developer adds pages to a site.
In their most complex form, developers tie Dynamic Widgets to specific system events used by the MODx document parser. Events allow you to alter the default behavior of the system. This is how the Rich Text Editors convert a text area into a RTE instance. This is also how Developers override core system functionality without changing the core system code (e.g., synchronizing user logins between MODx and a Forum software).
@bindings
@Bindings provide powerful ways to dynamically attach dynamic data sources to Content Fields. Developers use @bindings as either a default value for the Content Field or as an Input source. @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 directly alter the output of 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 (e.g., Rich Text Editors, pop-up list input boxes, display grids or button builders). @Bingings when used with Formatting Widgets make a powerful combination that makes it possible for Developers to create complex application functionality in a very short time.
Placeholders
Placeholders are dynamically declared variables (or system configuration settings) used when building custom web application functionality. Placeholders while quite simple in context make it much easier to create a bettter separation between the design and the logic of a custom application.
Modules
MODx refers to packages of Templates, database structures, Widgets and Content as Modules. Modules can provide simple functionality like altering the way the core system behaves, or as comprehensive integration with a third-party application.
Implementing it all
The above descriptions are not definitive as of yet, but we would really appreciate any feedback you may have. We hope be able to make the parser consist of one recursive preg_match (or whatever) on nestable [[ tags with a separate pass for non-cached objects. This would allow for things like [[widget? &color=`[*colors*]` &foo=`[[blah? &bar=`[[blahblah]]` ]]` ]] to work, which is currently impossible in MODx.
We also hope to optimize the performance and flexibility of the document parser via fewer loops, and using function callbacks vs. case/switch statements. It would ultimately hopefully provide for:
- all objects being cachable or non-cachable (currently only snippets are non-cachable)
- all objects being nestable
MODX Staff
