Proposed MODx 1.0 RoadMap and Initial Progress

FYI, it’s been quiet here, but I’ve been hard at work experimenting with a few ideas on reorganizing the core and I think I have 25-30% of the implementation work done on the following roadmap, which I am proposing for MODx 1.0 release.

• Light Object Model, compatible with PHP 4 and 5 -- This will make it possible to write components against the core without writing SQL, making it possible to utilize alternate database platforms, load the MODx API in external PHP scripts, and more... Other features include single-table class-inheritance, full table metadata access, and even run-time extendable classes.
• modDataService: PDO for MODx -- including native PDO support and PHP 4.x and 5.0.x emulation; this will replace the DBAPI, which can be refactored to utilize the new PDO services where possible, and loaded as an optional extension for backwards compatibility. Features include prepared statements for DB-server-side caching of common SQL statements, encourages SQL that is SQL-injection proof, is very lightweight, and is the standard in PHP 5.1+ for data access.
• modContext: Multi-Sites, Sub-Sites, and much more! -- With the introduction of contexts, you can override any MODx system configuration setting, in much the same way that a user setting can override a system setting now. Features will include referencing system settings in your context setting values, and uses can range from subdomain contexts, to culture-specific contexts, to usergroup-specific contexts, to application sub-contexts, or even traditional php contexts, where PHP files could be used and take advantage of the framework’s object model without the parser overhead.
• modRevision: Content Revisioning -- All content, which will be represented by the class modElement or any extension of that class, will feature multiple revisions, which can be utilized for rollback or publishing workflow features
• modCulture: Content Localization -- All content revisions can further be overridden by a specified culture, falling back to default content defined for the site
• modLexicon: Content Internationalization Extensions -- Advanced words and phrase services to allow simple but powerful i18n components and sites to be constructed with a minimum of effort. This lexicon will replace the traditional language files and can also serve to assist in dictionary- or glossary-building, auto-linking, and more.
• modParser: Simplified Tag format and new Recursive Tag Parser -- New unified tag format with full nested tag support and simplified parsing algorithm based on modElement class structure.
• modResource: -- Documents, Weblinks, web services, AJAX services, and more; anything you can think of to access via a URI/URL
• modElement: -- Simply any type of content that makes up a modResource. From templates to template vars to modules, to snippets, to plugins, they will all be derivations of the all powerful modElement class.
• modRegistry: -- A set of message queues can serve for any kind of logging (debug, audit, error, stats, monitoring, etc.), persistent message storage, synchronous message passing across requests, sessions, contexts, or even sites (if combined with a modResource web service that could provide access to the registers from trusted remote sites).
• No eval() snippet/plugin execution -- Snippets and other components that have required eval() will now be written to a script cache as a function, and included rather than eval()’d; this is for security concerns as well as increasing performance, especially in PHP 5 platforms, where eval() can be up to 28x slower in some instances where it is called repetitively.

Those of you with access to the SVN branches can see the progress on the new core code that will provide all the above and more I just don’t have time to write down, at http://svn1.cvsdude.org/rethrash/tattoo/tattoo/branches/jason-dev/trunk/core/

Also, I’ll be adding tasks to Flyspray this weekend based on this for the 1.0 RoadMap to be reflected there, so please provide whatever feedback you can, voice what questions and concerns you may have about any of these points, and prepare to help me simplify and extend the core of MODx to become the premiere Web 2.0 Content Management and Application Framework.

Is that all?



I’m so looking forward to this!

Awesome! Normally I’d say "That sounds great. I especially like _____." but I especially like it all.

And thanks for the clear explanation, everything seems to make sense. Most of the questions floating around in my mind is how to make it all work from the UI side but we can cross that road when we get to it.

Keep up the good work man!

A couple of more I neglected to include in the original post:

• modUser / modUserProfile / modUserGroup / modRole: Identity Services -- Simplified user model, that is easily extensible via the new lightweight object model, which will include easy ways to dynamically extend any core class without hacking any core code or worrying about future updates to the user model. Simply design a class extension of modUser, register it in your core configuration, and the core will use your extended class definition, overriding whatever functionality or adding whatever custom data columns you want to persist.
• Enhanced Access Control -- Still reviewing the best options here; may stick with the existing structures for now and try and plan migration to a more standard ACL-style security model post-1.0; more on this soon, but let me know if you have any thoughts here that might coincide with the refactoring work going on in the rest of the 1.0 roadmap. I’m leaning towards a security model using a modAccess class extended from modElement that can be attached to (or called via the API from) any modResource, or any other modElement object. IOW, you could attach a single or multiple access elements to a page, a template, a TV, a snippet, a plugin, or a chunk; or even build and call an access element from your snippets/plugins.

This sounds AWESOME Jason!

Very good move here Jason.

It’s good to see that you’ve choosen to take the PDO approach to data access. Some of the ideas raised here are similar to the ones I have for GreenCore. While I haven’t had time to finalize it yet I’ll check you what you’re doing thus far.

Is this the model for Tattoo or MODx?

Just a quick 1.0 progress update for the team:

[*] I have a 1.0 roadmap ready and a copy is attached to this post. I have included an estimated percentage complete on each bullet point for reference.
[*] I have now successfully implemented several projects using XPDO, both for managing a custom database application, and for managing MODx 0.9.x data via an OO API. I am currently merging the latest changes to XPDO based on these experiences into the existing 1.0 code I have completed.
[*] I am also working on a schema for generating a complete OO API with XPDO for the current MODx trunk. This will allow 0.9.x users to start using XPDO and becoming familiar with the common API functions and dealing with PHP objects while 1.0 is being completed. Look for a proof of concept example of this, hopefully later today or tomorrow.

Also, I will be ready in the next week or two to start building the new manager interfaces for 1.0. These will be developed from scratch as stand-alone PHP pages that can utilize any part of the MODx 1.0 core, unlike the current MODx manager. Anyone on the team that is interested in contributing to this part of the 1.0 effort, please contact me.

Otherwise, please review this and reply back with any questions, concerns, or suggestions. Ryan is in the process of turning this into a less developer-oriented document for public consumption.

Here’s the initial preliminary overview draft.

Very nice overview, Ryan

Just a few typos to report: ’Web Serivices’ and ’Placehoders’

One question about the overview and the roadmap: Which part of the roadmap covers the resource element maps? I’ve been looking over bits of the new core to get a feel for it and want to make sure I can place all the different elements.

Great work guys!