A few weeks ago, we had a discussion about where to put the integration
between the Symfony Components and third-party libraries.
To refresh your memories, let's say that Symfony Components are
re-usable and *standalone* libraries that can be used without the
Symfony full-stack framework. They *must* not have any mandatory
externals dependencies (they can however have mandatory dependencies on
other Symfony2 components -- like Form and Validator for instance).
At the time of the decision, we had two main examples: the use of
Doctrine for the Security Component (for the ACLs -- which is a lot of
code), and one class in Form Component for Doctrine support. We decided
to put the glue code in the components themselves mainly because of the
ACL support. The main argument was that without the ACL implementation
within the component, the ACL part of the Security component was not
really useful (as it would have been a bunch of interfaces). So, we
decided to do the same for the Form framework to be consistent.
So, what has changed since then and why I think we need to take another
direction now?
Last week, I wanted to use the Translation Component outside of a
Symfony project, and this project happens to also use Twig. So, I needed
to integrate Twig and the Translation Component together and soon, I
realized that this integration already exists in TwigBundle. I could
have used the Twig bundle as is without using the Symfony framework as
this is just another namespace, but it just feels weird. So, at first, I
asked Simon at Sensio to move classes from the Twig bundle to the Twig
Extensions repository (in a new TwigX namespace).
Then, on Saturday, during a Sensio hackaton, we started to discuss this
matter again. First TwigX is not really a vendor name, and then, we
realized that the problem is really similar that the one we have with
the Symfony Components and Doctrine integration. And of course, we
cannot decide to create a DoctrineX namespace.
Where to put this glue code then? We have these possibilities:
* In the Bundles: even if is technically possible, this is out of
question as it feels weird for a user not using the framework to ask him
to install Symfony bundles.
* In the third-party libraries (in Twig, Doctrine): this is not really
possible as each library should only be about its own code and not about
the integration of third-party code.
* In the Components: that's the decision we made. But now that we have
many more examples, I think this is not the right decision anymore (also
because of the git sub-tree thingy -- more on that below). For example,
having the 'yaml_encode' Twig filter under the Yaml Component feels
really bad.
* In a new Symfony sub-namespace: that's my proposal today.
The new Symfony sub-namespace goal is to host the glue code between the
Symfony Components and third-party libraries. This idea was not really
considered when we discussed this topic last time because it was really
about two use cases and one of them (the Security/Doctrine integration)
was really specific as explained above.
The more we thought about this, the more we thought it was the way to
go, also because moving classes away from the Twig bundle gave us many
more examples:
* Yaml Component: the 'yaml_encode' Twig filter;
* Router Component: the 'path' and 'url' Twig functions;
* Templating Component: the 'asset' function.
* Form Component: all the form related functions and tags;
Adding a new namespace makes a lot of sense now that we have many more
examples. It also makes a lot of sense as one of our mantra is to not
reinvent the wheel. So, if we want others to also adhere to our
principles, we need to make it really easy to integrate the Symfony
wheel within their own projects.
So, along the Symfony\Component and Symfony\Bundle namespaces, I propose
to add a Symfony\Bridge namespace:
Symfony\Bridge\Twig\Extension\TransExtension
Symfony\Bridge\Twig\Extension\FormExtension
Symfony\Bridge\Twig\Extension\YamlExtension
Symfony\Bridge\Doctrine\ACL\
Symfony\Bridge\Doctrine\Form\
...
What does it mean for the developer?
For the "average" Symfony Framework user: This change is totally
transparent as the Symfony\Bridge namespace will be hosted under the
main Symfony repository.
For the developer who just want to use some of our components: If he
wants to use a standalone component, it changes nothing; if he wants to
use a component with a third-party library that we support, then he can
just get the related bridge. And this is really easy now that we have
the Git sub-trees. Like we have one Git repository per component
(read-only), we will also have one repository per bridge. So, working
with Doctrine and the Form Component for instance means that you need to
get the Doctrine repos, and two small dependencies:
* The Form component repo: symfony/Form
* The Doctrine bridge repo: symfony/DoctrineBridge
As you can see, instead of managing two repositories, the developer will
now have to manage three of them, not a big deal. And it seems like
things will then be explicit (you need to explicitly get the bridge if
you need it), more decoupled (the components do not have optional
dependencies anymore), and easier to understand (you know where to look
for things).
I realize that we make a discussion a few weeks ago, but I think that we
now have many more examples that demonstrate this decision we took is
not the best one anymore. And last but not the least, it addresses the
concerns some of you had when we decided to put everything in the
components.
Fabien
--
Fabien Potencier
Sensio CEO - Symfony lead developer
sensiolabs.com | symfony-project.org | fabien.potencier.org
Tél: +33 1 40 99 80 80
--
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
