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
>>>>         

-- 
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to