Sylvain Wallez <[EMAIL PROTECTED]> 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/>
