cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: CForms work to do before marking it stable
Date Thu, 04 Nov 2004 08:18:05 GMT
Sylvain Wallez wrote:
> 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.
If that is really feasible I am sending you some polish beer to try out! You 
cannot even imagine how many problems the unique-id constraint makes if you 
use O/R tools (hibernate to be specific).

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Mime
View raw message