Really, the only thing missing IMO is..., so...

Ok, as I see a lack of understanding of the power and scope of object relational mapping and how it can help abstract data sources from both core and end-user defined elements in this framework, I'm going to wait for x3 release and then attempt to implement a working prototype of my vision to demonstrate the incredible ease of use we could bring to MODx web developers, webmasters and content authors with focus on this one feature.

I think once everyone sees what I'm talking about in action, you'll all agree that we can make available an incredible drag-and-drop enabled, simple form-based web content AND application management system (AMS??) with this one fairly simple addition. It would address all of the following areas:

- core (required and immutable) component data access abstraction: we could retrieve and store core data like content, snippets, etc. in any conceivable repository, be it relational DB, XML, text file or even Lotus Notes (laughing to self) [for the first iteration, I'm shooting for simply defining the abstraction layer and refactoring the existing MySQL code as a MySQL bridge with data providers for the core elements]

- external (user-defined) data access abstraction: we could do exactly the same for external data access to any potential repository; it would be best to provide the same object navigation capability at this level, as we do in the interface, to make API coding against it as easy as possible

- I18N and L10N: I can easily see placeholders using custom-defined objects to define/store/retrieve localised content in multiple languages and even encodings, using any technique conceivable; the objects are always the same to author, modify, or manage through a UI; a developer simply provides the data access methods for "gettin' her done" (e.g. you might have a gettext provider, or a simple delimited text file provider, or a DB provider)

- easy web content and application development: define your object taxonomy(ies) (including actions and/or events; just some of the things we could "attach" to these objects), build some templates using your defined objects (and actions), describing them in a very user-friendly format, and you've got a web site (or application)

- data aggregation (aka federated data): by chaining data access bridges and defining priorities, it is possible to aggregate data from multiple, disparate sources, to use in the framework (e.g. a phpBB user base + a corporate LDAP repository + a custom user profile table)

Essentially, by authoring different data access bridges for each repository we wanted to support, the abstracted objects used in the front-end of the framework and the back-end of the framework could be ported to any data platform imaginable. And, every platform's bridge could be optimized for that repository, without regards for platform incompatibilities with other chosen target implementations.

Add standard import/export capabilities for these objects, upgrades, component sharing, and other similar capabilities will be simplified immensely.

Enough talking; like xwisdom suggests, time to take action and show everyone how it would work!

Jason, this sounds really cool. As you said, though, it's just a bit on the uber-technical side for me to get by just reading about it. Perhaps we could arrange a MODx convention down here in Texas (yeeeeeee-haw!) and talk about this stuff face-to-face and see examples of how it'd work. If I get it then, I can then translate it into something that even the marketing interns could understand and appreciate.

Anyone up for meeting somewhere in Texas, say Dallas or Fort Worth? (I'd say elsewhere, but the wife, 18-month old and checkbook would protest too much after our recent move).

aw, shucks, so I guess Sapporo is out of the question then :?:

I will be interested in seeing this working, too, as I so far cannot see how this can be accomplished without destroying any backwards compatibility and having to completely rewrite the system. I'm also concerned about the performance hit vs what we gain as opposed to just having a straightforward API.

I'm definitely open to it, I'm just worried about performance. Especially as I deal in high traffic sites -- just one of my sites will do well over 40 million page views in a year -- and I have yet to see any ORM system be able to hold up under that kind of traffic without building static pages (which doesn't work for me).

I am very anxious to see it actually work, though!

Just an opinion.

I wonder if some kind of class/API couldn't be put together to provide backward compatibilty. OSX and VGS come to mind.

Redoing the whole system ..... ..... ..... hmmmm ...... urrrrrr ......

That is a good question! I am behind the idea of going with a industry leading compliance or even better yet forward looking compliance that would intice others to follow suit.

The end user experince should be similar at the very least with a better experience as our goal. However, I doubt if the end user would know the difference if the backend code were to be changed or not.