Can one MODX rule them all?

I know MODX is here to stay, it's the confusion about what is happening with the manager side of things. Is Revo staying with extJS or is jQuery being considered? jQuery is dom manipulation and is limited so I can't see it being able to achieve the level required for CMPs.

I think what spooked clients is the change in direction and seeing the bugs area not being answered as often. For me being a partner, I'm also getting confused at another change of direction in 12 months. I think what needs to happen is a solid, clear cut road map and don't change course when something doesn't work right away.

I think Revo is the way forward as I've spent a lot of time with it now... I used Evo for longer but extJS and CMPs totally sunk Evo for me. I understand why non-programmers prefer Evo or those not wanting to get their hands dirty with coding but it seems that having 2 branches isn't helping things.

I'd be in favour of breaking the 2 apart completely cos generally you're either an Evo or Revo user. It's not often both, especially if you're dealing with larger clients. Of course, this is my opinion.

[ed. note: rossco last edited this post 14 years, 5 months ago.]

A few things:

MODX will, for the time being, be using ExtJS in its default manager theme. It doesn't make sense to quickly shift to another framework, for reasons I'll outline below. Currently, the decision is to stay on Ext3 until we reach MODX 3.0, in which we will re-evaluate and most likely move to Ext4 at that point. There are a few reasons for this:

- We don't want to move too quickly to Ext4, as it would completely break Ext3 CMPs (yes, I know there is a compatibility layer, but trust me, it isn't plug-and-play, and requires modifications to code to get it to work; I tried getting it in back a year ago). We don't want to cause all Extras that have CMPs to break in a patch release, or a minor release, for that matter. We'd like to make that change on a release where things are likely to break anyway (major releases, ie, 2.2-3.0, 3.1-4.0, etc). When we do move to Ext4, it will offer us cleaner code generation and on-demand loading of JS files (this means: faster)

- This means that we're on Ext3 for now. This is mainly for continuity - we decided that it's better to allow people time to learn the system rather than changing it too soon and scaring away adopters. Is it perfect? Far from it. Is it a foundation to build on? Yes.

Now, for those who say that Ext is bloated and slow, I have a few questions: One, have you tried 2.2 with compression on? It's actually quite fast - initial page loads (not the store/tree loading that occurs after page load and usage). Secondly, yes, it is slower than Evo's page loads. I agree 100%. The reason is this:

In Evo, it is incredibly difficult to build as rich and as powerful a UI as you can in Revo. In Revo you could build a ajax grid with pagination, searchability, drag/drop, window connection (New Chunk, for example), automatic field validation, and inline editing. All in less than 200 lines of code. That is flat out impossible to do in Evo. Not to mention, in Revo, these tools are automatically available to you in the default manager theme. You can create powerful UX for your Extras instantly, if you take the small amount of time to do so. Could there be more tutorials to do so? Absolutely, and there will be eventually, as more people get involved.

In Evo, however, you have no such toolkit at your disposal. You have Mootools, which is a very limited framework. You have to build any sort of rich UI from scratch. Which means that building anything beyond a simple marketing site is *very* difficult in Evo. I can say this with experience - I helped deploy the College of Education at UT-Austin onto MODX Evo prior to me starting to work at MODX. They had 4000+ pages, lots of custom data, and more. It was a nightmare to do in Evo. I also did quite a few small sites in Evo, and found that any work requiring beyond the provided Extras was very difficult. This is why I joined Jason and we created Revo.

We wanted MODX users to have all that Evo had (which yes, there are no Evo features not in Revo - Modules are now CMPs and the Security system is different, but the features are still there, just more robust), but we also wanted to give them a much larger and more powerful toolkit to build sites with. ExtJS gave us that option - we can create powerful, extendable UIs that scale from small sites to massive ones. We can give people a toolkit (modext) that allow people to quickly make UIs for their sub-applications powering their websites and web presences. We had to standardize on something, and no other library offered the toolkit that ExtJS did. I was partial to jQuery at first (yes, I was!), but it didn't have a powerful grid system. It didn't have a fast-loading JS tree that allowed for drag/drop and asynchronous loading (a *must* for larger sites). It didn't have solid automatic form validation systems. It didn't have a solid, dynamic custom-event-based API. It didn't have great context menu support. ExtJS had all of that, and in a solid MVC API that was well-documented. That's why we chose it. It was simply better for a powerful, rich application.

In Evo, it loads fast because it's in frames. But that means you can't do drag/drop from the tree to a content field (at least, not to a content field with an RTE in it). You can't easily manipulate data in and out of those frames. In Revo, we ditched frames, mainly for this reason: the community pushed hard at the time to get us to remove it. People didn't like the frames. I understand where people come from now, I do. Frames allow for partial page loads, rather than full-out page loads.

But let me explain a bit further into Revo's operating procedure - and its UX vision - in the manager, and something that Revo allows that Evo doesn't. In Evo, a Module (CMP in Revo) is simply a page in that frame. To completely separate it from the manager is impossible. You can't break it out of that frameset and properly return back to it. In Revo, you can simply tell the current manager page to not load the default headers, and viola - you have full control of the page and the JS framework you want to use. You can build an entirely new application in there, and have full access to the MODX DB model.

Secondly, and this is very important, you can very easily build a custom manager theme for all or as many pages in the manager as you choose. You just create a new directory in the manager/templates and/or the manager/controllers directory and override the files you want to override. Just want to redo the Resource Create page for a site? In Evo you can do this, but you have to use the default "action" (controller) page. In Revo, you can use the default controller, *or* create your own controller, and use your own JS files and such. You can even include and extend the default controller's class file and just override certain methods.

That means - and this is a big deal, you can simply create an entirely new manager interface for Revo just by copying and editing files into a separate manager theme. Lossendae (Stephane Broulard) made a clean gray theme for Revo back in 2.0, and distributed it in the Extras section. He used ExtJS in his theme, but you don't have to. You could make an entirely new UI from jQuery. Don't want the left-hand tree? You can do that. Easily.

This means, if you guys don't like the ExtJS default UX, that's ok. Start a community project here at MODX to make a simpler, jQuery-based theme that only does simple things. Make it perfect for clients. Make it in frames! (Or not.) Make it blazingly fast. Then package it up and distribute it via Package Management. Heck, if it's good enough, we'll consider adding it into the default distribution as a "light" theme or something. We would support that development 100%.

However, the core MODX team is small. We don't have the capacity to do 2 manager UX's without the community's help. Trust me when I say this - if the community comes up with a brilliant alternative UX for Revo, you will most absolutely not be turned away. I want to make that clear.

Finally, we are taking seriously the front-end performance comments for Revo. I've commented a lot on the manager UX element here, and Jason (opengeek) has commented some on the core front-end performance, but we are taking steps to make the core more sleek, more fast, and more scalable. That is - and always has been - a strong priority. It's why we chose to do xPDO rather than use Propel or another already built ORM/framework in MODX. We made xPDO lighter - on purpose.

A lot of the bloat (that, honestly, was to help migrate users used to Evo) was knocked off in 2.1, and even more in 2.2. I can guarantee that trend will continue. 2.3 will clean up a lot of the package management cruft, make it cleaner (and REST-based) and streamline Extras development.

We hear your complaints about Revo; and we're not abandoning Evo by any means. But what we are is appealing - appealing to you - to help us make Revo better. Help us take the best parts of Evo that you like and get them in Revo (within reason - I don't see us using Mootools again ). That's what we're asking of you guys. Help us help you. I hope my reply has clarified some things, and offered some paths to integrating your ideas in. Let's keep this discussion going. [ed. note: splittingred last edited this post 14 years, 5 months ago.]

n Evo, it loads fast because it's in frames. But that means you can't do drag/drop from the tree to a content field. You can't easily manipulate data in and out of those frames.

http://www.useragentman.com/blog/2010/01/10/cross-browser-html5-drag-and-drop/
http://www.useragentman.com/tests/dragAndDrop/05b-crossFrameSetData/ [ed. note: sottwell last edited this post 14 years, 5 months ago.]

we are taking seriously the front-end performance comments for Revo.

Excellent, that's all I wanted to hear.

Thanks freejung. We really are (insert many "very"s here) serious about the performance. As Dustin pointed out in the Agency-world, telling clients, "well it's slow because it's quick to develop for, do you know how hard it would be otherwise?" doesn't cut it—especially when they've experienced other systems that are fast, intuitive and adequately robust as far as they know.

Further and equally important, it violates our vision as an organization—it's simply not the best experience for them.

Susan, thanks for sharing those references. I wish those were fully baked a couple of years ago! We will definitely review them, and please keep them coming!


Rossco, we can't commit to specifics yet for the future Manager, other than to say it will change. It could be a multi-pronged approach—a power-user tool for MODX experts (in ExtJS) and an easily modifiable, task-focused Client UI that installs in a separate context, that works lightning fast and looks amazing (probably not in ExtJS). If we take this approach, the Client UI likely won't have access to the full configuration options, ACLs, etc. We will get back to you on where we think we're headed for input if you're up for participating. [ed. note: rethrash last edited this post 14 years, 5 months ago.]

I know most people use jQuery but it's certainly less flexible than mootools. Both are no match for extJS though but for general front end stuff, mootools does everything jQuery can and more.

Good news about extJS in my opinion, I wasn't a fan to begin with till I realised the potential of CMPs. With you mentioning how extJS 4 works, with loading JS files only when required, I already do this with mootools.

An example is loading the recaptcha JS files only if I need them, also I created another simple class that is loaded in after the recaptcha script. Rather than having one huge JS file, I'm breaking the elements down and only calling them in when required. Makes it easier to manage I guess.

All you need to do is include the class in your page and initialise it on domReady. Pass the MODX resource ID through to the script

Just include this in your MODX page.


Stick the following in a file and upload this to your web server.


Only a small piece of JS code is held in the database, the important MODX controlled parts are past through the domReady script, the myScripts class sits as a file and accepts the params passed through. Helps keep the DB free from unruly amounts of JS code.

Anyway, that was slightly off topic but an example of mootools loading assets when required. [ed. note: rossco last edited this post 14 years, 5 months ago.]

With the refactoring of the action pages to use templates (like the Welcome page does, like eForm, Jot and Ditto) the $modx->regClientWhatever() functions are available, so loading whatever Javascript library you please, and only when needed, will be simple enough.

Although you are correct about using MODX to load the files in, that won't work in all circumstances. The purpose of the method above is to load the next script when the previous script is ready. Sometimes you may use a script hosted else where and require it to be loaded in a specific order.

Also, I was just showing how easy it is to pass MODX placeholders, TVs or what ever to JavaScript without having to hold unnecessary amounts of JS code in the DB.

That's the beauty of MODX, you do it the way you feel is best and suits what you are trying to achieve.

Cool tips rossco, keep 'em coming!

"well it's slow because it's quick to develop for, do you know how hard it would be otherwise?" doesn't cut it

Yeah, that's pretty much what I was trying to say. Another way of putting it would be that if you're sacrificing performance for convenience and accessibility to non-programmers, you're basically just enabling people who don't know what they're doing to write bad code.

That's not helpful. I can write bad code all by myself without any help from you, thank you very much! ;-)

What would be uber would be to enable people who don't know what they're doing to write good code.