Speaking of tables, Juergen, how are you faring with the (table navigation) changes you had in mind? And what is the status of the Sortable stuff in the table package?
Regards,
Eelco
Christopher Turner wrote:
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= <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
