Fine Tuning Ajax Handling in CForms

[Quoin Developers <qu...@gmail.com>]

Currently, it's all or nothing when it comes to using AJAX on a form.
With this enhancement, form widgets can be marked with <fi:styling
ajax='false' />, and they will trigger a non-ajax form submission.

I believe it is useful to give the developer control over which
widgets use AJAX and which do not.

Note that the patch files also include a fix to a separate AJAX issue.

forms_onsubmitHandlers = null

Causes problems when in AJAX mode - submit handlers are only called
the first time an ajax submit is called. Thereafter, the array of
handlers is null, and none are called.

The patch and more detail is available at
http://issues.apache.org/jira/browse/COCOON-1774.

Regards,
Eric Meyer, VP, Quoin, Inc.

Re: Fine Tuning Ajax Handling in CForms

[Sylvain Wallez <sy...@apache.org>]

Quoin Developers wrote:
>> Why do you need such flexibility?
>>     
>
> Concretely, I was running in to
> http://issues.apache.org/jira/browse/COCOON-1570 and realized that I
> could get what I needed by simply switching out of ajax mode (plus
> scrolling back up to the top of the page).
>
> And then I discovered that there was no simple way to switch out of
> ajax mode. The first way I discovered to switch out of ajax mode was
> to embellish onclick with "cocoon.forms.ajax=false;
> forms_submitForm(this, '{@id}'); return false". I could do that with
> fi:style, but it was clunky. I tried to embellish the onclick and
> onsubmit in the xsl, but that still felt clunky, so my approach
> evolved a bit.
>
> Bottom line, in my current application, I have certain page widgets
> that benefit from ajax updates to the form, however, the final
> form-level validation is simpler if i can switch out of ajax mode.
> This patch lets me do that. It felt useful, but I could be convinced
> otherwise.
>
> It /may/ be that once I fix 1570, that 1774 will be less critical, but
> I don't like that AJAX is all or nothing, as to me it feels a bit like
> it should be a per-widget decision.
>   

I see. Well, I'm not really happy with adding more complexity by 
allowing individual widgets to specify Ajax mode, but I understand the 
issue.

Also, I realize that not all widgets nor all stylings allow Ajax mode, 
and this <fi:validation-errors> (which I never used myself) shows it.

So let's go for it, and have the default mode defined on the form (with 
the "ajax" attribute) and allow it to be overriden on widgets.

Now this orverriding should be limited to _terminal_ widgets (i.e. 
inputs and buttons) and not be considered hierarchically (e.g. adding 
ajax="false" on a repeater), in order to keep things as simple as they 
can be.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: Fine Tuning Ajax Handling in CForms

[Quoin Developers <qu...@gmail.com>]

> Why do you need such flexibility?

Concretely, I was running in to
http://issues.apache.org/jira/browse/COCOON-1570 and realized that I
could get what I needed by simply switching out of ajax mode (plus
scrolling back up to the top of the page).

And then I discovered that there was no simple way to switch out of
ajax mode. The first way I discovered to switch out of ajax mode was
to embellish onclick with "cocoon.forms.ajax=false;
forms_submitForm(this, '{@id}'); return false". I could do that with
fi:style, but it was clunky. I tried to embellish the onclick and
onsubmit in the xsl, but that still felt clunky, so my approach
evolved a bit.

Bottom line, in my current application, I have certain page widgets
that benefit from ajax updates to the form, however, the final
form-level validation is simpler if i can switch out of ajax mode.
This patch lets me do that. It felt useful, but I could be convinced
otherwise.

It /may/ be that once I fix 1570, that 1774 will be less critical, but
I don't like that AJAX is all or nothing, as to me it feels a bit like
it should be a per-widget decision.

> > Note that the patch files also include a fix to a separate AJAX issue.
> >
> > forms_onsubmitHandlers = null
> >
> > Causes problems when in AJAX mode - submit handlers are only called
> > the first time an ajax submit is called. Thereafter, the array of
> > handlers is null, and none are called.
> >
>
> Yeah, that's a problem. But we cannot keep it either, as some of the
> handlers are registered by widgets that are replaced by the update.
>
> The move to Dojo which I'm currently working on should solve this issue.

Excellent. We can keep or leave those lines, but my application
doesn't work without a patch. I tried to still clear the
forms_onsubmitHandlers when not in ajax mode. I'm open to alternate
suggestions.

This related item also seemed interesting
http://issues.apache.org/jira/browse/COCOON-1718 and may relate to
these types of issues.

Let me know if I can be helpful with the Dojo work.

Regards,
Eric

Re: Fine Tuning Ajax Handling in CForms

[Sylvain Wallez <sy...@apache.org>]

Quoin Developers wrote:
> Currently, it's all or nothing when it comes to using AJAX on a form.
> With this enhancement, form widgets can be marked with <fi:styling
> ajax='false' />, and they will trigger a non-ajax form submission.
>
> I believe it is useful to give the developer control over which
> widgets use AJAX and which do not.
>   

Why do you need such flexibility?

> Note that the patch files also include a fix to a separate AJAX issue.
>
> forms_onsubmitHandlers = null
>
> Causes problems when in AJAX mode - submit handlers are only called
> the first time an ajax submit is called. Thereafter, the array of
> handlers is null, and none are called.
>   

Yeah, that's a problem. But we cannot keep it either, as some of the 
handlers are registered by widgets that are replaced by the update.

The move to Dojo which I'm currently working on should solve this issue.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director