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

Ajax rendering lifecycle for components half broken + Solution.

    Details

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

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      785
    • Status Whiteboard:
      Hide

      size_medium importance_large

      Show
      size_medium importance_large

      Description

      The current state of affairs for component rendering is, that we render the
      components in the ajax case by openening the <update> tag before handling the
      control of the rendering to the component. Now this causes several problems.
      First component authors are enforced into an artifical update part, which
      prevents them from fully utilizing the control possibilities of the ajax API!
      Secondly this causes problems in ajax cases where the component does not follow
      the structure of one root element having the client id of the component as id.
      Third this has caused problems in the past regarding javascript evaluation since
      there was no clear way wether embedded scripts needed to be evaled or not (we
      settled down on evaling them over both implementations)

      Now here is a proposed change to remove that problem:
      a) Define a marker interface AjaxAware or PPR Aware
      b) The marker interface has to implement a method renderPPR
      c) The rendering lifecycle now is extended to following first render the
      component as done normally (the ppr aware components can react and render
      placeholders), but the components which are render aware then need to be pushed
      onto a stack which after the update phase is processed.
      Once update is done the all components on the stack need to have renderPPR
      called. Where they now have full control over the response xml.
      Additionally if an open command from the response triggers a pprAware component
      on as child of the original ppr control, the child must be pushed onto a stack.
      Once the pprAware processing is done on the parent, the child stack has to be
      processed etc...
      Until all components are processed.

      Advantages of this approach: It would allow full control of the ppr stack for
      the component authors while being downward compatible to the existing approach.
      Disadvantage you do not have full control over the entire rendering process if
      you stack ppr aware components this might cause sidebehavior between ppr and non
      ppr aware components if the ppr aware components are badly designed (a tradeoff
      which I personally think can be lived with, since the burden is here on the
      component author who gains significantly more control over the rendering
      behavior of his components)

        Activity

        Hide
        Ed Burns added a comment -

        Move to 2.1

        Show
        Ed Burns added a comment - Move to 2.1
        Hide
        Ed Burns added a comment -

        triage

        Show
        Ed Burns added a comment - triage
        Hide
        Ed Burns added a comment -

        rogerk

        Show
        Ed Burns added a comment - rogerk
        Hide
        rogerk added a comment -

        triage - important

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

        Additional info from
        https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=619
        which is a duplicate of this issue:

        It is not currently possible to call startEval from within component render -
        because startUpdate has already been called, and they cannot nest.

        From an email from Werner Punz:

        I think the PPR ResponseWriter should have added behavior
        > which means if you already are in an update tag (or generally open tag)
        > opening another tag like the eval section should be stacked and then
        > rendered after the open tag is closed.
        >
        > That way you can add eval sections for ppr cases in the long run and
        > also can make use of more parts of the PPR Writer api. Currently the
        > writer API as is, can only really be used for servlet cases not
        > components due to already being in update.

        Show
        rogerk added a comment - Additional info from https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=619 which is a duplicate of this issue: It is not currently possible to call startEval from within component render - because startUpdate has already been called, and they cannot nest. From an email from Werner Punz: I think the PPR ResponseWriter should have added behavior > which means if you already are in an update tag (or generally open tag) > opening another tag like the eval section should be stacked and then > rendered after the open tag is closed. > > That way you can add eval sections for ppr cases in the long run and > also can make use of more parts of the PPR Writer api. Currently the > writer API as is, can only really be used for servlet cases not > components due to already being in update.
        Hide
        rogerk added a comment -
            • Issue 619 has been marked as a duplicate of this issue. ***
        Show
        rogerk added a comment - Issue 619 has been marked as a duplicate of this issue. ***
        Hide
        rogerk added a comment -

        Even though Werner has done most of the preparatory work on this issue, I still
        have to move it to JSF
        2.2.

        Show
        rogerk added a comment - Even though Werner has done most of the preparatory work on this issue, I still have to move it to JSF 2.2.
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage

          People

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

            Dates

            • Created:
              Updated: