[Feature] Make CMSMS Autoloading PSR-0 compliant

[totophe]

Dear all,

I'd like to propose an implementation of PSR-0 compliant with CMS Made Simple.

For those who ignore what is PSR-0, a nice explanation can be found here: http://www.sitepoint.com/autoloading-an ... -standard/

The reason why I want to push PSR-0 autoloading is the same I want to push developers to use namespace in their classes. There are lot of advantages of using namespaces and autoloading but my goal is not to open that debate.

How do I propose to implement it? Just by modifying the current lib/autoloader.php class.

What do I propose ?

For the Core, just use the regular PSR-0 inclusion under /lib

For the modules, consider the vendor as the module name, and then follow the logic under the modules/Vendor/lib/rest_of_the_namespace

There is one "downside" of my method but that is already bypass by some modules is that the modules classes can be autoloaded even if the module is not activated. But this also means that we can really easily create modules that are just proxy for external packages like Amazon AWS or any external PHP SDK for instance.

Here is the patch http://dev.cmsmadesimple.org/feature_request/view/9552

So, what is your opinion on the subject?

[Jo Morg]

I voted yes. However this require some explanation:
I don't think most modules and/or respective libs should be loaded this way. To be honest I don't even like the PSR-0 recommendation, nor do I believe it is well though of to begin with. Nevertheless, given the amount of libraries and SDK's adhering to this recommendation I agree there is advantage to have CMSMS support PSR-0, but as an added method, not as THE method.
There are a few libs that can be added without the need for any kind of configuration and these could be made available to CMSMS through this method, without the overhead of having to create a wrapper module just to use it.
My two cents...

[chandra]

Using standards is every time a good approach.

+1

[totophe]

The PSR-0 is not only for third party modules but can really be used for your own modules libraries structures and come from PHP itself. I understand that everybody should be free to use it's own methods but pushing cmsms developers to use standards will also convince external developers to join the project, which is better for the community.

[Stikki]

Noted and discussed.

Conclusion?

Still continuing discussion... Sounds about right idea, but requires more testing.

[calguy1000]

I voted no for these reasons (in no particular order):

a: I'm not in favour of 'standardization' just for the sake of standardization there has to be a real tangible benefit. Particularly to an existing mature code stream such as ours. If we were starting a new project from scratch I would be much more open to the idea.

b: I'm not in favour of module B being able to utilize module A's classes if module A is deactivated/un-installed/needing upgrade. In my not so humble opinion, the module MUST be loaded first, before you utilize it's classes. Shortcutting the process by just including a dependent class has proven to be problematic. There are ways to ensure that this happens in the autoloading process but... that involves considerable testing to make sure that errors are handled smoothly.

c: I'm not in favour of the potential of third parties to pollute the CMSMS lib directory by dropping their classes in there and expecting them to work.

d: I'm concerned about the install and upgrade process (for modules and the core) and the API documentation scripts, including but not limited to the ability to clean up files and directories that are no longer used by the core or by modules. IMnsHO the dependency mechanism that modules have on each other, and of the core modules must be enforced as much as is reasonably possible. Bypassing those mechanisms should be discouraged.

e: We would still have to manage the old existing class names lest we convert everything and have to revise each and every file extensively. Converting them to use namespaces and the PSR-0 standard would IMnsHO be a large project with negligible gain.
Merely adding the PSR-0 capable core to the core autoloader would have negligible benefit to CMSMS. And potentially IMnsHO a negative impact.

f: Each third party module developer can easily implement PSR-0 or whatever standard they want for organizing their classes by writing their own autoload mechanism to be called after ours. They can provide this autoload mechanism in their base module and any modules that depend on the base module will automatically have the magic autoload mechanism. Therefore, module developers can use the PSR-0 or any other standard for their classes etc. without affecting the core at all.

The nice thing about standards is there are so many to choose from. Or, you can create your own

[totophe]

Hi there! Thanks for having taken the time to share your (long thought) opinion on the subject

Well, I disagree with not adopting some standards. Like PSR are becoming the foundations of PHP on which CMSMS is based. I agree that it is complex to implement and that it have some issue about control.

For the moment, my solution about it is not clean but maybe a better approach on the matter:

I use "composer" (https://getcomposer.org/) to include the third party libraries some of my modules rely on. The way I implement it for the moment is:

1. Create a composer.json file under the modules' /lib directory
2. Run the composer that will create the /lib/vendor directory
3. In the begining of MyModule.module.php I add a "require_once('lib/vendor/autoload.php');" that will add the vendor's autoloading mechanism.

This "solve" the problem of maintaining third party libraries, for the moment. I'm wondering if we shouldn't have a central way of managing third party dependencies via packagist. This way we could control and prevent:

1. Overloading with two modules that embed the same third party dependency
2. Being able to detect incompatibilities with two modules that would require different versions of a third party dependency

The main concern I have about this approach right now is to not become the kraken that Eclipse is.

Well, I'll continue to do my experiments until I find a reasonable approach.

[zaidcrowe]

@totophe - I'm no authority on this subject, but usability, speed and anything that helps getting to grips with cmsms is really hi in my interests, just wanted to say thanks for raising the topic - and please do keep feeding back here.

Calguy has some really valid points, this is a relatively mature project, but I can't help feeling that by putting your minds together, something "better" would definitely emerge.

Good luck with your experiments!