Marc Portier <[EMAIL PROTECTED]> 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...
