Design Patterns and the new MODx core

FYI, I just published a blog article (something I do way too infrequently) on the motivations and implications of the new MODx core. It focuses on how my experience with design patterns has helped transform MODx into a true object-oriented (OO), Model-View-Controller (MVC) framework, and what that means from an architectural point-of-view. This marks the first in a series of articles I’ll publish this month with the intention of helping everyone feel more comfortable with the upcoming changes.

Transforming MODx: Tales of OO, MVC, and O/RM

Cheers, and feel free to let me know what you think...

Jason

Thank you for giving us this insight OpenGeek. I’m so looking forward to see the new core in action

I can’t say I understood it all, but this will certainly be another pulling point for those folks who want OO or nothing (I unfortunately know of a few).

It does sound like it will make it that much more easier to build from and a lot more powerful to boot, so good work!

Quote from: OpenGeek at Dec 15, 2006, 02:49 PM

FYI, I just published a blog article (something I do way too infrequently) on the motivations and implications of the new MODx core. It focuses on how my experience with design patterns has helped transform MODx into a true object-oriented (OO), Model-View-Controller (MVC) framework, and what that means from an architectural point-of-view. This marks the first in a series of articles I’ll publish this month with the intention of helping everyone feel more comfortable with the upcoming changes.

Transforming MODx: Tales of OO, MVC, and O/RM

Cheers, and feel free to let me know what you think...

Jason

Great stuff, Jason. Anyway, will be the 1.0 version built upon this new core? And, if yes, when do we have to expect it will be beta-released?

Quote from: madmage at Dec 17, 2006, 10:31 AM

Great stuff, Jason. Anyway, will be the 1.0 version built upon this new core? And, if yes, when do we have to expect it will be beta-released?

More on this soon, but just to share my current plans...

Both the upcoming 0.9.7 and 1.0 releases are built on an xPDO-generated and xPDO-powered core. 0.9.7 is essentially 0.9.5 rewritten using xPDO, but without the significant database structure changes required to support some of the more advanced 1.0 features. This allows the legacy content manager interfaces and add-ons to work on top of the new core with little or no modification. In this sense, 0.9.7 will be a stepping-stone release which introduces the object-oriented API without changing any of the data structures or major features, allowing adopters to become familiar with the new core engine and coding style before being submerged into a world of strange new tables and classes like Revisions, Cultures, ResourceElements, AccessControls, Subjects, and Predicates, all of which will be part of the 1.0 transformation.

Current Rough Timelines:
[*] Release 0.9.7-alpha sometime between Christmas and New Years
[*] Complete 0.9.7-final development and testing cycles and release Q1 2007
[*] Around the same time there will be MODx 1.0.0-alpha release--FRAMEWORK ONLY (i.e. no content manager interface or add-ons included; primarily for add-on developers to get a head start, or to be used as a stand-alone framework)

Jason,

a phrase in your article caught my attention: you don’t have to write SQL code, the framework takes care of this. This seems to resembles the remarks Sean Kelly made in his famous screencasts about Plone. In "Better web apps" (http://oodt.jpl.nasa.gov/better-web-app.mov) he explores several web application frame works, like J2EE (Java based, duh), Plone (Python), TurboGears (Python), Django (Python) and Ruby on Rails (well... Ruby). He states in this video that the model should create the necessary SQL code, not an error prone human being.

Do you know this screencast? Is xPDO build on the same philosophy? And more in general, I am curious how the Tattoo release would stand up against these before mentioned frameworks...

Anyway, I think xPDO is very nice, so thank you for your article and the good work. I am looking forward to your next articles!


Bee

I might be wrong there but my interpretation is that basically what will be possible with the new MODx core will essentially be what already is in the dbAPI but taking advantage of PDO through xPDO.

Let me quote php.net about PDO :

PDO provides a data-access abstraction layer, which means that, regardless of which database you’re using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn’t rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility.

See : http://php.net/pdo

That would mean one of the primary benefits will be to be able to connect to a variety of databases (MySQL, PostGreSQL, Oracle...).
Now is xPDO a full-blown abstraction layer, Jason ?

Seems like this page answers the question I asked plus many others :
http://xpdo.org/development.html

NOTE: Link edited to use alias on actual http://xpdo.org/ site; trac site link is temporary and will be shut down very soon.

Quote from: BeeStar at Dec 17, 2006, 12:41 PM

a phrase in your article caught my attention: you don’t have to write SQL code, the framework takes care of this. This seems to resembles the remarks Sean Kelly made in his famous screencasts about Plone. In "Better web apps" (http://oodt.jpl.nasa.gov/better-web-app.mov) he explores several web application frame works, like J2EE (Java based, duh), Plone (Python), TurboGears (Python), Django (Python) and Ruby on Rails (well... Ruby). He states in this video that the model should create the necessary SQL code, not an error prone human being.

Do you know this screencast? Is xPDO build on the same philosophy? And more in general, I am curious how the Tattoo release would stand up against these before mentioned frameworks...

Have not seen that before; thanks for calling my attention to it.

I do not share the same philosophy that he does for sure, especially regarding machine-generated SQL being better than SQL authored by human beings. Consider the humans programmed the logic of the machine-generation, well, anyway, I won’t go there. In fact xPDO assumes that there is no practical automated way to generate SQL for every platform and SQL dialect in every persistence situation. That’s like building a content management system that meets every requirement for everyone. As described on my xPDO home page, it is not a SQL abstraction layer for this very reason. Instead, it is a SQL optimization layer, where you can use the generic SQL scaffolding when it makes sense, but still override any functionality, including basic CRUD operations, by simply providing your own implementation of a specific function (e.g. save() or load()) for a specific database platform.

Essentially, it will ease the pain of porting and tuning applications to specific platforms.

Without going into the arguments of machine-generating SQL or otherwise, I just wanted to add my support to the ModX devs for not only providing a cracking CMS from the user perspective, but one that is taking the core seriously and designing for the future. I’ve spent a lot of time working with several .Net based Open Source CMS (I’ll leave you to guess). They are all light years behind ModX in terms of providing a stable, user friendly solution which is capable of outputting accessible and validating XHTML. There are a few things I would love to see in ModX like revision management and document authorisation workflow but I can see from the description of 1.0 above that these things are not far away. Fantastic Stuff!