Indeed this is a discussion of architecture and design. In my case, on
the backend my data layer takes a from and a limit and rips off the
results and delivers to the client a json result. On the client, the
user can page forwards, backwards, jump to pages, and even change the
result limit to fetch. This is quite a bit of code and not easily
shared.
Karl..

On Feb 10, 1:29 pm, Alex Wallace <alexmlwall...@gmail.com> wrote:
> 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-scriptaculou 
> > s%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-scriptaculou 
> > s%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