RE: Cforms and Ajax validation workaround?

[Gary Larsen <ga...@envisn.com>]

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:cocoon@lojjic.net] 
> 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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>