MODx 3.0 based on Composer + Laravel 4 and Angular.js + jQuery

I've heard that something will be incorporated into the core.

I've been researching "frameworks of the month" lately and am anxious to discuss them with the community. I certainly see the appeal of AngularJS. As Jason mentioned front end dependencies for 3.0 are TBD.

My problem right now with AngularJS is simple, it claims to enhance HTML but really it just negates it. For example, here is their official docs shown with JavaScript turned on and off.


Seriously? The main nav links on their homepage don't even work without JavaScript.

I've been experimenting with ways to make AngularJS "no-js" friendly but it is difficult because AngularJS wants to be fed a different kind of markup than the web is built on.

To be honest, I don't see where it's a problem.
MODx uses javascript for pretty much everything.

The left tree for example, is one of the most loved feature of the CMS, and would not work without javascript.

Nowadays, it's more likely to run into users who can't use the admin on a tablet than one trying to use it without javascript enabled.
Wouldn'it be more logical to just show a warning message to this last user, telling him that javascript is required for the admin ?

Quote from: lossendae at Nov 24, 2013, 03:05 AM

To be honest, I don't see where it's a problem.
MODx uses javascript for pretty much everything.

The left tree for example, is one of the most loved feature of the CMS, and would not work without javascript.

Nowadays, it's more likely to run into users who can't use the admin on a tablet than one trying to use it without javascript enabled.
Wouldn'it be more logical to just show a warning message to this last user, telling him that javascript is required for the admin ?

I think MODX using JavaScript for pretty much everything is a huge problem. Certainly don't want to justify doing something in 3.0 because it was done that way before. I agree, 99% of users will have JavaScript turned on and most will be using modern browsers. The issue with me isn't with whether or not a page is functional with or without JavaScript.

AngularJS is what HTML would have been, had it been designed for building web-apps.

The issue is that mutilating HTML with a framework that makes it work "the way it would if" is putting the cart before the horse and can lead to being backed into a dangerous corner.

This is not to say I'm against AngularJS as an option, I'm just not convinced.

Quote from: dinocorn at Nov 24, 2013, 03:16 AM

I think MODX using JavaScript for pretty much everything is a huge problem. Certainly don't want to justify doing something in 3.0 because it was done that way before. I agree, 99% of users will have JavaScript turned on and most will be using modern browsers. The issue with me isn't with whether or not a page is functional with or without JavaScript.

The issue is that mutilating HTML with a framework that makes it work "the way it would if" is putting the cart before the horse and can lead to being backed into a dangerous corner.

This is not to say I'm against AngularJS as an option, I'm just not convinced.

Working with AngularJS involve much more planning than scripting.

The following thread can help put things in perspective (better than I do ) : http://stackoverflow.com/questions/14994391/how-do-i-think-in-angularjs-if-i-have-a-jquery-background

I do agree, going with Angular would be as involving as it has been to go with ExtJS. Most contributors will not be able to ge around it as easily as if jQuery is picked.

Quote from: lossendae at Nov 24, 2013, 03:36 AM

Quote from: dinocorn at Nov 24, 2013, 03:16 AM

I do agree, going with Angular would be as involving as it has been to go with ExtJS. Most contributors will not be able to ge around it as easily as if jQuery is picked.

I think the big question is does the API for interacting with the Manager (to build custom themes, components, and pages) have to require any particular front end framework?

I think this is a great suggestion that would very likely assist MODX to gain some serious adoption. Drupal 8 is headed down this path -- leveraging existing Symfony components to expand it's ecosystem and reach.

IMO Modx should not be so tightly coupled xPDO. Developers should be free to switch to different implementations if they desire to do so. This is one of the many reasons in the past we have had difficulty justifying the adoption of Modx to larger corporations -- xPDO is barely known, whereas Doctrine for example is extremely well known, and it is also understood and contributed to by a much larger pool of developers.

Modx would also benefit from a mobile-first approach for the admin UI and an improved widget-type system that allows users to customise their own dashboard. But instead of defaulting to security feeds, default it to widgets what capture Modx is used so often - analytics, social analytics -- ghost is a great example (although it's primarily a blogging platform). Modx is of course not a blogging only platform like ghost, but with popularity of the Articles extension shows how commonly it is used as one.

The thinking and execution behind the Modx CMS admin itself is unparalleled, it truly is a fantastic system to work with from a user perspective. Resources, Chunks, Access Control, User management, a Plugin system, the admin interface -- it's done this exceptionally well. What I believe it needs to truly gain heavy traction particularly with companies (Fortune 500 and larger companies in particular) is to loosen the framework up a bit and encourage the use of existing packages.

The whole point of MODx is that it is a CMS built using a xPDO-based framework.

Been doing some experimenting with Angular. It is a crafty tool, no doubt. I can't find the link at the moment but there is a site showing the source for the same task app done on several different frameworks. Would like to go through something similar to really get hands dirty and compare some of these front end tools.

As oneplex is suggesting, the "new thing" is to offer the users of a tool/cms/framework the ability to choose. We've had "modules" (extras) for a while in the CMS world, allowing for the extensibility of the tool. The next step is to allow for the ability to choose for more in depth, under the hood, things, like the ORM.
And as far as I have seen, JP DeVries, who seems to be driving this discussion of MODX 3 forward, likes this idea of letting the user choose.

So just to summarize a little bit from what I have understood from this interesting discussion and in particular what was said by the MODX gurus.
(Disclaimer! This list is just my own understanding and by no means a summary of set in stone official statements.)

- MODX 3 will not be based on a back end framework like Symfony or Laravel. But maybe some third party components.
- It will use some kind of packaging/dependency tool like Composer.
- MODX is, and will probably continue to be, tightly coupled with xPDO. So probably no other ORM for MODX 3.
- It will not use ExtJS. Will use other/better/simpler front end tools. Angular.js is being heavily discussed.

Please correct me if any of the above statements are totally wrong.

---

I'm still very much in love with the simplicity (and power as far as I can see) of Laravel 4. And Angular is still super cool and powerful.
I've tried the latest Symfony a couple of months ago, and that too is really nice, but Laravel seems even simpler.

Although I know MODX is not aiming to be the simple tool, but the most powerful one