Le 16/01/2011 15:04, Fabien Potencier a écrit :
Hi all,
As of now, the default directory structure of a typical Symfony2
application reads as follows:
app/
src/
Application/
Bundle/
vendor/
web/
src/ contains all the PHP code: the code you write for your
application and the code you need from external sources (under the
vendor/ sub-directory but also under Bundle/).
The first question is: What about moving ALL code that does not belong
to the application to the vendor/ directory, outside the src/ one:
app/
src/
vendor/
web/
That way, src/ only contains the code for your specific application:
src/
Application/
...
And vendor/ contains all your dependencies:
vendor/
Bundle/
Sensio/
CasBundle/
...
doctrine/
symfony/
...
I think this structure makes more sense than the current one. It also
eases the separation between your app code and everything else, which
I think is a good thing.
+1 for moving the vendor code from the src dir.
Not really related to that, but nonetheless interesting, I have
another question. The bundles are stored by default under two main
namespaces: Application/ and Bundle/. This has been decided a long
time ago, but it breaks the interoperability standard, as the first
part of a namespace should be the vendor name.
So, instead of:
Bundle\Sensio\CasBundle
We should probably have:
Sensio\Symfony\Bundle\CasBundle
This has many advantages like:
* It follows the interoperability standard;
* If allows to easily package your "plain PHP" code (think Model
here) and your Symfony bundles under the same namespace:
Sensio\Symfony\Bundle\...
Sensio\Doctrine\Extension\...
Sensio\Design\...
The only drawback I can see is the fact that the namespace is much
longer than before.
Longer namespaces does not seem a big problem to me as IDEs autocomplete
them. Is there an impact on performances ?
A bigger drawback is the autoloading. Currently the autoloader knows how
to find the Bundle namespace. This change would require to register all
third-party bundles in the autoloader.
I know that it virtually breaks everything out there, but this is our
last chance to get it right.
Any thoughts?
Fabien
--
Christophe | Stof
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
