Modx revolution future Vs rest of the world

I'm not a MIGX user yet but one of my clients has an EE site which I occasionally have to update. There's an add on called Matrix for EE which is really handy. http://pixelandtonic.com/matrix
Is this what MIGX achieves albeit with some manual integration?

@lossendae: I just re-read this thread again and, now that I know a little more about the systems involved (psr-0, FIG, Composer, Packagist, etc.), was even more impressed by your points than I was before.

Can you say a little more about how you use Composer with MODX? I'm still trying to wrap my head around Composer. The docs are awful for people who know nothing about it, imo. I get the concepts, but I still don't know what it actually does, physically, or at what point it acts in the package management process (during development?, during the build? during the install?). I'm wondering how I could use Composer and if it would make sense to integrate it into MyComponent.

Quote from: BobRay at Apr 17, 2013, 03:14 AM

Can you say a little more about how you use Composer with MODX? I'm still trying to wrap my head around Composer. The docs are awful for people who know nothing about it, imo. I get the concepts, but I still don't know what it actually does, physically, or at what point it acts in the package management process (during development?, during the build? during the install?). I'm wondering how I could use Composer and if it would make sense to integrate it into MyComponent.

Hello BobRay,

I use Packagist as an helper when I need to use a feature that already exists and/or have a generic implementation available via Composer.

For example, for the next Cliche (modx package) version, I'm using 3 packages from Composer (for upload, phpthumb and oembed). Those 3 librairies are/will be generic and reusable "as is" in other project (not using modx).
The rest of the code is modx related and is developed following modx conventions for most of it.

So far, that gives me a basic folder structure like the following:
- controllers
- docs
- elements
- lexicon
- model
- processors
- vendor
* autoloader.php
* composer.json
* index.class.php

As you can see, it does change very much from any modx package appart from the composer related files and folder (composer.json + vendor folder) and a custom autoloader(.php) that i use for my modx project.

What it actually does ?

It let me use/reuse librairies/code that should be framework agnostic.
It's also a dependency manager, as each package can specifiy if they have some dependencies, which will be retreived when i install/update composer.
It's a huge helper when you use different tools per client request, as you can reuse the same code with different core tool.

What it actually does physically ?

Composer is used via the command line and when you use the command "composer.phar install", it will retreive the packages precised in the composer.json file (along with all their dependencies if any) in the vendor directory.
It will also generate an autoloader file (also in the vendor directory), and a composer.lock file (similar to ruby gem's lock files).
Then, include the "vendor/autoload.php" file from your project to use the loaded Composer packages.

At what point it acts in the package management process ?

Within Modx 2.x, I believe that it should be used per project if needed.
Since they're php librairies, they are used during development process and if the package is distributed for end users, all composer packages should be shipped in the modx package as well.
Note that I would not forcefully take this "all shipped" approach if the package was geared toward developpers.

How I could use Composer and if it would make sense to integrate it into MyComponent

With Modx 2.x realm, you should use Composer as you see fit.
What i showed is only one approach (and i would be happy if some other composer users can show us how they would do).

As for if it make sense for MyComponent, I would say only if your component needs it.
Unless i'm wrong, from what i can see on github, it's mostly modx related and does not use code that can be defined as generic/useful outside of Modx 2.x

Thank you! That was very interesting and informative.

I have two potential uses and I'm wondering what you think about them. None of my extras use any major external libraries (e.g., swiftmailer, monolog). I'm thinking of two smaller use cases.

1. I have utility functions (which could be object methods) that end up in multiple extras of mine, things like a debug function, a directory walker, a combo cli/modx output, a function to get the concatenated code of a php file and recursively all included files, etc. Some depend on each other. I'm wondering if Composer/Packagist would be overkill for bringing them into the development directory of a new extra -- they all usually end up in the package as installed. They might be of use to other MODX extra developers and some would be of use beyond MODX.

2. Some extras depend on other MODX extras, I'm wondering if it makes sense to use Packagist/Composer to bring them in.

In both 1 and 2, MyComponent could (I assume) call Composer/Packagist to bring them in during the Bootstrap phase if told to in the project config file.

1. That is a great idea actually.
It would help many devs and allow some of them to propose their own addition to the package (If php 5.4 was more popular, I would have even told you to check out Traits for these kind of helpers).

Plus it would encourage modx users to progressively get accustomed to composer. Definitively great!

2. If those Extras are on Packagist, why not.
The best solution imo would be to a "packagist" website setup by the modx crew on a modx domain, to handle those kind of extras management.
Doing it with the current Packagist website is not a bad idea. If it work as expected it can encourage the modx team to look at it sooner.

The only issue i can see, is that composer needs to be installed on the machine its running on (or provide the composer.phar file with your package).

Thanks. I assume that for #1, they should be class files so the autoloader would work.

One more question. If I use composer to bring them into a package's development directory and put the vendor directory in the package (under core?) and include the autoloader in my code, the end user wouldn't need Composer, right?

This is not a requirement, you can also add them as functions in a file if you want to.
You can specify the file via the schema composer.json file in your project. See here

Once you do that (and include the autoloader), do you just do this?

I don't post that often but have just found this thread. We build software as well as building some sites using MODX. For all other software we use composer/packagist or npm & grunt.

In my humble opinion Composer has to be the way forward way to as every PHP developer I know has moved / is moving to this way of working. Drupal 8 uses lots of Symfony components as I'm sure most will. The great thing with frameworks like Laravel 4 is that they are built on the back of loads of other great libraries and they can focus on being great at what they do as they utilise the code and testing of hundreds of developers.

It may well have to be a v3 as it could mean a re-write built on many other dependencies. One of the things that I have always liked about MODX is the thought in the user flow and not so much about the tech. Some of the tech feels over-engineered at times (great design choices at the time) but now simpler, standardised ways of working in PHP are being adapted by everyone else.

I think this restricts the growth of the community as lots of developers are jumping between frameworks daily and don't want to spend their time learning proprietary systems. Learning how to use most of Laravel 4 after using Symfony 2 was literally a case of hours rather than weeks.

Someone said to me recently that the best way to hit the community tipping-point is to get to a stage where your community members can make money out of what your platform. I think this is really true with WP. Think of the community growth if users could a) easily build their own plugins/themes etc and b) monetize them.

This shouldn't be read as dismissive just in agreement that the next direction would seem sensible to use the fast growing PHP standards.

Hi everyone, i just came across the following comment from Larry Garfield (creator of Drupal) :

Perhaps the biggest change is that the big projects are collaborating more and more.

I work on Drupal, and the upcoming Drupal 8 has done a massive amount of work to remove our own one-off implementations and adopt existing 3rd party (usually better) components. Most of those have come from Symfony in our case, but we also have Guzzle (HTTP client), Zend Framework's Feed library (RSS/Atom handling), Doctrine's annotations library, and others.

Parts of Zend were refactored to make them easier for Drupal to leverage, using the Aura framework as a model. Drupal and Symfony CMF, arguably competing projects, co-authored a common Routing system that both projects are now using, as is ezPublish. Symfony and Zend now share some common 3rd party libraries for proxy handling. Just about everybody is using the PSR-0 or PSR-4 autoloaders now (except Wordpress). People from one project are showing up at conferences for another project.

I refer to this process as people "getting off their islands", and building bridges between different communities. It's truly awesome to see.

It's really an exciting time for the PHP community. If your PHP experience is still grounded in lots of random functions lying around, objects that aren't really objects, and parameter orders you don't understand, you *really* need to take another look. You're about 10 years out of date on the language that runs 80% of the web.

Many hints that clearly tells taht collaboration should be part of the future of the Modx.
Original article.