Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      Currently component referencing with the JSF API is very limited.
      Keywords can currently only be used with f:ajax and not for e.g. outputLabel "for" attribute.
      Also keywords cant be combined and we dont even have many keywords.

      For PrimeFaces, i created a small modular API to enhance the search alogorithm as you can read here:
      http://blog.primefaces.org/?p=2740

      Noteable features are:

      • keywords can be used for all components
      • combinable keywords like @composite:@parent or @form:myId
      • currently a (limited) pluggable framework to allow new keywords for endusers

      For the JSF API, a new artifact for resolving expression for findComponent (like ViewHandler etc.) would be great and can easily be enhanced by component libraries.
      Maybe something like "ComponentExpressionResolver".

      If its somehow possible, i would like to help to create and finalyze the API.

      Sorry for Issue 1237 - please close it.

      1. 20170113-1208-2_3_x-wls-12_2_1-development-fss-client.txt
        3.09 MB
        Ed Burns
      2. 20170116-0432Z-JAVASERVERFACES_SPEC_PUBLIC-1238.diff
        310 kB
        Ed Burns
      3. AjaxBehaviorRenderer.java
        14 kB
        Ed Burns
      4. changebundle.txt
        1 kB
        Ed Burns
      5. changebundle.txt
        4 kB
        Ed Burns
      6. spec-1238.diff
        303 kB
        Ed Burns
      7. spec-1238-20170114.diff
        0.7 kB
        Ed Burns

        Activity

        tandraschko created issue -
        Hide
        Ed Burns added a comment -

        Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Ed Burns made changes -
        Field Original Value New Value
        Priority Major [ 3 ] Trivial [ 5 ]
        Manfred Riem made changes -
        Assignee Ed Burns [ edburns ]
        Ed Burns made changes -
        Priority Trivial [ 5 ] Minor [ 4 ]
        Hide
        Ed Burns added a comment -

        This area is very sensitive to performance problems.

        Show
        Ed Burns added a comment - This area is very sensitive to performance problems.
        Hide
        tandraschko added a comment - - edited

        The performance won't be affected for existing applications as the new search expression logic is only used if the whole expression string contains a "@".
        Some expressions are faster, some are slower but the overall performance is very good and i did a lot of optimization for it.

        Would great to see it in the next API release. BootsFaces implemented a similiar API.
        As i said, i would take care of it and would contribute my ideas to the JSF API.

        Show
        tandraschko added a comment - - edited The performance won't be affected for existing applications as the new search expression logic is only used if the whole expression string contains a "@". Some expressions are faster, some are slower but the overall performance is very good and i did a lot of optimization for it. Would great to see it in the next API release. BootsFaces implemented a similiar API. As i said, i would take care of it and would contribute my ideas to the JSF API.
        Hide
        stephanrauh added a comment - - edited

        I agree with Thomas. I consider the advanced search expressions very useful. So useful, that I implemented them in BootsFaces 0.8.0 myself. As for the performance considerations: granted, we should keep the performance in mind. However, I'm using the PrimeFaces search expressions for years now without noting a performance penalty. In particular, the expressions I use most frequently - @parent, @next and @previous - are implemented in a very efficient way.

        Show
        stephanrauh added a comment - - edited I agree with Thomas. I consider the advanced search expressions very useful. So useful, that I implemented them in BootsFaces 0.8.0 myself. As for the performance considerations: granted, we should keep the performance in mind. However, I'm using the PrimeFaces search expressions for years now without noting a performance penalty. In particular, the expressions I use most frequently - @parent, @next and @previous - are implemented in a very efficient way.
        arjan tijms made changes -
        Priority Minor [ 4 ] Major [ 3 ]
        Hide
        balusc added a comment -

        This is one of the things I'd like to see in JSF 2.3 as well. Community contribution is very welcome.

        Show
        balusc added a comment - This is one of the things I'd like to see in JSF 2.3 as well. Community contribution is very welcome.
        Hide
        Ed Burns added a comment -

        Diff of pull request 4.

        Show
        Ed Burns added a comment - Diff of pull request 4.
        Ed Burns made changes -
        Attachment spec-1238.diff [ 55870 ]
        Ed Burns made changes -
        Assignee Ed Burns [ edburns ]
        Ed Burns made changes -
        Attachment changebundle.txt [ 55871 ]
        Ed Burns made changes -
        Attachment changebundle.txt [ 55872 ]
        Hide
        Ed Burns added a comment -

        Committed as b243817. Will roll back immediately if the build breaks.

        Show
        Ed Burns added a comment - Committed as b243817. Will roll back immediately if the build breaks.
        Ed Burns made changes -
        Comment [ Hudson appears clean. ]
        Hide
        Ed Burns added a comment - - edited

        This change appears to have broken the WLS 12.2.1 builds so I must revert it. I will move it to a topic branch.

        Revert commit is 6e74667c.

        Show
        Ed Burns added a comment - - edited This change appears to have broken the WLS 12.2.1 builds so I must revert it. I will move it to a topic branch. Revert commit is 6e74667c.
        Hide
        Ed Burns added a comment -

        Commit 3dade0c50300d62da59a7d30b693743903da7aed on topic branch has the work.

        Show
        Ed Burns added a comment - Commit 3dade0c50300d62da59a7d30b693743903da7aed on topic branch has the work.
        Hide
        arjan tijms added a comment -

        Was it the Spec1238IT test that failed? If so adding the following to the test might rectify it:

        @JsfTest(value = JSF_2_3_0_M10, excludes = {WEBLOGIC_12_1_4, WEBLOGIC_12_2_1})
        
        Show
        arjan tijms added a comment - Was it the Spec1238IT test that failed? If so adding the following to the test might rectify it: @JsfTest(value = JSF_2_3_0_M10, excludes = {WEBLOGIC_12_1_4, WEBLOGIC_12_2_1})
        Ed Burns made changes -
        Attachment spec-1238.diff [ 55873 ]
        Hide
        Ed Burns added a comment -

        Thanks Arjan, yes it was that test that failed. But I don't want to exclude it on WLS. It should run on WLS if it is a truly backward compatible change, which it must be since it is not hidden behind a context param.

        Show
        Ed Burns added a comment - Thanks Arjan, yes it was that test that failed. But I don't want to exclude it on WLS. It should run on WLS if it is a truly backward compatible change, which it must be since it is not hidden behind a context param.
        Ed Burns made changes -
        Attachment spec-1238.diff [ 55870 ]
        Ed Burns made changes -
        Ed Burns made changes -
        Attachment spec-1238-20170114.diff [ 55875 ]
        Ed Burns made changes -
        Attachment 20170114-1515-i_spec_1238.diff [ 55876 ]
        Ed Burns made changes -
        Attachment 20170114-1515-i_spec_1238.diff [ 55876 ]
        Ed Burns made changes -
        Attachment 20170115-1253Z-JAVASERVERFACES_SPEC_PUBLIC-1238.diff [ 55877 ]
        Ed Burns made changes -
        Attachment 20170115-1253Z-JAVASERVERFACES_SPEC_PUBLIC-1238.diff [ 55877 ]
        Ed Burns made changes -
        Ed Burns made changes -
        Attachment AjaxBehaviorRenderer.java [ 55879 ]
        Hide
        Ed Burns added a comment -

        Ok, commit 3ab4cf8 has the fix that passes all tests. If it breaks the build this time, it is possible we may not have this feature in JSF 2.3.

        Show
        Ed Burns added a comment - Ok, commit 3ab4cf8 has the fix that passes all tests. If it breaks the build this time, it is possible we may not have this feature in JSF 2.3.
        Hide
        Ed Burns added a comment -

        Built with

        webapp.projectStage=Development
        webapp.stateSavingMethod=server
        webapp.partialStateSaving=false
        webapp.serializeServerState=false

        Show
        Ed Burns added a comment - Built with webapp.projectStage=Development webapp.stateSavingMethod=server webapp.partialStateSaving=false webapp.serializeServerState=false
        Ed Burns made changes -
        Attachment jsf-systest.war [ 55880 ]
        Hide
        Ed Burns added a comment - - edited

        Commit dcca156 has the @Ignore of the failing tests.

        Show
        Ed Burns added a comment - - edited Commit dcca156 has the @Ignore of the failing tests.
        Hide
        Ed Burns added a comment -

        Commit c1eff0f removes the @Ignore and reverts the change that was causing them to fail.

        Show
        Ed Burns added a comment - Commit c1eff0f removes the @Ignore and reverts the change that was causing them to fail.

          People

          • Assignee:
            Ed Burns
            Reporter:
            tandraschko
          • Votes:
            6 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated: