Sylvain Wallez wrote:

> Bruno Dumon wrote:
> 
>> On Fri, 2004-04-30 at 23:04, Marc Portier wrote:
>>  
>>
> 
> <snip/>
> 
>>> 3/ make Repeater again a ContainerWidget (which it IMHO is not...
>>>   
>>
>>
>> but feels as the easiest way out of this.
>>
>> Maybe this case illustrates that Repeater should be a ContainerWidget
>> after all? If it's not a ContainerWidget, how could it possibly contain
>> widgets as children (which the RepeaterRows are)?
>>  
>>
> 
> Same feeling here: a repeater *contains* rows, which in turn *contain* 
> widgets.
> 

sure,
just like both List and Map 'contain' values, yet they do so in a 
semantically distinct way, and there is little shared methods between them


but just like you guys I can't ignore the use case from Fredy here, but 
that seems to be a reality that comes together with the existence of 
getFullyQualifiedId() and is thus better placed as a lookupWidget on the 
Widget interface (not on some container)

>> Lets look at the interface (javadocs dropped):
>>
>> public interface ContainerWidget extends Widget {
>>    public void addWidget(Widget widget);
>>    public boolean hasWidget(String id);
>>    public Widget getWidget(String id);
>>    public Iterator getChildren();
>> }
>>
>> Of these methods, the only one that is problematic is addWidget. But it
>> seems like that method can be problematic for other ContainerWidgets as
>> well, eg MultiValueField or RepeaterRow.
>>
>> I also see a problem with that method 'tout court', in that we have an
>> addWidget but not a removeWidget?
>>  
>>
> 
> Mmmh... we need addWidget on some container widgets as part of their 
> setup by their widget builder. But it doesn't seem to me we need it at 
> all in the interface. It's a private contract between the buider and the 
> instances it creates.
> 

yep, as mentioned there is probably only 'union' that would really need 
something like this during run-time execution (but I'ld need to check in 
detail)

> Now about getWidget(): it is used to crawl down the widget tree, but its 
> name is inconsistent with getParent() which is used to crawl up the 
> tree. getChild() looks better to me. So what about having:
> - getChild(id) searching in the _direct_ children of a widget.
> - getWidget(path) performing a tree traversal using the dotted notation 
> (e.g. "contacts.1.name").
> 
> These two methods would be available on ContainerWidget only (including 
> repeater).
> 
> WDYT?
> 

this sounds similar to my distinction between getWidget and lookupWidget
but I think the latter could also be defined on the level of Widget 
directly.

that would make 'navigating' the widget tree a feature of every widget 
and as mentioned before more logically come together with the 
getFullyQualifiedId (that would be equal to some getPath() in fact?)

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org