Community Concerns

On a side note, I actually don't find changing the parsing/template engine to be of a very high priority for MODX at current; it's not a pain point for the most part, and isn't difficult to learn. Far more important work should (IMO) be focused on:

* Moving away from ExtJS 3 in the manager interface
* Adding in Content Elements (or something similar) to allow Resource-specific page fields to be defined, and moving away from a pre-defined standard set (would also help simplify Form Customization). Think "Resource Types".
* Adding in Composer support to allow more efficient utilization of libraries, installation of packages, and life-cycle management of development for MODX sites
* Bringing up a stark discussion on whether xPDO is the right tool for the ORM job. It's dated, and there are far more powerful OS ORMs out there that have many more contributors and would be more familiar to incoming MODX contributors

IMO, development should be planned, detailed, scoped and prioritized around these items.

As I told YJ last night - I still believe MODX, at its core, has the best architectural layout and focus of any OS CMS out there. But others are catching up fast, and these above things would help push MODX to the next level.

Quote from: splittingred at Jun 03, 2014, 08:38 AM

On a side note, I actually don't find changing the parsing/template engine to be of a very high priority for MODX at current; it's not a pain point for the most part, and isn't difficult to learn.

If MODX would change its parsing/template engine, it would not longer be MODX (IMO)
There are allready several ways to use other template-engines, if one feels to need any.

Quote from: Bruno17 at Jun 03, 2014, 10:01 AM

Quote from: splittingred at Jun 03, 2014, 08:38 AM

On a side note, I actually don't find changing the parsing/template engine to be of a very high priority for MODX at current; it's not a pain point for the most part, and isn't difficult to learn.

If MODX would change its parsing/template engine, it would not longer be MODX (IMO)
There are allready several ways to use other template-engines, if one feels to need any.

completely agree with that from my side, and as Bruno says, it is probably already possible to use other template-engines, it would be nice though to have something like packages for different ones that would act as a drop in replacement, not as high of priority that I'd like to put (sparse) contribution time in it though...

Quote from: splittingred at Jun 03, 2014, 08:38 AM

* Moving away from ExtJS 3 in the manager interface

absolutely, highest priority of all! I'm tempted to vote for emberJS instead of the more popular angularJS, but not sure if "we" would go for another "niche" library (though much better one) with a desicion like that...

Quote from: splittingred at Jun 03, 2014, 08:38 AM

* Adding in Content Elements (or something similar) to allow Resource-specific page fields to be defined, and moving away from a pre-defined standard set (would also help simplify Form Customization). Think "Resource Types".

also very high priority for me, there was a discussion in the forums (I guess) about something like that recently and as far as I remember Jason said that the "default" fields were a decision made because of performance

As far as Content Elements, I found BobRay's latest blog post very interesting. http://bobsguides.com/blog.html/2014/06/02/why-extend-modresource/

Quote from: splittingred at Jun 03, 2014, 08:16 AM

Quote from: sepiariver at Jun 03, 2014, 03:15 AM

Today, there's no shortage of love and commitment to MODX from the people in MODX, LLC, and that in itself is something to be positive about, don't you think?

YJ, absolutely, but I would just be careful about saying there wasn't in the past. You don't know the motivations or hearts of those who were before you, and it does no one good to speculate otherwise.

Thanks for this, Shaun. And I agree, speculating on the hearts of others is a losing and dangerous game. Just so you know I wasn't referring to you there, but to the majority of upper management at the time, who explicitly expressed in documented comms that MODX CMS was *not* first priority.

It's true Ryan was a small part of that management team but now he's a bigger part of a very different management team, with a vastly different agenda and strategy. It's a huge leap between then and now, within the LLC, and one of the main points I've been trying to communicate here. It's a win, amongst losses.

On that note, MarkH am I not allowed to celebrate those wins? Is there a rule now in the Forums that people who celebrate wins, those with a positive outlook on the current state, are not allowed to post? Are you saying that just because I have a "staff" badge on my icon I can't express my true feelings and passions about MODX CMS?

My post was not propaganda. It was my honest take on things, and even if I didn't work for the LLC I'd have the same message and outlook.

Wholeheartedly agree though, regarding Jason's technical leadeship — wouldn't want it any other way [ed. note: sepiariver last edited this post 12 years, 3 months ago.]

YJ, I'm not saying you can't celebrate wins, or have a positive attitude for that matter. In my last post I highlighted that I too am positive about the future of the MODX project, assuming we manage to change the project leadership for the better so everyone wins.

What I do take a problem with - despite my respect for you as a person and our interactions in the past - is how your optimism translates into muddling down the serious concerns being offered and discussed in the thread, and how the post is all about "we got this, just wait" and not "okay, here's the plan and how you can help" which is exactly what we were talking about.

That staff badge has a big impact on how people look to you and interpret your message, so use it wisely.

Quote from: Bruno17 at Jun 03, 2014, 10:01 AM

Quote from: splittingred at Jun 03, 2014, 08:38 AM

On a side note, I actually don't find changing the parsing/template engine to be of a very high priority for MODX at current; it's not a pain point for the most part, and isn't difficult to learn.

If MODX would change its parsing/template engine, it would not longer be MODX (IMO)
There are allready several ways to use other template-engines, if one feels to need any.

I think this is an important thing to understand and discuss. One of my mistakes as a team member was to try and discourage key contributors from forking or advocating fundamental changes, such as the templating engine or anything else really.

The pursuit of creative freedom can lead us to a place we need to allow ourselves to create freely. Official roadmaps and the concern of whether or not something would be approved as a PR can become lines that creatives need not draw within.

absolutely, highest priority of all! I'm tempted to vote for emberJS instead of the more popular angularJS, but not sure if "we" would go for another "niche" library (though much better one) with a desicion like that...

Lately I have been working on trying go get some momentum going with the matboard project and we are still in need of a EmberJS advocate. I attended @html5devconf this year and got a chance to learn a lot about EmberJS and make a few acquaintances. I'd love to explore and discuss what it brings to the table further.
https://gitter.im/jpdevries/matboard

Quote from: dunnock at Jun 02, 2014, 04:06 PM

If the foundation would be done, the 5 board members should be cherry picked from different aspects of web development. One has to master SQL, One has to master ExtJS (cursed thing), etc... in my opinion. And that is tough pick really who would be qualified for the positions. Mark could be the chairman and the big leader. But rest of the positions, hmmm.... from what I've followed the community. There are rare few who understand core enough. But hey, that's just my opinion again

With all due respect to Mark, but I think the only person in MODX Universe suitable for the position of chairman is Shaun McCormick.

To be honest, in a board like that, there shouldn't even be a chairman (though I am flattered Petri). There should be 5 people with equal authority. The only chairman it needs is one to lead meetings, and that one should be different each time.

Quote from: Bruno17 at Jun 03, 2014, 10:01 AM

Quote from: splittingred at Jun 03, 2014, 08:38 AM

On a side note, I actually don't find changing the parsing/template engine to be of a very high priority for MODX at current; it's not a pain point for the most part, and isn't difficult to learn.

If MODX would change its parsing/template engine, it would not longer be MODX (IMO)
There are allready several ways to use other template-engines, if one feels to need any.

I would like to think that Modx is more defined by its ease of use rather than its template system.

And like Shaun said, it's relatively trivial, this is just about the template system.

What happen when /if Modx switch from xPDO to Eloquent or Doctrine ? And what about a real routing system ?

There will always be someone in the community to say that *this* feature is what makes Modx -> Modx. Therefore, should Modx stay just like it is or should it try to be something different (please note that i did not use the terms better or evolve voluntarily) ?

Quote from: exside at Jun 03, 2014, 10:12 AM

Quote from: splittingred at Jun 03, 2014, 08:38 AM

* Moving away from ExtJS 3 in the manager interface

absolutely, highest priority of all! I'm tempted to vote for emberJS instead of the more popular angularJS, but not sure if "we" would go for another "niche" library (though much better one) with a desicion like that...

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.

One of the key advantage of Wordpress adoption, is that it does not require to know any javascript to customize the admin very deeply.