Stand With Ukraine. Stop Putin. Stop War.

The MODX Manager interface is a very rich interface: there's right click options all over the place, modal windows are pretty much second nature and dynamic validation and AJAX submissions make it a very interactive experience. The design is easy for clients to understand, yet it offers the power users even more power to do the things they need to do. All of that is powered by a library called ExtJS, developed by Sencha. As a very powerful JavaScript framework it generates virtually everything you see in the MODX manager. A newer version is also used for the MODX Cloud Dashboard.

I've been learning ExtJS since 2010, every since I got interested in MODX Revolution development and extending, bending and plainly hacking the sh*t out of it. Tutorials, lots of code gazing and client projects, and over two years later I feel like I'm comfortable with what it can do and understanding the often cryptic errors. At some point, it starts becoming a source of frustration. And I can boil that frustration down to one sentence..

I love ExtJS for what it does, but I hate the way it does it.
~ Mark Hamstra

ExtJS is a dream

Don't leave yet! At least hear me out on this one. After having spent 2+ years learning ExtJS and its implementation within the Revolution manager, I am convinced it's a developers' dream. I totally understand why it was chosen to power Revolution back in the day.

  1. Rapid prototyping and interface building. Just define (basically) a big array, and you have a fully functional interface, completely blended in with the rest of the manager.
  2. Packs a large amount of widgets that are infinitely configurable and customizable.
  3. Through its object oriented philosophy, you can easily reuse other definitions in an object oriented fashion and save the hard work. Define a widget once, use it everywhere.
  4. ExtJS makes stuff work and look fancy across browsers.

In a nutshell, ExtJS is an insanely powerful framework that makes fancy stuff easy to achieve. It takes time to learn (and I bet a more senior developer would pick it up much faster than I did), but once you bridged the learning curve you have a lot of power at your fingertips.

ExtJS is a nightmare

  1. It's obviously a JavaScript framework, and ExtJS builds the interface from JavaScript definitions. There are exceptions where you can take existing DOM elements as basis, but you still need to use (and load) all the JavaScript to use the interface as intended. If an error occurs somewhere, ExtJS tends to decide to show an empty page instead.
  2. ExtJS builds elements with a shitload (yes, that's a technical term) of divs and tables. Here's an example an actual "Save" button. My guess is that it does that to make it look good cross-browser, but it clutters up the DOM and makes it more difficult to cleanly create a custom theme with crazy inheritance and royal class-soups. Truth be told, this seems improved in ExtJS 4.
  3. Similar to the previous point, sizes are *very* often defined inline (style="width: 134px;"). This could be helpful, but it isn't one bit if you try to build a more fluid layout.
  4. The ExtJS learning curve is quite steep. In the context of MODX Revolution, this harms community involvement as the amount of developers improving the core is small, and takes a long time to grow. In a proprietary environment (such as MODX Cloud) this isn't a huge concern as you can invest in training and hire the right people, but I'd argue it is a huge problem in the open source scene.
  5. The ExtJS licensing has historically been vague, at least in our context.
  6. ExtJS is slow. Not only does it have to load a few megs would worth of javascript before it can even start building your interface, but it's not particularly fast in doing that in many cases.

Despite being a big proponent of ExtJS for the reasons mentioned earlier, over time I have become more frustrated with the cons of the framework that I believe are doing serious harm to community involvement in Revolution. Learning ExtJS has been a great business decision (it made up probably a good 85% of my freelance work), but as I'm a big community fan I'd rather see something a bit more.. approachable.

The Ideal Framework

So, taken the above considerations, what would be The Ideal Framework for a MODX manager? Here's my personal list of requirements.

  1. Easy to get started with, plenty of existing documentation and tutorials.
  2. Easy to extend and capable of Object Oriented paradigms to cut on development time (rapid prototyping) and code duplication.
  3. Large set of available widgets to build interfaces with, but with a lean core.
  4. Fast.
  5. Progressively enhanced so that users with old browsers can still get a proper experience. As it's a backend I'm fine with it requiring JavaScript, but regular HTML and CSS should provide a baselevel experience.

In my mind (and I can hear sighs coming), jQuery fits a large number of those requirements. Getting started with it is easy, documentation and tutorials are everywhere and the amount of widgets (plugins) available for jQuery is enormous. It easily lets you use progressive enhancements paradigms and considering JavaScript itself is an object oriented language, yes that applies to jQuery as well.

Does just sticking jQuery into the manager provide a maintainable product? No; it needs more thought. The manager is big and complex and just filling up a footer with $(document).ready() tags wont make things better than ExtJS. But I do think a properly implemented object oriented "wrapper" could definitely be what MODX needs.

And that's what I started mocking up.

Introducing a jQuery Based Manager

If you follow me on Github, you may have noticed some recent commits to a new alternative-manager branch in my Revolution fork. This contains a Proof of Concept of how I think a jQuery-object-oriented-wrapper-framework could provide a better experience for the MODX Manager.

So far only the manager login and dashboard has been (mostly) converted, but it's a lot of work. Everything that can be represented as plain HTML/CSS is being converted to that, while other bits of HTML are being used to load up widgets based on a "data-role" attribute.

My first impression of this proof of concept is that it would definitely be powerful, lean and extensible enough to replace a heavyweight like ExtJS, without getting stung by the downsides of the framework. So far (at an early state, obviously), my jQuery alternative sure feels smoother and faster than the ExtJS one too. It needs a lot of work, and tearing out ExtJS of the manager sure is more work than just removing the files, but my belief is that in the end it would be worth it.

So now what?

Now.. I want your feedback. What do you think about ExtJS; and my jQuery-based alternative? Would you support (and better yet; help out) an initiative like this, or am I being a pity fool? Do you want to see a demo?

Depending on your feedback, I want to publish a couple blog posts in the coming weeks on some of the decisions I've made so far and what I think the implications of them are.

Just to prevent any rumors: no I was not asked to work on this for my job at MODX, nor does this proof of concept mean that jQuery is what will power MODX in the future. It's me being curious if jQuery could be a practical alternative and at some point a few weeks ago deciding there's only one way to find out..

UPDATE T+45mins: Despite publishing this article at a time where people are either enjoying a nice drink or a comfortable bed, the response (in the comments, on twitter and on skype) has been awesome! Please do keep it going and let me know anything you'd like to know about the jQuery manager in the comments below. I'll try to answer as much questions about that in a follow up post in the next week or so. Of course, feel free to just go ahead and have a look at the JavaScript. I'll also look into making a public demo available.


I must be dreaming^^.... =))... This is exactly what I have been thinking about for a few weeks now (just trying to start and (re)build the manager with cleaner html, css and jQuery)!!!

Your points above are exactly what I'm thinking about the whole extJS stuff, it's powerful for sure, but is it really the best choice? But I'm not a really "good" voice for that because my extJS skills are on a 1 of 100... =/, so if I say "aaaa, I hate extJS, can't change anything in the manager, blabla", my word is worth nothing because I almost know nothing about it coding-wise, so I can just tell the negative sides (like not being able to develop cmp's) without knowing potential good ones. So I'm really happy that you as a big time modx insider are thinking the same (especially about the community involvement) as I do.

Will have a veeery good look at your github fork, try to wrap my head around it and commit whatever I can to make this happen!! I'm sure there would be a crapload of nice Addons from people who (like I'm) are just not able to do them because of extJS (and they know probably jQuery very well from the frontends of their websites)!

Keep up what you're doing! jQuery FTW =D

Mark Hamstra

Glad you're so excited! ;)

Part of the reason I decided to post this is because of the uneven split between people that know ExtJS and those that don't. While it was great for my freelance business being on the right side, something as crucial as an admin panel shouldn't be limited to a few handful of people that have spent a long time mastering ExtJS. I think using jQuery would open up a lot more community involvement, and we can't have enough of that!

Benjamin Morrison

I have tried looking into ExtJS a few times and it just makes me want to cry. I get jQuery, I love it and it's fantastic. I'm a terrible coder (designer and i integrate with Modx well) and even I have it down. I just think that perhaps ExtJS is a bit overkill considering. In all honesty, it's one reason I build any custom functions with frontend management rather than a component in the manager. I get why they did it, really I do, but perhaps two branches should have been started in the initial development to determine what would work best. True that would have taken longer, but even with my skills, I could have some components by now.

Benjamin Morrison

Just a quick question to Mark... how well do you think the idea of a jquery re-write would be received by the core development team? I would understand if you wouldn't want to speculate.

Mark Hamstra

I could speculate, but in the current state it's nothing more than a proof of concept (that I personally think is pretty awesome and could work very well). Different members of the core team will also have different opinions (ExtJS isn't a new subject).

If anything, this is a super major breaking change (outside of the core manager, all currently existing manager components will break), so if it gets to the point where it actually does get integrated into the core, it would need to be a major release.


Mark, hi!
If you create stores, grids, custom listeners and other better than it`s have in ExtJS, i`ll try it. But now i know not library better then ExtJS.
In MODX Revolution we can not nativly set user photo in manager panel, but i create Extra modAvatar, which do this, and it`s look like native.
And it`s not code in core. It`s just ExtJS Addon.

Mark Hamstra

If at some point this PoC becomes more functional, you should definitely give it a good spin.

I'm an extra developer too, so I know the cool stuff you can do in ExtJS that might be more complex with vanilla js or jQuery. In what's on my fork now, I also load KendoUI which has some pretty cool widgets, data stores and all sorts of advanced goodness. jQuery handles listeners pretty well too :)

I appreciate you leaving a comment and sharing what's important to you. My goal is to make everything you could do with Ext possible with this too and personally I dont think we're far off ;)


Mark, i`ll be glad to try you`r alternative manager panel on days


Mark, i`ll be glad to try you`r alternative manager panel on days.

P.S. can i reg here?

Ivan Klimchuk

Mark! It awesome!

I have long wanted to offer jquery instead of ExtJS.

This idea have a big future! Because many developers know php, javascript and jQuery, but ExtJS is more complex for start. And if we can use jQuery in manager more people will want use MODX.

I forked your branch and will try help your.


????, ?? ??? ?????????? ??? ? ????????? ???? ???????

Mark Hamstra

I understand Russian is easier for you, but if you could try and stick to english that'd be nice for others ;)

And no there's no registration on the site (might add it in the future) for now.

And keep in mind it's still a proof of concept lacking many features - it needs a lot of work before it's functional :p

(I'm also looking into why the quip database tables aren't using UTF8 and your comment looks funky.)


Just do it© !

I have tried to make a manager theme.. but i was only able to change the colors... so many stuff in there.. :/


Good article! I think extjs in modx would be more user-friendly if modext has a simple visual editor like such in delphi and modx-like templates of backend with all power of chunks and snippets.


Sorry, but i tired to write nickname and email for each comment. Why not use Login Extra or other?

Mark, i havea big-big question: why you rewrite modManagerController::registerBaseScripts in core (and may be others) instead create orw namespase, set another request/response classes and etc.? I want try for another manager panel, but i done want use another panel only, with modified core.

Mark Hamstra

I'll look into it for a next iteration of the site. The original thought was that I didn't want to force people to sign up to leave a comment, but I'm considering using HybridAuth now that's available :)

As for why I'm making changes in the core: core changes are needed to get ExtJS out of it. And as I am more interested in a replacement rather than an alternative you can run side-by-side.

Also, it's not yet in any sort of functional state where you can actually do much with it, so I don't recommend throwing it up on a live site.


| core changes are needed to get ExtJS out of it
Discuss use own request/response classes and controllers. You know how to use custom controllers classes and overwrite base classes.

Mark Hamstra

Primarily doing it this way to prevent spending time on something that already exists. In my head it is a future replacement, not a separate alternative you could install (like HandyMan), so keeping it where it should end up makes sense to me. Theoretically, that should make a pull request to get it into the official repository easier as well.


Hi mark,
You can't imagine how much I do agree with you.
Despite being comfortable with extjs, I am pretty sure that having a jquery based manager would greatly help modx to grow as a community.


Imo MODX lost some momentum maybe. I have heard concerns of speed issues, if EXTjs is as heavy as you say that certainly takes some load time.

The MODX college link on the website fell perfectly flat, with little contribution, as an aside,
Major releases can be buzz kills, time to market being a bit of a barrier.
Just thoughts, thanks.


Forgot to add a big fat 'Go for it'! also.
Thanks for your contributions.


Oh by the way, if you want to have some advanced grids like ExtJS built with jquery, maybe dataTable can be your savior.
And if your confortable with PHP, here is a php wrapper that can help you do so

Mark Hamstra

Grids are definitely one thing that ExtJS does quite good and are difficult to replace. Though I'd also argue grids are overused in MODX ... but that's a separate blog probably :P

Ben Marte pointed me to Kendo UI when I was just getting started with tearing out ExtJS, and I was immediately drawn to some of the amazing widgets it comes with. Kendo UI is developed by telerik, who also develop SiteFinity (a commercial enterprise CMS), so they know their stuff, and frankly I think it shows in the widgets. Checkout their grid widget:


It looks good, I didn't know about it, thank you.
plus it does not use the Hungarian code style...
Yet another tool to check out. :)

Joe Molloy

Not withstanding the inherent weaknesses of ExtJS so elegantly outlined above and particularly for me, the size of the library , the cluttered DOM it produces and the lack of MODExt-specific documentation/tutorials, I have to point out that while I do know the ExtJS is a substantial hurdle to cross for potential addon developers (one I have had to cross myself), I can't help but think there is some benefit in that as well as it results in encouraging devs to adhere to good OOP design and implementation practices. We have seen how the low barrier of entry in PHP development has been its Achilles heel as well as the key to its popularity.

I also like ExtJS in that it promotes common coding practices and consistency of look, feel and user experience.

I am not setting my face against the greater flexibility and lower barrier to entry that JQuery would bring in coding approach and interface and nor am I an OOP snob but I would strongly suggest that along with any coding initiative such as the one you are starting Mark, that it might be worth taking a leaf out of Google's approach to Android and the way they are now strongly promoting standardised interfaces across apps by providing excellent guideline documentation on best practice for both coding and design. Developers on the whole seem to be happily embracing this approach.

Mark Hamstra

Thanks for some great thoughts there, Joe!

I agree that using OOP patterns are great to use, and that jQuery is mostly used in a more procedural way. That doesn't mean you can't use OOP design with jQuery... JavaScript itself is object oriented!

In a follow up posts I'll go into some more actual coding and implementation I've done so far, but OOP is definitely a big part of it. Here's the javascript for a "module" (could call it a widget too, not too fussed about naming) that would be used for one element to toggle visibility of another:

JP DeVries

This is really exciting stuff. One thing I continue to see about MODX is it isn't afraid to address its weaknesses even if it means fundamental change, and a lot of work.

JP DeVries

Just a quick question to Mark... how well do you think the idea of making MODX 3 not dependent on any one JS framework at all would be received by the core development team? I would understand if you wouldn't want to speculate.

Mark Hamstra

I don't know what the core dev team thinks... ask them, not me! :P

Personally, I am very curious how you would build a usable admin interface that doesn't have a JS dependency at all. I'm open to exploring options, but personally I feel that at some point plain HTML/CSS wont be enough.

If you just don't want to tie it to one framework, I worry that everyone will use whatever they see fit, and that it becomes a complete mess. I'd rather provide one, easy to use, well documented framework and "strongly recommend" using that.


| Theoretically, that should make a pull request to get it into the official repository easier as well.
I dont want for ExtJS will be removed from official manager panel.

Mark Hamstra

It's a very early proof of concept for a super major breaking change.

If it happens, it will take a long time for it to even get to a stage where it can be considered for inclusion.

Shaun McCormick

Hi all, very helpful feedback. As per the discussion, I thought it might be helpful to better explain the reasoning behind ExtJS's selection for Revolution directly from the people who made the decision, rather than just here-say. The reasons ExtJS was chosen were:

1. Features
At the time of Revolution's early development (back when it was still 0.9.7), there was, in fact, no javascript library that could even come close to what ExtJS was doing in terms of UX. I mean it. There was no solid jQuery-based grid; no other JS library had a decent tree-navigation system; and form validation in other systems was often a patchwork of various plugins that often conflicted.

This left us with what, at the time, was a very simple decision. Either make a manager with limited functionality in jQuery in 3 times the time, or go the ExtJS route (which at that time was just finishing the 1.1 version) and get Revo developed into a UX that made sense at the time and had all the features we needed to do the proper UX.

Remember, at Revo's conception, HTML5 didn't exist yet. There was no powerful systems like we have now that even came close.

2. Grids

I know this is part of #1, but *so* much of what Content Management is in reality is just management of listable items. ExtJS has always had a fantastic grid widget, and one that could easily be extended and scaffolded across the system, while still preserving the synchronicity of look and feel that made for good UI design. A few mistakes, in retrospect, were made with regards to grids - the dependency on right-clicks for menu actions, rather than some sort of button/cog to lead users to more options; also, not enough data-presentation tailoring (think custom row rendering, a la today's Package Management) for various types of data that led to grids feeling "techy" and "developer-centric".

3. Time

Revo was a massive rewrite. There was lots going on behind the scenes, from figuring out just *how* much of Evo we wanted to have backwards compatible. At first, we started out as 0.9.7 just being a small under-the-hood rewrite, but then we realized that a big change was needed. We then wanted to completely rewrite everything, breaking from backwards compatibility and ensuring a solid, coherent product, but external and internal pressures forced us to have kind of a hybrid approach of some rewrites, some stay-the-course. This please everyone, satisfy no-one approach ended up causing us some pain down the road. 2.2 (and 3.0) have helped this quite a bit, but there is lots more to do.

So, in the early days of Revo, we decided that it was far more fortuitous to save us time in the UX part, and use ExtJS. This allowed us to rapidly prototype a UX that got rid of frames (a HUGE community-pushed endeavor that nearly everyone wanted) and still kept a lot of the functionality that frames offered.

Was the UX perfect? Absolutely not, and far from it. We even admitted that, multiple times. The styling stunk. The one-field-per-line approach was awful. Usability was awesome in some areas (hello drag and drop tree) and horrid in others (cramped, tight fields with little inline help). Plus, we had just launched a UI with a product with a JavaScript library that was just then starting to break into the mainstream - and really wouldn't get big until about 2 years later.

So, we took a risk. Did it pay off? You can debate whether it did or not, and really the answer there would be subjective based on personal preference, but I can say with objectivity that our downloads of Revo, as compared to Evo, were vastly higher. Revo, for all its failures, was doing far better than its older cousin in terms of adoption (still is).


Those are but a few of the reasons we chose ExtJS (there's more, but for brevity I'll stop). So, what about the future, you ask? Is MODX wedded to ExtJS? I have an answer for you: "No." Absolutely not. However, every product has criteria, so what is MODX wedded to? MODX is wedded to flexibility and power. We do not plan to become a WordPress, or a SquareSpace, for that matter. We want to choose a technology for the UX that allows us to offer a user experience that does not limit the designers ability to create powerful sites, and yet doesn't cramp a developer who wants to prototype new functionality into the manager without having to start from scratch every time.

I hear this often - "switch to jQuery!" - which, I will be honest, I'm not entirely unsympathetic toward. But, let's be honest. Can jQuery fit the requirements to truly make a Revo manager? If it can, great! But if it fails in any of the following areas, then it's probably more of an excuse to not liking ExtJS than a viable alternative for the manager.

1. Grids

jQuery has simply not had anything remotely comparable to grids in it, ever. Yes, KendoUI (which, btw, steals a lot of its grid structure from Ext - and looks remarkably similar in source!) and a couple others have them, but for the most part jQuery is massively lacking here.

So what specifically do grids need?
- Remote Data Stores: I want to load data from AJAX, so that I can load the page faster than having to wait. This also allows me to paginate the data properly.
- Toggle-able Grouping: I want to be able to organize a grid like I would in Excel. But on the web.
- Inline-editing: Double-click to edit a field. Auto-save when out of focus. Etc. Etc.
- Column or row-based custom rendering: If I want one column to be a different text or feel than a normal grid, this better be doable.
- Toolbars: to be able to attach things to the bottom and top of the grid at will

2. Form Validation

Again, ExtJS makes this ridiculously easy. It also allows me to define methods that validate fields quickly - I can write one function that can validate any number of fields, flag them, and prevent submission. Secondly, I can even add field-specific errors when receiving back AJAX responses from a form submission - with only a few lines of code. Defining fields takes maybe 2-3 lines of JSON. Simple. Quick. Can another JS library do that?

3. Trees

MODX heavily relies on the tree, for better or worse. It's great to visualize data and structure that way, and ExtJS allows us to do this on a per-node level; it also very easily allows drag/drop within or outside of the tree, and allows node-checking (ie, don't let me drop here because of X or Y reason that I defined).

4. Drag/Drop

Mentioned above, but did you know you can drag/drop an item from the tree into *any* field in MODX, and have it auto-create the MODX tags for you? (Or popup a form with Snippet options, for instance.) Did you know you don't have to tell MODX to do this when writing a CMP or Extra? It does it for you, in only a few lines of code, due to the OOP nature of forms and drop-areas in ExtJS.

Any tool that would come in would need to be able to allow:
- Drag/drop of items in views (such as Gallery items, for instance)
- Drag/drop of tree nodes to fields
- Drag/drop of tree nodes around to other tree nodes
- Drag/drop reorder of grid rows

5. Extendability

This is a big one. In order to promote coherence in the UX, we need to keep every UI that an Extra runs looking like the core UI. This promotes good UX, rather than something looking like it was written in 1995.

ExtJS allows us to do this through MODExt, which just extends ExtJS. Further, CMP or Extra writers just extend the MODExt classes, so that their UIs automatically have all the styles (and features) of MODExt tools. This means MODX Extra developers *write vastly less code*.

That extends to the MODX core UI as well - think about how many pages there are in the manager - how many sections, how many different things MODX's UI does. Now, imagine how big the JS files would be if *every* single action in the UX was defined separately, from scratch, without being extended. It'd be a nightmare, and slow as well. ExtJS (and others, too, admittedly) allow us to easily extend objects and provide this functionality. It also promotes good code.

So, if another tool wants in, it needs to also allow this level of extendability, so that it's easy to create new Extras in MODX's UI.


I'm not presenting that feature list as an argument *for* ExtJS, for what it's worth. I just want you to understand the reason why MODX hasn't switched off yet. We haven't gotten a serious proposal of a UI framework that can do all that MODX does, faster and easier. If this discussion and work that Mark has started gets us one: great! Awesome! Fantastic! That would be a _huge_ deal, and one the core team would *absolutely* take seriously. But until then, we're going to stick with what works (ExtJS4 is in Cloud, in case you're wondering, and loads quite fast).

We also will research other frameworks for 3.0 - hear us on that - but this is an Open Source project. It depends on the contributions of people. If everyone just complains about ExtJS, that's not going to solve anything, and ExtJS will likely stay due to the lack of an alternative. If people instead work on creating a better, just-as-feature-complete solution that can replace it, great! Then MODX can move to something else. But complaints and criticisms do not an alternative make.

I'm excited to see where Mark's work goes. I would hope others would help with it, since Mark already works a day job and is doing this on his off time. Hopefully it will provide a solid alternative to ExtJS - or, alternatively, find that maybe ExtJS is the best road taken, and we should move to ExtJS4 (or 5) for MODX 3.0. We'll see.

Apologies for the long post, but I found it important to comment. Thanks all. Your passion and eagerness to improve the MODX product is *definitely* not ignored, and vastly appreciated. MODX will live strong because of such.

Shaun (splittingred) McCormick

P.S. I also would like to point out to Mark, that KendoUI runs on GPLv3, which will cause some serious licensing issues for those trying to make money in any application or Extra that uses it. (MODX uses GPLv2 for this very reason.) ExtJS has a FLOSS extension for our usage in MODX, that keeps ExtJS free for our users.

Mark Hamstra

Thanks, Shaun!

I know the web scene was very different, what, seven years ago? Like you point out, many considerations that now play a major role didn't even exist in theory yet back then.

Thanks for sharing your list of requirements, too. I completely agree with most of them and many have already been mentioned here by others, or are on the roadmap (conveniently located in my mind) for this jQuery prototype. The only way to find out if it's feasible and workable is to build it and test it, so that's what I'll be doing ;)


Shaun, i know Revo manager panel was builded by you, and you know power of ExtJS like no one of us. Your level very and very impressive! An you know what we lost if we`ll switch on jQuery.
Maybe you know i create some Extras working in manager panel, and i want to say if MODX3 or highter will be based on jQuery, probably i will not develop on MODX3, and stay on Revolution.
In jQuery i can`t do this:
xtype: 'my-cmp'

Mark Hamstra

You haven't even seen a functional prototype yet, and you are already dismissing it!

jQuery is commonly used as very low level DOM manipulation library. Yes, I know. That doesn't rule out more advanced usage, at all!

To give you back your example, something like this is pretty much possible already:
or we could even build a simple API to do something like this:

Please, Nikolay, stop freaking out! :P

What I'm doing is making proof of concepts and prototypes to see if it could be functional and provide the same level of functionality as ExtJS - but then done better and faster, without sacrificing developer convenience. I want the same features you want, so trust me, if it is not possible to do that with jQuery I will be the first to pull the plug out of this project.

My intention is not to turn your world upside down tomorrow, I only want to investigate alternatives for the long term.


I know jQuery to. It`s library for frontend.
OK, time shows.

Peter Bowyer

Shaun, a general question about validation with ExtJS.

"ExtJS makes this ridiculously easy. It also allows me to define methods that validate fields quickly"

How easy is it to tie in with custom server-side validation, and can the two be handled in one place? There are many places where I may not trust the user not to manipulate the request, and validating client-side only (and generically on the server) is not an option.

I am aware this is a generic problem with Javascript client-side frameworks and I haven't seen any neat way of handling it (even where the same JS validation can be run on the server via nodeJS and in the browser). Meteor has done some interesting work on this IIRC, but I can't track down the link.

Josh Gulledge

Thanks Mark for the post. Thanks Shawn for you response, I totally understand the reasons your team chose ExtJS for Revo. I think it meet the goals you have stated well. I don't think it is helpful for some to say that was a wrong decision but rather lets focus on how can MODX/community can look to the future. First it would be defining the goals and priorities of both for the future.

A question I had for a long time is does the Manager/CMPs have to be built like the manager currently is built? And is everyone limiting the debate only to a new JS framework to build the manager the way it has always been built? If that's the case you will have a very hard time not using ExtJS unless lot of people contribute to writing the JS wrappers/MODX-UI. I personally would like to use MODX methods(Chunks and Snippets) to make the Manager and all my CMPs with an HTML(5)/CSS first approach then pick the best JS framework that will add the effects/behaviors/AJAX, maybe even moderate progressive enhancement. I am confident this can be done as I have been working on a conceptually related project and hopefully I have time in the next month or so publish it.

JQuery, quick thoughts:
1. Grids: SlickGrid is a good one -
2. Form Validate: could possibly take advantage of HTML5 validation attributes or data attributes in association with jQuery Validation
3. Trees: I have recently been working on a project where I reviewed a lot of types for server side PHP/MySQL and see how changing some of the server side would make the Trees much faster. As for the JS, I don't think it would be to difficult to have rules dependent on the JSON response.
4. Drag/Drop tree elements to form fields: Not trying to be rude, but how many people actually even know about those special features? I don't know if they are even documented, I found them by accident a year ago. If this is not a very used feature (low demand) then why should it be a requirement or set to high priority?
5. Extendability: As I mentioned above I have been working on a project on and off for some time that will allow very easy extendability built on MODX regardless of framework chosen (via plugin you can control all output with simple API). The basic idea is you use a Chunk for a field type and the Snippet will fill it with all of the appropriate attributes. For AJAX use something like this in just a few lines:

Just my two cents:)


A great read Mark.

Every time I look at ExtJS for very long, I get a stomach ache. I understand why it was chosen, but I couldn't agree more that it's hurting MODX development.

I would love to contribute improvements to the Manager, but to do so, I would have to spend at least a month or two learning ExtJS.

It's also the reason that many of my extras aren't integrated into the Manager as well as they might be.

It seems to me that grids and trees are the main features. If you can do them in jQuery or another more intuitive system, I'm all for it.

Btw, I think shitload is one word. ;)

Mark Hamstra

Thanks Bob! I've fixed the typo :P

The next bit on my list to build out in this jQuery prototype is an actual tree widget (the resources one), so we'll see how that goes! ;)

Peter Bowyer

First up, well done for moving beyond thinking about it (where I stick) and getting a proof of concept written!

It's Sunday morning and I haven't looked at your code yet, but I wanted to share my thoughts.

First: Javascript libraries. I applaud the choice of jQuery but feel it is too low-level for what you're trying to achieve. I feel EmberJS is the best fit, but I would be tempted to try with AngularJS (which IIRC has some support for web components - see paragraph 15 onwards for why I'm excited about this, and combined with jQuery. I love KnockoutJS but I don't see it being a fit here; BackboneJS is the grand-daddy and probably not the best choice now. All have an extra learning curve, but all prevent you needing to write your own OO-framework on top of jQuery. And none have the learning curve/overhead of ExtJS!

Part of the ExtJS problem (if I digress) is that MODX is forcing people to learn an old version, which isn't a good use of most people's time now. I also feel that outside enterprise tools, ExtJS has been superceded.

Before picking a solution though, I'd like to know what the problem is :) Do we want to do the same style of content editing (a la re-implement the current manager on another JS framework), or fundamentally change how it works? I presume the former, and have only considered that!

Second: MODX Architecture. I had to build what effectively was a small custom manager for a client in September and based it off your Handyman project, as it needed to create, save and reorder MODX resources of a particular template type. I was rather depressed by how difficult MODX made this and how focused around an EXTJS output it was - I was calling processors from server-side PHP as this was the 'best' way to insert data, and then having to parse the EXTJS formatted response. If this improved, and if different formatters could be easily plugged in so I could get a definition of all fields & TVs on a page in a non-EXTJS JS format (so I can render using either PHP or another JS framework) then building a custom manager would become much easier.

I'll add a disclaimer that I haven't worked so much with MODX Revolution since discovering this, as it concerns me that as a framework (not a CMS) I don't see it being discussed/worked on (in public, I can't see what happens inside the LLC). Maybe the framework API has changed and is a high priority for the team to improve, to produce a Content Management Platform.

Mark Hamstra

Thanks for those links, that's some interesting reading. I've been pointed to Ember and Angular before but as I'm not familiar with it yet, I decided to see how far plain jQuery gets me. :P

As for the problem we're solving - I'd reckon that is different for everyone who has left a comment here (or is still lurking). My problem is that (despite being a pretty darn powerful framework), ExtJS is deterring a lot of community involvement. It's simply too complex to quickly understand and start building with, and it can be plain frustrating to work with if you don't fully understand the entire framework.

As for your architecture question - the processor response is ExtJS formatted. When called using runProcessor (like in HandyMan), it returns a modProcessorResponse object that let's you check if $response->isError() or loading that data it collected with $response->getObject(). If you access it through a connector (like you would in the manager with AJAX), it's formatted as a JSON encoded array. Again, not ExtJS specific as you can super easily load that with jQuery too.


+1 for AngularJS.
If you'd like to build a "future proof" backend: Use it [!!!111] (btw: Angular uses / works well with jQuery, too).

And also have a look at this (super exiting) talk about webcomponents:

Andrew Smith

I think its time I drop the ball in here. I read most of the comments and read Mark's post. I think there are many points to consider and many things said which I must say are just personal opinions.

Since I don't want to target anyone specific or pinpoint any comment specific, I think the first major hurdle for the MODX manager is UX, the current UX leaves a bad taste in my mouth, it is far from optimised and far from user friendly. I think the underlying framework has a bit to do with it but not responsible for the entire issue. Lets get the UX correct and some sort of design pattern to follow for component developers, there is nothing as bad as inconsistent experience for a user.

I will not touch on ExtJS at this point as my comments might start flames, lets just say it is currently deterring developers away from MODX. To me MODX still feels like a company run project, not a open source community run project. Until the barrier is broken, it will prove hard for MODX to penetrate mass market.

Mark Hamstra

Totally agree - the UX is just as important if not more important than the framework behind it. My personal belief is that a more easy to style and customise manager will lead to more design and ux experts taking stabs at radically different interfaces.

Right now, if a designer wants to (for example), throw the sidebar to the right, it would likely need changes in the ExtJS, meaning the designer needs an understanding of ExtJS in order to experiment with something else.

With a more HTML/CSS/jQuery based interface, this might just be swapping a float and some margins.

Joe Molloy

Right, as I said on Twitter, I'm feeling what Shaun and Peter have said here most. I think we all agree that we want consistency in the UI, UX and in coding practices. Imagine the horror down the line of being pulled in to maintain or extend a CMP free-for-all not to mention the inconsistencies in terms of UX for users. I know Mark this isn't what you intend. You intend to structure things using JQuery itself but that would essentially mean another layer and I think as Shaun pointed out, yI suspect you will come close to replicating the ExtJS framework in JQuery, let's call it MarkJS :)

Therefore I think there is merit in Peter's comment that JQuery is too low down in the abstraction layers to deal with this problem effectively, OO is all about avoiding re-inventing the wheel which is where my Twitter comment on adding the MarkJS management layer being kind of un-OO to me comes from. If JQuery was a good fir for this problem domain I think we would already see platforms using it this way.

While I do see that ExtJS has been a barrier to developers jumping on board with add-on development, I do think that developers also need to recognise the importance of the points that Shaun raised regarding consistency and efficient OO design and do need to be prepared for some degree of a learning curve if they are serious about contributing to MODX.

Also, in a conversation I had with Jason before, I was reminded that you don't have to build components on the back end at all, you can access all you need and build your own UI on the front end - maybe a path for some to consider - that approach certainly suits some components - take Translex for instance - the UI is all JQuery driven.

I also am strongly of the mind that as a platform, the architectural, design and UX choices made shouldn't be because something is casual developer friendly, it should be because it improves the platform significantly for all. I like that at times MODX has stretched me as a developer - I'm a better coder for it.

Mark Hamstra

Thanks for the thoughts, Joe!

MarkJS sounds cool, and I look forward to going into a bit more detail about how it works and how it brings more OOP and consistency to my proof of concept / prototype in a future post.

Andrew Smith

I still don't see what you are getting at with this, you provide a barrier and surely that system userbase will run dry soon, actually no it will become a elitist community. This is something Drupal suffers from hence the reason we have so many Wordpress websites where they turned the blogging platform into a CMS.

Everyone seem to talk about this consistent UI, UX that ExtJS provides, in reality it provides none. A developer can still do whatever he wants to make it look as ugly as he wants, after all its just JS, CSS and a bloat load of HTML. Take a typical example as ExpressionEngine which is build on jQuery, the UI/UX remains consistent amongst developers, you provide style guides and coding standards and devs will follow if they want to provide a professional looking addon. Can we stop with this jQuery doesn't provide consistent UI.

Please lets not make MODX a elitist community, I might stand as one of those elites but surely dont like it.

Yet again JavaScript is OO. If you are after a widget set system, then say so but don't say jQuery is not OO because it doesn't have a bunch of extendable widgets (HTML, CSS, JS) in itself.


Totally agree with you here.

I know that WP is considered like evil by most of Modx community, but as much displeasing as it sounds, it is MUCH more easier to build anything in WP admin than in modx.

And after having tried other solutions as well, i know for sure that they're even better and easier alternative to... WP

And going back to UX, WP comes "bundled" with jquery and a lot of other js librairies as well, but if you look at most of 3rd party plugins, they all use the look and feel of WP with ease because admin pages are just HTML that any designer can pick copy/paste and add their own logic into it.

Now, they all lacks on client side validation, but even if it is a fancy feature and can be helpful, server side validation cannot be replaced. ever.

You can do almost what you want with Extjs, design wise and feature wise, but it takes longer to implement compared to jQuery. Notably for simple scripts.

Furthermore, I somehow disagree with Mark on the floating approach with Extjs, it does not work that way.

The manager use Ext layouts facilities, which should always manage the way pages are rendered and resized and behave.
That's why when someone use a landing div in the main container and modx.load(), resize and styles (moslty on grids) often looks weird because modx itself does not use Ext layout manager, but its own div that Ext can't work with properly.

At one point Mark did propose to get back to simple HTML + CSS admin and then add JS above it if necessary. I would love this approach thousand times against the all JS framework that forces you to work the way the CMS decided you should work.
Creative freedom should not only belong to the front end...


Doesn't jQuery have and maintain jQuery UI??
Wouldn't this be a way to obtain the UI elements without excess programming??
Thank you, Tom

Peter Bowyer

It does have, however:

1. It evolves very slowly
2. It is buggy
3. It is ugly (1.9 is meant to fix this)
4. It is bloated
5. The widgets feel like they've been designed by committee, rather than by people with real problems to solve. Look at their slider (the most recent example I had to deal with), and labelling it on page load vs after the slider has been dragged...

It works, but I wouldn't wish it on anyone!

Mark Hamstra

jQuery UI has a couple of good widgets (datepicker, autocomplete is fairly okay), but I think the biggest con of the jQuery UI is that I think they're not per se extendable. My wrapper could extend it, but my gut says that there's better widgets out there than the ones offered by jQuery UI :P

Joe Molloy

I don't think anyone here said that JS isn't OO, I know I didn't. What I did say is that the abstraction in JQuery is at too low a level for the problem domain we are looking to address and that its worth looking at other approaches. I expressed a thought just as Shaun did (more articulated) that Mark could be basically reinventing the wheel, which is not a very OO thing to do. If someone has set their face against learning anything new and prefers to just recycle what they already know then fair enough (that's kinda OO in itself) but I don't think any platform should be arthitected on that basis.

Nor I think is anyone here in the business of or oblivious to, the dangers of creating an elitist community, I certainly am not, spending some of my Friday evening attending the first MODX user meetup in Ireland at which I spoke with designers and devs at various levels of competency and encouraged them all to participate as fully as they possibly can.

Let's just remind ourselves of the definition of elitism:
1. The belief that certain persons or members of certain classes or groups deserve favored treatment by virtue of their perceived superiority, as in intellect, social status, or financial resources.
a. The sense of entitlement enjoyed by such a group or class.
b. Control, rule, or domination by such a group or class.

So let's move away from the emotive language of terms such as elitism here please and the frankly inaccurate accounts of what has been said, that gets us nowhere.

I agree Andrew that a lot can be achieved with style guides and coding standards and myself and Mark had exchanges in this regard on Saturday via Twitter - I suggested taking a look at how Google were dealing with this viz Android. I also can't help thinking however that perhaps if the effort required to agree and produce those went into MODExt documentation, tutorials and examples it might be just as beneficial for the platform.

My two cents on this stands. Its going to be a substantial task to make a robust, consistent and extensible UI using JQuery and I do feel that all options should be investigated throughly including retaining ExtJS and how it might be made more novice developer-friendly.

Mark Hamstra

Thanks for your comment, Joe! :)

I think the "jQuery isn't OO" statement came from twitter, somewhere, which of course has a character limit that throws subtleties out the window. Not sure who it was that said it, but you're right that it doesn't matter.

If one thing has been said several times it's the need for some sort of style guide to build a more consistent UI, and I agree that's important.

GP Sietzema

Here's my 2 cents...

I have never understood why Revo is completely Javascript driven. I'm from a time where we taught people the following:
- HTML is for structuring
- CSS is for styling
- Javascript is for adding fancy effects
- PHP is for validating
- Ajax is a way to make stuff quicker and require less page reloads

Right now ExtJS is used to create the whole UX. HTML wise this is a joke. Try inspecting the HTML...

I come from the evo and pre-evo era. This was when the manager was ultra-fast. Right now, the manager is slow as hell, especially on some older machines. At first I really appreciated the whole frameless UI, but right now, I long for the Evo speed.

@Shaun: I get your reasons back in the day, but I think we oversaw one thing: this won't work for 99% of all developers. ExtJs is simply missing adoption. That's one of the reasons we as a company have troubles adding extra's to MODX. It's time-consuming to teach everybody ExtJs.

- Grids: this should be done by templating t.b.h. PHP + HTML
- Form validation should be server side or using ajax. If you want to do it with Js, I'm sure there some jQuery library which can help us out.
- Trees: I'm pretty sure this can be done in other js libs
- Drag/Drop: Does anyone use this, at all? The only thing we use is drag/drop to change the order of objects in the tree.
- Extendability: if no-one develops anything, there's not much to extend ;-)

To be honest, I'm a less=more guy. I kind of got brainwashed by Apple, 37 Signals and companies like that. But it's a proven concept. Currently, MODX is a bit like the Linux (as a desktop OS) of CMS's. It's a brilliant system, if you know how to use it. But if you're not an expert or run into issues, you're finished.

I don't agree on the UX consistency. UI shouldn't be made using Javascript, it's a bad concept. It should be made with simple HTML and styled with CSS. If we want to keep the UX consistent, we need to:
- Create helpers to easily write the UI in HTML
- Create a CSS standard to style everything (like Foundation does with standard CSS classes)

To finalise my reply and plea for change: we're loosing pitches because of manager & caching speed issues. The manager because it's slow and the cache because every change clears the whole cache. It makes content management a burdon. We're nearly forced to do content management at night, so we don't slow down user experience on the frontend of the website.

It's hurting us right now. It also slows down community involvement. I'm fairly sure that Core MODX changes are mostly done by the MODX team, which is a shame.

Honestly, if we change the UI and the caching, we'll kick every other CMS's ass!

Mark Hamstra

Thanks GP, I think you make some excellent points. (And I only tend to drag and drop in trees, which most tree (JavaScript) widgets I have seen supports. )


You've hit the nail on the head GP. There was a time when nobody would have considered a purely JavaScript powered manager. It has evolved and is now a very powerful option, but we need to take a step back to ask a very important question. Does it help me accomplish my task faster?
If you are a core developer there is definitely a speed improvement using ExtJS over the more traditional approach, heck even back end developers can benefit form it.If we step back and look at the manager from an end user perspective, simply put it fails.
The goal of an end user is to update their website, and in most cases it's unlikely they will touch 60-80% of the manager functionality/power. It doesn't allow them to to make changes faster, drag and drop files to upload them, or otherwise simplify the task of maintaining their website.
So let me end with a question. Who is really our target audience and is ExtJS (or *insert your option*) going to make using MODX easier for them?

Jim Graham

First, I come to you as a designer-turned-developer over the past few years. Thus, my knowledge of JQ or ExtJS is by no means deep.

I think an important reason JQ is more approachable than ExtJS is the quality of documentation. While it gives the experienced developer what they need to know, it also gives plenty of narrative and example code to illustrate how to use most functionalities. And community response to questions is pretty good.

IMO ModX suffers from a similar documentation issue that ExtJS does: Yes, the various classes, methods, properties, etc. are aptly enumerated, but there's not much in the way of explanation of intent, concept, or full and multiple examples of usage. This, in my mind, is the primary barrier (nightmare).

Patrick Nijkamp

I think that one feature where ExtJS will really stand out, and I dont see that mentioned in your post, is data management.

You are talking about GUI, sure jQuery can fill that gap. I have been working with Ext extensively and jQuery as well so that will work.

But what about data management...? In Ext when you link a store to a grid and update a store the grid is automatically repopulated. The ways you can use a store are infinite as are its configuration parameters.

I personally have never found a data tool as good as Ext. Separating data and view components even in script. The reason most people are frustrated is the lack of documentation. I see no reason why they should not use ext4. I do see a reason why they should NOT build their own wrapper in the next manager. Because they wont document it well enough for people to actually understand and because it differs quite a lot from the Ext philosophy.

I know of no data tool as powerful as ext and if you do please let me know! :)

Patrick Nijkamp

I have been working with ExtJS and jQuery for years...and I think if you only think of the GUI (as you seem to do, in your article) jQuery is a very good platform to build a manager on. It's fast, light-weight (especially compared to ExtJS) and has a lot of plugins.

I feel like you are forgetting the fact that ExtJS doesn't only do GUI exceptionally well, but it has amazing data management capabilities. You can manage data in JSON stores (or other types) and select/filter/update these stores and the GUI elements involved will get auto-updated. That is an amazing feature that I haven't found anywhere else yet in such a nice package.

I think ExtJS 4 is also a great improvement over 3, speedwise and classwise. I think the biggest mistake with the MODX Manager is MODExt. It's too far from the basic Ext philosophy and people can't get MODExt by looking at the ExtJS docs. The MODExt extension has nearly no documentation, sure some basic stuff...but no class reference and stuff like that. I always found it a hassle to build on MODExt and would rather see a pure ExtJS 4 manager solution that uses a custom theme.

I cannot imagine anything you cannot do with ExtJS that MODX needs, and even if that is the case: just script an addon not a new ExtJS core (so people are not forced to use MODExt grids instead of ExtJS grids for example). I think that will get the learning curve down quite a bit.

So to sum it up, jQuery for GUI: very nice. But I think ExtJS's data management capibilities superseed jQuery's or even plugins available for jQuery. I love the fact that ExtJS even separates data from view in the JS.

Mark Hamstra

I hope my post did highlight that I don't think ExtJS sucks, but that it's an extremely powerful library... it just deters community involvement in the core because it's so hard to learn.

Also, I don't agree with the notion that modExt is illdocumented or very different than the core Ext philosophy. It directly extends Ext and adds a couple methods here and there, and then it adds a bunch of components (in the same way Ext ships with components). Pretty much all modExt components directly extend a core Ext component, eg MODx.Window extends Ext.Window, while adding convenience methods or default behavior:

As I've written about before - when learning modExt, you're actually learning ExtJS, and frankly I don't think anyone is going to document the entirety of ExtJS again, just because in MODX it is labelled modExt and has some added functionality. That ExtJS has several ways it can be used and instantiated, whereas Shaun chose a specific style for his coding work, doesn't mean you have to do it that way.

I agree data management through stores is pretty awesome in ExtJS. That said, ExtJS is not the only library that does that. Kendo UI has something quite similar called a DataSource: and you could say EmberJS does the whole javascript MVC thing a lot better than ExtJS.

Patrick Nijkamp

I definantly got the fact you think ExtJS is good, no comment there.

I guess we could always go for jQuery as a GUI and add a data management script that serves just that purpose. With jQuery you do get the advantage of picking the best of everything instead of having to settle with the negative sides of stuff (like with ExtJS, I certainly agree that building components in pure javascript might not always be the best solution).

Jeroen Kenters

I've been thinking about this for almost an entire day, but I'm still not sure where I stand. Both as a developer and as a MODX Ambassador.

From the developer viewpoint, I think I agree with almost everything Mark already mentioned in his blog post. ExtJS is great for creating even complex interfaces in just a few minutes. Something that won't be easy to accomplish using anything else (like jQuery). That being said: it happens too often that I find myself debugging some weird JS error. Or that I want to use some ExtJS feature that is not documented well. Google searches usually result in finding the same problems without solutions or solutions for an older ExtJS version.
Converting the manager to jQuery (or anything else) will not solve all of these problems of course. Some things, like building complete interfaces in a few minutes, might even get a bit worse. But at least we would be using something that's really well documented and has a very large community.

Then there is the Ambassador (and sales in general too) viewpoint... The manager is really slow compared to the competition. Not a deal breaker for small sites, but if you have to maintain a major news paper site in the manager it might well be. Every lost second means money in this kind of business.
And how am I supposed to advertise MODX to WordPress/Drupal/etc devs? MODX on itself is little known to the rest of the world. Using a not so popular JS library like ExtJS really doesn't help to convince devs to start using it. There is a reason some devs stick to WP or Drupal no matter how terrible those systems might be; jQuery. While it might not be easy to build a custom module for those systems, it's at least easy to start with. No need to learn some new unkown JS library; just jQuery and PHP.

So yes: I guess I would love to move to jQuery or something better known. But I really hope we could still have all of the ExtJS power when we do.

Bob Ray

What a great discussion. Thanks, Mark for getting this rolling.

As I said earlier, as an admittedly neophyte user, ExtJS seems almost intentionally unintuitive to me, and as G.K. says, the HTML it produces is cluttered and difficult to style.

That said, there's no denying its power, and in the new version (if MODX Cloud is any indication), speed.

I would hate to think what it would take to do this in JQuery:


Mark, I think it's a great idea! From the moment I met MODX about 2 years ago, I really didn't like the idea that it's using ExtJS and I'm sure jQuery would do the job much better.

Martin Gartner

Hi Mark,

My question which may be a little off topic - but how do I include jQuery for usage in a CMP? I tried this in method loadCustomCssJs() but doesn't work. It seems MODx tries to minify the allready minified code!?


Mark Hamstra

Yep, off-topic and yep, that auto minifies and combines the files into one ;)

If you don't want that, you may want to use $this->modx->regClientStartupScript($url) instead.


Great post but I think what's being ignored here is once a site is built, ordinary people have to use it everyday. In that regard the sheer slowness of the back-end is a killer. So maintaining an updating a site becomes a real chore as we have to wait for the interface to load all the time.

Anything that speeds it up has got to be a winner, so please, please press on and give us a demo.


I'll sell my soul to ModX when it'll move from ExtJS backend UI :O
Just wondering - are you planning to continue rewrite backend UI to JQuery, or this is just proof of concept and nothing more?

Mark Hamstra

I've starting working on a follow up blog post which will go into more specific detail about the proof of concept: how it works, why it works that way, and hopefully that post will be the start of a community effort for making things better.

This post illustrated my proof of concept, the next post should raise the bar to an early prototype on which to continue building :) I've spoken with some people about how it works, and all of them are quite impressed, so I'm not going to give up the idea ;)


So why not throw out ModExt and replace it with ExtJS 4.x or something similar?? Seems extJS is not the problem, ModExt is the problem...ModExt on top of extJS it seems to me. Someone try a PoC using extJS 4.x or whatever only instead of ModExt??
Thank you, Tom (not a programmer)

Mark Hamstra

ExtJS 4 is worth a shot, but modExt is *not* the problem. If there is nya problem with modExt, is that's the documentation for modExt doesn't tell people to use the ExtJS documentation enough.

modExt == ExtJS with a handful of slight modifications and more sensible defaults to make it easier to use.

The issues I highlighted in this article are problems in ExtJS, not the changes in modExt.


OIC, thank you for explaining. Thank you, Tom


I think that you undersestimate MODExt issues a lot.

If you stay within what it has been designed to do, then MODExt do the job just fine.

Problems arises once you want to get out of the predefined behaviours.
Issues just pile up until you realize that you should have started with the Ext base class directly.
MODExt bring its own issues on top of Ext issues.

Mark Hamstra

I've not had modExt specific issues that I can remember as being specifically modExt, maybe except some CSS styling issues in edge cases.

The point that remains (which you seem to agree on) is that even when you get rid of the modExt implementation, you still have the downsides of Ext to deal with.


I had issues with MODExt, most of them form related, where the predefined classes assumed behaviours that i didn't need/like/want.

Those were not bugs, but issues that were all solved by falling back to the original Ext components.

Now indeed, we agreed on the part of ext downsides.
I can't wait to read you r foolow up article on your jquery approach :)

James Rotering

I haven't waded through all the comments yet, but I'm excited that this discussion is happening.

I've been contemplating in my head the past few weeks a similar concept; but rather than an "alternative manager", I've been thinking of it almost as "A separate CMS for content developers, built on MODX" (which I think of more as a CMS built for designers and developers). The focus would be much more on a pleasant user experience for putting content into web pages, building finished pages out of new and existing content. Instead of starting with full administrator access to everything, and locking down everything they don't need through permissions & form customization, take the opposite approach with an interface that only lets them build content with the tools you've explicitly provided for them.

Not sure whether there is any potential overlap between this concept and what you are working on, but there might be just a little bit.

Mark Hamstra

I'd reckon that a good interface designer could come up with a superb interface that would work for both content managers and administrators and developers. Couple that with some better default permission sets, and my guess is that we're almost there :)


I couldn't agree more. The complexity of making CMP's is stunting the growth of the community and thus the growth of MODX. I myself are one of the 'embarased' developers (i'm sure there are a lot more) that's just not smart enough to figure out how to make addons and modules for my clients and the community with the given information. Not for lack of ideas but it is just to hard to grasp all the necessary tech thats involved.
I would love to be able to contribute more to my favorite CMS.
But its not only the complexity of the technology itself thats holding me back it's also the lack of proper tutorials and examples. The fact that most of the RTFM pages leave me riddled sometimes is due to the fact that there are no comprehensible examples. Yeah i know do the 'Doodles'. I did that and failed because its not only Extjs but also modx conventions, PHP programming, UXD etc. and i don't have all the time in the world to work on this. One has to encounter only a few blindspots (not a shitload) to get hopelessly stuck. Sometimes i can't even formulate a proper question for the forums. I hope when there are more tutorials on making CMP's, all of theme together wil enlighten me/us.
Off course i'm not the first that encounters this but because i can't leave comments on the RTFM page i can't ask and no one can help the author of the page by leaving a good example. so i'll say this for the nth time to the modx team "open up comments on the RTFM pages so the community can help making them better and complete."
Right now the only a few people (elite?) can comment on a RTFM page. but haven't figured out yet how to join that group. Adobe does this on and most blindspots in the examples or content are dealt with in the comments on each page.

@mark when you are experimenting with a Jquery manager maybe this is a nice addition. . Making it possible to edit a site without the use of the manager at all. like a Quickedit for REVO

Phil Brook

Mark - This is a fantastic idea - ExtJS is such a big learning curve - personally I always use jquery.

Comments are closed :(

While I would prefer to keep comments open indefinitely, the amount of spam that old articles attract is becoming a strain to keep up with and I can't always answer questions about ancient blog postings. If you have valuable feedback or important questions, please feel free to get in touch.