javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-333

Portlet Bridge issue: Namespace using Consumer Id when portlet response

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2
    • Component/s: Portlet
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      333
    • Status Whiteboard:
      Hide

      EGTop5 effort_hard cat2 frame size_large importance_medium draft

      Show
      EGTop5 effort_hard cat2 frame size_large importance_medium draft

      Description

      Background: As portlets are components of some consuming application page they
      must worry about rendering unique consumer ids/names so as not to collide with
      other content writers (on the same page). At a minimum portlets are required to
      namespace their global client ids using a consumer supplied ID that is unique
      for that portlet. In addition, though ultimately not the portlets
      responsibility, it is recommended that the portlet additionally namespace all
      (form) field names/ids as this can reduce a consumer's burden that can't allow
      each portlet to run in an independent form.

      Need: Need to make it easy/generic/universal for a UIViewRoot to implement
      NamingContainer where when running in a portlet request will encode in the
      generated id a name that is in part derived from the unique id passed by the
      consumer (by calling ExternalContext.encodeNamespace). So as not to perturb
      Faces pages running in a servlet environment this NamingContainer will only
      augment the id if running in a portlet request.

      Discussion items:

      1. Should javax.faces.component.UIViewRoot implement NamingContainer and
      support above?
      2. Should we make it easy for the bridge to wrap any UIViewRoot to provide
      this behavior if not already supported? Note: the primary issue here is making
      UIViewRoot wrappable, as it currently isn't. The secondary issue relates to
      allowing the bridge to inject itself into the UIViewRoot creation process so it
      can wrap – easily done when ViewHandler.createView is done but not when the
      component is create directly.
      3. In all cases the Bridge needs a way to determine that the Portlet
      NamingContainer is implemented by the UIViewRoot. This is needed not only so
      the bridge knows whether to wrap or not but also so it can set a header/property
      in the response indicating to the consumer that such name spacing has occurred.
      Currently the bridge recognizes this if the UIViewRoot class is annotated with
      javax.portlet.faces.annotation.PortletNamingContainer. Can we use this?

        Activity

        Hide
        Ed Burns added a comment -

        rogerk

        Show
        Ed Burns added a comment - rogerk
        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
        Ed Burns added a comment -

        This appears to be a duplicate of JAVASERVERFACES-3031.

        Show
        Ed Burns added a comment - This appears to be a duplicate of JAVASERVERFACES-3031 .
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

          • Assignee:
            Unassigned
            Reporter:
            mfreedma
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 4 days
              4d
              Remaining:
              Remaining Estimate - 4 days
              4d
              Logged:
              Time Spent - Not Specified
              Not Specified