tags:

views:

117

answers:

2

Is server side pagination where the pagination script calculates the number of entries in a database then make the links? All I know is server side is faster and better if there is alot of data and client side is using javascript?

What makes a pagination script server or client side?

Also, right now I am planning to use this pagination which is like digg-style. Can someone tell me if that is server-side pagination? (sorry if my terminology is off)

+4  A: 

Client side is when you pull all the data down and then the client segments the data into pages.

Server-side is usually done by the client providing a key that is passed to the server and then the server only selects out that "page" of data. For example if you were displaying people by last name, the first page might be created by telling the server that you want people with the last name of 'A' and that you want 10 rows returned.

The server would do something like:

SELECT ssn, fname, lname 
FROM people 
WHERE lname like 'a%' and rownum <= 10 ORDER BY lname, ssn;

If the last/10th record has a last name of 'abbot' with an SSN of 555555555, then the next page could be retrieved by the client passing those values back to the server which would then do something such as:

SELECT ssn, fname, lname 
FROM people 
WHERE lname >= 'abbot' and ssn > 555555555 and rownum <= 10 ORDER BY lname, ssn;

Server-side is considered better for large-sets of data as the amount of data transferred to the client is far smaller than if all the data is pulled down and "paged" by the client. It also lowers the memory required for the client side as well as taking advantage of the strong capabilities of databases to sort data or use existing sorted indexes to speed selection.

RC
So you are saying if it displays 1 2 3 [4] 5...59 60 that is client side? because it shows all the pages and not just one page
ggfan
No, the server could tell the client how many pages there are so the client knows how many numbers to display.
Carson Myers
+2  A: 

Server side pagination:

The server takes a number of parameters from the user (current page #, ordering, etc) and performs whatever search required to get just the relevant records. These are sent to the client, along with links to more pages, etc.

Each time the user clicks a link, you get a page refresh showing the new data.

Useful when:

  • there's many results or the payload for each result is quite large
  • looking up/processing the results is very time consuming
  • users rarely go past the first page

Not so great because:

  • Each click is a round trip to the server, which might take some time
  • Maintaining state is a PITA

Client side pagination:

The server sends all available records to the client, and using Javascript, these results are split into pages and rendered client-side. Changing pages or item ordering is as good as instant, and requires no server interaction. This makes it much easier to cache the results on the server side.

Useful when:

  • There's not many results (only a handful of pages)
  • Users will be using many pages (therefore sending the extra data isn't a waste)
  • Splitting up a form: because each page of inputs is merely being hidden and not removed, the entire form can be sent in one form submit.

Not so great because:

  • The initial page load is much larger
  • Might cause problems for users without JS on (though graceful degradation is quite possible)
  • You may need to duplicate your display logic into Javascript.

A Blended approach

Write your application to fully use server-side pagination. Once that is working, use javascript to intercept all links which change the page or the ordering, and send those requests via AJAX. Adapt your server-side script to return just the HTML necessary for any given page, and none of the page chrome around it when it is responding to an AJAX request.

Benefits:

  • Minimal payload for each page-turn = faster response times.
  • Completely scalable.
  • Degrades perfectly.
nickf