Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.1
    • Fix Version/s: None
    • Component/s: Ajax/JavaScript
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      861
    • Status Whiteboard:
      Hide

      size_small importance_large

      Show
      size_small importance_large

      Description

      Currently there is no clean standardized way to detect a portlet szenario for
      the ajax apis and the attached scripts.
      The main difference is as far as I know how the portlets are handled that we
      have an identifier on the element identifying the portlets viewroot.

      We need a publc api which allows to detect the portlet identifier so that
      further processing is eased.
      Also the apis have to be checked if they are portlet szenario save in their
      specifications (which they probably are as soon as we have the portlet
      identifier determination routine in).

      Probably a public api like jsf.util.getViewRootId() suffices, which would under
      normal szenarii return a "" and in a portlet scenario would return the root
      identifier.

        Issue Links

          Activity

          Hide
          rogerk added a comment -

          triage

          Show
          rogerk added a comment - triage
          Hide
          rogerk added a comment -

          triage

          Show
          rogerk added a comment - triage
          Hide
          tedgoddard added a comment -

          This JIRA appears to describe an API for obtaining the javax.faces.ViewState. This would be very useful in a number of cases:

          • obtaining the ViewState key as a stable value during page rendering would allow it to be directly written into rendered output removing the need for post processing of the response (for server-side state saving only)
          • the ViewState key could be guaranteed to be made available to each form, fixing some Ajax and full page refresh interoperability bugs
          • the ViewState key could be used to implement View "scope" objects without making use of the ViewMap directly, given that the ViewMap is not available until after the UIViewRoot has been restored (for instance, handling bean values affecting ui:include would be simplified)
          Show
          tedgoddard added a comment - This JIRA appears to describe an API for obtaining the javax.faces.ViewState. This would be very useful in a number of cases: obtaining the ViewState key as a stable value during page rendering would allow it to be directly written into rendered output removing the need for post processing of the response (for server-side state saving only) the ViewState key could be guaranteed to be made available to each form, fixing some Ajax and full page refresh interoperability bugs the ViewState key could be used to implement View "scope" objects without making use of the ViewMap directly, given that the ViewMap is not available until after the UIViewRoot has been restored (for instance, handling bean values affecting ui:include would be simplified)
          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.
          Hide
          Manfred Riem added a comment -

          Set priority to Minor

          Show
          Manfred Riem added a comment - Set priority to Minor

            People

            • Assignee:
              Unassigned
              Reporter:
              werpu12
            • Votes:
              5 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 1 week, 3 days
                1w 3d
                Remaining:
                Remaining Estimate - 1 week, 3 days
                1w 3d
                Logged:
                Time Spent - Not Specified
                Not Specified