> 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, '[EMAIL PROTECTED]'); 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
