Community Concerns

2. We definitely need flexible fields for both Resources and Users that are available for single-query searching and sorting. ClassExtender helps with this, but it's not a long-term solution. I will be more than happy to see it become obsolete or morph into a wizard for a new system.

This is more UI than architecture related isn't it ?

I probably wasn't clear enough on this -- nothing to do with the UI.

At present, Resources have dedicated fields. If you want to add more without extending the modResource object (which has its own problems), you have use TVs, or Resource properties. Both are relatively hopeless for fast and convenient data storage or retrieval. Retrieving resources based on their TV values can mean dozens (sometimes hundreds) of queries to the database to show a single page (more detail here: http://bobsguides.com/blog.html/2014/06/02/why-extend-modresource/ ).

You can get resources based on their dedicated content fields with a single DB query. There needs to be a way of adding custom fields without giving that up, which would mean a change in architecture.

Quote from: BobRay at Jun 03, 2014, 05:43 PM

I probably wasn't clear enough on this -- nothing to do with the UI.

At present, Resources have dedicated fields. If you want to add more without extending the modResource object (which has its own problems), you have use TVs, or Resource properties. Both are relatively hopeless for fast and convenient data storage or retrieval. Retrieving resources based on their TV values can mean dozens (sometimes hundreds) of queries to the database to show a single page (more detail here: http://bobsguides.com/blog.html/2014/06/02/why-extend-modresource/ ).

You can get resources based on their dedicated content fields with a single DB query. There needs to be a way of adding custom fields without giving that up, which would mean a change in architecture.

Something like like Resource Variable ? Can be an addition. Having Template Variable and Resource Variable can be a really good feature.
Isn't that also close to what Content Block from modmore offers ?

I'm not familiar enough with Content Block to answer that, though it is more or less what ClassExtender offers for both Users and Resources.

Quote from: dinocorn at Jun 03, 2014, 04:49 PM

Quote from: netProphET at Jun 03, 2014, 02:43 PM

Quote from: lossendae at Jun 03, 2014, 12:23 PM

Going full stack with either Angular or Ember can cause the same issue as Extjs in the long run.
Why not go back to something simpler first (php + templating) and add a few bit of javascript when necessary ? Decoupling as much as possible the manager from a specific JS framework usage outside of core features.

+10,000

I agree with this as well. I started the matboard project out of fear of being responsible for picking "the" framework that was chosen. Especially in today's rapid landscape I'm not sure there is one answer. While the project started really as a way to offset some of the responsibility for choosing "the one" to the community, it has evolved into the realization that creative freedom may be able to brought into the Manager without binding it to a particular JavaScript framework.

This possibility excites me more than anything, and I think we can do it.

If 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)?

Quote from: BobRay at Jun 03, 2014, 04:04 PM

This the most active thread I've ever seen here, and it's also the first time I've ever seen a truly sophisticated discussion of the pluses and minuses of MODX's current and future architecture with input from many key MODX users and developers.

Not true, as I have addressed most of these points in the past and got attacked for them by community members on this very forum. Its however good to see the community has matured.

Back to the topic at hand:

1. I would much rather see xPDO tweaked than abandoned. There is a ton of xPDO-dependent code out there that would have to be extensively rewritten and tested if we moved to another ORM. I don't think there are any fatal flaws in xPDO's architecture and it's one of the most intuitive ORMs I've seen.

xPDO is dated, time consuming and not to mention that horrid thing called xml for schemas, Doctrine should be the defacto goto ORM or use a Datamapper instead.

3. I also see the templating engine as not a high priority. Whatever it's issues, I think we have much bigger fish to fry.

I think if you look at the codebase you will see that this is a high priority, whether it stays or go. Everything is very much coupled so tightly you can't remove or swap a component without it breaking everything else.

4. I'd like to see a return to a role-based security permissions system, where each user's role determines what they can see and do, rather than a system where the users' potential actions are controlled by a complex interaction of permissions, policies, policy templates, roles, and group membership.

This is by far one of the most complex for no reason things I have seen in a CMS that is aimed at non enterprise websites. A simple ZendACL implementation would be way better.

5. I have mixed feelings about using Composer for all package management, though there's no question that Package Manager needs work. I think Composer creates a very high technical bar for contributors. I see some technical and practical advantages of it, but I'm not sure they outweigh the negatives. It's difficult for me to be objective on this because for me it would mean losing many of the advantages of MyComponent and having to redo several dozen extra packages. I'm also concerned about the effect of having every MODX extra package become suddenly obsolete. Maybe there's something here I'm not getting.

This point has no relevance to what composer would do for MODX, composer would by no means act as a new Package Management(I think this is broken by design either way), composer is a dependency management tool, it would mean we no longer have to worry about how dependencies load, follow a industry standard autoloading mechanism and be a part of the wider PHP community as a whole as the MODX community seem to have always been in a silo away from everyone else.

6. I dislike extJS as much as the next guy, but I'm not sure moving to something like Angular or Ember is the answer (though I do like what I've seen of Ember). JavaScript is always going to slow things down and raise the bar for developers. If the Manager could be re-done in plain HTML and CSS with some Ajax calls to processors, I think the increase in speed and ease of customization would more than outweigh any disadvantages.

I think anyone interested in this should contribute to JP's matboard and we can see how best to approach this and no Ember or Angular Single Page Application wouldn't be an option. Plus no one wants to be in a lock-in again after this whole ExtJS madness. [ed. note: easylancer last edited this post 12 years, 3 months ago.]

Hey all,

I'm gonna step in now and give a few thoughts ... mainly in reply to Andrew (silentworks) post but also just general observations.

I agree with Andrew (silentworks) on the fact that this is a subject that's been broached a few times. I think (for the better as well) that we are a community of opinions ... we all strive for the better of MODX but also have different needs and wants. In the past, these discussions have fizzled out or (like this one was a few pages back) into a 'see who can throw the shit at the wall and make it stick better' conversation - please, we're all better than that. Everybody should have their say, nobody left out, and not one person made to feel like their say is being diminished.

For me, personally, I don't think xPDO is outdated ... it needs a few updates but it's certainly not outdated. I'd much rather spend a bit of time creating a XML schema (which sometimes actually makes you think a bit more about the data model you're creating) than not. That being said, I think Jason (opengeek) was or still is looking into not even needing the XML schema for xPDO - I don't want to be jumping the gun here or making assumptions, I just remember in some far distant part of my mind having that discussion.

Regarding the template engine, I do agree with a few of the previous posters that it's not a high priority to change. I can understand, I think, where you are coming from Andrew though ... this is something that should be discussed further indeed though ... what are the shortcomings of what we have now?

Onwards to ACLs ... bloody ACLs, haha! Bit like marmite, love 'em or hate 'em. I'd argue that, yes, ACLs are difficult to get to grips with but they're definitely not impossible. We (at MODX) are doing things with ACLs that you'd find hard to do with any other permissions system (definitely not possible with the Evo permission system). So, yes, the ACLs can be improved - a lot of feedback we get is in the presentation of those in the Manager, I think we've all acknowledged as a team they need to be presented better (and made a bit more accessible).

Onto Composer, yes and yes - we need to support Composer going forward in my opinion. Is it straightforward to do that at this point in time? Nope. That doesn't mean we can't look down the avenues of what it would take and start that from there. As far as Package Management, yes, people do confuse Package Management with Composer sometimes ... they are two very different things. I don't see Package Management as broken ... just needs a bit of attention in the right places. I mean, for one use-case, let's think about Marky Mark and his business model if we suddenly ditched Package Management :p

And we have the designer bit, oh lord, yes ... please do contribute to Matboard I'm not even going to comment on the designer stuff, it's not my forte and I'd likely sound stupid even attempting to talk about it. I will say though, the decision to choose the next JS framework (if we do over something more home-grown) is a big one and not one to be taken lightly ... how many Extras out there now rely on ExtJS? Not that I think ExtJS is wonderful, but sometimes better the devil you know ... I'd like to see concepts, if anybody has any, that would mean we get the same kind of components (grids, trees etc.) that we need for the Manager without having to jump through hoops more than what we have with ExtJS ... and that's my parting challenge I leave to you all

I'm almost sure I've seen posts suggesting that Composer/Packagist be used in place of transport packages. That's what I was responding to. My apologies if I misread or imagined those posts.

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.

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?

Bob, I did the "vanilla js" version. Well, mostly - I still need to get around to dealing with the case where content is pasted into the form from the client's Edit->Paste option. onChange? onKeyUp?

Basically you have a simple requirement to create a page that uses your choice of javascript to have a title, a form field, and a save button. The title has to change as you edit the form field, and the save button has to be enabled/disabled according to changes to the form field.

You know, ExtJS wouldn't be so bad if Form Customization actually did what it's supposed to do, and for all forms instead of just resources.

Add a field - if it isn't in the resource_extended_fields table, then ask to automatically add it, as well as re-writing the table's structure file, whatever that might be (personally I have no problem with xml, but PHP ini file format or JSON would work just as well). Processors would simply grab the fields from the POST and save them.

I know somebody who's working on an alternative Manager using a custom version of JQuery who has implemented AJAX auto-saving of all fields, not just in System Settings. It's really nice, and blazingly fast.

I am glad and excited about this thread. It is comforting to watch people now discussing the status quo and future of the MODX codebase - people nonetheless, who actually seem to know what they are talking about, one way or the other. Which unfortunately does not include me, I'm just an everyday user of MODX. I am able to file bug reports and help out the occasional newbie, but this discussion is way over my head. I feel like a passenger on a free plane flight, listening in on a serious discussion about fuel shortage and flight routes the pilots are having, because they left the intercom switched on.
As such it is exciting, as well as scary.

Which brings me to the point of my post: while it is tremendously great to see the technical discussion picking up momentum and bringing MODX staff and community members closer together, let's not forget about main point and probably the more important issue this thread started out with - the percieved shortcomings in the MODX LLC / community communication culture and the proposed changes to the MODX organization, i.e. foundation. 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.