MyFaces Core
  1. MyFaces Core
  2. MYFACES-3259

Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.10, 2.1.4
    • Component/s: None
    • Labels:
      None

      Description

      demo forthcoming; it would seem the FaceletCompositionContext would need to keep track of the delegate as well as the id of enclosing validators in order to be able to apply the xml attributes.

      1. MYFACES-3259.tar.gz
        5 kB
        Matt Benson
      2. MYFACES-3259.tar.gz
        5 kB
        Matt Benson
      3. MYFACES-3259-1.patch
        31 kB
        Leonardo Uribe

        Activity

        Matt Benson created issue -
        Hide
        Matt Benson added a comment -

        works on Mojarra; the CustomValidator included simply validates that its own 'something' attribute has been provided.

        Show
        Matt Benson added a comment - works on Mojarra; the CustomValidator included simply validates that its own 'something' attribute has been provided.
        Matt Benson made changes -
        Field Original Value New Value
        Attachment MYFACES-3259.tar.gz [ 12489259 ]
        Hide
        Matt Benson added a comment -

        updated test project with CustomValidator implementing StateHolder instead of Serializable

        Show
        Matt Benson added a comment - updated test project with CustomValidator implementing StateHolder instead of Serializable
        Matt Benson made changes -
        Attachment MYFACES-3259.tar.gz [ 12489408 ]
        Hide
        Leonardo Uribe added a comment -

        In theory the behavior of <f:validateBean> related to allow wrap input components is unique, compared to other validators. There is no description on any part of the spec about validators or other attached objects different to <f:validateBean> or <f:ajax> that supports "wrap" mode.

        By some coincidence the example proposed here works on Mojarra, but I have to note according to the spec this is not intentional.

        From other point of view, it has sense to support this. I think this should be reported to the EG and then propose a solution on MyFaces. Unfortunately, it is necessary to change some internal code and that will take some time.

        Show
        Leonardo Uribe added a comment - In theory the behavior of <f:validateBean> related to allow wrap input components is unique, compared to other validators. There is no description on any part of the spec about validators or other attached objects different to <f:validateBean> or <f:ajax> that supports "wrap" mode. By some coincidence the example proposed here works on Mojarra, but I have to note according to the spec this is not intentional. From other point of view, it has sense to support this. I think this should be reported to the EG and then propose a solution on MyFaces. Unfortunately, it is necessary to change some internal code and that will take some time.
        Hide
        Matt Benson added a comment -

        Thanks for the attention, Leo. I agree that this wasn't covered in the spec. I'll reread those sections and file an issue.

        Show
        Matt Benson added a comment - Thanks for the attention, Leo. I agree that this wasn't covered in the spec. I'll reread those sections and file an issue.
        Hide
        Matt Benson added a comment -

        Filed http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1033 .

        In the meantime, is there any reason MyFaces should not support this functionality on an implementation-specific basis?

        Show
        Matt Benson added a comment - Filed http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1033 . In the meantime, is there any reason MyFaces should not support this functionality on an implementation-specific basis?
        Hide
        Leonardo Uribe added a comment -

        In theory there is no reason why this could not be added. I have a patch for this one but it requires more testing, because it supposed to do some critical changes.

        Show
        Leonardo Uribe added a comment - In theory there is no reason why this could not be added. I have a patch for this one but it requires more testing, because it supposed to do some critical changes.
        Hide
        Matt Benson added a comment -

        How can I help?

        Show
        Matt Benson added a comment - How can I help?
        Hide
        Leonardo Uribe added a comment -

        Attached patch not ready for commit.

        Show
        Leonardo Uribe added a comment - Attached patch not ready for commit.
        Leonardo Uribe made changes -
        Attachment MYFACES-3259-1.patch [ 12490619 ]
        Hide
        Leonardo Uribe added a comment -

        This is what I have so far. The solution works but looking more carefully this change should follow the same rules as f:ajax. For example, f:ajax does not "pass" through composite components, but "pass" over anything else. The strange thing here is f:validateBean does not have that obvious restriction (but maybe that restriction does not apply after all). I still don't know what to do in this case. What we need here is have some examples about what should work and what shouldn't work, and then implement something according to that.

        Show
        Leonardo Uribe added a comment - This is what I have so far. The solution works but looking more carefully this change should follow the same rules as f:ajax. For example, f:ajax does not "pass" through composite components, but "pass" over anything else. The strange thing here is f:validateBean does not have that obvious restriction (but maybe that restriction does not apply after all). I still don't know what to do in this case. What we need here is have some examples about what should work and what shouldn't work, and then implement something according to that.
        Leonardo Uribe made changes -
        Assignee Leonardo Uribe [ lu4242 ]
        Hide
        Leonardo Uribe added a comment -

        I checked again the solution proposed and now I'm sure this is the way to go. In theory if a composite component class implements EditableValueHolder should not allow f:validateBean to take effect inside its body, but if that so, it is not expected any other UIInput component should be into its body. f:validateBean is very special, but it has some problems like the one described in MYFACES-2528 that suggest the only way to fix them is create a validator that extends from BeanValidator, but it should work the same.

        Composite components usually are used to group components and "derive" more components. f:validateBean is used to fill the gap between JSF and JSR-303 bean validation, so really it try to "decouple" validation and move it from the view to the managed beans. It works as a "controller" for validation, so apply it across composite components does not cause any problem at all, because at the end the validation rules are on the managed beans. In f:ajax case, it is clear the client behavior applies to the composite component, not to the content.

        For other specific validators that does not has a similar intention like f:validateBean should not use wrap mode. But it is not really necessary to enforce that condition, instead, this should be let to the developer of such validator, but the jsf implementation should just allow it.

        If no objections I'll commit the proposed patch soon.

        Show
        Leonardo Uribe added a comment - I checked again the solution proposed and now I'm sure this is the way to go. In theory if a composite component class implements EditableValueHolder should not allow f:validateBean to take effect inside its body, but if that so, it is not expected any other UIInput component should be into its body. f:validateBean is very special, but it has some problems like the one described in MYFACES-2528 that suggest the only way to fix them is create a validator that extends from BeanValidator, but it should work the same. Composite components usually are used to group components and "derive" more components. f:validateBean is used to fill the gap between JSF and JSR-303 bean validation, so really it try to "decouple" validation and move it from the view to the managed beans. It works as a "controller" for validation, so apply it across composite components does not cause any problem at all, because at the end the validation rules are on the managed beans. In f:ajax case, it is clear the client behavior applies to the composite component, not to the content. For other specific validators that does not has a similar intention like f:validateBean should not use wrap mode. But it is not really necessary to enforce that condition, instead, this should be let to the developer of such validator, but the jsf implementation should just allow it. If no objections I'll commit the proposed patch soon.
        Hide
        Matt Benson added a comment -

        Thanks for all the attention to this, Leo!

        Show
        Matt Benson added a comment - Thanks for all the attention to this, Leo!
        Leonardo Uribe made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.0.10 [ 12317870 ]
        Fix Version/s 2.1.4 [ 12317868 ]
        Resolution Fixed [ 1 ]
        Leonardo Uribe made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Matt Benson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development