☆ A M B ☆
If we get lost here in technical excitement and the underlaying cause, that brought us here in the first place, is not adressed anymore, this thread will be all but forgotten in two weeks time and all will be as was/is.
Let's stay on topic and leave technical/personal issues out of this for now. Lots of great ideas in this thread, but I think that is a bit too early. It all starts at the beginning, being true leadership of the project. Once that's been taken care of we can move on to the roadmap with all the awesome features we need. One step at a time or otherwise it will be the same thing all over again, where nobody knows where we are heading and what everybody is doing.
I need to justify to myself and my clients why MODX. If we can build functionality that Wordpress can't deliver it has to be done at a speed and price the client is willing to tolerate.
In other words, who is the target customer. Gary mentioned We (at MODX) are doing things with ACLs that you'd find hard to do with any other permissions system. Personally none of my clients want anything complex. They either want a few pages in the web context requiring login or they want a few pages in the mgr context only accessible by selected CMS users. Therefore let's build functionality that a) gives us a differential from Wordpress and b) addresses the needs of the vast majority rather than introducing complexity to enable it to work in every conceivable scenario.
That's all I had to add.
If there are many (some threshold number) downloads of an "Extra", then shouldn't that automatically trigger the dev team to add that functionality to the core? If you can think of reasons why that is not true, then at least: when a threshold number of downloads on an Extra occurs, shouldn't that be a trigger to the dev team that the Extra belongs in a special grouping of Extras that at least get a cursory test by the dev team, awarded a gold star, and be listed somehow as having been tested - and passed? Otherwise, you'll get a newbie like me walking in the door and spending 100 hours trying to get an Extra to work - that simply does not work - but is convinced it has to be the newbie's own fault.I would just like to add my voice in support of this very well-made point. My own example: the Login extra. It would make only huge sense to complete all the effort that has gone into the security model of MODx by having a properly integrated and supported front-end login/password management facility.
☆ A M B ☆
I don't see comparing MODX to WP as 'the big picture'.
MODX is as "different" from WP as it can get. If doing a future-proof, complex site in half the time with a better UX isn't a selling point than I don't know what is.
As much as we might envy the size of a user base like WP's: it's a different market/target/audience.
MODX is all about flexibility while others focus on DIY and easy of use.
The only REAL constructive criticism I've seen in this thread is from Bob Ray. Everybody else wants to rip MODX 2 into pieces. If this thread was named MODX 3 "Constitution" I'd agree with everybody. But so many want to see all existing code so drastically changed it would break everything (except the colors of the logo) and then have MODX to agree that would be just great!?
I don't see a roadmap for Drupal to be transformed from a microwave to a toster, from a ferrari to a kia... Sorry.
Quote from: dinocorn at Jun 03, 2014, 04:49 PMIf this is possible with the current architecture I'm so in with helping =), that would mean that I can contribute with my existing knowledge (as I also had to learn emberJS, I just experimented a bit with it, but far from good with it...)...what would be the approach to get the data from the db? PHP in the first line, basically snippets inside the manager (very simply spoken)?
Let's talk more on if it is possible with the current architecture so I can convince you to contribute regardless
The work being done in Matboard targets a breaking version, of which there is yet to be an architecture, so the answer of whether or not it is possible is...sure?
I've looked at the Matboard GitHub page several times, but have never been able to get any sense of what I would actually *do* if I wanted to contribute. I'm probably just missing something obvious, but I'm probably not the only one.
I'll work on more of a "getting started" page in the README or as part of the wiki. I'm hoping to be able to dedicate some significant time to the project particularly next month.
Matboard is described as a "proof of concept" project, but is there really any doubt that the Manager (especially the simplified version used in Matboard) could be done using any of the named JS platforms? Also, if we're going to compare Manager options, shouldn't there be one that uses JQuery and one that doesn't use any JS platform at all?
The "proof of concept" is a bit of a disclaimer I suppose. When I started matboard, I was looking for a way to get started on breaking changes free of any sort of official announcements or decisions. While the project was born as a way to explore user experience as it relates to MODX, I wanted to keep the project more abstract and not MODX specific.
Matboard is a proposal for a way we can discuss, explore, and test different JavaScript solutions to the same problems. Currently there is jus one rather plain experiment, there will be more to follow and I hope people feel free to propose new ones. It tries to borrow from the design process, in that we put our work on a board if you will, step back, discuss and critique it. That is why I want to stress we aren't working on anything set in stone here. I think it is important not to get too fixated to whatever you are putting on that board so that when you step back you can dissect it and not yourself as well. I would like the discussion to be able to try and poke holes of any size in any solution so that at the end we know we have ran some unit tests from a user experience and design perspective.
This leads to my next point, which I would really like to stress.
I'd like to work on a matboard experiment, but I am worried if it doesn't get chosen I will be wasting my time.
Completely valid concern, but no time is wasted in this process regardless of what, if anything, is chosen in the end. For example, I think the most important experiment, which has yet to be written, is the ExtJS version. Why? I'd also like to borrow from the scientific process and even though many feel like ExtJS time has come and gone, I think it is critical that we can run tangible baseline comparison against it in our discussions.
I mentioned earlier that the mission statement in my mind has evolved from an attempt to find "the" framework that fits the bill to an attempt to not have to pick one at all. Rather than hoping we find the toolkit the solves our woes, maybe we can bring creative freedom more so into the Manager.
Sounds to good to be true? Trust me, I know. I'd also like to encourage anyone to not hesitate to bring concerns up. There are many hurdles to conquer no doubt, I just hope there still aren't to many under the bleachers I forgot about
tbh, WP is as flexible as MOdx is.I don't really want to add to this thread drifting offtopic but I guess we have different definitions about what flexibilty means.
Wordpress API is awful, but the admin is far more easier to customize than Modx is. In part due to ExtJS but not only. "Extending" the base is way more easier than extending modResource. Without having to know much about php.
We may prefer the way Modx does things, but it does not make it more flexible.
☆ A M B ☆
I don't really want to add to this thread drifting offtopic but I guess we have different definitions about what flexibilty means.
If flexibility means hacking PHP into a *cough* "theme" then yes, anything is possible in WP. Just like it's possible to open a can with a screwdriver.