cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [CForms] Repeater is not a ContainerWidget?
Date Mon, 03 May 2004 23:24:45 GMT


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

Mime
View raw message