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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
