Hi Dan, That is the point I had the idea.
We could implement the situation that if you're using an AnnotationNamespace, we could do the validation if the Namespace exists or not. Also we could validate if user is using AnnotationNamespace + Class is it exists or not. All the rest must remain ignored. So we are able to do 2 validations that can benefit the Symfony users at least. If we drop the support to DefaultAnnotationNamespace, we would have these rules valid for all situations, preventing > 90% os usecases. The only remaining one would be if the user defines the FQCN and the class doesn't exist. It should be ignored. What do you guys think about these changes? It may increase the complexity of the Annotations algorithm, but we may increase the verbosity to user in case of mistakes. Cheers, On Wed, Mar 9, 2011 at 7:18 PM, Dan Leech <[email protected]> wrote: > i think the validator component actually does use the Doctrine > annotation reader in: > > vendor/symfony/src/Symfony/Component/Validator/Mapping/Loader/AnnotationLoader.php > > but in anycase, if the validator registers the "validation" namespace > then surely if that namespace is encountered it can be assumed that > the class should exist? > > On 9 March 2011 22:06, Tim Nagel <[email protected]> wrote: >> There are multiple annotation readers used (validation and the orm dont use >> the same one) - if you set it up so that they throw exceptions at all on >> unknown situations they'll step on each other when parsing files. >> I dont see an easy way to achieve any kind of feedback, some kind of logging >> might work but the information is cached and not generated on each pageload. >> >> t >> >> On Thu, Mar 10, 2011 at 09:00, Dan Leech <[email protected]> wrote: >>> >>> yeah, i can see how it is difficult and actually even not practical >>> with the current implementation .. but perhaps possible if there were >>> no default namespace and so each namespace is manually registered and >>> then when encountered the parser knows that the class should exist? >>> >>> On 9 March 2011 18:45, Benjamin Eberlei <[email protected]> wrote: >>> > That would be convenient indeed, but its not practical. >>> > >>> > Say you use @param. or @var or @example or anything. What would stop the >>> > annotation reader from throwing an exception in these cases? >>> > >>> > This is why no exceptions are thrown and unknown annotations are just >>> > skipped. >>> > >>> > greetings, >>> > Benjamin >>> > >>> > On Wed, 9 Mar 2011 17:16:04 +0000 >>> > Dan Leech <[email protected]> wrote: >>> > >>> >> hello all >>> >> >>> >> Today I have been working on a custom validator and it took longer >>> >> than expected, but have finally got working. >>> >> >>> >> It took longer than expected I think because the annotation reader >>> >> ignores classes which dont exist, so at >>> >> first I had no idea why >>> >> >>> >> @validation:MyValidator >>> >> >>> >> or >>> >> >>> >> @validation:Foo\Bar\MyValidator >>> >> >>> >> didnt work. >>> >> >>> >> Then after digging into the source code I added the namespace for my >>> >> validator in the DIC so now >>> >> >>> >> @myValidation:MyValidator >>> >> >>> >> was pointing to the correct class, but unforunately I had a typo in my >>> >> namespace declaration so it >>> >> took me longer still! >>> >> >>> >> Anyway, just putting it out there, it would be cool if the annotation >>> >> reader could identify a class reference >>> >> and throw an exception if the class doesnt exist. >>> >> >>> >> I have written a little blog post for posterity: >>> >> >>> >> http://www.dantleech.com/blog/creating-a-custom-validation-constraint-in-conjunction-with-annotations >>> >> -- >>> >> Dan Leech >>> >> >>> >> Web Developer >>> >> www.dantleech.com >>> >> >>> >> -- >>> >> 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 >>> > >>> >>> >>> >>> -- >>> Dan Leech >>> >>> Web Developer >>> www.dantleech.com >>> >>> -- >>> 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 >> >> > > > > -- > Dan Leech > > Web Developer > www.dantleech.com > > -- > 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 > -- Guilherme Blanco Mobile: +55 (16) 9215-8480 MSN: [email protected] São Paulo - SP/Brazil -- 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
