@Gedmo is also using the same annotation namespace for several
extensions, so there is another use case where the patch breaks.
I have to weigh the interests of users against ease-of-use here. I had
tons of cases where people misspelled annotations, or for example in
validation annotations, just got the Casing wrong and then it is not
working, without any error messages. I agree that the parser has to be
liberal to work with all the ugly annotations code out there, but in the
case of "namespace exists, but annotation wasnt found" I thought to be
100% sure that throwing an exception is actually very helpful for
developers.
Any solutions to make this work?
greetings,
Benjamin
On Thu, 7 Apr 2011 10:42:02 +0200, Johannes Schmitt wrote:
A further complication is that some annotations are parsed while the
DI container is compiled, so a parser could not be set-up using the
container, but we would need a separate mechanism for this.
If we change the namespace, then I think it only makes sense if we
change it for both bundles, for example @framework/@security.
A third option which was not mentioned yet is to fork the annotation
parser, and adapt it to our needs.
Kind regards,
Johannes
On Thu, Apr 7, 2011 at 10:36 AM, Christophe COEVOET wrote:
Le 07/04/2011 10:20, Lukas Kahwe Smith a écrit :
Hi,
Right now MongoDB ODM cannot be used together with both
FrameworkExtra/SecurityExtra due to changes in Doctrine Common
master. MongoDB ODM however requires Doctrine Common master
because the interfaces where added only there.
For more information on the issue see:
http://www.doctrine-project.org/jira/browse/DCOM-45 [1]
Now one solution would be to "fix" Doctrine Common master to allow
registering multiple handlers for the same annotation prefix.
Another one, which I would prefer is for
FrameworkExtra/SecurityExtra to use different prefixes, since I
find it a bit confusing that they are both using the same prefix.
The first solution would require changing Doctrine Common to allow
several namespaces for an alias in the parser AND reusing the same
parser in both bundles. The second part would require to handle this
at the framework level as SecurityExtra and FrameworkExtra should
both work when the other is not available which forbid defining the
parser in one bundle and reusing it in the other.
So I would also vote for a different namespace (what about
@security ?)
--
Christophe | Stof
--
If you want to report a vulnerability issue on symfony, please send
it to security at symfony-project.com [2]
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]
[3]
To unsubscribe from this group, send email to
[email protected] [4]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en [5]
--
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 [7]
Links:
------
[1] http://www.doctrine-project.org/jira/browse/DCOM-45
[2] http://symfony-project.com
[3] mailto:[email protected]
[4] mailto:symfony-devs%[email protected]
[5] http://groups.google.com/group/symfony-devs?hl=en
[6] mailto:[email protected]
[7] 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
