cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [CForms] Repeater is not a ContainerWidget?
Date Sun, 02 May 2004 21:27:39 GMT

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.

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 

> 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. "").
> These two methods would be available on ContainerWidget only (including 
> repeater).

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

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 Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message