javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-1674

Complications from relocation of resource components

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Incomplete
    • Affects Version/s: 2.0.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,674
    • Status Whiteboard:
      Hide

      size_medium importance_medium

      Show
      size_medium importance_medium
    • Tags:

      Description

      Encountered while analyzing the following thread:

      http://mail-archives.apache.org/mod_mbox/myfaces-
      dev/201005.mbox/%3c4BF34C9E.3010108@oracle.com%3e

      ScriptStyleBaseRenderer registers itself as a PostAddToViewEvent listener on
      <h:outputScript>/<h:outputStylesheet> components. When the components are added to the view,
      ScriptStyleBaseRenderer calls UIViewRoot.addComponentResource() on these components. This has the
      side effect of removing these components from their parent and re-adding them under a new parent:
      the UIViewRoot.

      This results in several complications:

      1. These components are repeatedly re-created on each request.

      When tags are re-executed on postbacks against an existing component tree (during render response),
      these components are no longer found were they are expected to be. As a result, the tag will re-create
      the component and re-add it to its original parent on every request.

      This can result in a loss of state, though in the <h:outputScript>/<h:outputStylesheet> cases the
      likelihood of any bonus state being associated with these components is low. Even so, this approach
      seems wasteful - we should not need to continually re-create these components.

      2. EL-based attributes of these components are evaluated in the wrong context.

      EL expressions may reference objects/context set up by ancestor components. Since these components
      are re-located to the UIViewRoot, EL expressions specified by page authors may not evaluate in the
      expected manner - ie. EL expressions that rely on ancestor context will fail as the ancestor chain
      changes during relocation.

      3. Non-rendered resources are added.

      Since PostAddToViewEvents are delivered to all components, not just components in rendered subtrees,
      this means that non-rendered resources will be added/included in the response.

      The above email thread discusses a possible way to avoid this - eg. we could add a post-tag
      execution/pre-render tree visit that would allow resources for the rendered tree to be collected in
      context.

      This is going to require spec support/changes, so we'll likely need to log spec issues if this isn't already
      covered by spec issues that Leonardo has filed.

        Activity

        Hide
        rogerk added a comment -

        Retarget - spoke with Andy Schwartz and we agreed that we would need to specify
        new Visit Hints.

        Show
        rogerk added a comment - Retarget - spoke with Andy Schwartz and we agreed that we would need to specify new Visit Hints.
        Hide
        Manfred Riem added a comment -

        Can you verify if this is still an issue with the latest 2.1 release?

        Show
        Manfred Riem added a comment - Can you verify if this is still an issue with the latest 2.1 release?
        Hide
        Manfred Riem added a comment -

        Lowering priority because of no response

        Show
        Manfred Riem added a comment - Lowering priority because of no response
        Hide
        Manfred Riem added a comment -

        Lowering priority because of no response

        Show
        Manfred Riem added a comment - Lowering priority because of no response
        Hide
        Manfred Riem added a comment -

        Closing because of inactivity

        Show
        Manfred Riem added a comment - Closing because of inactivity

          People

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

            Dates

            • Created:
              Updated:
              Resolved: