A practical use case for converter inheritance would be identical -- allowing custom converter per-instance messages properties.
Since the JSF spec does not declare validator and converter classes final, assume that inheritance is possible and that properties will propagate. Again, if you are subclassing a converter, there's obviously some reason why you did it rather than writing one from scratch. On 6/4/08, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > > > > On Wed, Jun 4, 2008 at 3:21 PM, Mike Kienenberger <[EMAIL PROTECTED]> > wrote: > > > > On 6/4/08, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > > > * @JSFJspProperty name = "message" inheritedTag="true" returnType = > > > "java.lang.String" longDesc = "alternate validation error message format > > > string" > > > */ > > > public class CSVValidator extends ValidatorBase > > > > > > Inheritance of properties for converters and validators are not > supported > > > (in my concept there is no sense to allow this, but if there is a strong > > > reason we can study the impact and change it), so all properties defined > on > > > the parent (in that case ValidatorBase) should be defined again with > > > inheritedTag="true". > > > > I guess I'd have to disagree that there's no sense in allowing > > inheritance of properties on validators and converters. The original > > goal of the ValidatorBase class was to provide a message properties to > > all subclasses. > > > > Why would you extend a validator or converter if you weren't planning > > on using the same properties of the parent? > > ValidatorBase is the only case of inheritance for validators. But from this > point of view is valid allow inheritance for validators. Checking the code, > a change only affects tomahawk, so there is no problem. On sandbox, all > validators do not use detailMessage and summaryMessage on its tld (this fact > makes me feel strange about ValidatorBase), so this could be a side effect. > I'll try it in deep and commit it. I'm not found yet a practical usage for > inheritance for converters, so I'll let it as is > > Thanks for your suggestions > > Leonardo Uribe > >
