Uploaded image for project: 'Commons Validator'
  1. Commons Validator
  2. VALIDATOR-61

[validator] Locale validation doesn't validate all fields (improper form processing)

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • None
    • None
    • None
    • Operating System: other
      Platform: Other

    • 30955

    Description

      Say we have the following formSet definition:

      <!DOCTYPE form-validation PUBLIC
      "-//Apache Software Foundation//DTD Commons Validator Rules Configuration
      1.1//EN"
      "http://jakarta.apache.org/commons/dtds/validator_1_1.dtd">

      <form-validation>
      <global>
      <validator name="required"
      classname="org.apache.commons.validator.TestValidator"
      method="validateRequired"

      methodParams="java.lang.Object,org.apache.commons.validator.Field"
      msg=""/>
      </global>
      <formset>
      <form name="nameForm">
      <field property="firstName" depends="required">
      <arg key="nameForm.firstname.displayname"/>
      </field>
      <field property="lastName" depends="required">
      <arg key="nameForm.lastname.displayname"/>
      </field>
      </form>
      </formset>
      <formset language="en" country="US" variant="TEST1">
      <form name="nameForm">
      <field property="middleName" depends="required">
      <arg key="nameForm.lastname.displayname"/>
      </field>
      </form>
      </formset>

      </form-validation>

      You would expect that when validating with locale en_US_TEST1 middleName would
      be mandatory, but it isn't because in ValidatorResources.processForms() while
      adding the default fields to the current form, we are not adding the fields
      from the form itself!

      Now there is a decision to make and that is what is the preferred order for the
      merged form (merged because we are adding the fields from the default formset).
      I'd say to put first the default formset's fields, but I think it would be nice
      to be able to specify its order (for javascript mainly).

      IMO, this bug is very related to #16920 because it is a locale issue and it has
      to do with the way forms are processed. I would propose to have a locale
      hierarchy: If we are using the formset with locale "en_US_TEST1", this formset
      should include the fields from "en_US", "en" and the default formSet (of course
      iff they haven't been overriden).

      I've made a patch which solves this issues. All the tests are passing fine and
      the new one I created for checking this bug also.

      If this is done properly, the "extends" attribute from Form gains added
      functionality. Right now, form extension is only looking in the formSet it
      belongs which includes its forms + defaultForms. We could have a extension
      syntax definition for this making it possible to extend "en.US.formName" or
      something like this (I am not sure if this would be useful though if we make a
      proper use of the locale hierarchy I talked about). So the ideal scenario would
      be to have a huge default form set, small language aware formsets, smaller
      country aware formsets and so on. I beleive the philosophy of the validator
      should go this way (I think it was in the first place).

      Tell me what you all think and I'll submit a patch if necessary.

      Nacho G. Mac Dowell

      Attachments

        1. ASF.LICENSE.NOT.GRANTED--js.patch
          9 kB
          Nacho G. Mac Dowell
        2. ASF.LICENSE.NOT.GRANTED--locale.patch
          22 kB
          Nacho G. Mac Dowell
        3. ASF.LICENSE.NOT.GRANTED--locale.patch
          42 kB
          Nacho G. Mac Dowell
        4. ASF.LICENSE.NOT.GRANTED--localePatch.txt
          20 kB
          Nacho G. Mac Dowell
        5. ASF.LICENSE.NOT.GRANTED--localePatch.txt
          22 kB
          Nacho G. Mac Dowell

        Activity

          People

            Unassigned Unassigned
            mac@apache.org Nacho G. Mac Dowell
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: