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:[EMAIL PROTECTED] Envoyé : Thursday, February 16, 2006 5:39 PM À : [email protected] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
