Skip to content
This repository

Make module and plugin structures PSR-0 compliant #235

Closed
drak opened this Issue January 10, 2012 · 11 comments

7 participants

Drak Carsten Volmer Craig Heydenburg Robert Gasch Pawel Preneta Michael Ueberschaer Mateo Tibaquirá Palacios
Drak
Owner

PSR-0 is a standard which is almost 2 years old and requires that classes translate directly to paths: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md. 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

Foo\
Foo\Controller\AdminController.php
Foo\Api\UserApi.php
Foo\FooVersion.php
Foo\Resources\view\admin.tpl
Foo\Resources\config\...
Foo\Resources\docs\...
Foo\Resources\locale\...

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

Carsten Volmer
Collaborator

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?


Craig Heydenburg
Collaborator

+1000 to Carsten's OT comment.

Drak
Owner

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.

Robert Gasch
Collaborator

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.

Robert Gasch
Collaborator

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.

Pawel Preneta
Owner

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

Drak
Owner

@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.

Michael Ueberschaer

@drak

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.

Mateo Tibaquirá Palacios
Collaborator

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.

Drak drak closed this April 01, 2012
Drak
Owner

This change is now supported in 1.3.6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.