cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [CForms] Repeater is not a ContainerWidget?
Date Sun, 02 May 2004 21:57:36 GMT
On 02.05.2004 23:27, Marc Portier wrote:

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

Not much time to think through all this, so I will only add my comment:

I like the getWidget/lookupWidget much more than getWidget/getChildren. 
The semantical difference of the latter one is not that obvious, the 
same is true IMO for the path. Accessing descendant widgets by a yet 
another path expression is somewhat unexpected. Real XPath would be an 
alternative, but still not what I would like to see.

Joerg

Mime
View raw message