Making MODx truly Web20 friendly

As it is, the MODx "engine" does nothing to support Web20 and Ajax (not just fancy DOM scripting for local effects). It doesn’t do anything to get in the way, but neither does it acually offer any help. Ajax requests need to be made to stand-alone php files that have no access to the MODx class, unless you want to include the entire document.parser.class.inc.php file in every request processor file. And that is problematic because the class includes other files and paths become an issue. And including the parser class file includes all the logging, caching, TV and snippet and chunk processing, and user management methods, considerably bloating what gets loaded beyond what is needed. Even the DB api uses $modx-> class methods, so it can’t be used independently either.

This leaves the Ajax developer on his own; other than getting the initial document loaded he may as well not even be using MODx.

I am looking into developing an Ajax developer’s package that will be a parallel core with what is basically a picked-apart parser class file, broken up into several different class files that can be included into the Ajax request processor files as needed, and all stored in one standard location so paths won’t be an issue. It will contain a central server-side request handler, something like what is discussed in this article.

This is a great idea Susan. In fact Jason and I were just discussing breaking apart the parser for 0.9.2 but are a bit concerned about adequate testing time. Regardless, Jason’s 1.0 roadmap (and actual progress) already has this done in a way that might address everything you’re hoping for (I think it does in fact).

How long do you think this might take in the current document.parser? Any change this week for an 0.9.2?

I don’t think anything like that will be coming from me that quickly; I’m good for little stuff around the edges, but very nervous about messing around with the core! But I might surprise myself, we’ll see what I accomplish this week. I’m not looking at this from the inside out, as core modification, but from the outside in, as making it easier to do Ajax requests which are independent from document parsing. It will probably converge at some point, though.

Quote from: sottwell at Mar 25, 2006, 11:16 PM

As it is, the MODx "engine" does nothing to support Web20 and Ajax (not just fancy DOM scripting for local effects). It doesn’t do anything to get in the way, but neither does it acually offer any help. Ajax requests need to be made to stand-alone php files that have no access to the MODx class, unless you want to include the entire document.parser.class.inc.php file in every request processor file. And that is problematic because the class includes other files and paths become an issue. And including the parser class file includes all the logging, caching, TV and snippet and chunk processing, and user management methods, considerably bloating what gets loaded beyond what is needed. Even the DB api uses $modx-> class methods, so it can’t be used independently either.

This leaves the Ajax developer on his own; other than getting the initial document loaded he may as well not even be using MODx.

I am looking into developing an Ajax developer’s package that will be a parallel core with what is basically a picked-apart parser class file, broken up into several different class files that can be included into the Ajax request processor files as needed, and all stored in one standard location so paths won’t be an issue. It will contain a central server-side request handler, something like what is discussed in this article.

I absolutely disagree with this approach. The core is being completely modularized and slimmed down for 1.0 so only the required pieces are loaded on each request, and you’ll be able to use the $modx API independent of the parsing (i.e. use it in a standalone PHP page). Plus, there are already ways the engine can assist Web 2.0 development, and even more so in 1.0; for instance, you can generate JSON or XML responses as MODx documents now, and soon, you’ll be able to create a document that serves as an SOAP web service interface or an XMLHttpRequest broker. And I’m sure there is plenty more we can do to assist Web 2.0 developers from the core.

Indeed, I am in full agreement with that! And I certainly would much prefer to leave the core code to you professionals. I just wasn’t sure how long this is likely to take.

After experimenting with AJAX for a few weeks, I would definetely say that Web 2.0 is not something that need to be handled inside the framework, instead it’s more to the developers themselve in implementing it.

But providing a given set of library and best practices to build web 2.0 application on MODx will be great though. I believe that’s one of your talent as well Susan WHatever that you wrote is always easy to understand and get to the point.

Quote from: sottwell at Mar 26, 2006, 01:44 PM

I just wasn’t sure how long this is likely to take.

Not long I think; I’m working on the new core in parallel with finishing up 0.9.2 and hope to have a working prototype of the new core by next weekend. That doesn’t mean it will be feature complete (probably only about 50-60% complete in fact), but that the major core functionality will be operational and the new code ready to be reviewed, tested, abused, etc. After we get 0.9.2 out the door, I want to refocus the whole team on 1.0 tasks (i.e. skip 0.9.5), migrating existing components to use the new API’s, and authoring documentation for the new core framework. I’ll also be working on a proper developer’s guide to the new framework, along with a migration guide for legacy MODx developers, explaining what will and won’t work, and including tips and ideas for finding alternate solutions to unsupported legacy components (defined as one that directly accesses or depends on raw SQL that would be affected by the data structure changes required to support this new framework).