cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fredy Dobler" <>
Subject Re: [CForms] Repeater is not a ContainerWidget?
Date Mon, 03 May 2004 12:11:19 GMT
Marc Portier wrote:
> 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
>>> widgets as children (which the RepeaterRows are)?
>> Same feeling here: a repeater *contains* rows, which in turn *contain*
> 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
> 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)

I think the semantic diffrence between a List and a Map are a lot more
distinct than the diffrence between the Repeater and the ContainerWidget
The only diffrence in the semantically way I see, is that the Repeater
only accepts one kind of Widget, the RepeaterRow. I think in all other
aspects the Repeater is semantically the same as a ContainerWidget.

>>> 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
>>> seems like that method can be problematic for other ContainerWidgets
>>> 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
>> 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
>> 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
>> 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
> 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?)

A lookup function on the Widget level sounds good to me.


View raw message