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.
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.
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?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
