cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: [CForms] Repeater is not a ContainerWidget?
Date Mon, 03 May 2004 15:43:49 GMT
Sylvain Wallez <sylvain@apache.org> writes:
> 
> 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.

I've touched on this before, but once more, I think you may want to have
a behavior that is a little more polymorphic and doesn't intermingle
presentation with containerization.  Basically, there are use cases
where you want to be able to present a page in different ways depending
on how much data travels with a given retrieval instance of an object.
In our proprietary forms solution we allow many different presentations
for a given container depending on how much data came back from the back
end.  

For example, if no data came back we may present a "Search page", if one
instance came back, we may present an "Edit page", and if multiple rows
came back we may present a grid to pick the item to edit from.  All of
this is under control of the forms designer (which presentations are
available and when), but the basic idea is that you shouldn't even have
write forms control logic to switch between views: just support the
Search -> Pick -> Edit scenario straight out of the box (and allow a
short cut from Search to Edit when the search results in an exact
match)...

>From what I'm understanding of cForms this would imply that everything
should be wrapped in a high level widget and you'd want to support
methods like getRowCount(), hasNext(), getNext(), etc... But the high
level view of the widget hierarchy would never change and traversal
through the complete container hierarchy would always be identical.

<snip/>


Mime
View raw message