There are actually just two little changes necessary in the Abstract DoctrineBundle so i want to open up the changes to MongoDB Bundle for someone else again. The Doctrine Bundle changes already took me quite some hours and I cant look at it anymore :-)
See https://github.com/fabpot/symfony/pull/465 for one way how to do the refactoring. greetings, Benjamin On Fri, 21 Jan 2011 22:34:26 +0100, Benjamin Eberlei <[email protected]> wrote: > Just realized that the Doctrine* (except Migration) bundles have to be > done in one rush, so i take all of them. > > On Fri, 21 Jan 2011 22:25:31 +0100, Benjamin Eberlei <[email protected]> > wrote: >> Is there an example on how to do this? I would do the Doctrine Abstract >> and Doctrine ORM/DBAL Bundle. >> >> On Fri, 21 Jan 2011 11:29:21 -0500, Jeremy Mikola <[email protected]> >> wrote: >>> Fabien just pulled in Johannes' commit that ensures Extension xxxLoad() >>> methods are only invoked once (an array of all config arrays are now >>> received, instead of a single array at a time). See: >>> >>> >> > https://github.com/fabpot/symfony/commit/8d19136a554b0e8eb6eaec1c60969336ab3bebaa >>> >>> The commit is currently backwards-compatible in that it the original >>> xxxLoad() methods were just renamed to doXxxLoad() and are still being >>> invoked multiple times. The next step will be implementing intelligent >>> config merging for each extension loader, which will entail removing > the >>> doXxxLoad() methods as that logic goes back to xxxLoad(). Merging will >>> need >>> to happen at the start of xxxLoad(), either inline or with a separate >>> internal method. Each extension's merge logic will differ, but we'll >> want >>> to mimic the current behavior as much as possible. The long and short >> is >>> that at some point, config keys will simply override each other or >> possibly >>> throw an Exception if the situation warrants (e.g. two Security >> firewalls >>> or >>> providers with the same name). >>> >>> Per yesterday's IRC meeting < >>> http://trac.symfony-project.org/wiki/IRCLogs20110120>, we wanted to >>> coordinate work so no one wastes time duplicating efforts. These > appear >> to >>> be the extensions up for grabs: >>> >>> - ZendBundle/DependencyInjection/ZendExtension.php >>> - CompatAssetsBundle/Twig/Extension/AssetsExtension.php >>> - DoctrineBundle/DependencyInjection/DoctrineExtension.php >>> - WebProfilerBundle/DependencyInjection/WebProfilerExtension.php >>> - >>> >> DoctrineAbstractBundle/DependencyInjection/AbstractDoctrineExtension.php >>> - >> DoctrineMongoDBBundle/DependencyInjection/DoctrineMongoDBExtension.php >>> - SwiftmailerBundle/DependencyInjection/SwiftmailerExtension.php >>> - TwigBundle/DependencyInjection/TwigExtension.php >>> - FrameworkBundle/DependencyInjection/SecurityExtension.php >>> - FrameworkBundle/DependencyInjection/FrameworkExtension.php >>> >>> I offered to take on FrameworkExtension. Would anyone else like to >>> volunteer? >>> >>> >>> -- >>> jeremy mikola -- 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
