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 Binding Revisited.
Date Tue, 30 Mar 2004 17:08:42 GMT
Marc Portier <mpo@outerthought.org> writes:
> 
> Long due, but here goes...
> 
> Over time our RepeaterBinding has been reported as behaving 
> 'odd' and as 
> 'not expected', in the best cases some argumentation could bend those 
> into 'unobvious'...
> The brave among us probably just patch the beast or make their own 
> 'SimpleRepeaterBinding' and go on with their job...

<big-snip/>

We're not using woody/cforms since we have a proprietary forms system
we've built over the years.  However, I do have an observation from our
system:  we've learned over the years that in the middle layer we really
don't want to distinguish between single valued things and multi-valued
things.  Single value things are just a special case of multi-valued
things.  

What we are building is instead a way to distinguish between the "type"
of thing and its presentation behavior.  Types of things are essentially
Java classes or SQL types, Strings, Integers, Decimals, Dates, Cblobs.
etc.  

Presentation behaviors are sort of like Woody widgets: currently our
list includes: normal, hidden, single-value list, multi-select list,
searchers, read-only and a couple of others I won't go into (compound
object behaviors).  We really need to normalize behaviors a little more,
so that hidden and read-only can be yet a third dimension, but I think
you can see where this is going:  basically, anything can be presented
any way and you don't have to modify the middle layer to change the
presentation (and yes, if a thing has multiple values presented as
"normal", you get multiple "text" input fields).

Don't know if any of this is of any use in the cforms design, but we had
to learn this the hard way...





Mime
View raw message