Sylvain Wallez wrote:
Ralph Goers wrote:
<snip/>
The bottom line is you cannot have code sitting around forever telling
people its great but you have to use it at your own risk cause we
might change it anytime we feel like it. This has just been going on
for far too long. The code is never going to be perfect.
I hear you Ralph. And my impression is that we've become shy about
modifying this API although it is considering unstable. There are things
that must be done though, even if as you say the result is never perfect.
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?
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.
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.
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.
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.
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?
--
Leszek Gawron [EMAIL PROTECTED]
IT 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
