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
