I also agree with Chris. I think it is a proper behaviour of the component.
Any thoughts on returning 'this' from the setter? i.e.:
public PasswordTextField setResetValue(boolean resetValue)
{
this.resetValue = resetValue;
return this;
}
Now, only the name of the property, and I'll do my first commit :-)
* resetValue
* resetPassword
* resetModel
* clearValue/Password/Model
?
Regards,
Martijn
Eelco Hillenius wrote:
I agree with Chris here. Chris, what do you think about Tables then,
which you currently can only use when you subclass them. An
alternative could be to do have cell population done by a delegate.
Would you prefer this, or do you think the current method is more
elegant?
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
-------------------------------------------------------
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
