In my case, I have created a TextField component, that is a panel that
contains internally a TextField wicket component. Now, if I add the
method addToField, the user will have two methods:
TextField.add(IBehavior behavior)
TextField.addToField(IBehavior behavior)
I think that this case will be more confused than if I have only one
method:
TextField.add(IBehavior behavior){
textField.add(behavior);
}
I don't want to add any behavior in the panel, I only want to add
behaviors in the field. Why do I have to create another method, that it
will be more confused for the user?
This is the same situation that when we use the IAlternateParent. We
add the component in a component, but the real parent is another...
I am definitely /not/ against removing final, but it is not going to
work (not in general that is).
Alberto's defense is that the user thinks he is working with a field,
while in reality he is working with a panel. I assume that Alberto is
using a panel because he wants some extra functionality around the
field, say a button or a link. Anyway, now the user adds some behavior,
say 'new SimpleAttributeModifier("style", "background-color: #d91")'.
Now in the described setup only the field will get the new background,
while the user probably also wanted to color the whitespace around it.
As a user I would find this pretty confusing.
In short: there is no way of hiding the fact that the component you are
offering to a user is a composite, if you also want the user to have
access to the inner components.
So my solution would be to either expose the inner field through a
getter, or write the addToField method that was discussed earlier.
Regards,
Erik.
Eelco Hillenius schreef:
I could definitively live with removing final there. And maybe some
other methods too.
Anyone against removing final from add(IBehavior)?
Eelco
On 11/9/06, Alberto Bueno <[EMAIL PROTECTED]> wrote:
Hi,
now I have this solution, but I don't like it for you reasons:
- Now I have two methods to add a Behavior: add(IBehavior) and
addToField(IBehavior), and for the users can be confuse.
- I want to have a transparent component. The user doesn't have to know
that he is working with a panel. This is working with a "field". If I have:
MyField extends Panel{
public MyField(MarkupContainer parent, String id){
super(parent, id);
new TextField(this, "myField");
}
}
For the user, MyField is a form Component, and if he add a new Behavior,
the user thinks that the behavior is for the field, not for the panel.
This is the idea...
Why don't you write in your panel: void addToField(Behavior b) {...}?
There is no need to corrupt the meaning of Wicket methods ;)
Regards,
Erik.
Alberto Bueno schreef:
Hi,
I want to overwrite the add(IBehavior) method of the component, but this
method is final.
I want to use the same idea of AlternateParent when we add a new component.
I have a panel, and I want to add a behavior in the panel, but the
behavior is used in a field
component that is in the panel.
I don't want to say:
panel.get("myField").add(new MyBehavior());
I want to say:
panel.add(new MyBehavior());
and in the add() method of the panel say:
public Component add(final IBehavior behavior)
{
get("myField").add(behavior);
}
Any idea to implement this functionality?
Thanks
|
