I missed the IRC conversation, but I think that validation groups are the answer here. I'm not entirely familiar with JSR-303, but from the limited Java constraint syntax I've worked with (e.g. "@NotNull") they are first-class citizens in the code and seem to stack constraints as classes are extended.
As I mentioned on Twitter, it forced me to rethink how my domain model was structured, and this was before validation groups were working properly (last summer). Presently, I think validation groups are the solution for you. The default group can be used for essential constraints you don't expect/want children overriding (e.g. a uniqueness constraint). And in your case, I foresee having groups for any constraints of a parent that you'd have need to "disable". If I were going to implement functionality to remove previously-mapped constraints, I'd investigate adding methods to Symfony\Component\Validator\Constraint\ClassMetadata, but going down that path would likely fork the Validator component's implementation of JSR-303. If we're going to aim for compliance with a standard, I'd rather see us embrace it and work within the conventions to do what we need. Surely Java developers have encountered your challenge (and likely event anticipated it when devising the standard). For many, this will clearly be another uncomfortable difference from Symfony1, but I don't think it's anything a doc on best practices can't overcome. On Tue, Nov 30, 2010 at 4:26 AM, Lukas Kahwe Smith <m...@pooteeweet.org>wrote: > > On 30.11.2010, at 10:15, Lukas Kahwe Smith wrote: > > > Hi, > > > > I just realized that there is no way to get rid of validation rules > defined in a parent class when extending. Now I can think of a couple of > approaches to handle this: > > > 4) On IRC Thomas suggested that validation groups could potentially also be > useful here. So one could either tell the form to only use a specific (set > of) validation group(s) or one could clear specific validation group(s) via > some annotation. > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org > > > > -- > 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 symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com<symfony-devs%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- jeremy mikola -- 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 symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
