You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Pedro Rodriguez <pe...@fbn.ca> on 2006/02/16 23:38:39 UTC
[Validator] Multiple Form's Fields for the same property
In order to override default validator messages, the msg's name refers
the validator name.
How can I distinguish two validations with different messages using the
same kind of field's dependency?
Adding different Fields into the same Form for a same property is a kind
of solution (another one is to create identical mask1, mask2, mask3, .
but no no!):
<form name="AForm">
<field property="a" depends="mask">
<msg name="mask" key="error.a.mask" />
<var><var-name>mask</var-name><var-value>${MASK}</var-value></var>
</field>
<field property="a" depends="validwhen">
<msg name="validwhen" key="errors.a.1"/>
<var><var-name>test</var-name><var-value>TEST_1</var-value></var>
</field>
<field property="a" depends="validwhen">
<msg name="validwhen" key="errors.a.2"/>
<var><var-name>test</var-name><var-value>TEST_2</var-value></var>
</field>
</form>
There is a field list in Form with all those fields (the three of then
for the same property). This list is used to validate and everything
seem to be fine ..
However, the Field's unique key is presently associated to the Field's
property.
While dealing with Form dependencies (using Form's extends) the Field's
key is being used as a key in a Map of fields (coherent with the
uniqueness of Field's key) . Obviously, it makes illegal the use of
"Multiple Form's Fields for the same property".
What we did then was:
We added support into Form for Multiple Fields for the same property,
using a suffix to field's key if more than one field are used for the
same property.
What do you think?
Pedro Rodriguez
AVIS DE NON-RESPONSABILIT: Ce document transmis par courrier lectronique est destin uniquement la personne ou l'entit qui il est adress et peut contenir des renseignements confidentiels et assujettis au secret professionnel. La confidentialit et le secret professionnel demeurent malgr l'envoi de ce document la mauvaise adresse lectronique. Si vous n'tes pas le destinataire vis ou la personne charge de remettre ce document son destinataire, veuillez nous en informer sans dlai et dtruire ce document ainsi que toute copie qui en aurait t faite. Toute distribution, reproduction ou autre utilisation de ce document est strictement interdite. De plus, le Groupe Financire Banque Nationale et ses filiales ne peuvent pas tre tenus responsables des dommages pouvant tre causs par des virus ou des erreurs de transmission.
DISCLAIMER: This documentation transmitted by electronic mail is intended for the use of the individual to whom or the entity to which it is addressed and may contain information which is confidential and privileged. Confidentiality and privilege are not lost by this documentation having been sent to the wrong electronic mail address. If you are not the intended recipient or the person responsible for delivering it to the intended recipient please notify the sender immediately and destroy this document as well as any copies of it. Any distribution, reproduction or other use of this document is strictly prohibited. National Bank Financial Group and its affiliates cannot be held liable for any damage that may be caused by viruses or transmission errors.
RE : [Validator] Multiple Form's Fields for the same property - Form inheritance
Posted by Pedro Rodriguez <pe...@fbn.ca>.
Actually, for Form inheritance, we are using the field's property: If at
least one field for a particular property exists in a form (sub-form)
then we ignore all fields for the same property defined in the parent
Form (super-form).
Having user-defined field's keys we should be able to manage the Form
inheritance validation overriding at the field key level!
Why if, beside of generating real unique Field's key in the scope of the
Form we let the user explicitly indicate the field's key (not just the
property) in a validation rules xml?. For that, we need to add "key" as
an optional attribute for field in the dtd.
Or, do not generate field's keys at all? ... having the user to assign
unique keys in case of conflicts (more than one field for the same
property). The point is that to be backward compatible we can't enforce
field's key uniqueness because I feel that using different fields for
the same property is not a rare practice.
-----Message d'origine-----
De : Pedro Rodriguez [mailto:pedro.rodriguez@fbn.ca]
Envoyé : Thursday, February 16, 2006 5:39 PM
À : commons-user@jakarta.apache.org
Objet : [Validator] Multiple Form's Fields for the same property
In order to override default validator messages, the msg's name refers
the validator name.
How can I distinguish two validations with different messages using the
same kind of field's dependency?
Adding different Fields into the same Form for a same property is a kind
of solution (another one is to create identical mask1, mask2, mask3, .
but no no!):
<form name="AForm">
<field property="a" depends="mask">
<msg name="mask" key="error.a.mask" />
<var><var-name>mask</var-name><var-value>${MASK}</var-value></var>
</field>
<field property="a" depends="validwhen">
<msg name="validwhen" key="errors.a.1"/>
<var><var-name>test</var-name><var-value>TEST_1</var-value></var>
</field>
<field property="a" depends="validwhen">
<msg name="validwhen" key="errors.a.2"/>
<var><var-name>test</var-name><var-value>TEST_2</var-value></var>
</field>
</form>
There is a field list in Form with all those fields (the three of then
for the same property). This list is used to validate and everything
seem to be fine ..
However, the Field's unique key is presently associated to the Field's
property.
While dealing with Form dependencies (using Form's extends) the Field's
key is being used as a key in a Map of fields (coherent with the
uniqueness of Field's key) . Obviously, it makes illegal the use of
"Multiple Form's Fields for the same property".
What we did then was:
We added support into Form for Multiple Fields for the same property,
using a suffix to field's key if more than one field are used for the
same property.
What do you think?
Pedro Rodriguez
AVIS DE NON-RESPONSABILIT: Ce document transmis par courrier lectronique
est destin uniquement la personne ou l'entit qui il est adress et
peut contenir des renseignements confidentiels et assujettis au secret
professionnel. La confidentialit et le secret professionnel demeurent
malgr l'envoi de ce document la mauvaise adresse lectronique. Si vous
n'tes pas le destinataire vis ou la personne charge de remettre ce
document son destinataire, veuillez nous en informer sans dlai et
dtruire ce document ainsi que toute copie qui en aurait t faite. Toute
distribution, reproduction ou autre utilisation de ce document est
strictement interdite. De plus, le Groupe Financire Banque Nationale et
ses filiales ne peuvent pas tre tenus responsables des dommages pouvant
tre causs par des virus ou des erreurs de transmission.
DISCLAIMER: This documentation transmitted by electronic mail is
intended for the use of the individual to whom or the entity to which it
is addressed and may contain information which is confidential and
privileged. Confidentiality and privilege are not lost by this
documentation having been sent to the wrong electronic mail address. If
you are not the intended recipient or the person responsible for
delivering it to the intended recipient please notify the sender
immediately and destroy this document as well as any copies of it. Any
distribution, reproduction or other use of this document is strictly
prohibited. National Bank Financial Group and its affiliates cannot be
held liable for any damage that may be caused by viruses or transmission
errors.
AVIS DE NON-RESPONSABILIT: Ce document transmis par courrier lectronique est destin uniquement la personne ou l'entit qui il est adress et peut contenir des renseignements confidentiels et assujettis au secret professionnel. La confidentialit et le secret professionnel demeurent malgr l'envoi de ce document la mauvaise adresse lectronique. Si vous n'tes pas le destinataire vis ou la personne charge de remettre ce document son destinataire, veuillez nous en informer sans dlai et dtruire ce document ainsi que toute copie qui en aurait t faite. Toute distribution, reproduction ou autre utilisation de ce document est strictement interdite. De plus, le Groupe Financire Banque Nationale et ses filiales ne peuvent pas tre tenus responsables des dommages pouvant tre causs par des virus ou des erreurs de transmission.
DISCLAIMER: This documentation transmitted by electronic mail is intended for the use of the individual to whom or the entity to which it is addressed and may contain information which is confidential and privileged. Confidentiality and privilege are not lost by this documentation having been sent to the wrong electronic mail address. If you are not the intended recipient or the person responsible for delivering it to the intended recipient please notify the sender immediately and destroy this document as well as any copies of it. Any distribution, reproduction or other use of this document is strictly prohibited. National Bank Financial Group and its affiliates cannot be held liable for any damage that may be caused by viruses or transmission errors.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org