Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Component/s: Uncategorized
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      426
    • Status Whiteboard:
      Hide

      EGTop5

      Show
      EGTop5

      Description

      For an annotation-based validation, append "createDefaultValidator" method to an
      Application object ( as far as appropriate configuration tags ).
      In the base UIInput component, call validate method for a this validator in
      addition to a per-component validators.
      For a null- or empty values validation, call validator methods for an all
      submitted values ( even for an empty or null ).

      1. changebundle.txt
        4 kB
        Ed Burns
      2. changebundle.txt
        2 kB
        Ed Burns
      3. changebundle.txt
        7 kB
        Ed Burns
      4. changebundle.txt
        221 kB
        Ed Burns

        Issue Links

          Activity

          Hide
          pmuir added a comment -
          • JSR-303 has the concept of validation groups (such that you can apply only
            certain validations annotations)
          • it should be possible to select which group you are validating from JSF
          • There can be more than one group and a default group should be expected
            (this concept is defined in Bean Validation)
          • the group is just a string
          • you should be able to set the validation group for a group of input
            components e.g.

          <f:validate groups="firstscreen">
          <h:inputText id="firstname" value="#

          {account.firstname}" />
          <h:message for="firstname" styleClass="error" />
          <br/>
          <h:inputText id="lastname" value="#{account.lastname}" />
          <h:message for="lastname" styleClass="error" />
          <br/>
          <h:inputText id="cellPhone" value="#{account.cellPhone}" />
          <h:message for="cellPhone" styleClass="error" />
          </f:validate>

          - You should also be able to set the group for a single component

          <h:inputText id="firstname" value="#{account.firstname}

          ">
          <f:validate groups="firstscreen" />
          </h:inputText/>

          • The only sane solution we could see was to validate against the actual
            populated model. This doesn't work in the current JSF lifecycle, so is probably
            beyond the scope of JSF 2
          • Note that, except for the classical password verification example, most
            cross component validation involve somewhat complex rules that are closer to
            business rules than validations. In the password case, there should be a JSF
            validator.
          • Should JSR-303 validations be applied by default if a validation annotation is
            present on the property the input component's value expression binds to?
          • Yes
          • How do you disable validation?
          • Explicitly through:

          <f:validator disableValidator="true">

          • All validators should be callable via Ajax
          • Client side (JS) validation with no Ajax call. This has some challenges! Some
            ideas/notes
          • The idea is to avoid any call to the server (less overhead, more responsive)
          • Validators expose some metadata about what they do (e.g. string length,
            number max value). A custom validator can expose a number of pieces of
          • Custom metadata can be exposed
          • metadata is used to attach JS validators to an input component (the
            validator applied in process validations phase may impose extra validation over
            the metadata based JS validator)
          • custom JS validators may be written which are registered and attached for an
            exposed piece of metadata (for example the validator might say it validates
            uk.postcode, in which case the JS validator for uk.postcode would be attached).
            JS validators can be registered in faces-config.xml. Kito says "This sounds like
            it should be an extension of the current validator registration, which means it
            will also be possible to use annotations. The actual JS validator should also
            reference a JSF resource."
          • How to render validation error messages. JSR-303 has a pluggable message
            resolver which can access e.g. contextual information from Web Beans. This isn't
            available on the client, so the proposal is to provide a "safe" message which is
            generated when the page is rendered. The only replacement it can make is for the
            current input value
          Show
          pmuir added a comment - JSR-303 has the concept of validation groups (such that you can apply only certain validations annotations) it should be possible to select which group you are validating from JSF There can be more than one group and a default group should be expected (this concept is defined in Bean Validation) the group is just a string you should be able to set the validation group for a group of input components e.g. <f:validate groups="firstscreen"> <h:inputText id="firstname" value="# {account.firstname}" /> <h:message for="firstname" styleClass="error" /> <br/> <h:inputText id="lastname" value="#{account.lastname}" /> <h:message for="lastname" styleClass="error" /> <br/> <h:inputText id="cellPhone" value="#{account.cellPhone}" /> <h:message for="cellPhone" styleClass="error" /> </f:validate> - You should also be able to set the group for a single component <h:inputText id="firstname" value="#{account.firstname} "> <f:validate groups="firstscreen" /> </h:inputText/> How to deal with cross-validation (where you need to validate one field against another). This is https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=1 The only sane solution we could see was to validate against the actual populated model. This doesn't work in the current JSF lifecycle, so is probably beyond the scope of JSF 2 Note that, except for the classical password verification example, most cross component validation involve somewhat complex rules that are closer to business rules than validations. In the password case, there should be a JSF validator. Should JSR-303 validations be applied by default if a validation annotation is present on the property the input component's value expression binds to? Yes How do you disable validation? Explicitly through: <f:validator disableValidator="true"> All validators should be callable via Ajax Client side (JS) validation with no Ajax call. This has some challenges! Some ideas/notes The idea is to avoid any call to the server (less overhead, more responsive) Validators expose some metadata about what they do (e.g. string length, number max value). A custom validator can expose a number of pieces of Custom metadata can be exposed metadata is used to attach JS validators to an input component (the validator applied in process validations phase may impose extra validation over the metadata based JS validator) custom JS validators may be written which are registered and attached for an exposed piece of metadata (for example the validator might say it validates uk.postcode, in which case the JS validator for uk.postcode would be attached). JS validators can be registered in faces-config.xml. Kito says "This sounds like it should be an extension of the current validator registration, which means it will also be possible to use annotations. The actual JS validator should also reference a JSF resource." How to render validation error messages. JSR-303 has a pluggable message resolver which can access e.g. contextual information from Web Beans. This isn't available on the client, so the proposal is to provide a "safe" message which is generated when the page is rendered. The only replacement it can make is for the current input value
          Hide
          Ed Burns added a comment -

          EGTop5

          Show
          Ed Burns added a comment - EGTop5
          Hide
          Ed Burns added a comment -

          Change target milestone to 2.0

          Show
          Ed Burns added a comment - Change target milestone to 2.0
          Hide
          Ed Burns added a comment -

          Created an attachment (id=203)
          fix for this bug, merge from branch to trunk

          Show
          Ed Burns added a comment - Created an attachment (id=203) fix for this bug, merge from branch to trunk
          Hide
          Ed Burns added a comment -

          Created an attachment (id=214)
          Change to default validator activation.

          Show
          Ed Burns added a comment - Created an attachment (id=214) Change to default validator activation.
          Hide
          Ed Burns added a comment -

          Created an attachment (id=215)
          reset everything back to the way it was.

          Show
          Ed Burns added a comment - Created an attachment (id=215) reset everything back to the way it was.
          Hide
          Ed Burns added a comment -

          Created an attachment (id=221)
          Fix for performance optimization to not invoke BV unless necessary

          Show
          Ed Burns added a comment - Created an attachment (id=221) Fix for performance optimization to not invoke BV unless necessary
          Hide
          Ed Burns added a comment -

          take ownership

          Show
          Ed Burns added a comment - take ownership
          Hide
          Ed Burns added a comment -

          Fixed

          Show
          Ed Burns added a comment - Fixed
          Hide
          Ed Burns added a comment -

          Prepare to delete api subcomponent

          Show
          Ed Burns added a comment - Prepare to delete api subcomponent
          Hide
          Manfred Riem added a comment -

          Closing resolved issue out

          Show
          Manfred Riem added a comment - Closing resolved issue out

            People

            • Assignee:
              Ed Burns
              Reporter:
              alexsmirnov
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: