MODx Application Framework. The AJAX Part..

Hello MODx Community

I’m wondering if there is a unified way to build AJAX Applications using MODx? Sure, you can cook your own soup, using either prototype, mootools or whatnot and then build a server application for you needs.
However, i’m quite sure that this will turn into a huge mess in no time without a unified way of doing things. Imagine a snippet using mootools, another one using prototype (on the same page). One developer uses the index-ajax.php, another one his own implementation... not exactly a application framework is it?
Are there plans to unify these sort of things for a future release of MODx? Sort of a solid base - that makes sure of data exchange, security, client-framework - to build AJAX Applications on top?
Personally i like the way how XAJAX handles stuff. That’s just my personal taste though, but it really helps to build ajax driven applications without starting from scratche every time.

What do you think?
-- banal

MODx doesn’t force anything. Common sense though definitely dictates you’ll have better luck picking a front-end JS Lib and sticking with that. Picking Mootools now avoids conflicts with QuickEdit if you use that.

I’ll let someone else comment on index-ajax (up to 0.9.6.1p1) vs including the main index file (coming in 0962) vs rolling your own (and XAJAX).

Quote from: rthrash at Feb 01, 2008, 08:20 AM

MODx doesn’t force anything. Common sense though definitely dictates you’ll have better luck picking a front-end JS Lib and sticking with that. Picking Mootools now avoids conflicts with QuickEdit if you use that.

Well yeah. It has its benefits if you’re not forced to do things in a fixed manner. I just wonder if it will turn out well in the long run. I’m not talking about sticking to a JS Lib myself, i have no problems with that. I’m talking about the community as a whole. If there are so many different Snippet/Module/Plugin Developers, different Coding styles and practices and, well, different JS Libs, you’ll run into troubles sooner or later (incompatible snippets etc)...

Ah, so what you’re really asking in a way is if we’re going to turn MODx into YAPS (Yet Another Portal Solution). The answer there is unquestionably "NO!".

MODx was started so developers can explicitly control every aspect of their sites with ease (starting by the need for clean XHTML/CSS site without having to hack the core to death), and to maintain an upgrade path. Limiting choices as critical as an Ajax Library is an area that simply shouldn’t be dictated in our mind by a web developer’s framework of choice. Clearly there’s best practices to encourage, but not on that front I don’t think.

Quote from: rthrash at Feb 01, 2008, 08:40 AM

Ah, so what you’re really asking in a way is if we’re going to turn MODx into YAPS (Yet Another Portal Solution). The answer there is unquestionably "NO!".

I think this topic has merit without creating YAPS. I’ve bounce from overlib, to prototype now to mootools partly due to my lack of javascript knowledge and partly to stay in sync with the MODx dev team. I recently needed an interactive calendar on a customer’s site. I’m still early in my javascript learning curve so I searched through the existing MODx resources and found a few candidates including CALx which did exactly what I needed. As I check it out I find it uses overlib.js, not mootools, so off I go to recreate what has already been created because my pages already use mootools in the header and footer. I’ve seen the conflict on my own sites when I try to mix javscript libraries on the same page. Javascript functions become unpredictable. In my mind there are a whole series of MODx resources that I can’t use because of the potential javascript conflict.

That’s the "dark side" of a truly open solution. No limits can also mean that one man’s solution may conflict with another’s. But the philosophy here is that it’s worth that possibility (probability?) to have the option to have your own solution in the first place.

Quote from: Chuck at Feb 01, 2008, 09:09 AM

I’ve bounce from overlib, to prototype now to mootools partly due to my lack of javascript knowledge and partly to stay in sync with the MODx dev team.

Your desire to stay in sync with the dev team is simply a result of leftover dependencies on a specific library in the manager interface being used by add-ons meant to run on the site front-end, then further clouded by those add-ons being included in the sample site. These dependencies were incidental and not a best practice by any means, but simply part of the early growth of the community. And though I can’t say the choices the core team has made on which javascript library to employ for the "default" manager interface moving forward do not affect choice made when designing and deploying a MODx site, they should in no way limit the potential of the site to use whatever library is needed for a particular feature, possibly only on a single page.

Quote from: Chuck at Feb 01, 2008, 09:09 AM

I recently needed an interactive calendar on a customer’s site. I’m still early in my javascript learning curve so I searched through the existing MODx resources and found a few candidates including CALx which did exactly what I needed. As I check it out I find it uses overlib.js, not mootools, so off I go to recreate what has already been created because my pages already use mootools in the header and footer. I’ve seen the conflict on my own sites when I try to mix javscript libraries on the same page. Javascript functions become unpredictable. In my mind there are a whole series of MODx resources that I can’t use because of the potential javascript conflict.

But part of your selection of add-ons should be based on the requirements you have for javascript library interaction. Just because the only currently available add-ons contributed to the repository depend on specific libraries that conflict with other choices you’ve made in your site development, and you are left with the problem of having to develop a solution that does meet your requirements due to those conflicts, does not mean that MODx is not doing it’s job as a framework. Remember, this is first and foremost a CMS and PHP application framework, not a CMS and javascript application framework. And though we are certainly willing to explore ways to better take advantage of any standards that are established in the AJAX/PHP world, those will have to exist before we can.

I envision at some point, if we continue to attract users that contribute code back to the project, there will be sets of components that use specific AJAX libraries and cover a wide-variety of features. I simply do not see a way that these issues can be resolved at this time without forcing all MODx developers into using a single AJAX solution, which, as Ryan said in not so many words, we will not do.

Quote from: rthrash at Feb 01, 2008, 08:40 AM

Ah, so what you’re really asking in a way is if we’re going to turn MODx into YAPS (Yet Another Portal Solution). The answer there is unquestionably "NO!".

Hm. No, i’m not talking about turning MODx into another Portal Solution. Not at all... i’m just talking about extending the "Application Framework" approach for AJAX driven sites. I mean: You already have a DB wrapper, Plugins, Snippets and several other (sort of) "middleware" components integrated into MODx, why not implement something like this for ajax? Something that allows the community to build stable and secure AJAX driven sites using the MODx Framework without too much of a hassle. Not that they can’t do it on their own way, more that MODx offers a solid base to use if they choose to do so. Much like the DB-Wrapper. You can use it if you want but you’re not forced to do so at all... it just handles some stuff for you and probably makes your code more portable (for example if MODx would be ported to another DB like Postgres or similar).

Quote from: OpenGeek at Feb 01, 2008, 09:34 AM

I envision at some point, if we continue to attract users that contribute code back to the project, there will be sets of components that use specific AJAX libraries and cover a wide-variety of features. I simply do not see a way that these issues can be resolved at this time without forcing all MODx developers into using a single AJAX solution, which, as Ryan said in not so many words, we will not do.

Thanks OpenGeek! I had a similar thought after I posted this morning. Categories of contributions that take embedded technology into consideration. My support of the OP’s position was based on a my own learning experience with MODx. Please continue to resist the YAPS temptations!

I came to MODx from the e107 world and can appreciate all the flexibility that MODx is designed to offer. My frustrations with hacking away at e107 core code vanished when I adopted the MODx way. My focus has been on creating new code and not fixing somebody else’s code to do what I need. I’m just not where I want to be yet from a coding skills perspective and for the time being rely on the contributions of others until I can become coding independent.

MODx inherent flexibility has made me a better web site designer. I don’t want to go back to the one-size-fits-all world of other CMS projects and will contribute to MODx community as best I can. MODx is one of the few open source projects that I put my money where my mouth is and made a small monetary contribution last year. I hope others in the community realize the jewel that MODx is and contribute in the best ways they can too.

Stay the course!