You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/06/08 22:08:16 UTC
CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
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
2 - decide if we keep "form.model" and its specific JS api
3 - make the API more bean and template friendly, as discussed recently
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)
5 - flatten the configuration to allow for easier extension with the
xconf include mechanism in 2.2
Other pending changes are enhancements and new features rather that
backwards incompatible changes.
How does this sound?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms stabilization tasks (was Re: Marking cforms stable in
2.1.8)
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>
>> I personally don't use v2 nor v3. People using it are invited to
>> speak up!
>
>
> You answered the question in your summary of the last year GT
> Hackathon discussion about cforms
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109774752401800&w=2)
> yourself:
>
> [...]
> - 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)
So this speaks for a removal of form.model...
> - implement an equivalent to the bookmark feature of V2, by a function
> property of the form that gets called at each request roundtrip
Done: see cleanupHook and restoreHook in Form.js
> - add helper methods to the Form class to create event listeners from JS
> functions
Can be done quickly, and doesn't prevent marking state stable as it will
be an addition
> - restrict the "cocoon" object that's available in the event handlers
> so that it does not provide response-related methods (sendPage etc)
To be done.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms stabilization tasks (was Re: Marking cforms stable in
2.1.8)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Paul Crabtree wrote:
>
>> Hi, i've just finished quite a large cocoon site using 2.1.7 with
>> Forms V3. We choose this version for two reasons:
>>
>> 1. At the time i couldnt find much info on the different versions or
>> why they were there so assumed V3 meant it was more mature and the
>> latest.
>>
>>
>
> Well, yes, the latest, but the youngest and therefore not the more
> mature :-)
>
>> 2. showForm() in V3 offers the ability to send viewData
>>
> V1 does also
>
>> and declare a function for execution after the form has been shown
>> each time.
>>
>
> V1 does also, allowing two functions to handle the iterative nature of
> showForm: one after the page has been displayed (for cleanup) and one
> when the browser submits the form (for restoring).
>
>> V2
>> allows a function but no viewData and V1 allows viewData but no
>> function (i think). We therefore felt V3 had a richer, more flexible
>> JS API and we thought we were going to need the function and viewData
>> for our project.
>>
>>
>
> Ok. So the good news is that V1 does all what you need and more !
IIRC only one implementation handles javascript event handlers
(form.widget.onValueChanged = function() { } or something ). I do not
have a cocoon checkout on this station so I cannot check. Is it still so?
--
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
Re: CForms stabilization tasks (was Re: Marking cforms stable in
2.1.8)
Posted by Sylvain Wallez <sy...@apache.org>.
Paul Crabtree wrote:
>Hi, i've just finished quite a large cocoon site using 2.1.7 with
>Forms V3. We choose this version for two reasons:
>
>1. At the time i couldnt find much info on the different versions or
>why they were there so assumed V3 meant it was more mature and the
>latest.
>
>
Well, yes, the latest, but the youngest and therefore not the more
mature :-)
>2. showForm() in V3 offers the ability to send viewData
>
V1 does also
>and declare a function for execution after the form has been shown each time.
>
V1 does also, allowing two functions to handle the iterative nature of
showForm: one after the page has been displayed (for cleanup) and one
when the browser submits the form (for restoring).
>V2
>allows a function but no viewData and V1 allows viewData but no
>function (i think). We therefore felt V3 had a richer, more flexible
>JS API and we thought we were going to need the function and viewData
>for our project.
>
>
Ok. So the good news is that V1 does all what you need and more !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
Posted by Paul Crabtree <pa...@gmail.com>.
Hi, i've just finished quite a large cocoon site using 2.1.7 with
Forms V3. We choose this version for two reasons:
1. At the time i couldnt find much info on the different versions or
why they were there so assumed V3 meant it was more mature and the
latest.
2. showForm() in V3 offers the ability to send viewData and declare a
function for execution after the form has been shown each time. V2
allows a function but no viewData and V1 allows viewData but no
function (i think). We therefore felt V3 had a richer, more flexible
JS API and we thought we were going to need the function and viewData
for our project.
Hope this helps.
Paul
On 6/10/05, Reinhard Poetz <re...@apache.org> wrote:
> Sylvain Wallez wrote:
>
> > I personally don't use v2 nor v3. People using it are invited to speak up!
>
> You answered the question in your summary of the last year GT Hackathon
> discussion about cforms
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109774752401800&w=2) yourself:
>
> [...]
> - 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)
> [...]
>
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
> --------------------------------------------------------------------
>
Re: CForms stabilization tasks (was Re: Marking cforms stable in
2.1.8)
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> I personally don't use v2 nor v3. People using it are invited to speak up!
You answered the question in your summary of the last year GT Hackathon
discussion about cforms
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109774752401800&w=2) yourself:
[...]
- 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)
[...]
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: CForms stabilization tasks (was Re: Marking cforms stable in
2.1.8)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
>> 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.
A question. Right now it looks like this:
<forms-formmanager>
<widgets>
<widget name="form"
src="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder"/>
<widget name="field"
src="org.apache.cocoon.forms.formmodel.FieldDefinitionBuilder"/>
<widget name="group"
src="org.apache.cocoon.forms.formmodel.GroupDefinitionBuilder"/>
</forms-formmanager>
why was widget definition builder selector implemented as
SimpleServiceSelector and not as DefaultServiceSelector in first place?
>
> So this changes nothing to the architecture and the existing components,
> but will lead to small changes in the configuration.
--
Leszek Gawron lgawron@mobilebox.pl
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
Re: CForms stabilization tasks (was Re: Marking cforms stable in
2.1.8)
Posted by Reinhard Poetz <re...@apache.org>.
Mark Lundquist wrote:
>
> On Jun 9, 2005, at 1:48 AM, Sylvain Wallez wrote:
>
>> I personally don't use v2 nor v3. People using it are invited to speak
>> up!
>
>
> I have a few Cocoon projects, and I use v2 in all but one of them (the
> oldest one)!
Can you give a short explanation on the reasons for using v2 instead of v1?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jun 9, 2005, at 1:48 AM, Sylvain Wallez wrote:
> I personally don't use v2 nor v3. People using it are invited to speak
> up!
I have a few Cocoon projects, and I use v2 in all but one of them (the
oldest one)!
cheers, :-)
—ml—
Re: CForms stabilization tasks (was Re: Marking cforms stable in
2.1.8)
Posted by Sylvain Wallez <sy...@apache.org>.
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
Re: CForms stabilization tasks (was Re: Marking cforms stable in
2.1.8)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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 lgawron@mobilebox.pl
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