Paginate results sets on the server to increase performance

Registered by jason.p.pickering on 2010-04-22

Currently, results sets, such as the list of data elements, indicators are returned in bulk to the client. It be more efficient to have the option to paginate the result set on the server, and return a smaller block of data to the client. This has apparetnly been implemented in the patient based module (http://<email address hidden>/msg04545.html) and should be extended to include data elements, indicator, and potentially any other objects that return relatively large amounts of data to the browser.

More specifications as follows.

1) Use the user settings to determine what the initial sorting order should
be (e.g. name, shortname, etc). Retrieve the first block of data based on whatever the user
settings are when the user enters the page. At this point there would
be no filter applied to the result set, but the first 30 rows (or so) in the correct order would be displayed to the user.

2) Should the user apply a filter, a new block of data would need to
be retrieved, based on the user input.

One thing that I have noticed
is that there should be some sort of "delay" implemented until the
user finishes typing. It would be inefficient to send an AJAX request
each time the user types a character, but the request should be
generated once the user stops typing. This might require some
experimentation. My browser sort of does a "hiccup and even freezed" each time I filter
on the data element list, as it filters after the input of each
character. If it would be possible to wait until the user actually
finishes typing, and then make the filter, this might result in a
better user experience. On a slow machine of mine, Firefox has crashed
several times while trying to filter the data element list. If getting the AJAX right proves to be too difficult, then simply a button "Filter" that you user would need to press would be a better option to a hung browser.

3) I would think it would be desirable to view all results (the
current view that we have) as well.

This should be consistent for all main lists in the system.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
jason.p.pickering
Direction:
Needs approval
Assignee:
Quang Nguyen
Definition:
Approved
Series goal:
Accepted for trunk
Implementation:
Implemented
Milestone target:
milestone icon 2.0.6
Started by
Lars Helge Øverland on 2011-01-05
Completed by
Lars Helge Øverland on 2011-01-05

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.