@stof configurable exception will stop processing further annotations for the given class.
@Beberlei In my opinion, in one hand, it is a good idea to make alias dependent on single namespace. This makes it impossible to crap a vendor alias in any project. And it will give an exception which makes it clean to understand the issue. But in the other hand, it forces to make a single place for all annotations used by this alias, which will couple some implementions. On Thu, Apr 7, 2011 at 11:25 AM, Benjamin Eberlei <[email protected]>wrote: > On Thu, 07 Apr 2011 11:24:10 +0200, Christophe COEVOET wrote: > >> Le 07/04/2011 10:53, Benjamin Eberlei a écrit : >> >>> @Gedmo is also using the same annotation namespace for several >>> extensions, so there is another use case where the patch breaks. >>> >> @Gedmo is now fixed by refactoring its extension to put all >> annotations in the same namespace but I find it weird as annotations >> are not in the namespace of the given extension anymore. >> >>> >>> 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? >>> >> What about making the exception configurable ? this way it could be >> disabled by bundles willing to share the same alias between several >> namespaces (handled by different readers as it is the only way for >> this) and could be enabled for others (the Validator and >> Doctrine*Bundle could use it for instance) >> >> > Configurable is a bad way imho, as users cannot trust the behavior anymore. > > -- >> Christophe | Stof >> > > -- > 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
