Comments on: Planning for size in your web application http://almaer.com/blog/planning-for-size-in-your-web-application blogging about life, the universe, and everything tech Sat, 08 Sep 2012 07:06:53 -0700 http://wordpress.org/?v=2.8.4 hourly 1 By: Peter Bell http://almaer.com/blog/planning-for-size-in-your-web-application/comment-page-1#comment-34217 Peter Bell Fri, 29 Sep 2006 03:20:58 +0000 http://almaer.com/blog2/planning-for-size-in-your-web-application#comment-34217 If you want to provide a generic solution, set a threshold (say 500 instances). Below that the system uses client side paging, beyond it calls a SP which handles the paging. That is the way I generate apps. In that way a client has control over the threshold on an object by object basis and I don't nee to write custom code when a collection starts to grow! Best Wishes, Peter If you want to provide a generic solution, set a threshold (say 500 instances). Below that the system uses client side paging, beyond it calls a SP which handles the paging. That is the way I generate apps. In that way a client has control over the threshold on an object by object basis and I don’t nee to write custom code when a collection starts to grow!

Best Wishes,
Peter

]]> By: Paul Barry http://almaer.com/blog/planning-for-size-in-your-web-application/comment-page-1#comment-34216 Paul Barry Thu, 28 Sep 2006 19:04:52 +0000 http://almaer.com/blog2/planning-for-size-in-your-web-application#comment-34216 How about add paging to your list users screen? How about add paging to your list users screen?

]]> By: Anthony Eden http://almaer.com/blog/planning-for-size-in-your-web-application/comment-page-1#comment-34215 Anthony Eden Thu, 28 Sep 2006 18:43:24 +0000 http://almaer.com/blog2/planning-for-size-in-your-web-application#comment-34215 I've noticed more and more that the typical dev cycle now involves creating the simple interface first, using it and then refactoring as time passes, and I'm just fine with that. As you pointed out, during the testing and initial rollout a user list (paginated of course) *is* the easiest interface to understand, and in most cases it is also the easiest to implement. As the list grows refactoring is critical to adapt to the (hopefully) growing user base. Anyhow, being a skilled refactorer is going to be increasingly important (as if it isn't already extremely important already), and having languages which are terse and easy to refactor are is also going to be more and more important. And this is not refactoring at the method level I'm talking about, but refactoring at the functional level. I’ve noticed more and more that the typical dev cycle now involves creating the simple interface first, using it and then refactoring as time passes, and I’m just fine with that. As you pointed out, during the testing and initial rollout a user list (paginated of course) *is* the easiest interface to understand, and in most cases it is also the easiest to implement. As the list grows refactoring is critical to adapt to the (hopefully) growing user base.

Anyhow, being a skilled refactorer is going to be increasingly important (as if it isn’t already extremely important already), and having languages which are terse and easy to refactor are is also going to be more and more important. And this is not refactoring at the method level I’m talking about, but refactoring at the functional level.

]]>