3 ms·

I'm confused as to why this is hard. I code primarily in java with JSF for views and this is possibly the simplest thing to do in any of my projects. Using so

by mbell 15y ago

I'm confused as to why this is hard. I code primarily in java with JSF for views and this is possibly the simplest thing to do in any of my projects. Using something like primefaces I generally never even need to write a line of javascript unless i need to customize some action and I can use theme roller / stock css for appearance. Example: http://www.primefaces.org/showcase-labs/ui/datatableComplex.jsf http://www.primefaces.org/showcase-labs/ui/datatableComplex.... This is working client side, if i want to do server side its as simple as implementing a single class that pushes the sorting/filtering/paging off the to the database: Example: http://www.primefaces.org/showcase-labs/ui/datatableLazy.jsf http://www.primefaces.org/showcase-labs/ui/datatableLazy.jsf It can't really be much harder to do this on other stacks can it?

rrrazdan 15y ago
JSF is a bit of exception. I haven't 'really' searched but its harder to do this in say Struts. What rule of thumb for the data size do you use when choosing between client side and server side sorting?
- mbell 15y ago
  I wouldn't say there is a hard rule of thumb and there are three levels of operation possible, at least with primefaces: 1) All row data sent to client side, all paging done on client 2) Backing controller contains a List with all data in memory, client only gets 1 page at a time via ajax updates. 3) A truly 'Lazy' data model, ajax request for a new page of rows, controller references a lazy data model that fetches just that page worth of data from the database tier and sends it to the client. In practice I really only use #2 and #3 normally. Unless the application has a bad internet connection as a requirement I assume its faster or negligible to fetch pages via ajax vs loading them all into the client up front. As far as choosing between #2 and #3, for my applications its usually obvious, the table either contains 5-25 items (go with 2) or thousands of items (go with 3). In the middle ground i guess it comes down to loading: Can you afford to use more memory in the web tier or would you rather keep that memory usage down and suffer slightly long update times? Assuming your database is well designed it should only had maybe 10ms onto your response time to just grab the page from the database vs already having it in memory.
deleted 15y ago
[deleted]
pinaceae 15y ago
1., make the Ui scale to 50000 records. pagination sucks in a table. fixed columns headers with dynamic width based on the content are needed. fixed as in display a scrollbar to scroll the table rows.

by mbell 15y ago

rrrazdan 15y ago

JSF is a bit of exception. I haven't 'really' searched but its harder to do this in say Struts. What rule of thumb for the data size do you use when choosing between client side and server side sorting?

mbell 15y ago
I wouldn't say there is a hard rule of thumb and there are three levels of operation possible, at least with primefaces: 1) All row data sent to client side, all paging done on client 2) Backing controller contains a List with all data in memory, client only gets 1 page at a time via ajax updates. 3) A truly 'Lazy' data model, ajax request for a new page of rows, controller references a lazy data model that fetches just that page worth of data from the database tier and sends it to the client. In practice I really only use #2 and #3 normally. Unless the application has a bad internet connection as a requirement I assume its faster or negligible to fetch pages via ajax vs loading them all into the client up front. As far as choosing between #2 and #3, for my applications its usually obvious, the table either contains 5-25 items (go with 2) or thousands of items (go with 3). In the middle ground i guess it comes down to loading: Can you afford to use more memory in the web tier or would you rather keep that memory usage down and suffer slightly long update times? Assuming your database is well designed it should only had maybe 10ms onto your response time to just grab the page from the database vs already having it in memory.

deleted 15y ago

[deleted]

pinaceae 15y ago

1., make the Ui scale to 50000 records. pagination sucks in a table. fixed columns headers with dynamic width based on the content are needed. fixed as in display a scrollbar to scroll the table rows.