Modx revolution future Vs rest of the world

To my knowledge, there has never been a MODX extra that people could buy as you buy extras for the other major CMS platforms (though I suspect that no one is getting rich that way).

Actually there is one that I know of; Bert Oost (of MODXpo EU 2012 fame) sells SimpleCart.

http://www.oostdesign.com/modx-revolution-cms/modx-extras/simplecart-webshop/

Quote from: easylancer at Feb 21, 2013, 12:50 AM

Wow plenty of points here which I have been raising over the past 4 months or so on Twitter, via Skype with various MODX devs. I am all for change as you prescribed Lossendae. I think they should be welcomed by the MODX core team, if not all at once at least little by little.

Just for the sake of an example, I would like to point out some CMS with comparable or greater user base who are in the process of refactoring a great deal of their core in order to use a framework as the core base (or switch).

• Drupal 8: Who's going to be fully Symphony 2 backed
• PyroCMS 3: Who's switching from codeigniter to Laravel (Actually they're changing progressively with version 2.2.X, starting with the ORM and the user management system)

Their users are not afraid of the big changes and welcome it with open arms.
And we're talking about Drupal here, who theorically have the power to make and maintain it's own framework...

Quote from: easylancer at Feb 21, 2013, 12:50 AM

I am working on a few Extras to make some of these ideas possible, although not in the core as I would like it to be but it will be a good enough proof of concept once done.

I've seens some doodle on bitbucket from you, playing with Modx, Composer and the Eloquent ORM.
I can't wait to see the fruit of your work

Quote from: BobRay at Feb 21, 2013, 03:42 AM

I personally like xPDO a lot.
I don't think it would be at all difficult to create a wizard to help people design a system of relational tables and create the schema and class and map files for them (though it would be time-consuming).
The infrastructure to do that is already built into xPDO, and the createXpdoClasses snippet gets you about half-way there. With a well-made UI and a way to specify the relationships between the tables, it would be dead simple to add your own tables to MODX using xPDO.

I too love the syntax and helpers that xPDO brings to the table. Plus, it's the ORM who made me started with PDO and the whole ORM thing.

But ultimately, in 2013, it's not an UI issue.
It's because an UI is necessary in the first place.

Let's take Eloquent for example, I just need a class extending the base model and i can start working.
No schema, no maps to regenerate, no needs to make a schema for each SQL engine, hence no need to have maps per SQL engine, no UI needed.

Modern ORM favoritise convention over configuration.

Quote from: BobRay at Feb 21, 2013, 03:42 AM

BTW, autoloading classes is already fairly simple in Revolution with PHP 5 (unless I'm misunderstanding your point).
MyComponent, and I think some other extras, already do it.
I think a MODX convenience method to register autoloaders would be really easy to make and could use the existing namespace path field.

Indeed, i use it in my components, even with native namespaces when i can.
I also use Composer + Packagist in modx.
To be fair, in my components i also have my own process to have completly static chunks and snippets.

But it's my own code, not a CMS convention:
- If i want to use getResource i must learn another way for static.
- Repeat the process again if i want to use Quip

I want to know if at some point i would not need to have my own implementation and be happy enough with the CMS features and helpers to use it directly. As well as having identical convention's in other plugins

What I first recognized with xPDO is a movement away from visualizing the database. More concern about the data itself, and less about how it's structured in the database, even to the point of being able to abstract out to some degree the fact that the data may be getting pulled from multiple tables. I presume these newer ORM applications move even farther in this direction.

I have mixed feelings about this. With the importance of the database, I'm not really comfortable about getting more and more layers between me and my database. But then, is it really important for me to know all about that unless I'm actually developing core features? In which case, I'll know about it anyway.

I think an attempt was made at this kind of thing some years ago with the "Object Oriented Database" projects. I played around with CA's Jasmine for a while, and it was interesting, but never took off. From what I can gather, the entire concept of a OO database generally isn't considered to be a very good idea, so what is really needed is the middleware...of which xPDO is an example. Sufficiently abstracted middleware (controllers, I suppose, in the MVC model) would make the end-user totally unaware of and indifferent to the database engine or the actual structure of his data storage.

Quote from: sottwell at Feb 21, 2013, 10:08 AM

I have mixed feelings about this. With the importance of the database, I'm not really comfortable about getting more and more layers between me and my database.

I guess you would have been more confortable without an ORM.
Ultimately it's just a tool, and in some framework you can do whatever you need to do without using the ORM at all. (Eloquant is an ORM used by the Laravel Framework, but the framework query builder behind it is "Fluent" which you can use directly if you don't want to use the ORM).

In modx you can also use xPDOCriteria and directly write SQL code.

However i want to stress out the convention over configuration.

For example, in Modx we have the object called "modTemplateVar" which in fact refers to the table "site_tmplvars".
This as caused me some headaches because like you, i like to dabble in my db and write/test sql from the command line.
But here i assumed that the table name would be "template_vars", and I could not find my way around unless i made a script with $modx->getTableName('modTemplateVar') or looking up in modx's schema.
Note that most core tables are using the plural table name, singular object convention quite well in Modx.

The ORM is supposed to facilitate my work, even though those are details, in the long run it makes a difference.
I have worked with modx projects who are using non conventionnal objects to tables naming, it's not nice to work with those, ever.
And when it happen, i feel just like you, thinking that xPDO just works against me and makes me lose time (and mental sanity in the process).

Quote from: BobRay at Feb 21, 2013, 03:42 AM

To my knowledge, there has never been a MODX extra that people could buy as you buy extras for the other major CMS platforms (though I suspect that no one is getting rich that way). There simply isn't any infrastructure for that. You could argue that there would be more developers working on extras and the quality of both the extras and their documentation would improve significantly if that infrastructure existed.

I think this is an idea that deserves a lot more discussion. Probably on another thread; I shouldn't have hijacked Stephane's post to bring this up.

Quote from: lossendae at Feb 20, 2013, 08:47 PM

The industry seems to welcome Composer + Packagist, as THE way to manage libraries dependencies and/or whole CMS distribution.

Does Modx have any plan to be a part of this at some point ?
Or will it develop it's own way of doing thing appart ?

I'm certainly favoring adopting Composer + Packagist as the distribution and dependency manager. I have no interest in developing YAPS (Yet Another Packaging Solution).

Quote from: lossendae at Feb 20, 2013, 08:47 PM

Will modx plan to use native PHP namespaces (instead on relying on heavy prefixing) ?
What about CMS wide autoloading ?
Will modx follow PHP-FIG (PSR-0/1/2) recommendations, too ?

I have already started exploring various approaches to convert xPDO and the xPDO-based model classes to be PSR-0 compliant, while maintaining as much backwards compatibility as possible. You can see some of this experimental work in my fork of xPDO on GitHub in the release-3.0 branch; see https://github.com/opengeek/xpdo/tree/release-3.0 for details.

I know that may not be what you want to hear in terms of your O/RM preferences. But in terms of preserving any backwards compatibility, abandoning the core of our API is probably not the best route. I also believe the xPDO approach has advantages that will become more apparent when taking full advantage of PHP 5.4+ language features.

Quote from: lossendae at Feb 20, 2013, 08:47 PM

At the time when modx came out, Jason did review a lot of tools before choosing to do it's own "better" tool.
I believe that he was right at the time, xPDO was a very cool tool, and imo better than the alternative.
But now, in 2013, xPDO feels like yesterday's Doctrine for me.
Today i can use a complete ORM without having to build a schema, generate maps, while being less verbose and more straight forward than with xPDO.

Does MODx still evaluate what it could gain by using 3rd party codes for the core ?
Like using some of the Symphony 2 components (yes this is linked to composer usage).

We’re committed to adopting and/or creating what's right for MODX and the Community. This means we need to evaluate all the practical and available options, while weighing backwards compatibility and performance.

We likewise are exploring adoption of at least some of the PHP FIG standards. This includes considering 3rd-party libraries and components that provide value to the project and its adopters.

The next major version of xPDO can be just as relevant, easier to use, and even lighter and faster; all while preserving a decent upgrade path for existing xPDO models. It can not only fit into the PHP FIG standards, but could also work completely by convention versus configuration, while also adding some new unique advantages to the framework.

Quote from: lossendae at Feb 20, 2013, 08:47 PM

Since Modx seems to evolve toward the cloud, i have a feeling that the CMS/Framework/ORM will have less "hands" to work on it, and therefore will not be able to evolve as fast as it would like to be.
Why trying to play catch up indefinitely (and reinventing the wheel) when you don't have the time (or the money i guess) to do it on your own ?
Maybe take a 3rd party tool as a strong base, a maintained API, with having lots of support and industry recognition is not such a bad move ?

Progress has admittedly been slow recently on the core, but I’m not sure we are playing catch up with anyone. Our core team is small, but contributions to the CMS and Extras are increasing, and MODX adoption continues to accelerate. Further, I think MODX Cloud is and has been a perfect partner for evolving the core product by putting the core team more directly back in touch with the everyday concerns of hosting a MODX site.

MODX has a unique approach to the CMF problem—one that is different from most out there. It has advantages (like total creative freedom and no forced markup or taxonomy) over the approaches taken by all of the other systems you mentioned are jumping into PHP FIG adoption curve. Sometimes being a little late to the party can have advantages in terms of standards adoption.

Would I like to have more collaboration and "hands" on the core code to help it better evolve? Sure. To help it evolve more quickly? Debatable. I would love to mentor additional developers to contribute to the core, or even become integrators for the official repository. We want to evolve methodically, so we’re not constantly racing to chase the latest PHP features or emerging standards (that may need more time to mature).

Quote from: opengeek at Feb 21, 2013, 06:04 PM

I'm certainly favoring adopting Composer + Packagist as the distribution and dependency manager. I have no interest in developing YAPS (Yet Another Packaging Solution).

Kudos \o/

Quote from: opengeek at Feb 21, 2013, 06:04 PM

I know that may not be what you want to hear in terms of your O/RM preferences. But in terms of preserving any backwards compatibility, abandoning the core of our API is probably not the best route. I also believe the xPDO approach has advantages that will become more apparent when taking full advantage of PHP 5.4+ language features.

Fair enough, I'll wait for your take on modern ORM to see if xPDO can step up to the challenge

Quote from: opengeek at Feb 21, 2013, 06:04 PM

We likewise are exploring adoption of at least some of the PHP FIG standards.

Adopting some of this standard can be enough. They're recommendation's and even those who adopt them don't comply apply all of them throroughly.

Quote from: opengeek at Feb 21, 2013, 06:04 PM

MODX has a unique approach to the CMF problem—one that is different from most out there. It has advantages (like total creative freedom and no forced markup or taxonomy)

Well, I must be honest on this point, i consider the "total freedom" speech of Modx as a marketing point. Nowadays most of the recent CMS/F and framework have template engine that are as clean & separate as what modx propose.
Some of them (Twig, Blade, Mustache...) are less verbose and allow better readability notably when using simple control or conditionnal structure.
Those tools allow the same level of "creative freedom" as Modx propose. Or even better.

So, sure, Modx template engine is way ahead of Wordpress who is a whole mess of HTML + PHP, better than Smarty who accuse his age as well, somehow simpler then Drupal & Joomla who both still assume too much on behalf of their users.

But just saying it doesn't convince me more than real life example. Like modx folks tend to say, there is a world outside of the triplet (WP, Joomla, Drupal). That statement also applies to Modx.

Quote from: opengeek at Feb 21, 2013, 06:04 PM

over the approaches taken by all of the other systems you mentioned are jumping into PHP FIG adoption curve. Sometimes being a little late to the party can have advantages in terms of standards adoption.

And sometimes it can reduce adoption by potential users too.

Correct me if i'm wrong but you meant Composer and not PHP FIGs ?
PHP FIG are one thing that Modx can already do.

Appart from autoloading and namespaces, most of the recommendations are already in there (they were baked in even before those recommendation came out, when modx was ahead of everyone #grin).
Plus it's just code styles adjustements, you're using PHPStorm, it only a matter of seconds to reformat the code to follow PSR-Whatever.
I can already distribute code following PSR recommendation for Modx.

In my opinion, Composer is much more important than PHP FIGS. Composer help me works better/faster/stronger, PHP FIGS not really.
The workload induced to make xPDO Composer ready will obviously take much longer than following PHP FIG coding standards.

Who's right ? Who's wrong ? Future will tell, but as far as I'm concerned, i would rather use the tool that allows me to work more efficiently.
What the state of things today ?
- I can make code that work everywhere (and eventually distribute it more efficiently) even in modx, with little to no adaptation.
- I can make code for modx, and then code for XXX CMS, and then code for code for YYY, and repeat the process for whatever tool I'm using. and lose time.

Quote from: opengeek at Feb 21, 2013, 06:04 PM

Would I like to have more collaboration and "hands" on the core code to help it better evolve? Sure. To help it evolve more quickly? Debatable. I would love to mentor additional developers to contribute to the core, or even become integrators for the official repository. We want to evolve methodically, so we’re not constantly racing to chase the latest PHP features or emerging standards (that may need more time to mature).

I'm following Modx for long and as far as I can see, the most active & tech savvy users are rather satisfied by the current feature sets, and are either not really aware of what's going on (in the PHP world) or don't really care (or just wait for it to mature... )

That's just fine, there are no problem with that, that does not make Modx less good than it is now.
It may be the right road for Modx and I tend to believe that I may not be in the target audience of Modx.

I'll keep an eye of Modx, and thank you to have me help me discover some fantastic concept and make me love my job more.
Thanks for your answers and good luck

One word. MIGx.

Quote from: lossendae at Feb 21, 2013, 09:27 AM

I too love the syntax and helpers that xPDO brings to the table. Plus, it's the ORM who made me started with PDO and the whole ORM thing.

But ultimately, in 2013, it's not an UI issue.
It's because an UI is necessary in the first place.

Let's take Eloquent for example, I just need a class extending the base model and i can start working.
No schema, no maps to regenerate, no needs to make a schema for each SQL engine, hence no need to have maps per SQL engine, no UI needed.

Modern ORM favoritise convention over configuration.

So Stephane, while you are still here (don't know how soon will you go somewhere else for all that PHP standardization/modularization :

is there any good OO-to-DB (scaffolding/ActiveRecord...) library out there for PHP that isn't dependant on full framework?
Something that requires only initialization with some solid database access layer like PDO and immediately brings rapid development to the table?

Quote from: danilocuculic at Feb 22, 2013, 06:19 PM

So Stephane, while you are still here (don't know how soon will you go somewhere else for all that PHP standardization/modularization :

Oh i'm not going anywhere, as i have to continue to work with modx.
I just will not expect to be "hyped" from it

Quote from: danilocuculic at Feb 22, 2013, 06:19 PM

is there any good OO-to-DB (scaffolding/ActiveRecord...) library out there for PHP that isn't dependant on full framework?
Something that requires only initialization with some solid database access layer like PDO and immediately brings rapid development to the table?

Yes I do: https://github.com/dandoescode/capsule

Capsule is a Composer package which allows to use Illuminate database layer. Illuminate is the (modularized) components whose are part of the Laravel 4 framework.

It allows :
- Direct access to the db : http://laravel.com/docs/database/fluent
- Or using a nice ORM via models if needed : http://laravel.com/docs/database/eloquent

I've used it with Wordpress because I like the syntax, functionalities, direct access without setup and I can use it without relying on globals everywhere (the wp infamy) thanks to the nice Facade interface.
Imo, it's not really a plus in the modx context as xPDO is on par syntax wise and accessible everywhere.