cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
Date Thu, 09 Jun 2005 08:48:44 GMT
Leszek Gawron wrote:

> Sylvain Wallez wrote:

>> The main points to achieve stable state are:
>> 1 - remove v2 and v3 apis
>
> I assume there are some features that we would like to port back to 
> v1. Could we identify them?


I personally don't use v2 nor v3. People using it are invited to speak up!

>> 2 - decide if we keep "form.model" and its specific JS api
>
> Nearly all of my projects are based on that functionality. Probably 
> there are a lot of guys like me out there who found that functionality 
> semi-stable.


Hehe, I was expecting such reactions :-)

See my answer to point 3 below regarding this.

>> 3 - make the API more bean and template friendly, as discussed recently
>
> We can omit that for now - this has got nothing to do with public 
> interfaces IMO. After the fix in JXTG jx-macros.xml are performant 
> enough to release them as stable.


Yes it has to do with public interfaces. For example, having 
Widget.getChildren() returning a Map can allow expressions such as 
"form.children.firstName.value".

And this notation makes IMO form.model far less useful, as it allows a 
compact dotted notation (yes, with an additional "children") without 
hiding the widget API as form.model does.

>> 4 - consider the cforms expression language which is different from 
>> other ELs used throughout Cocoon (use in fd:assert validator but also 
>> other less known places)
>
> Can we use Rhino expressions? It would be consistent with binding 
> language.


Yes. With the refactored script-friendly API, this allows an overall 
consistency.

>> 5 - flatten the configuration to allow for easier extension with the 
>> xconf include mechanism in 2.2
>
> I could give it a shot but I have no deeper knowledge of cocoon.xconf 
> syntax in this case. Do we have to make every widget a component? That 
> doesn't feel right.


Nono, what I'm talking about is the various subcontainers that exist in 
CForms, such as <forms-datatypes> <forms-formmanager> and 
<forms-bindings> and move one level up the components they define.

So this changes nothing to the architecture and the existing components, 
but will lead to small changes in the configuration.

>> Other pending changes are enhancements and new features rather that 
>> backwards incompatible changes.
>>
>> How does this sound?
>
> Fixable quite fast. Is there any official date that we aim to relase 
> 2.1.8?


None that I know of. ApacheCon is not far and is the occasion to do some 
collective high-bandwidth work. So end of July?

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message