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/
mpo@outerthought.org mpo@apache.org
|