Sorry, I think this is a bad idea. I'm personally against subclassing components for things like this (and also for the attribute modifier stuff as well - which is why I implemented it the way I did). I think we need to think of this from a more object-oriented approach rather than always talking about components. In my opinion we should only sub-class a component when we are creating a different type of component. Where we want a construct that is not a different type of component but changes the behaviour of an existing component then it should be via a property and methods on that component.
I think the distinction is perhaps quite subtle, but the impact on class hierarchy complexity and reusability is very significant. In order to make a decision of whether to add functionality to a component or create a subclass of the component the following questions need to be asked (and these aren't Wicket specific, they are general OO principles):
1) Are we creating a new component that has a different set of behaviour and responsibility? YES - subclass
2) Does the user visualise the component as different real-world abstraction? YES - subclass
3) Are we just providing a way to control the behaviour of an existing component? YES - add property and methods
In my mind subclassing PasswordTextField to add clearing value functionality is wrong because it does not represent a different real-world abstraction, we are just changing the behaviour of an existing abstraction.
From my experience, Java anonymous inner-classes are one of the main reasons for the difficulty distinguising between when to sub-class and when to add properties. I would argue that you should never sub-class via an anonymous inner class unless you can think of a sensible name for that class that meets the standard OO rules (i.e. represents a real world abstraction and can be represented as a noun).
Class ValueClearingPasswordTextField is not a valid abstraction because value clearing describes behaviour rather than a type abstraction. Therefore, the value clearing behaviour should be added to the existing component.
I would suggest that this approach should be taken whenever there is an argument over whether to extend or to add functionality. As an additional example, HtmlTagModifier is another example of a dubious subclass. It doesn't represent an abstraction but is instead a class that describes behaviour altering functionality. This was the reason for deprecating this and adding the behaviour modification functionality into the existing classes.
Regards,
Chris
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: 24 November 2004 13:21
> To: '[EMAIL PROTECTED]'
> Subject: AW: [Wicket-develop] [ wicket-Bugs-1072362 ]
> PasswordTextField resets model value
>
>
> Another idea just came into my mind. Why not make render the
> password value the default and in case someone wants to
> change that, he simply subclasses
> PasswordTextField.handleComponentTag() like
>
> add(new PasswortTextField("password", password)
> {
> protected void handleComponentTag(final
> RequestCycle cycle, final ComponentTag tag)
> {
> super(cycle, tag);
> tag.put("value", "");
> }
> }
>
> This way, we won't have to add a property (which might make
> Chris happy, because we keep the session memory small) and
> isn't it the Wicket way?
>
> Regards
> Juergen
>
> -----Urspr�ngliche Nachricht-----
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] Im
> Auftrag von Eelco Hillenius
> Gesendet: Mittwoch, 24. November 2004 13:48
> An: [EMAIL PROTECTED]
> Betreff: Re: [Wicket-develop] [ wicket-Bugs-1072362 ]
> PasswordTextField resets model value
>
> Nope, sounds as a good idea.
>
> Eelco
>
> Martijn Dashorst wrote:
>
> >The solution to this bug is IMO to add a property to the
> >PassworldTextField component called 'resetContents', with appropriate
> getter/setter pair.
> >
> >The handleComponentTag method should then read the flag and depending
> >on the value reset the contents of the field, or fill it
> with the model
> value.
> >
> >Anybody object to this?
> >
> >Martijn
> >
> >
> >-----Oorspronkelijk bericht-----
> >Van: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED]] Namens
> >SourceForge.net
> >Verzonden: woensdag 24 november 2004 11:20
> >Aan: [EMAIL PROTECTED]
> >Onderwerp: [Wicket-develop] [ wicket-Bugs-1072362 ]
> PasswordTextField
> >resets model value
> >
> >Bugs item #1072362, was opened at 2004-11-24 11:19 Message generated
> >for change (Tracker Item Submitted) made by Item Submitter You can
> >respond by
> >visiting:
> >https://sourceforge.net/tracker/?func=detail&atid=684975&aid=
1072362&gr
>oup_i
>d=119783
>
>Category: None
>Group: None
>Status: Open
>Resolution: None
>Priority: 5
>Submitted By: Martijn Dashorst (dashorst) Assigned to: Nobody/Anonymous
>(nobody)
>Summary: PasswordTextField resets model value
>
>Initial Comment:
>The PasswordTextField component resets the model value on rendering.
>This should be made optional, in order to support entry forms for user
>credentials when editing the userdata.
>
>
>----------------------------------------------------------------------
>
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Wicket-develop mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
