Well all in all there is exactly one argument that henrik and I have kept
repeating and rephrasing:
Ship the Doctrine code in the Doctrine bundle, because there it belongs.
It is for the same reasons that there is a Twig Bundle, a Zend Bundle and a
Swiftmailer bundle. All of these 3 componentes have exactly zero code in
the Symfony\Component namespace. I fail to see how we can argue that we
support Doctrine, Twig and Swiftmailer, however still keep the code of Twig
and Swiftmailer in their bundles, and moving Doctrine code to
Symfony\Component.
There are several small examples (glitches in the DIC matrix) were it is
visible that DBAL/Doctrine code in the components lead to weird depenedncy
problems:
# app/config/security.yml
security.acl:
connection: default
Security Extension is defined in the Framework bundle but it knows
something about "connections". What is that even for a concept for the
Security bundle to know? Clearly the dependencies should be the other way
around leaving you to define a service that handles the acl:
# app/config/security.yml
security.acl:
service: my.dbal.service
In this case the service would be defined by the DoctrineBundle where it
properly belongs. However then the code wouldnt be shipped in the
DoctrineBundle and lie somewhere different. So the security acl extension
is just build to support Doctrine as a special case to make it look as if
the dependencies were defined in a straightfoward way.
Other code defines in the orm.xml the entity classes and repositories that
are used for the Default Security Provider
"Symfony\Bundle\DoctrineBundle\Security\EntityUserProvider":
https://github.com/fabpot/symfony/blob/master/src/Symfony/Bundle/DoctrineBundle/Resources/config/orm.xml#L41
However the service itsself is again defined in the Security Extension.
Clearly a breakage of concerns. So if you went over and pulled all the
stuff into the Security extension but you don't enable the Doctrine Bundle,
everything breaks. So yes, you have a dependency from Framework/Security on
DBAL.
I havent looked at the form Doctrine dependencies yet, but i will sure
find similar "weird" constructs in the Extension there.
Our strict application of Dependency Injenction and the failure to comply
with it package wise leads to this "glitches" in the matrix that show the
dependencies are wrong, A depends on B where it should be the other way
around. Form and Security should only provide extension hooks to the
outside world and Doctrine is one "provider" that can hook into them. If
Doctrine were to hook into it, configuration would surely be in the
Doctrine Extension. Which would look rather weird if the code is not itself
in the DoctrineBundle.
Now with this approach we need to have a two way implementation:
1. Special case to get Doctrine working
2. Common case to allow hooks into Security and Form
I fail to see how this is KISS.
greetings,
Benjamin
On Fri, 28 Jan 2011 13:23:45 +0100, Bernhard Schussek
<[email protected]>
wrote:
> Henrik,
>
> You are entitled to have any opinion that you like. Noone told you
> otherwise.
>
>> Which translated means stuff that you, fabien and bernhard see fit.
>
> The discussions with the community are a great help in shaping a
> picture of how to do things in the best way. Based on these
> discussions and our own experience, we go with the solution that is
> most convincing to us. I can't help it if we fail to see convincing
> arguments in your posts.
>
>> Well if you like it or not people will look at the components for a way
>> to
>> structure their own code so that they have consistency with the
framework
>> they work with. So this will come naturally.
>
> I think you are exaggerating things a lot. Bundles can be independent
> packages, sure. You don't need to build any separate libraries just
> for the sake of it. But at some point _some_ bundles might grow so
> large that it makes sense to extract the Symfony2-independent code.
> That is what we do with the components, and it's good, because users
> of other libraries can easily reuse the code. But it's nothing you
> have to do for every tiny bundle.
>
>> If would very much like to do a PDO implementation if i had the skill
to
>> do
>> it
>
> Ok. Since there's noone else to do it, there is no PDO implementation
> now. Please stop asking for one.
>
>> So you will move the ORM validator(s) to the component but leave the
ODM
>> ones in the bundle?
>
> If we decide to maintain it, we might move ODM support to the core. As
> I said, this needs to be considered once ODM is stable.
>
> Bernhard
> --
> Software Architect & Engineer
> Blog: http://webmozarts.com
> Twitter: http://twitter.com/webmozart
--
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
