Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <418921B9.1030003@apache.org>
Date: Wed, 03 Nov 2004 19:21:45 +0100
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: CForms work to do before marking it stable
References: <416E4C38.40202@apache.org> <41891753.8080702@apache.org>
In-Reply-To: <41891753.8080702@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Reinhard Poetz wrote:

> Sylvain Wallez wrote:
>
>> Hi all,
>>
>> Here's the result of the discussion at the GT about the work needed 
>> for CForms to reach stable state. Thanks to Pier for being the 
>> secretary. He did it so well ;-P
>>
>> Flowscript integration:
>> - don't use JS wrapping classes for widgets: they introduce 
>> yet-another-API which is sometimes confusing.
>> - update the widgets' java public API so that it's more 
>> "Rhino-friendly" (check JavaBean conformance and add accessors where 
>> needed)
>> - implement an equivalent to the bookmark feature of V2, by a 
>> function property of the form that gets called at each request roundtrip
>> - add helper methods to the Form class to create event listeners from 
>> JS functions
>> - restrict the "cocoon" object that's available in the event handlers 
>> so that it does not provide response-related methods (sendPage etc)
>>
>> Java code:
>> - ignore the "action-command" attribute which is currently useless 
>> except for repeater-actions and row-actions
>> - implement widget states (a patch has been provided for this which I 
>> will take care of)
>>
>> Misc:
>> - write a form definition schema so that definitions can be 
>> optionally validated.
>> - flatten the CForm-related component in cocoon.xconf. This will ease 
>> the transition to a non-Avalon container
>>
>>
>> There was also a discussion also after my presentation on union & 
>> class about renaming these widgets to something more meaningful to 
>> people having no C knowledge. The renaming we came up to is as follows:
>> - <fd:union> --> <fd:choose>
>> - <fd:case> --> <fd:when>
>> - <fd:struct> --> <fd:group>
>> - <fd:class> --> <fd:macro>
>> - <fd:new id=""> --> <fd:expand macro="">
>>
>> The renaming of class/new to macro/expand is mandated by the fact 
>> that a <fd:new> inlines the contents of the class definition without 
>> an enclosing container.
>>
>> Sylvain
>
>
>
> What's the status of the binding framework? Found these mails from 
> march: http://marc.theaimsgroup.com/?t=108059916300004&r=1&w=2
>
> At least, on-delete-bean is missing, isn't it?


Maybe :-) (I'll have to look at this in deeper detail)

About the repeater binding, I had an simple idea that could tremendously 
simplify the binding job: a repeater could have a row creation counter, 
each row holding it's own counter value.

Upon load, rows would be numbered e.g. 1, 2, 3, 4. On save, if we find 
e.g. rows 4, 1, 5, 13, we can determine that rows 4&1 were moved, rows 
2&3 deleted and rows 5&13 are new. That may avoid that complicated (and 
difficult to understand) unique-id stuff that is currently needed in the 
repeater binding.


Another option to ease repeater binding could be to attach the loaded 
data as attributes in the widget row, thus giving instant access to that 
data at save time. And if some rows don't have that attribute, we know 
that these are new ones.


WDYT?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }