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 <[email protected]> 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 <[email protected]>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 <[email protected]> wrote: > > > On Feb 9, 5:30 pm, "T.J. Crowder" <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 > > [email protected] > > > > > > . > > > > > > To unsubscribe from this group, send email to > > [email protected]<prototype-scriptaculou > > s%[email protected]> > > > > > > . > > > > > > 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 > > [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<prototype-scriptaculou > > s%[email protected]> > > . > > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
