Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
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 [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
smime.p7s
Description: S/MIME Cryptographic Signature
Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
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 <[EMAIL PROTECTED]> 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)
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)
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)
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)
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 and and move one level up the components they define. A question. Right now it looks like this: src="org.apache.cocoon.forms.formmodel.FormDefinitionBuilder"/> src="org.apache.cocoon.forms.formmodel.FieldDefinitionBuilder"/> src="org.apache.cocoon.forms.formmodel.GroupDefinitionBuilder"/> 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 [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
Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
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 and 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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
RE: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
> -Oorspronkelijk bericht- > Van: Leszek Gawron [mailto:[EMAIL PROTECTED] > > > 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. > Every widget is created from a WidgetDefinition, and every WidgetDefinition is build by a WidgetDefinitionBuilder. These builders are setup as components, and from there it's the builders, and the definitions that determine how a specific widget should be setup. So not every widget will be a component. I think sylvain means that users can easily add their builders etc (not just for widgets, but also for bindings, or maybe datatypes, or convertors, or...) to the forms configuration. Bart.
Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
Sylvain Wallez wrote: Ralph Goers wrote: 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
CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)
Ralph Goers wrote: 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 WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
