Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 36105 invoked from network); 30 Mar 2004 18:16:09 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 30 Mar 2004 18:16:09 -0000 Received: (qmail 79278 invoked by uid 500); 30 Mar 2004 18:15:57 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 79216 invoked by uid 500); 30 Mar 2004 18:15:56 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 79199 invoked from network); 30 Mar 2004 18:15:56 -0000 Received: from unknown (HELO smtp1.xs4all.be) (195.144.64.135) by daedalus.apache.org with SMTP; 30 Mar 2004 18:15:56 -0000 Received: from outerthought.org (195-144-088-083.dyn.adsl.xs4all.be [195.144.88.83]) (authenticated bits=0) by smtp1.xs4all.be (8.12.10/8.12.10) with ESMTP id i2UIFwPQ012907 for ; Tue, 30 Mar 2004 20:15:58 +0200 Message-ID: <4069B95D.7010908@outerthought.org> Date: Tue, 30 Mar 2004 20:15:57 +0200 From: Marc Portier Organization: Outerthought User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [cforms] Repeater Binding Revisited. References: <1E0CC447E59C974CA5C7160D2A2854EC097DCE@SJMEMXMB04.stjude.sjcrh.local> In-Reply-To: <1E0CC447E59C974CA5C7160D2A2854EC097DCE@SJMEMXMB04.stjude.sjcrh.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hunsberger, Peter wrote: > 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... > thx for this, really appreciate it have to let it sip in a bit... -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