You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Emond Papegaaij <e....@student.utwente.nl> on 2004/11/15 21:10:07 UTC
Problem with cForms and validation
Hi,
We are using cForms with the standard cForms validation for some time now. A
couple of days ago I decided to upgrade to the latest Cocoon snapshot,
however with this snapshot the validation doesn't work as expected anymore.
Somewhere a change has been made to the way Cocoon handles validation of
fields that were left blank. It now tries to validate a null reference, which
leads to a NullPointerException. I've seen this happen with 'normal' text
fields, fields with a converter to Integer, aggregate fields with fd:regexp
and with custom validation classes.
I don't think it makes sense to validate a null reference as it should always
be considered correct when the field is not required. Reverting to Cocoon
2.1.5.1 solved it, so it's definitely a problem introduced somewhere in the
new Cocoon version. Is it a bug or is it the way it's supposed to be? It
makes the combination of validation with non-required fields quite useless.
Best regards,
Emond Papegaaij
Here is a snapshot of the definition of a field that is causing problems when
left blank:
<fd:aggregatefield id="poBoxZipCode">
<fd:label>Postcode</fd:label>
<fd:datatype base="string"/>
<fd:split pattern="([1-9]{1}[0-9]{3}) ?([a-zA-Z]{2})">
<fd:map field="digits" group="1"/>
<fd:map field="letters" group="2"/>
</fd:split>
<fd:combine expression="Concat( digits, letters )"/>
<fd:widgets>
<fd:field id="digits">
<fd:label>Postcode</fd:label>
<fd:datatype base="string">
<fd:validation>
<fd:regexp pattern="[1-9]{1}[0-9]{3}">
<fd:failmessage>CUT ERROR</fd:failmessage>
</fd:regexp>
</fd:validation>
</fd:datatype>
</fd:field>
<fd:field id="letters">
<fd:datatype base="string">
<fd:validation>
<fd:regexp pattern="[a-zA-Z]{2}">
<fd:failmessage>CUT ERROR</fd:failmessage>
</fd:regexp>
</fd:validation>
</fd:datatype>
</fd:field>
</fd:widgets>
</fd:aggregatefield>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Problem with cForms and validation
Posted by Emond Papegaaij <e....@student.utwente.nl>.
On Tuesday 16 November 2004 08:47, Bruno Dumon wrote:
<cut problems with cForms and validation on non-required fields>
> Try moving the fd:validation tags out of fd:datatype (so that they are
> siblings of fd:datatype). The validation has been refactored from
> datatype validators to more general widget validators, and the
> compatibility to support the old syntax seems to be broken.
Thanks! This works like a charm. This new way of validation is the way it is
going to be and the old one will be deprecated?
Best regards,
Emond Papegaaij
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Problem with cForms and validation
Posted by Bruno Dumon <br...@outerthought.org>.
Try moving the fd:validation tags out of fd:datatype (so that they are
siblings of fd:datatype). The validation has been refactored from
datatype validators to more general widget validators, and the
compatibility to support the old syntax seems to be broken.
On Mon, 2004-11-15 at 21:10 +0100, Emond Papegaaij wrote:
> Hi,
>
> We are using cForms with the standard cForms validation for some time now. A
> couple of days ago I decided to upgrade to the latest Cocoon snapshot,
> however with this snapshot the validation doesn't work as expected anymore.
> Somewhere a change has been made to the way Cocoon handles validation of
> fields that were left blank. It now tries to validate a null reference, which
> leads to a NullPointerException. I've seen this happen with 'normal' text
> fields, fields with a converter to Integer, aggregate fields with fd:regexp
> and with custom validation classes.
>
> I don't think it makes sense to validate a null reference as it should always
> be considered correct when the field is not required. Reverting to Cocoon
> 2.1.5.1 solved it, so it's definitely a problem introduced somewhere in the
> new Cocoon version. Is it a bug or is it the way it's supposed to be? It
> makes the combination of validation with non-required fields quite useless.
>
> Best regards,
> Emond Papegaaij
>
> Here is a snapshot of the definition of a field that is causing problems when
> left blank:
> <fd:aggregatefield id="poBoxZipCode">
> <fd:label>Postcode</fd:label>
> <fd:datatype base="string"/>
> <fd:split pattern="([1-9]{1}[0-9]{3}) ?([a-zA-Z]{2})">
> <fd:map field="digits" group="1"/>
> <fd:map field="letters" group="2"/>
> </fd:split>
> <fd:combine expression="Concat( digits, letters )"/>
> <fd:widgets>
> <fd:field id="digits">
> <fd:label>Postcode</fd:label>
> <fd:datatype base="string">
> <fd:validation>
> <fd:regexp pattern="[1-9]{1}[0-9]{3}">
> <fd:failmessage>CUT ERROR</fd:failmessage>
> </fd:regexp>
> </fd:validation>
> </fd:datatype>
> </fd:field>
> <fd:field id="letters">
> <fd:datatype base="string">
> <fd:validation>
> <fd:regexp pattern="[a-zA-Z]{2}">
> <fd:failmessage>CUT ERROR</fd:failmessage>
> </fd:regexp>
> </fd:validation>
> </fd:datatype>
> </fd:field>
> </fd:widgets>
> </fd:aggregatefield>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org