Loading ...
Sorry, an error occurred while loading the content.
 

Re: Data layer for speed in fat-ajax applications

Expand Messages
  • y_lsmith
    ... [snip] ... the page. ... http://dev.forkjavascript.org/trac/browser/branches/RB-0.1/public/javascripts/fork/mutate.js#L83 ... This method is a good
    Message 1 of 8 , Jul 31, 2008
      --- In ydn-javascript@yahoogroups.com, "Peter Michaux"
      [snip]
      >
      > It is a roundabout way to use innerHTML.
      >
      > Suppose a table in the actual pages needs to be updated. If a variable
      > "rows" holds the html to be used as the new rows of the table then do
      > this
      >
      > var d = document.createElement('div')
      > d.innerHTML = '<table><tbody>' + rows + '</tbody></table>';
      > var tbody = d.childNodes[0].childNodes[0]
      >
      > This tbody element can replace the current tbody element actually in
      the page.
      >
      > This procedure using innerHTML is much faster than using createElement
      > and appendChild to build up the cells and rows of a table.
      >
      > ----
      >
      > I've wrapped this type of functionality up in a library:
      >
      >
      http://dev.forkjavascript.org/trac/browser/branches/RB-0.1/public/javascripts/fork/mutate.js#L83
      > http://forkjavascript.org/mutate/docs
      >
      > Peter
      >

      This method is a good solution for moderately sized tables containing
      content free of event handlers. In DataTable's case, we didn't have
      that option because the tables can get quite large, and cell contents
      can be rendered using implementer specific formatters, which are free
      to add event handlers.

      Luke
    • Peter Michaux
      ... Why do you write moderately sized ? I specifically used this for a very large table. The larger the table the bigger the benefit. Using event delegation
      Message 2 of 8 , Jul 31, 2008
        On Thu, Jul 31, 2008 at 9:21 AM, y_lsmith <lsmith@...> wrote:
        > --- In ydn-javascript@yahoogroups.com, "Peter Michaux"
        > [snip]
        >>
        >> It is a roundabout way to use innerHTML.
        >>
        >> Suppose a table in the actual pages needs to be updated. If a variable
        >> "rows" holds the html to be used as the new rows of the table then do
        >> this
        >>
        >> var d = document.createElement('div')
        >> d.innerHTML = '<table><tbody>' + rows + '</tbody></table>';
        >> var tbody = d.childNodes[0].childNodes[0]
        >>
        >> This tbody element can replace the current tbody element actually in
        > the page.
        >>
        >> This procedure using innerHTML is much faster than using createElement
        >> and appendChild to build up the cells and rows of a table.
        >>
        >> ----
        >>
        >> I've wrapped this type of functionality up in a library:
        >>
        >>
        > http://dev.forkjavascript.org/trac/browser/branches/RB-0.1/public/javascripts/fork/mutate.js#L83
        >> http://forkjavascript.org/mutate/docs
        >>
        >> Peter
        >>
        >
        > This method is a good solution for moderately sized tables containing
        > content free of event handlers.

        Why do you write "moderately sized"? I specifically used this for a
        very large table. The larger the table the bigger the benefit.

        Using event delegation is a good solution for this problem; however,
        It is possible to use event handlers with this system. For example,
        particular elements can be found after the innerHTML operation and
        handlers attached. Another method to use event handlers is to have
        inline event handler attributes in the HTML and use the flyweight
        pattern where the cell identifies itself in a call to some other
        functions.

        Peter
      • y_lsmith
        ... variable ... createElement ... http://dev.forkjavascript.org/trac/browser/branches/RB-0.1/public/javascripts/fork/mutate.js#L83 ... If you have a large
        Message 3 of 8 , Jul 31, 2008
          --- In ydn-javascript@yahoogroups.com, "Peter Michaux"
          <petermichaux@...> wrote:
          >
          > On Thu, Jul 31, 2008 at 9:21 AM, y_lsmith <lsmith@...> wrote:
          > > --- In ydn-javascript@yahoogroups.com, "Peter Michaux"
          > > [snip]
          > >>
          > >> It is a roundabout way to use innerHTML.
          > >>
          > >> Suppose a table in the actual pages needs to be updated. If a
          variable
          > >> "rows" holds the html to be used as the new rows of the table then do
          > >> this
          > >>
          > >> var d = document.createElement('div')
          > >> d.innerHTML = '<table><tbody>' + rows + '</tbody></table>';
          > >> var tbody = d.childNodes[0].childNodes[0]
          > >>
          > >> This tbody element can replace the current tbody element actually in
          > > the page.
          > >>
          > >> This procedure using innerHTML is much faster than using
          createElement
          > >> and appendChild to build up the cells and rows of a table.
          > >>
          > >> ----
          > >>
          > >> I've wrapped this type of functionality up in a library:
          > >>
          > >>
          > >
          http://dev.forkjavascript.org/trac/browser/branches/RB-0.1/public/javascripts/fork/mutate.js#L83
          > >> http://forkjavascript.org/mutate/docs
          > >>
          > >> Peter
          > >>
          > >
          > > This method is a good solution for moderately sized tables containing
          > > content free of event handlers.
          >
          > Why do you write "moderately sized"? I specifically used this for a
          > very large table. The larger the table the bigger the benefit.

          If you have a large table, I would think that appending a docfrag to
          the existing tbody would render faster because the entire DOM
          structure in the tbody isn't being recreated, only reflowed. Less
          memory consumption by avoiding the lengthy string concat as well. If
          event handlers in the content weren't a concern, I might see if I
          could use that method to create the additional rows to populate the
          docfrag, though. That said, I've not done benchmarks because the
          event handler issue makes the point moot for now, imo. It would
          certainly be interesting to see some numbers. I might put something
          together if I ever get a spare moment :)


          >
          > Using event delegation is a good solution for this problem; however,
          > It is possible to use event handlers with this system. For example,
          > particular elements can be found after the innerHTML operation and
          > handlers attached. Another method to use event handlers is to have
          > inline event handler attributes in the HTML and use the flyweight
          > pattern where the cell identifies itself in a call to some other
          > functions.

          Event delegation is generally a good idea and we strongly encourage
          using it. Declaring inline handlers is something we discourage,
          though. There are cases when they may make sense pragmatically, but
          generally speaking we recommend against their use. As to
          (re)attaching event handlers after writing innerHTML, when nesting
          widgets that maintain their own state, UI, and event infrastructure,
          it's non-trivial (if possible) to rewire them after clobbering a
          parent container's innerHTML, and certainly nothing we'd expect
          implementers to have to deal with. We maintain the existing DOM as
          much as possible to avoid conflicts with implementer code/style.

          Luke
        • Peter Michaux
          ... My situation is a complete replace of the tbody where all rows are changing. This is used in pagination or a very big dataset. Peter
          Message 4 of 8 , Jul 31, 2008
            On Thu, Jul 31, 2008 at 11:38 AM, y_lsmith <lsmith@...> wrote:
            > --- In ydn-javascript@yahoogroups.com, "Peter Michaux"
            > <petermichaux@...> wrote:
            >>
            >> On Thu, Jul 31, 2008 at 9:21 AM, y_lsmith <lsmith@...> wrote:
            >> > --- In ydn-javascript@yahoogroups.com, "Peter Michaux"
            >> > [snip]
            >> >>
            >> >> It is a roundabout way to use innerHTML.
            >> >>
            >> >> Suppose a table in the actual pages needs to be updated. If a
            > variable
            >> >> "rows" holds the html to be used as the new rows of the table then do
            >> >> this
            >> >>
            >> >> var d = document.createElement('div')
            >> >> d.innerHTML = '<table><tbody>' + rows + '</tbody></table>';
            >> >> var tbody = d.childNodes[0].childNodes[0]
            >> >>
            >> >> This tbody element can replace the current tbody element actually in
            >> > the page.
            >> >>
            >> >> This procedure using innerHTML is much faster than using
            > createElement
            >> >> and appendChild to build up the cells and rows of a table.
            >> >>
            >> >> ----
            >> >>
            >> >> I've wrapped this type of functionality up in a library:
            >> >>
            >> >>
            >> >
            > http://dev.forkjavascript.org/trac/browser/branches/RB-0.1/public/javascripts/fork/mutate.js#L83
            >> >> http://forkjavascript.org/mutate/docs
            >> >>
            >> >> Peter
            >> >>
            >> >
            >> > This method is a good solution for moderately sized tables containing
            >> > content free of event handlers.
            >>
            >> Why do you write "moderately sized"? I specifically used this for a
            >> very large table. The larger the table the bigger the benefit.
            >
            > If you have a large table, I would think that appending a docfrag to
            > the existing tbody would render faster because the entire DOM
            > structure in the tbody isn't being recreated, only reflowed.

            My situation is a complete replace of the tbody where all rows are
            changing. This is used in pagination or a very big dataset.

            Peter
          Your message has been successfully submitted and would be delivered to recipients shortly.