On 12/15/10 10:44 PM, Benjamin Eberlei wrote:
Hey Fabien,
i was thinking about your idea of having the mapping configuration exactly like
routing works, optionally delegating the mapping configuration to each bundle.
While I like the idea on paper, looking at the routing code i think this is
overkill for several reasons:
1. Doctrine Mapping configuration needs at most 4 configuration parameters per
driver. So each bundle would have small files with 1-4 lines of configuration
max.
One other benefit I see is that you can map any directory (read outside
bundles) from the main configuration file; which allows you to nicely
decouple your entity classes from the Symfony directory structure.
2. The loader code in the routing component has quite some LOC. I am not sure i
want to maintain such an overhead just to save configuring 1 vs 4 LOC.
3. There is no code to help me implement this pattern, i would effectively
duplicate all the routing and DIC effort in this regard. Additionally we would
duplicate this effort in ORM, and Mongo + Couch ODMs. A general Symfony
approach to load sub-configurations would definitely be necessary here.
Right. The loader has quite some code because of its flexibility. In
fact, the code is already duplicated in both the Routing and the DIC.
From time to time, I and others think about refactoring this code to
its own component, but with only two occurrences, I think it didn't make
sense. Now if we go down this road also for the Doctrine ORM and ODM
bundles, I think we can start working on a shared component.
Fabien
One example of the marginal difference this change would make is attached.
greetings,
Benjamin
doctrine.orm:
bundles:
AnnotationsBundle: ~
YamlBundle:
dir: Resources/config/doctrine/metadata
alias: yml
mappings:
manual:
type: xml
prefix:
DoctrineBundle\Tests\DependencyInjection\Fixtures\Bundles\XmlBundle
dir:
%kernel.root_dir%/../src/Symfony/Bundle/DoctrineBundle/Tests/DependencyInjection/Fixtures/Bundles/XmlBundle/Resources/config/doctrine/metadata
alias: TestAlias
doctrine.orm:
bundles:
AnnotationsBundle:
resource: AnnotationsBundle/Resources/config/doctrine/mapping.yml
YamlBundle:
resource: YamlBundle/Resources/config/doctrine/mapping.yml
mappings:
manual:
resource: MyBundle/Resources/config/doctrine/mapping.yml
On Sun, 12 Dec 2010 12:34:40 +0100
Benjamin Eberlei<[email protected]> wrote:
On Thu, 09 Dec 2010 18:36:03 +0100
Fabien Potencier<[email protected]> wrote:
On 12/9/10 6:14 PM, Benjamin Eberlei wrote:
Well doctrine bundle uses the standard Doctrine stuff, but it applies the
fixed way of autodetecting. This makes it so hard to work with it in all
the special circumstances.
I'll patch the code and make a pull request to you and /cc it to jonathan.
Thanks
Fabien
Here is the pull requests:
https://github.com/fabpot/symfony/pull/264
Two challenges i also wrote on the pull request comment:
1. We should adjust the MongoDB bundle accordingly
2. Docs and Sandbox have to be updated to show how this works now.
I am up to doing this if we agree that this patch is going to be merged.
greetings,
Benjamin
Benjamin
On Thu, 09 Dec 2010 17:53:23 +0100, Fabien Potencier
<[email protected]> wrote:
On 12/9/10 5:44 PM, Benjamin Eberlei wrote:
yes.
That's excellent then. I'm all for it.
The less code we have in the Doctrine bundle, the better. Doctrine
should be a first-class citizen in Symfony, but Symfony should use the
standard Doctrine way of doing things.
Fabien
On Thu, 09 Dec 2010 17:12:38 +0100, Fabien Potencier
<[email protected]> wrote:
No, Doctrine already supports all this. The DoctrineBundle is what
makes
it so unflexible.
So if I understand correctly, you want to:
* remove the "automatic" code added by the Doctrine bundle
* add support for the new syntax, which is just a way to configure the
"standard" Doctrine mapping objects.
Correct?
Fabien
--
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
--
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
--
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
