The first case is actually not practical if you have different annotation readers with different namespaces.
I would only add the following validation: Explicit Namespace exists/matched, but class not found! On Wed, 9 Mar 2011 23:05:19 -0300, "[email protected]" <[email protected]> wrote: > 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
