Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
<snip/>
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
IMO, it's more like Collection and List : a Collection lets you iterate through its content, whereas a List extends this behaviour by giving you positional access to its content. That's what repeater.getRow() gives us.
There *must* be a unified interface for all widgets that aren't terminal (i.e. that contain other widgets). This is key to be able to write generic walkers, the simplest one being lookupWidget().
walkers would have an equally complex job either checking a return for null or else checking an instanceof and performing typecast
in fact, it just came to me that this discussion is just a general TO_DECIDE_YOURSELF part of the classic 'composite' pattern (see quote), there doesn't seem to be a general answer/guideline on this, it's just up to us to find a best fit
<qoute from="the book (section: composite/implementation/nr.3)">
Sometimes a little creativity shows how an operation that would appear to make sense only for Composites can be implemented for all Components by moving it to the Component class. For example, the interface for accessing children is a fundamental part of a Composite class but not necessarily Leaf classes. But if we view a Leaf as a Component that never has children, then we can define a default operation for child access in the Component class that never returns any children. Leaf classes can use the default implementation, but Composite classes will reimplement it to return their children.
</qoute>
<snip />
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?)
I still find this somewhat an argument, but...
Reading also J�rg's opinion, my preferred navigation API is :
- getChild(String name) to get a direct child of a widget (replaces getWidget which isn't precise enough to say if it considers children only or also descendants)
- lookupWidget(String qname) which does a descendant lookup only, based on child names sperarated by dots.
am quite ok with this as well...
I don't find my own 'vibes' amounting to a conclusive argumentation to date, I was just hoping others would find more elements and was just looking for some thoughts I'ld maybe missed...
sorry if this sounded as wasting time...
regards, -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]
