Bah. I disagree.
Just because an IDE will do this delegation work for you
doesn't make it right. I personally disagree with favoring composition
over inheritance in this case. I think it makes the resulting code less
managable.
+1 for allowing inheritance.
Gili
On Sun, 30 Jan 2005 15:20:18 +0100, 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
>
>Eelco Hillenius wrote:
>
>> Just look at the code, e.g. DataTextField. That's code duplication. It
>> would be possible to wrap the textfield class/ use delegation but that
>> would mean much more code, and also that class not being a 'TextField'
>> because it would inherit from e.g. HTMLComponent directly.
>>
>> All I want to do is stuff like:
>>
>> class FValidateTextField extends TextField
>> {
>> public FValidateTextField(String name, Serializable object,
>> String expression)
>> {
>> super(name, object, expression);
>> add(new FValidateAttribModifier(this));
>> }
>> }
>>
>> There's nothing wrong with wanting to do that, is there? I mean, by
>> adding such a modifier to instances I really introduce new behaviour
>> which thus satisfies the inheritance requirement of behaviour, but it
>> is still a text field that uses the normal text field rendering
>> behaviour.
>>
>> Eelco
>>
>>
>> Martijn Dashorst wrote:
>>
>>> And this is not possible using delegation? Or would that be too much
>>> effort on the developers part?
>>>
>>> Martijn
>>>
>>>
>>> Eelco Hillenius wrote:
>>>
>>>> When working on the contrib section, it's quite irritating that most
>>>> form component implementations (like TextField etc) are final. What
>>>> I would like to do a lot (and think other users might as well) is
>>>> just override such a class and provide a custom constructor that
>>>> adds eg some attribute modifiers or validators. I also think this
>>>> would be quite a common use case for users that want to implement
>>>> their componany std's components etc.
>>>>
>>>> I would like to propose to make the form components non-final *but*
>>>> finalize all important methods that have component specific
>>>> implementations (like handleComponentTag or handleBody) final.
>>>>
>>>> Any objects/ what's your vote?
>>>>
>>>> Eelco
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> 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
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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
>>
>
>
>
>-------------------------------------------------------
>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
>
-------------------------------------------------------
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
