This has digressed into a more architectural problem, which is whether the
data should be delivered in one large payload or incrementally loaded from
the server. The code I originally posted would be used to slice one large
table (already delivered from the server) into smaller tables. That isn't
the best architecture, but it seemed to solve for the original problem.

The best workflow that I can see would load the just *first* table of data
(40 rows) on page load. Once the user chose to move to the next result set,
I would fetch *all* of the
data. As previously mentioned, storing the data in JSON behind the
scenes is fast.
Prototype would then be used to create and destroy the table elements in the
DOM as needed, but loading the first 40 and then loading the rest upon user
invocation seems like the most efficient architecture.

Best,
Alex

On Wed, Feb 10, 2010 at 1:24 PM, T.J. Crowder <t...@crowdersoftware.com>wrote:

> > Would you mind posting or emailing me the source code?
> > Thanks.
>
> The source code to what? You've lost me a bit. I was describing how
> you can do this, not describing code that I have lying around...
> --
> T.J. Crowder
> Independent Software Consultant
> tj / crowder software / com
> www.crowdersoftware.com
>
>
> On Feb 10, 2:18 pm, albert kao <albertk...@gmail.com> wrote:
> > On Feb 9, 5:30 pm, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> >
> >
> >
> > > > That really should be handled serverside IMO. Otherwise all the data
> > > > is downloaded upon initial page call when all you need is one page
> > > > worth at that point.
> >
> > > For me it totally depends. You can have a *lot* more rows of data in
> > > memory as an array of JavaScript objects without taking a performance
> > > hit than you can *display* as table rows. IE bogs down hugely after
> > > only a couple of hundred rows (and the user after only a couple of
> > > dozen), but IE happily holds thousands of rows of pure data in memory.
> > > Similarly, you can send the data to the client in a nice efficient
> > > format, much more efficient than the HTML representation of those
> > > rows. And then when you're paging, the only lag the user experiences
> > > is the lag building the display. I've held thousands of rows of data
> > > in IE without running into performance problems and huge memory
> > > impacts; it's when I need to generate DOM nodes for them (directly or
> > > indirectly) that things spike.
> >
> > > For that reason, I'd maintain a window on either side of what's being
> > > displayed, and only go to the server just *after* the user has been
> > > presented with a new page of rows -- e.g., while they're digesting
> > > this new information they're looking at.
> >
> > > FWIW,
> > > --
> > > T.J. Crowder
> > > Independent Software Consultant
> > > tj / crowder software / comwww.crowdersoftware.com
> >
> > > On Feb 9, 9:10 pm, DJ Mangus <d.man...@gmail.com> wrote:
> >
> > > > That really should be handled serverside IMO. Otherwise all the data
> > > > is downloaded upon initial page call when all you need is one page
> > > > worth at that point.
> >
> > > > Sent from my phone so please pardon any spelling errors.
> >
> > > > On Feb 9, 2010, at 10:20 AM, albert kao <albertk...@gmail.com>
> wrote:
> >
> > > > > Instead of displaying one long table with many rows and use the
> scroll
> > > > > bar to look at the data.
> > > > > Is it possible to divide the table so that each screen will display
> at
> > > > > most 40 rows?
> > > > > The user click the "Next", "Previous" buttons to go to the next or
> > > > > previous page.
> > > > > or the "1", "2", "3", ... to go to any page directly
> > > > > Any sample code available?
> >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups "Prototype & script.aculo.us" group.
> > > > > To post to this group, send email to
> prototype-scriptaculous@googlegroups.com
> > > > > .
> > > > > To unsubscribe from this group, send email to
> prototype-scriptaculous+unsubscr...@googlegroups.com<prototype-scriptaculous%2bunsubscr...@googlegroups.com>
> > > > > .
> > > > > For more options, visit this group athttp://
> groups.google.com/group/prototype-scriptaculous?hl=en
> > > > > .
> >
> > Would you mind posting or emailing me the source code?
> > Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prototype & script.aculo.us" group.
> To post to this group, send email to
> prototype-scriptacul...@googlegroups.com.
> To unsubscribe from this group, send email to
> prototype-scriptaculous+unsubscr...@googlegroups.com<prototype-scriptaculous%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/prototype-scriptaculous?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to