Make module and plugin structures PSR-0 compliant #235

ghost opened this Issue Jan 10, 2012 · 11 comments


None yet

6 participants

ghost commented Jan 10, 2012

PSR-0 is a standard which is almost 2 years old and requires that classes translate directly to paths: Our module and plugin structure does not. This would mean altering the module structure removing the lib/modname part from the structure and moving everything into the module root (as was originally proposed).

We could then adopt Symfony2's bundle structure which places non-classes in a Resources folder. All of this could be achieved making it backwards compatible.

The next thing is we need to move away from PEAR naming, to namepsaces, so we can alter the loader to translate _ and \\ to be the same, this will allow easy refactoring and BC at the same time.

Lastly, in order to make the module structure entirely PSR-0 compliant, the modules/ folder would need an uppercase first letter, Modules\.

Lastly, there have been many complaints that the file naming makes it very difficult to know what file is which in IDE's like Eclipse and NetBeans. Adding the naming standards we apply to Exception classes and Abstracts/Interfaces would help, i.e. Controller\Admin.php would be Controller\AdminController.php

The module structure would look something like this


All this can be done with BC to the old structure.


Sorry, offtopic:

Why is the development of the master branch is so active?
Shouldn't we care about the other problems first and fix the bugs in release 1.3 branch?
I think we are wasting too much time in the master branch now.
We should rather focus on module development, on the AppStore and on our website.

How does it help us if we have the best score, but no users and no modules?

craigh commented Jan 10, 2012

+1000 to Carsten's OT comment.

ghost commented Jan 11, 2012

I am sorry but this is necessary for conversion to namespacing. As for activity on the release-1.3, development is open, and people may actively submit pull request patches against it, nothing is stopping anyone.

The master branch moves us into a direction as we have always planned, getting us away from many self developed technologies and re-using libraries so we have less maintenance work. I'm not going to justify my work on the master branch - this is exactly what we planned.

Unless there is some constructive discussion on the issues in this ticket I will just proceed to make the changes, they are BC anyway requiring very small tweaks to our autoloaders.

rgasch commented Jan 11, 2012

IMHO the "lib/modname" structure under the module directory was a bad idea from the start and should have been avoided. Getting rid of this is a good thing as long as backward-compatability is provided.

rgasch commented Jan 11, 2012

BTW, I think things like "Foo\Controller\AdminController.php" is another example of overkill naming conventions ... if the file is in the Controller directory, why does it have to be called "Controller"? IMHO stuff like this doesn't serve a sane purpose other than overstating the obvious.

jusuff commented Jan 15, 2012

+1 for the change.
And +1 for Robert's note.
The simpler - the better.

ghost commented Jan 15, 2012

@rgasch @jusuff I understand your point of view but the naming standard is actually very sensible when you look at the reasoning. Class names and file names follow a certain standard. If you have Foo\Api\Admin and Foo\Controller\Admin open at the same time you have no idea which class is which in an IDE. Secondly, class names are referenced in the shortcut because of the namespace and use declarations, so if you are using classes like this inside a class then you have no idea what they are since you have code that just says $foo = new Admin().

This is why you actually need to suffix the classes with what they are, This is not required in PEAR because you specify the full class name, but in namespaced classes it's pretty much required.



Sure about the meaning of your arguments.

And the more issues will come the more all participants will be overworked.
In this case I think it's more important when someone introduce the one or another issue.

I wish that we don't forget to work first for a Version 1.3.2 that works. There is enough to do.
Over 70 issues for the core.

matheo commented Mar 11, 2012

The IDE issue is a poor argument for such change IMO.
I use NetBeans and the tooltip of the current document tab has the full path.
Aptana in the other hand, makes the context pretty clear. This needs another good reason.

I like the current classes structure pretty much,
and I would like to see a clear example of Namespaces issues,
maybe I will face it soon, but ModUtil initially handles the API <-> Controller layers.

@ghost ghost was assigned Apr 2, 2012
@ghost ghost closed this Apr 2, 2012
ghost commented Jan 4, 2013

This change is now supported in 1.3.6

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment