Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Component/s: Uncategorized
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      89
    • Status Whiteboard:
      Hide

      state

      Show
      state

      Description

      Pursuant to AJAX and client script management in relation to web standards, it
      would make sense to extend the ResponseWriter to support client-side javascript.

      ClientResponseWriter extends ResponseWriter {
      public void writeScriptInclude(FacesContext ctx, String file);
      public boolean containsScript(String name);
      public void writeScript(String name, String script);
      public void writeEventByClientId(String id, String event, String script);
      public void writeEventByObject(String object, String event, String script);
      public void flushScripts();
      }

      Those are just a few rough methods. I posted some more well thought out methods
      in the EG mailing list a while back.

      The idea is that while rendering, the component renderers can buffer scripts for
      output when a flushScripts() is executed. This means that we could move away
      from mixing javascript and html where they would be applied as decorators at the
      end of the document (keeping things separate). This would also help remove
      redundancy in the renderers because it would be managed within the
      ClientResponseWriter.

      public ScriptRenderer extends Renderer {
      onStartElement()

      { renderer.flushScripts(); }

      }

      I'm going to probably prototype some of this functionality within Facelets.
      Another approach would be to treat Scripts as Objects which are queued to the
      ClientResponseWriter.

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          2.0

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

          IS> I still think about some kind of representation of the component tree on
          IS> client in some Javascript API.

          Show
          Ed Burns added a comment - IS> I still think about some kind of representation of the component tree on IS> client in some Javascript API.
          Hide
          Ed Burns added a comment -

          >>>>> On Fri, 27 Jul 2007 14:03:53 -0700, Adam Winer <adam.winer@ORACLE.COM> said:

          AW> One major problem with JSF, as it is today, that prevents
          AW> anything other than sequential processing of AJAX-JSF requests,
          AW> is state saving.

          To that end, I have added the "state" tag to the status whiteboard of
          [89-ClientScript]. Let's use the status whiteboard as a repository of
          tags that comprise meta-information for an issue.

          AW> Any postback can modify the state of the JSF UIComponent tree.
          AW> The state of the component tree is stored with a single token.
          AW> Consequently, if you attempt two postbacks simultaneously:

          AW> - Initial state: token A
          AW> - Postback #1 on A: applies state delta D1, returns token B == A + D1
          AW> - Postback #2 on A: applies state delta D2, returns token C == A + D2

          AW> OK, now what state are you in? B, or C? You need to be
          AW> in A + D1 + D2, but that doesn't exist.

          AW> Yes, you're OK if you have completely stateless trees, or can
          AW> guarantee that a postback does not modify any state. But
          AW> we don't have that guarantee today. We should definitely think
          AW> about what it would take to either:
          AW> - Support guarantees that a specific request is stateless even
          AW> if the tree overall has some state
          AW> - Support simultaneous overlapping pushes of state onto a single
          AW> tree (hard!)

          AW> Major problem #2, if you attempt any sharing of UIComponent
          AW> trees, is that UIComponents are not currently thread-safe.
          AW> We should be very careful about trying to make UIComponents
          AW> thread-safe in 2.0, IMO, as component development gets
          AW> a lot harder if they need to be thread-safe.

          AW> This, of course, only covers view-layer reasons why you
          AW> might not want to allow simultaneous requests. Models have
          AW> their own reasons.

          Show
          Ed Burns added a comment - >>>>> On Fri, 27 Jul 2007 14:03:53 -0700, Adam Winer <adam.winer@ORACLE.COM> said: AW> One major problem with JSF, as it is today, that prevents AW> anything other than sequential processing of AJAX-JSF requests, AW> is state saving. To that end, I have added the "state" tag to the status whiteboard of [89-ClientScript] . Let's use the status whiteboard as a repository of tags that comprise meta-information for an issue. AW> Any postback can modify the state of the JSF UIComponent tree. AW> The state of the component tree is stored with a single token. AW> Consequently, if you attempt two postbacks simultaneously: AW> - Initial state: token A AW> - Postback #1 on A: applies state delta D1, returns token B == A + D1 AW> - Postback #2 on A: applies state delta D2, returns token C == A + D2 AW> OK, now what state are you in? B, or C? You need to be AW> in A + D1 + D2, but that doesn't exist. AW> Yes, you're OK if you have completely stateless trees, or can AW> guarantee that a postback does not modify any state. But AW> we don't have that guarantee today. We should definitely think AW> about what it would take to either: AW> - Support guarantees that a specific request is stateless even AW> if the tree overall has some state AW> - Support simultaneous overlapping pushes of state onto a single AW> tree (hard!) AW> Major problem #2, if you attempt any sharing of UIComponent AW> trees, is that UIComponents are not currently thread-safe. AW> We should be very careful about trying to make UIComponents AW> thread-safe in 2.0, IMO, as component development gets AW> a lot harder if they need to be thread-safe. AW> This, of course, only covers view-layer reasons why you AW> might not want to allow simultaneous requests. Models have AW> their own reasons.
          Hide
          Ed Burns added a comment -

          AW> I still see components/renderers as mediators here - adding a
          AW> JS converter or validator to a black-box component is
          AW> not realistic, as it assumes knowledge of the DOM structure
          AW> of the component. Which means we need a standard JS
          AW> converter/validator API, and an easy-enough way to get
          AW> components to hook into it.

          Show
          Ed Burns added a comment - AW> I still see components/renderers as mediators here - adding a AW> JS converter or validator to a black-box component is AW> not realistic, as it assumes knowledge of the DOM structure AW> of the component. Which means we need a standard JS AW> converter/validator API, and an easy-enough way to get AW> components to hook into it.
          Hide
          Ed Burns added a comment -

          IS> Yes, that's true. We need standard JS API for validators. That presume
          IS> some client (JS) API for messages, component tree navigation and may be
          IS> some generic form of component state. And of course we need standard API
          IS> for asynchronous client-to-server events (Ajax) and may be something for
          IS> synchronous (normal form submission).
          IS> Looks like we need plenty of JavaScript there.

          Show
          Ed Burns added a comment - IS> Yes, that's true. We need standard JS API for validators. That presume IS> some client (JS) API for messages, component tree navigation and may be IS> some generic form of component state. And of course we need standard API IS> for asynchronous client-to-server events (Ajax) and may be something for IS> synchronous (normal form submission). IS> Looks like we need plenty of JavaScript there.
          Hide
          Ed Burns added a comment -

          Per 20080827 marking FIXED

          Show
          Ed Burns added a comment - Per 20080827 marking FIXED
          Hide
          Ed Burns added a comment -

          Prepare to delete api subcomponent

          Show
          Ed Burns added a comment - Prepare to delete api subcomponent
          Hide
          Manfred Riem added a comment -

          Closing resolved issue out

          Show
          Manfred Riem added a comment - Closing resolved issue out

            People

            • Assignee:
              Ed Burns
              Reporter:
              jhook
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: