I was wondering if adding support for validation-errors with Ajax is something that may be considered at some point.
I spent some time today looking at the jx template stuff, and while I have a better concept of what is going on, it's deep for me. Gary > -----Original Message----- > From: Jason Johnston [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 15, 2007 8:42 PM > To: users@cocoon.apache.org > Subject: Re: Cforms and Ajax validation workaround? > > Grzegorz Kossakowski wrote: > > Gary Larsen napisal(a): > >> The Ajax implementation in Cforms is fantastic, not not > being able to > >> use <fi:validation-errors> is causing me a problem. > >> > >> I need to use tab styling with groups since there are so > many widgets > >> on the form. The issue is that when a use submits the form, a > >> validation error could occur on a non-active tab. To the user the > >> submit button is just not working. > >> > >> Has anyone been able to come up with a solution to work > around this > >> issue? > >> > > > > Do you know what causes this limitation? Dojo, Ajax nature of > > requests/responses, DOM processing on the browser side, flaw in > > architecture or just simple bug that should be fixed? AFAIK most > > functionality of CForms should work equally well in Ajax > and non-Ajax mode. > > I was the one who reported the JIRA issue (COCOON-1570) and > worked at one point on a fix so I'll give a little background. > > The way CForms's AJAX mode works is that during an AJAX > request, the JXTemplate checks each widget for whether its > value or state has been changed, and if so wraps it in a > <bu:replace/> element. Then the browser-update transformer > strips out everything in the document except those bu:replace > elements, so the only thing sent back to the browser is the > widgets that have changed. > > So the problem with fi:validation-errors is that, being a > purely stylistic element (not evaluated by a JXTemplate > macro), it has no way to indicate that its contents have > changed, and gets stripped out of the AJAX response by the > browser-update transformer. > > I believe the best "final" solution will be to create a > ft:validation-errors (note the template namespace) element > which gets handled by a JX macro. That macro will be able to > determine if its contents need to be updated and if so create > the bu:replace element like any other template macro. I had > a partial implementation of this a long time ago, but it > would be way out of sync with current code and I'm not sure I > could find it anyway. > > I think that as a temporary workaround one should be able to > manually wrap the fi:validation-errors within a bu:replace > with an appropriate id. I haven't tried this though. > > > > Could you please elaborate a little more on this? What happens when > > you try to use ft:validation-errors, what happens to > validation errors > > on other tabs than active one. Do you know where they get lost? > > > > It would be great if you could fill the issue with as simple as > > possible example of the code (forms definitions and templates, > > sitemap, flowscript cod) that shows buggy behavior. I could take a > > look on this in a week or two. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >