I don't really see any benefit in approach 3 apart from its complexity. Mostly, I agree with Bernhard that a bundle should only be the integration of the Component into Symfony2, but not the component itself.
We also have to semantically differentiate between providing integration support for a certain library, in Bernhard's case Doctrine2, or relying on a library in order for something to work (Acl/ Dbal). It is just natural to have certain dependencies if you don't want to reinvent the wheel. In the Acl case, Fabien and I agreed months ago that we don't use Pdo, but instead Dbal for better interoperability with the different RDBMS. Separating the DbalProvider from the Acl system means literally ripping the heart out of the Acl system, and I fail to see how a simple namespace change justifies making the individual component unworkable? The components were designed to be a library which can be used without Symfony2, and I think we should carefully consider how much we want to sacrifice the usability experience for non Symfony users where we don't absolutely have to. Why should we discourage people to use our code? Kind regards, Johannes On 25 Jan., 17:24, Bernhard Schussek <[email protected]> wrote: > 2011/1/25 Fabien Potencier <[email protected]>: > > >> Having Symfony\Tiein would lead to complex discussions of wheather a > >> Doctrine class needs to be in the Bundle or the Tiein and details about > >> configuration and such. Bundles would then be essentially just the > >> DependencyInjection namespace + some resource files. > > IMO, bundles should not contain anything that is not Symfony2 > specific. I.e., if something can be reused without Symfony2, it > doesn't belong into a bundle, otherwise it does. > > Most bundles will contain small "applications", which are Symfony2 > specific. The core bundles, on the other hand, mainly integrate a > library into Symfony2. So these should indeed consist only of the DI > configuration and resources. > > I think this is also a question of advertisement. We can't really > promote bundles to be easily usable outside of Symfony2, because most > bundles won't be. > > Maybe the above tie-in concept is the best compromise, although I'd > rather like to call them extensions. Symfony2 users don't have to care > about extensions, because they are automatically integrated by the > corresponding bundles. But Zend users or users of other framework can > still benefit of all the power in our components. I think this will be > important to attract more people to Symfony2. > > So, solution 4: Extensions > -------------------------------------- > Provide extensions, that tie components and external libraries > together, but are documented for use outside of Symfony2. > > Symfony\ > Extension\ > Doctrine\ > DBAL\ > Security\ > ... > ORM\ > Form\ > ... > ODM\ > ... > jQuery\ > Form\ > ... > > This way, people can easily integrate the whole extension of a > dependency (Doctrine) or only parts of it (Doctrine\DBAL\Security). > > 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
