Re: CForms flowscript API musings

2004-04-26 Thread Leszek Gawron
On Mon, Apr 26, 2004 at 12:03:07PM +0200, Bruno Dumon wrote:
> On Sun, 2004-04-25 at 18:36, Upayavira wrote:
> > Christopher Oliver wrote:
> > 
> > > Bruno Dumon wrote:
> > >
> > >> I'm a bit annoyed by the current status of our flowscript API's for
> > >> CForms. I'll leave the intro for what it is and just jump right into it:
> > >>
> > >> Form.showForm()
> > >> ===
> > >> I find that this function hides too much of how a form is processed, and
> > >> stands in the way of doing more advanced stuff.
> > >>
> > >> I propose that instead of Form.showForm(), we just let the user control
> > >> it:
> > >>
> > >> var form = new Form("my_form_definition.xml");
> > >> var finished = false;
> > >> while (!finished) {
> > >>cocoon.sendPageAndWait("my-pipeline", {"form": form});
> > >>finished = form.processSubmit();
> > >> }
> > >>
> > >> In this scenario, you need to write 5 lines instead of one
> > >> form.showForm() call. However, it provides several advantages:
> > >>
> > >> * You can pass multiple form objects to the sendPageAndWait call (the
> > >> FTT supports referencing different forms using the location attribute on
> > >> ft:form-template)
> > >>
> > >>  
> > >>
> > > Can you describe this in more detail or provide some pseudo code on 
> > > how a page with multiple forms would be sent and processed (or point 
> > > to the documentation if there is already something about this)?
> > 
> > I've had need for this before: having a login form on every page as well 
> > as another form. This is my attempt:
> > 
> > With Bruno's code above, you could put a  > name="formID" value="login"/> hidden field into each form that 
> > identifies which form was submitted. Then you'd do:
> > 
> > var loginForm = new Form("my_login_form_definition.xml");
> > var mainForm = new Form("my_main_form_definition.xml");
> > var finished = false;
> > while (!finished) {
> >   cocoon.sendPageAndWait("my-pipeline", {"login-form": loginForm, 
> > "main-form", mainForm});
> >   if (cocoon.request.formID == "login") {
> > finished = loginForm.processSubmit();
> >   } else {  
> > finished = mainForm.processSubmit();
> >   }
> > }
> >  
> > That ought to do it.
> 
> Yep, that's what I had in mind.
> 
> >  There's a little hack with the 
> > cocoon.request.formID, but it should work, as far as I can see.
> 
> I don't think that's a hack.
> 
> The point is however that there's always only one form which is
> submitted and processed. So if the user edited data in different forms,
> only the changes in the submitted form will be retained. The alternative
> to avoid this is to create one form with multiple submit buttons.
> Depends on what you want.
That is right. But still I would like to maintain DIFFERENT form models and
pass several models to view. After that cforms framework renders them as one
form to retain all form values automatically.
lg
-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |



Re: CForms flowscript API musings

2004-04-26 Thread Bruno Dumon
On Sun, 2004-04-25 at 18:36, Upayavira wrote:
> Christopher Oliver wrote:
> 
> > Bruno Dumon wrote:
> >
> >> I'm a bit annoyed by the current status of our flowscript API's for
> >> CForms. I'll leave the intro for what it is and just jump right into it:
> >>
> >> Form.showForm()
> >> ===
> >> I find that this function hides too much of how a form is processed, and
> >> stands in the way of doing more advanced stuff.
> >>
> >> I propose that instead of Form.showForm(), we just let the user control
> >> it:
> >>
> >> var form = new Form("my_form_definition.xml");
> >> var finished = false;
> >> while (!finished) {
> >>cocoon.sendPageAndWait("my-pipeline", {"form": form});
> >>finished = form.processSubmit();
> >> }
> >>
> >> In this scenario, you need to write 5 lines instead of one
> >> form.showForm() call. However, it provides several advantages:
> >>
> >> * You can pass multiple form objects to the sendPageAndWait call (the
> >> FTT supports referencing different forms using the location attribute on
> >> ft:form-template)
> >>
> >>  
> >>
> > Can you describe this in more detail or provide some pseudo code on 
> > how a page with multiple forms would be sent and processed (or point 
> > to the documentation if there is already something about this)?
> 
> I've had need for this before: having a login form on every page as well 
> as another form. This is my attempt:
> 
> With Bruno's code above, you could put a  name="formID" value="login"/> hidden field into each form that 
> identifies which form was submitted. Then you'd do:
> 
> var loginForm = new Form("my_login_form_definition.xml");
> var mainForm = new Form("my_main_form_definition.xml");
> var finished = false;
> while (!finished) {
>   cocoon.sendPageAndWait("my-pipeline", {"login-form": loginForm, 
> "main-form", mainForm});
>   if (cocoon.request.formID == "login") {
> finished = loginForm.processSubmit();
>   } else {  
> finished = mainForm.processSubmit();
>   }
> }
>  
> That ought to do it.

Yep, that's what I had in mind.

>  There's a little hack with the 
> cocoon.request.formID, but it should work, as far as I can see.

I don't think that's a hack.

The point is however that there's always only one form which is
submitted and processed. So if the user edited data in different forms,
only the changes in the submitted form will be retained. The alternative
to avoid this is to create one form with multiple submit buttons.
Depends on what you want.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]



Re: CForms flowscript API musings

2004-04-25 Thread Upayavira
Christopher Oliver wrote:

Bruno Dumon wrote:

I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more advanced stuff.
I propose that instead of Form.showForm(), we just let the user control
it:
var form = new Form("my_form_definition.xml");
var finished = false;
while (!finished) {
   cocoon.sendPageAndWait("my-pipeline", {"form": form});
   finished = form.processSubmit();
}
In this scenario, you need to write 5 lines instead of one
form.showForm() call. However, it provides several advantages:
* You can pass multiple form objects to the sendPageAndWait call (the
FTT supports referencing different forms using the location attribute on
ft:form-template)
 

Can you describe this in more detail or provide some pseudo code on 
how a page with multiple forms would be sent and processed (or point 
to the documentation if there is already something about this)?
I've had need for this before: having a login form on every page as well 
as another form. This is my attempt:

With Bruno's code above, you could put a  hidden field into each form that 
identifies which form was submitted. Then you'd do:

var loginForm = new Form("my_login_form_definition.xml");
var mainForm = new Form("my_main_form_definition.xml");
var finished = false;
while (!finished) {
 cocoon.sendPageAndWait("my-pipeline", {"login-form": loginForm, 
"main-form", mainForm});
 if (cocoon.request.formID == "login") {
   finished = loginForm.processSubmit();
 } else {  
   finished = mainForm.processSubmit();
 }
}

That ought to do it. There's a little hack with the 
cocoon.request.formID, but it should work, as far as I can see.

Regards, Upayavira




Re: CForms flowscript API musings

2004-04-25 Thread Christopher Oliver
Bruno Dumon wrote:

I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more advanced stuff.
I propose that instead of Form.showForm(), we just let the user control
it:
var form = new Form("my_form_definition.xml");
var finished = false;
while (!finished) {
   cocoon.sendPageAndWait("my-pipeline", {"form": form});
   finished = form.processSubmit();
}
In this scenario, you need to write 5 lines instead of one
form.showForm() call. However, it provides several advantages:
* You can pass multiple form objects to the sendPageAndWait call (the
FTT supports referencing different forms using the location attribute on
ft:form-template)
 

Can you describe this in more detail or provide some pseudo code on how 
a page with multiple forms would be sent and processed (or point to the 
documentation if there is already something about this)?

Thanks,

Chris


Re: CForms flowscript API musings

2004-04-25 Thread Bruno Dumon
On Sun, 2004-04-25 at 16:25, Reinhard Poetz wrote:
> Bruno Dumon wrote:
> 
> >On Sun, 2004-04-25 at 14:54, Sylvain Wallez wrote:
> >  
> >
> >>Bruno Dumon wrote:
> >>
> >>
> >>
> >>>I'm a bit annoyed by the current status of our flowscript API's for
> >>>CForms. I'll leave the intro for what it is and just jump right into it:
> >>>
> >>>Form.showForm()
> >>>===
> >>>I find that this function hides too much of how a form is processed, and
> >>>stands in the way of doing more advanced stuff.
> >>>
> >>>I propose that instead of Form.showForm(), we just let the user control
> >>>it:
> >>>
> >>>var form = new Form("my_form_definition.xml");
> >>>var finished = false;
> >>>while (!finished) {
> >>>   cocoon.sendPageAndWait("my-pipeline", {"form": form});
> >>>   finished = form.processSubmit();
> >>>}
> >>> 
> >>>
> >>>  
> >>>
> >>As Chris pointed out some time ago, this way of doing things, although 
> >>fully functionnal, creates an unnecessarily long chain of continuations. 
> >>This can be avoided by using bookmark continuations (see the v2 JS 
> >>stuff), but makes the code less trivial.
> >>
> >>
> >
> >What's the problem with a long chain of continuations? I mean, the
> >continuation is created anyhow, does it matter where it's added in the
> >continuation tree? Ah, just realizing: maybe because it allows faster
> >expiring of continuations?
> >  
> >
> 
> It enables back/forward navigation. IIUC only after a valid form submit 
> the continuation is added to the continuation tree.

I see. (but not sure yet we should give up the elegant while loop for
this)

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]



Re: CForms flowscript API musings

2004-04-25 Thread Reinhard Poetz
Bruno Dumon wrote:

On Sun, 2004-04-25 at 14:54, Sylvain Wallez wrote:
 

Bruno Dumon wrote:

   

I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more advanced stuff.
I propose that instead of Form.showForm(), we just let the user control
it:
var form = new Form("my_form_definition.xml");
var finished = false;
while (!finished) {
  cocoon.sendPageAndWait("my-pipeline", {"form": form});
  finished = form.processSubmit();
}
 

As Chris pointed out some time ago, this way of doing things, although 
fully functionnal, creates an unnecessarily long chain of continuations. 
This can be avoided by using bookmark continuations (see the v2 JS 
stuff), but makes the code less trivial.
   

What's the problem with a long chain of continuations? I mean, the
continuation is created anyhow, does it matter where it's added in the
continuation tree? Ah, just realizing: maybe because it allows faster
expiring of continuations?
 

It enables back/forward navigation. IIUC only after a valid form submit 
the continuation is added to the continuation tree.
Maybe this can be solved with the wizard API that Sylvain proposed some 
month ago.

I'm not sure how we can solve multi-forms per page support though ... 
:-/ Any ideas?

--
Reinhard


Re: CForms flowscript API musings

2004-04-25 Thread Bruno Dumon
On Sun, 2004-04-25 at 14:54, Sylvain Wallez wrote:
> Bruno Dumon wrote:
> 
> >I'm a bit annoyed by the current status of our flowscript API's for
> >CForms. I'll leave the intro for what it is and just jump right into it:
> >
> >Form.showForm()
> >===
> >I find that this function hides too much of how a form is processed, and
> >stands in the way of doing more advanced stuff.
> >
> >I propose that instead of Form.showForm(), we just let the user control
> >it:
> >
> >var form = new Form("my_form_definition.xml");
> >var finished = false;
> >while (!finished) {
> >cocoon.sendPageAndWait("my-pipeline", {"form": form});
> >finished = form.processSubmit();
> >}
> >  
> >
> 
> As Chris pointed out some time ago, this way of doing things, although 
> fully functionnal, creates an unnecessarily long chain of continuations. 
> This can be avoided by using bookmark continuations (see the v2 JS 
> stuff), but makes the code less trivial.

What's the problem with a long chain of continuations? I mean, the
continuation is created anyhow, does it matter where it's added in the
continuation tree? Ah, just realizing: maybe because it allows faster
expiring of continuations?


on validators:
> >Since we now have the generalized concept of WidgetValidators, I propose
> >we use those to plug in the custom validation. In this way, the custom
> >validation will automatically be peformed as part of the normal form
> >processing cycle. WidgetValidators are currently however only part of
> >the WidgetDefinitions, we could make it possible to define additional
> >ones on the instances.
> >
> >The same should probably be done for event handlers. Currently the v2
> >API works around this limitation by using the FormHandler to allow to
> >add instance-specific event handlers.
> >  
> >
> 
> +1. form.validator was a hack needed before the generalized validation, 
> and isn't needed anymore. Also, do we still need FormHandler? My 
> impression is that we can remove it completely.

I would leave it in (it's not like it's much code anyway). The
FormHandler allows to capture all generated events without the need to
register individual event listeners on each widget, which might be
useful.


> >* pro: ScriptableWidget makes it much more natural to work with the form
> >in a javascript environment. Working directly with the Java objects
> >feels clumsy. If you look at the v2 API, it allows to easily do some 
> >powerful stuff like assigning javascript functions as event handlers.
> >  
> >
> 
> A java interface can easily be implemented in JS: see 
> http://www.mozilla.org/rhino/ScriptingJava.html, "implementing java 
> interfaces". Sure, it's not that easy as just passing a function as a 
> method argument, but we can provide convenience functions for this.

Ah, that's right, I was overseeing that.

> 
> >* con: different objects, different API's, different documentation,
> >needs work when new widgets or features/concepts are added. Makes it
> >more difficult to do one part of logic in javascript and another part in
> >Java. Makes the javascript code harder to move to Java if you want to.
> >
> >I'm still undecided on this topic (ScriptableWidget). I'd like to hear
> >what others think of this, and how they are actually working today (my
> >experience in using all this is rather limited). At first I was more
> >towards the ScriptableWidget approach, though as I'm writing this I'm
> >more leaning towards directly using the java objects, and creating some
> >convenience functions to wrap javascript functions as custom validators
> >and event handlers (as far as that's technically possible).
> >  
> >
> 
> I never used the ScriptableWidget API as, being primarily a Java 
> developper, the Java API is more natural to me. Also, although me may 
> provide a more JS-friendly API to allow more compact notations, it 
> should in no way restrict the accessibility of specific features of 
> particular widget implementations. By this, I mean that the JS wrapper 
> should delegate all properties and methods it doesn't know about to the 
> underlying java widget.
> 
> >Actually, that's leading me to another random thought: do we need the
> >javascript Form object? (this is unrelated to the ScriptableWidget
> >issue) Instead we could just have some convenience functions to create a
> >form instance, to get a binding object, ... Currently my code always
> >contains a var form and a var formWidget, and when starting I was always
> >making the mistake of using the form instead of the formWidget var, and
> >now I still find it annoying.
> >  
> >
> 
> Well, you can get the form widget using jsForm.getWidget()!

Yep, I know, but the distinction between the "form" and the "form
widget" seemed a bit strange to me (from a user point of view). I can
live with it though.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  

Re: CForms flowscript API musings

2004-04-25 Thread Sylvain Wallez
Bruno Dumon wrote:

I'm a bit annoyed by the current status of our flowscript API's for
CForms. I'll leave the intro for what it is and just jump right into it:
Form.showForm()
===
I find that this function hides too much of how a form is processed, and
stands in the way of doing more advanced stuff.
I propose that instead of Form.showForm(), we just let the user control
it:
var form = new Form("my_form_definition.xml");
var finished = false;
while (!finished) {
   cocoon.sendPageAndWait("my-pipeline", {"form": form});
   finished = form.processSubmit();
}
 

As Chris pointed out some time ago, this way of doing things, although 
fully functionnal, creates an unnecessarily long chain of continuations. 
This can be avoided by using bookmark continuations (see the v2 JS 
stuff), but makes the code less trivial.

In this scenario, you need to write 5 lines instead of one
form.showForm() call. However, it provides several advantages:
* You can pass multiple form objects to the sendPageAndWait call (the
FTT supports referencing different forms using the location attribute on
ft:form-template)
* allows to add custom code to be executed before the form is displayed,
and before a form submission is processed. This last one is useful for
multiple things:
   - adding checks to see if the user is allowed to submit the form
   at this moment (could be disallowed if he/she has gone
   forward/backward in the flow and changed stuff on another form)
   - if multiple forms were put on the page, allows to check using
   eg a request attribute which form submission should be
   processed.
   
   - or more generally, it allows to put other links on the page
   pointing to the same continuation but causing something else to
   be done then processing the form submission.
 

Never encountered these use cases up to now, but they seem valid ones.

* allows to use sendPage instead of sendPageAndWait for stateless
applications.
 

I was thinking about proposing to deprecate "showForm" in favor of 
"sendForm" and "sendFormAndWait", which are more similar to "sendPage" 
and "sendPageAndWait", along with the removal of the custom validator 
(more below).

For convenience we could still leave the form.showForm() function, but
make its content as simple as the one above.
Custom validation
=
The current CForms flow API's allow to specify a javascript function
that will be called to do custom validation. However, there seems to be
a problem with this.
Normally, it is the (java) form.process() method that will handle the
different stages of a form submission, which simplified is as follows:
- widgets read values from request
- events generated by this are processed
- widgets are validated *if needed*
(see also http://cocoon.apache.org/2.1/userdocs/forms/eventhandling.html
for the full cycle description)
Note the "if needed" for the validation: it could be that validation
must not be triggered, e.g. when an action widget has been activated.
However, the additional flowscript validation function seems to be
called always.
Since we now have the generalized concept of WidgetValidators, I propose
we use those to plug in the custom validation. In this way, the custom
validation will automatically be peformed as part of the normal form
processing cycle. WidgetValidators are currently however only part of
the WidgetDefinitions, we could make it possible to define additional
ones on the instances.
The same should probably be done for event handlers. Currently the v2
API works around this limitation by using the FormHandler to allow to
add instance-specific event handlers.
 

+1. form.validator was a hack needed before the generalized validation, 
and isn't needed anymore. Also, do we still need FormHandler? My 
impression is that we can remove it completely.

Multiple bindings
=
A simple one, but often requested on the user mailing list: it should be
possible to use multiple bindings with one form.
Currently we have the following functions:
form.createBinding(bindingURI);
form.load(object);
form.save(object);
To allow multiple bindings, we can extend the functions as follows:
form.addBinding(name, bindingURI);
form.load(name, object);
form.save(name, object);
The current functions can be left in place use "default" as the binding
name.
ScriptableWidget

This is a difficult issue, and touches right on the problem of how to
integrate java and javascript logic.
The ScriptableWidget makes that we have different "form" objects in the
javascript and java world (with somewhat different though equivalent
API's).
To make things more confusing, the javascript snippets that can be put
in the binding and form definition files are supplied with the original
Java widget objects, as is the validator function in the old (non-v2)
API.
There has been some discussion on pro/con ScriptableWidgets before, see:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=10794586371