Modx revolution future Vs rest of the world

Quote from: sottwell at Feb 22, 2013, 05:20 PM

One word. MIGx.

What do you mean ?

That is the "killer app" for MODx Revo, as far as I am concerned. It takes the concept of Template Variables and raises them by an order of magnitude. Not only does it provide for custom TVs, it can use the usual tmplvar tables or any of the other MODx tables (useful for managing customized groupings of resources) or its own custom tables, and it can also be used in the Manager to provide the power behind a Custom Manager Page. I would be interested to know of any other CMS that has anything quite like it.

Susan I can tell you that most other CMSes have this feature built in and not as a addon, it is more engraved in the core with a better implementation level. Plus the MIGX UI is ugly and sometimes buggy.

Before I sidetrack lets get back to the issues Stephane is discussing, I think changes will happen in the MODX world in perspective to Composer, using 3rd Party components and getting the community involved more. I am very happy with the answers that Jason has given about the direction the CMS will take, I would just like to see a clearer roadmap of these directions.

I worked on various CMSes in the past and their direction were always clear, I think the lack of clarity in the direction of MODX has led some developers to believe that the CMS isn't moving forward or is stuck in the past.

I can only say that we shouldn't think the CMS is ok where it stands because more users are adopting it, I am sure if we were to check the adoption rate compared to newer CMSes out there it might be the same amount of users. PHP is evolving, standardization is being brought in to make it easier to work with the same code in multiple projects in different systems, I can tell you that currently none of my MODX code can be used anywhere else apart from MODX. I find the framework part of MODX very discouraging due to this and would never consider MODX a framework.

One thing I must say is thanks to Shaun and Jason for the great work they have done to make this CMS what it is today and the great work they will continue to do evolving it. I would like to support this with more than just words but also with code contribution and I do feel others feel the same way.

Plus the MIGX UI is ugly and sometimes buggy.

Did you report this issues, which you found, anywhere, may be together with working solutions? github,forums?

Quote from: sottwell at Feb 23, 2013, 12:04 AM

I would be interested to know of any other CMS that has anything quite like it.

Let's take just WP. There are dozens of MIGx for WP.
Some of them even pushes the concept further by allowing custom fields management per post type (equivalent of custom resource type) without having to touch php or html. Correct me if I'm wrong, but MIGx is still a Template variable, but not a Resource type variable ?

If you look at Drupal, the Field API is backed in the core and does overpower MIGx with a fantastic public API that for example helped built (and further extends) the Drupal Commerce module.

Those are the two most popular CMS, but rest assured, most of the less known tools with sufficient user base have the same facilities.

So, yes, MIGx in the modx realm is awesome. But, no, in the modern CMS world, it's not a unique feature.

Quote from: easylancer at Feb 23, 2013, 01:35 AM

I can only say that we shouldn't think the CMS is ok where it stands because more users are adopting it, I am sure if we were to check the adoption rate compared to newer CMSes out there it might be the same amount of users. PHP is evolving, standardization is being brought in to make it easier to work with the same code in multiple projects in different systems, I can tell you that currently none of my MODX code can be used anywhere else apart from MODX. I find the framework part of MODX very discouraging due to this and would never consider MODX a framework.

You explained it better than i did

As an analogy, when Jason tell me that he want to wait until the technology mature, it reminds of MS, Nokia or RIM when the iPhone came out with a touchscreen only UI and a centralized App Store.
And when Google provided an average follow up with the first Android version.

MS, Nokia or RIM were the top and they pretty much said "let's wait until they mature".
Well, they (Android, iOS) all have matured well, and the old kings all struggle to claim a third wheel position despite having "now" solution almost on par.

It may be far fetched, but i do believe that Composer + packagist + PHP FIG are the future of php and not just a trend. And if I'm not wrong, I hope that Modx will not take the train too late because it waited for the technology to mature.
I would have loved the technology to mature along with Modx instead, not the project just to pick it up at some point.

If I may say so, I'm even a little disappointed that Modx is not part of the PHP FIG group.

but MIGx is still a Template variable, but not a Resource type variable

MIGX/MIGXdb is by far more than just a Template variable or a Resource type variable.

It can be used to manage subresources or records of custom-tables which can be connnected to another resource.
Or it can be used to create complex CMPs without writing a line of code.

It can make each field of custom-tables to work like Template-Variables in a CMP build by MIGXdb.... and much more.
The Template-Variables in MIGXdb-CMPs again can be MIGX or MIGXdb - fields itself, to manage again connected subrecords or records of connected tables.

All features are custom-extentable and all custom-configurations, custom-grid-functions, custom-processors and custom-templates can be packaged together and transported together with a custom-package.

I think the possibilities of MIGX are kind of unique.
(I did not look into features like that in other systems, just build and developed it further for what I need it, with every customer there came new features. Some came from community-ideas) [ed. note: Bruno17 last edited this post 11 years, 2 months ago.]

Thanks for the clarifications (I confess, i don't use MIGx ).
It really is similar to what other CMSes offers one way or another : a necessary tool.

In the end, it should even be built into the core (I thought that even before knowing about the current capabilites) and attached to some official doumentation.
The capabilities it brings to the table are far more seducing to my ears than "creative freedom" for example.

That was considered as a possibility and discussed during the last ModxPo, but discussion are so volatile. Is there any follow up on that subject ?

Quote from: Bruno17 at Feb 23, 2013, 07:20 AM

Plus the MIGX UI is ugly and sometimes buggy.

Did you report this issues, which you found, anywhere, may be together with working solutions? github,forums?

Hi Bruno,

I have just reviewed the issue in Github and realize it was raised as more of a lack on information issue.

https://github.com/Bruno17/MIGX/issues/14

I did run into other issues that I didn't raise at the time and haven't used MIGX since then.

Quote from: Bruno17 at Feb 23, 2013, 10:41 AM

but MIGx is still a Template variable, but not a Resource type variable

MIGX/MIGXdb is by far more than just a Template variable or a Resource type variable.

It can be used to manage subresources or records of custom-tables which can be connnected to another resource.
Or it can be used to create complex CMPs without writing a line of code.

It can make each field of custom-tables to work like Template-Variables in a CMP build by MIGXdb.... and much more.
The Template-Variables in MIGXdb-CMPs again can be MIGX or MIGXdb - fields itself, to manage again connected subrecords or records of connected tables.

All features are custom-extentable and all custom-configurations, custom-grid-functions, custom-processors and custom-templates can be packaged together and transported together with a custom-package.

I think the possibilities of MIGX are kind of unique.
(I did not look into features like that in other systems, just build and developed it further for what I need it, with every customer there came new features. Some came from community-ideas)

There is no way you can create a MIGX setup without writing a line of code. A JSON schema is required and for MIGX db you have to write a XML schema for the db, whereas something like Drupal's Field API require you to write zero code, PyroCMS streams require you writing no code at all. I am not stating these to say that MIGX is bad but I personally don't think its a game changer in the CMS world, only the MODX world. I think what you are doing is great Bruno, it has made creating CMP's a breeze and a less labor intensive task. I think this is awesome and this is something that should be integrated in core or something close enough to this.