MODX Manager - can we make improvements?

Forgive the train of through/minor rant approach of this post!

I'm wanting to try and help improve the manager experience in MODX Revo, but having forked the repo and taken a look around it seems very *very* confusing. I know not the ins and outs of ExtJS other that it seems to want to do crazy things like this: https://gist.github.com/Mark-H/503e4107bf9d75fbd54b which looks, astonishingly, to be the markup for ONE single button on a page. Why is this even a table? Not only are tables slower to render, it's not even tabular data!

I took a quick dig around in dev tools at the output html within the manager on the dashboard, looking at the resource tree:



It's div inside div inside div inside div inside div. It's massively over-bloated. Why is this so complicated? Why does MODX insist on absolutely positioning all the panels AND having them overflow: auto too? This is horrific user experience, it's not longer the 1990's - we don't need the javascript/css equivalent of an old-skool frameset. Do we? This problem is only exacerbated when you have to set up a site for additional languages. https://github.com/mikrobi/babel/issues/47

To rectify the panels with scrollbars inside panels with scrollbars over the outer panel's scrollbars we had to add some MORE javascript to MOVE the node somewhere else. Whether or not this is a one-off, odd one out sort of thing is by-the-by; The manager interface is massively and unnecessarily over-complicated.

I really want to make some improvements to it, but really not sure where to even start. I've looked through some of the SCSS and considered making changes but then I've got to set up SASS, Grunt, Node, etc etc etc and figure all that out too. Can the HTML tpls be simplified? Where can things be slimmed down? I've noticed that ModMore have a gallery plugin which seems to only rely on the ABSOLUTE BASICS of ExtJS and discards it wherever it can to improve speed and user experience: https://www.modmore.com/beta/ - can a similar approached be achieved in the rest of the manager?

Also, I believe MODX uses Smarty for templates which I understand is part of the slowness overall of MODX's output - how much work would it be to swap this out for a faster templating engine? http://www.raintpl.com/PHP-Template-Engines-Speed-Test/ - not suggesting that one in particular, but the speed tests run suggest that Smarty is pretty slow in comparison to even Twig and worse for memory consumption!

The thing when working with ExtJS is that you're not supposed to look at the DOM.

You build JavaScript classes instead (which can do cool stuff like extend others and selectively override bits), which do make more sense than the DOM you're inspecting, and then that JS gets parsed into the DOM and what not. The table-mess and divs-in-divs-in-divs is how ExtJS works for cross-browser compatibility. Made sense when ExtJS 3.x was built, but now I'd say not so much.

There are ways to customise the tpls for ExtJS (and I think that happened for the button tpl in 2.3) but there's probably no escaping the general markup structure. ExtJS 4.x is supposed to be a lot cleaner in general, but that's not a simple upgrade but would mean rewriting everything. Personally, I'd be more inclined to rewriting to something that is not ExtJS if we're rewriting


The biggest problem with any of these major changes is backwards compatibility. Take out Smarty, and the core (and extras using it) break. Take out ExtJS, and every bit of code written to interact with the manager will break.


MoreGallery was/is an experiment to see what we can do with other systems in the manager (Backbone in this case) and it works nicely, but it's a completely different developer mentality. ExtJS aims to be your framework for developing the entire thing, while Backbone is a building block to use with other building blocks to build your own custom framework.

As far as rewriting with something else, I've been playing with Angular, and so far I'm quite impressed.

Quote from: sottwell at Sep 22, 2013, 08:11 AM

As far as rewriting with something else, I've been playing with Angular, and so far I'm quite impressed.

Great to hear this Susan, I am a strong advocate of Angular but believe it would still leave us with a bit of a steep learning curve for anyone who is already familiar with working the jQuery way or ExtJS way. I think this topic will require a bit more investigating in order to come up with a viable solution that will work for everyone.

As Mark stated, most extras will be broken based on some of the changes that will be made for future major release of MODX, this should be expected, but at the same time, we need to make that transition as easy as possible for extras developers.

Yes, everybody will have their favorite library, and in the end the MODx team has to make their own decisions.

When you get right down to it, the Manager is nothing but an AJAX-based interface to the core. Fancy forms. The trick is to learn to understand xPDO and the core well enough to use it.

In fact, it could be done in plain HTML and CSS or in Plain HTML with some vanilla JavaScript.

Exactly. Actually, building a whole new Manager would be mostly just tedious, it's all just forms and the database, after all. Evo does it very simply, if not too terribly elegantly.

Properly using the MODx core to build the Manager means understanding the core itself as well as xPDO, all the API functions and database abstraction methods. I just gained some new insight this morning, in fact - the comments in the modrequest.class.php file refer to this URL http://www.martinfowler.com/eaaCatalog/frontController.html - very interesting concept.

Thanks for the replies all.

I started at the end of last week to take a look around the default manager theme and creating my own. It would be great if this was an easier thing to accomplish!

I absolutely love the concept of MODX, I love that I have complete control over what comes out on the front end of the site - but the manager really does need speeding up. How much of a big deal is it to upgrade to EXTjs 4 or whatever the current release is? If it's a big change, is it the kind of breaking change that 2.3 should bring - in the same way that some changes in 2.2 brought about better things?

Quote from: sottwell at Sep 22, 2013, 08:11 AM

As far as rewriting with something else, I've been playing with Angular, and so far I'm quite impressed.

I'm mostly front end, so stick mainly with CSS/HTML/jQuery, but the Angular site on a quick scan seems to be much cleaner?

It would require a whole new Manager. The existing Manager is built on an extended, customized version of ExtJs. See /manager/assets/modext for the files. This way we can have widgets like modx.panel.chunk.js and modx.grid.resource.active.js for fine control over the Manager interface. Theoretically it's great, but in practice it doesn't live up to expectations. Giving up the KISS principle for bells and whistles isn't usually a very good idea. I suspect, however, that a good part of the bottleneck is the adding of Smarty to the mix. I didn't like Smarty 10 years ago, and I don't like it any better now.