You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Gary Larsen <ga...@envisn.com> on 2007/02/15 16:01:22 UTC
Cforms and Ajax validation workaround?
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?
(Sorry if you have seen similar posts - this is my last on this)
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cforms and Ajax validation workaround?
Posted by Gary Larsen <ga...@envisn.com>.
Hi Felix,
> http://issues.apache.org/jira/browse/COCOON-1774. It affects to cocoon
> 2.1.8 but it seems to affecting also later versions. Maybe
> the comments can give you an idea why it doesn't works.
I had taken a look at this patch but was confused. The patch makes
modification to a resource that I could not find in the 2.1.9 sources:
/src/blocks/forms/java/org/apache/cocoon/forms/resources/js/cforms.js
It seems to allow a submit to run without ajax, but I don't know where to
make the change.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cforms and Ajax validation workaround?
Posted by Felix Knecht <fe...@otego.com>.
Gary Larsen schrieb:
> Thanks Tobia. I think the ajax problem is not populating
> fi:validation-message.
>
See https://issues.apache.org/jira/browse/COCOON-1570 and
http://issues.apache.org/jira/browse/COCOON-1774. It affects to cocoon
2.1.8 but it seems to affecting also later versions. Maybe the comments
can give you an idea why it doesn't works.
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cforms and Ajax validation workaround?
Posted by Gary Larsen <ga...@envisn.com>.
Thanks Tobia. I think the ajax problem is not populating
fi:validation-message.
> It generates a javascript popup that informs the user about
> the fields that need attention.
I like the idea of the popup though and will try it once this other issue is
resolved.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cforms and Ajax validation workaround?
Posted by Tobia <to...@linux.it>.
Gary Larsen wrote:
> 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?
I'm not sure if it's applicable to Ajax, but following our internal
usability guidelines we implemented this:
<xsl:template match="fi:form-template">
<xsl:apply-imports/>
<xsl:if test=".//fi:validation-message">
<script type="text/javascript">
<xsl:text>alert('The following data is missing or incorrect:\n</xsl:text>
<xsl:for-each select=".//fi:validation-message">
<xsl:text>\n</xsl:text>
<xsl:value-of select="local:capitalize(../@id)"/>
<xsl:if test="text()">
<xsl:text> (</xsl:text>
<xsl:value-of select="local:addslashes(normalize-space(.))"/>
<xsl:text>)</xsl:text>
</xsl:if>
</xsl:for-each>
<xsl:text>')</xsl:text>
</script>
</xsl:if>
</xsl:template>
It generates a javascript popup that informs the user about the fields
that need attention. Here are the helper functions:
<func:function name="local:capitalize">
<xsl:param name="s"/>
<func:result select="concat(translate(substring($s, 1, 1),
'abcdefghijklmnopqrstuvwxyz',
'ABCDEFGHIJKLMNOPQRSTUVWXYZ'),
substring($s, 2))"/>
</func:function>
<func:function name="local:addslashes">
<xsl:param name="s"/>
<xsl:choose>
<xsl:when test='contains($s, "'")'>
<func:result select='concat(substring-before($s, "'"),
"\'",
local:addslashes(substring-after($s, "'")))'/>
</xsl:when>
<xsl:otherwise>
<func:result select="$s"/>
</xsl:otherwise>
</xsl:choose>
</func:function>
HTH
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cforms and Ajax validation workaround?
Posted by Gary Larsen <ga...@envisn.com>.
Hi Jason,
Thanks for all the information on this issue. I don't believe my skills in
this area are adequate to provide a solution but I'll give the workaround
you suggested a try.
>
> 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.
>
Thanks again,
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cforms and Ajax validation workaround?
Posted by 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
>
Re: Cforms and Ajax validation workaround?
Posted by Jason Johnston <co...@lojjic.net>.
Grzegorz Kossakowski wrote:
> Gary Larsen napisał(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
RE: Cforms and Ajax validation workaround?
Posted by Gary Larsen <ga...@envisn.com>.
Hi Grzegorz,
> 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.
Here is the last posting I have found on this (the internal issues are
beyond me):
> -----Original Message-----
> From: Jörg Heinicke (JIRA) [mailto:jira@apache.org]
> Sent: Thursday, October 12, 2006 4:21 AM
> To: dev@cocoon.apache.org
> Subject: [jira] Updated: (COCOON-1570) fi:validation-errors styling
> element does not work in AJAX mode
>
> [ http://issues.apache.org/jira/browse/COCOON-1570?page=all ]
I'm having the same problem with 2.1.9. Perhaps it has been fixed in 10 but
I did not find any google hits to suggest this.
One of the messages implied a way to turn off ajax mode on submit which I'm
not sure how to do. If this can be done in the form definition then this
could be the work around I'm looking for.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cforms and Ajax validation workaround?
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Gary Larsen napisał(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.
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.
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org