Did you look at DataTextField? Besides coupling an attrib modifier (btw could have done that directly in handleComponentTag, but choose not too, because I want the attrib modifier to be directly available as well), I also override updateModel. I forsee this kind of components to be implemented a lot more. For instance, I had discussions with Johan and Maurice (collegue at Topicus) about the current Wicket approach. They said they would favor a more 'Swingish' style working with listeners etc instead of overriding component. Thus, instead of subclassing Link they would prefer to have a Link component they can instantiate and just register a listener class to. Wicket makes it easy to create these kind of extensions, but not if all those classes are final. We had the 'final' discussion before. I can live with final for a lot of classes (though I'll never be a huge fan of it), but I really think the classes of which you can be certain people want to override, should be non final. I this case, I waited proposing untill I was really getting irritated. I did not propose it with DataTextField, though the code duplication in there is very ugly, but actually waited for my second use case.
About the "favor composition over inheritance" argument. That's just a matter of how you look at it. Why not have components use a render delegate instead of methods like 'handleComponentTag'? Anyway, besides the argument being arbitrairy, it's not a strange idea to have your companies' set of components where you impose a certain degree of uniformity. That's what we (and you) have been doing with those Maverick actions and Struts actions as well; first start with a base type of our own, so that if we want to impose certain things, we could do it over there. Either this, or adapt AOP ;).
Eelco
Martijn Dashorst wrote:
Obviously your example shows too little of the problem, because in this instance, one doesn't gain much by the extension.
When the field is created on a Page, why don't you use:
public MyPage(PageParameters p) { TextField tf = new TextField("", foo, ""); tf.add(new FValidateAttribModifier(tf)); add(tf); }
I suppose when you want to have a special kind of field, like a social security number field, you'd want to extend TextField, but even then you can extend HTMLComponent, delegate all behaviour to TextField (which is very simple when using Eclipse), and put in your own behaviour.
It's a basic OO principle to "favor composition over inheritance" (use google on that :o)). In this case, you aren't creating an actual new kind of text field, but are adding some behaviour to the text field which can already be done using the public interface.
I'd use a Factory (Method) for this kind of behaviour rather than inheritance.
Martijn
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
