Rails - Mar 2005 - How do you usually handle pagination for returning page visits?

When I am a web user in (e.g.) an admin module, I often need various
ways of changing the views so that I can see the data I want.  For
example, if I am looking at a list of "customers", I may want to sort
by last name, and perhaps I want to show only those customers whose
purchases exceed X number of dollars.

Now, given that I just set up my customers list as I want it, let''s
say that I go to a separate controller, the "accounts" controller and
change some stuff, and then I come back to my customers list.  As a
user, I expect the customer list to be as it was when I last tweaked
the view the way I wanted it--sorted by last name and showing only
customers whose purchases exceed X number of dollars.

If all of the pages in my application expect this kind of
user-friendly behaviour, and assuming I am using a paginator (such as
the one now shipped in 0.11), it would be very messy to maintain the
"page" parameter from controller to controller and from view to view
without the use of session variables.  So I usually store it in the
session and call it back up when needed.

But it doesn''t seem that the paginator assumes people do this
normally--so I''m curious, how do you usually do it?  Should the
paginator have an option that allows the @session hash to be used
instead of the @params hash in order to recall the page number?

In a modified version of the pre-rails-0.11 paginator helper, I had
made it so that the paginator assumes the page is stored in
@session["#{model_name}_page"] rather than @params["page"]. 
In this
way, at the beginning of an action where the user may have clicked on
a page link (e.g. "next page", or "page 2") I could simply
set the
@session variable (e.g. @session["customer_page"] or
@session["account_page"]) if the @params["page"] parameter
was passed
in.  Without further complicating my controllers, the paginator would
then allow returning renders of the view to display the last page that
the user had seen.

Do you think the benefit of this sort of automation outways the cost
of learning it for a new rails user?

Thanks for your input,

Duane Johnson
(canadaduane)

Duane Johnson wrote:
> Do you think the benefit of this sort of automation outways the cost
> of learning it for a new rails user?
It''s a slippery slope.  I think that once folks are to the point of
wanting stuff like pagination they should be using Rails'' comfy
ergonomic tools to build it themselves or requiring a gem to augment
Rails'' features.  Rails is getting a bit rich on the Action Pack side--
whether you sup of it and grow full and hearty is a matter of taste.  I
think overall we''re tacking in the right direction.

jeremy

Jeremy Kemper wrote:
>Duane Johnson wrote:
>  
>
>>Do you think the benefit of this sort of automation outways the cost
>>of learning it for a new rails user?
>>    
>>
>
>It''s a slippery slope.  I think that once folks are to the point of
>wanting stuff like pagination they should be using Rails'' comfy
>ergonomic tools to build it themselves or requiring a gem to augment
>Rails'' features.  Rails is getting a bit rich on the Action Pack
side--
>whether you sup of it and grow full and hearty is a matter of taste.  I
>think overall we''re tacking in the right direction.
>
>jeremy
>_______________________________________________
>Rails mailing list
>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>  
>
Pagination is a universal problem in web development, it applies to all 
domains (although not all applications). Writing your own pager doesn''t
add any value to your business, anymore than writing your own hash table 
implementation would. Putting all these things in separate gems means 
the new user has to discover where all these things are, what they can 
do, where to get them etc. I say build it into the framework.

Is there a roadmap or feature list to 1.0?

Jeremy Huffman wrote:
> Pagination is a universal problem in web development, it applies to all
> domains (although not all applications). Writing your own pager
doesn''t
> add any value to your business, anymore than writing your own hash table
> implementation would. Putting all these things in separate gems means
> the new user has to discover where all these things are, what they can
> do, where to get them etc. I say build it into the framework.
> 
> Is there a roadmap or feature list to 1.0?
I respectfully and heartily disagree.  There are plenty of universal
problems.  Much of the art of Rails is in its choice of which to solve.

I raise the slippery slope concern because pagination edges close to the
application domain.

Which belong: libs for hierarchical nav menus, wizard workflow, user
authentication and authorization, internationalization?

Best,
jeremy

Jeremy Kemper wrote:
>Jeremy Huffman wrote:
>  
>
>>Pagination is a universal problem in web development, it applies to all
>>domains (although not all applications). Writing your own pager
doesn''t
>>add any value to your business, anymore than writing your own hash table
>>implementation would. Putting all these things in separate gems means
>>the new user has to discover where all these things are, what they can
>>do, where to get them etc. I say build it into the framework.
>>
>>Is there a roadmap or feature list to 1.0?
>>    
>>
>
>I respectfully and heartily disagree.  There are plenty of universal
>problems.  Much of the art of Rails is in its choice of which to solve.
>
>I raise the slippery slope concern because pagination edges close to the
>application domain.
>
>Which belong: libs for hierarchical nav menus, wizard workflow, user
>authentication and authorization, internationalization?
>
>Best,
>jeremy
>
>  
>
Slippery slope is a logical fallacy. The term slippery slope was coined 
by people debunking this tactic.

Please explain more specifically how you think pagination belongs to the 
application domain. Which domain is it that you think pagination belongs to?

I''d ask what guides the feature selection. If its something that 80% of
applications would use, shouldn''t it be considered? I doubt anywhere 
near 80% need web services but I still think its a good idea to include 
them so they can use the domain model.

A library to absctact things like nice javascript menus might be nice. 
That type of thing isn''t commonly seen, so I can hardly say its a 
universal problem or that it should be particularly high on the list.

Wizard workflow is just something you do in the controller, no need for 
any extension there - you could barely right four lines of code that 
would be applicable to more than one application.

User authentication certainly is a universal problem, I''m glad the
login
module was published - I think it should be in the framework. 
Authorization is pretty complicated, different applications have very 
different needs here so I don''t know that I''d tackle it - but
most
commercial frameworks do at least provide role-based security and that 
might be useful to perhaps 80% of application developers.

Internationalization certainly seems a very likely candidate as well, 
although again there wouldn''t be nearly 80% of apps that take advantage
of it.

Jeremy Huffman wrote:
> Please explain more specifically how you think pagination belongs to the
> application domain. Which domain is it that you think pagination belongs
> to?
My point is that Rails is here to help us build apps.  It is not the app
itself.  There''s a fine line there, and I''m trying to point it
out: what
is app and what is infrastructure?

jeremy

Jeremy Kemper wrote:
>Jeremy Huffman wrote:
>  
>
>>Please explain more specifically how you think pagination belongs to the
>>application domain. Which domain is it that you think pagination belongs
>>to?
>>    
>>
>
>My point is that Rails is here to help us build apps.  It is not the app
>itself.  There''s a fine line there, and I''m trying to
point it out: what
>is app and what is infrastructure?
>
>  
>
Certainly that is a very valid question. To me, "what is the app" is 
found in the business requirements document, or software spec, or UI 
design, or the product concept.

As an application designer I want to spend time on data definition, 
business logic, workflow logic and screen layouts. There is no value add 
in me writing a pager, or in me writing an internationalization system 
or a bunch of javascripts to do client-side validations anymore than 
there is a value add in me writing my own database system. I simply want 
to specify how those components should work together to realize my 
design goals.

If someone said they wanted to put in a module to handle shopping carts 
or calculate tariffs or capitalize equipment purchases I would line up 
on your side.

I am very interested in the debate here.  Rails has often been the
"right" tool for several of the applications I''ve written
because of
its grab-bag of abstracted, extensible solutions to common problems.

For example, the model validations are varied and several because of
the diversity of patterns that are tested for.  I think it would be
unfortunate to pull out, say, validates_confirmation_of because it is
not as common a pattern as the pattern addressed by
validates_uniqueness_of.  Of course, there has to be a threshold where
a pattern is considered "common" and therefore included in the
infrastructure.  I lean towards Huffman''s guideline for inclusion when
he states "I simply want to specify how those components should work
together to realize my design goals."

So what is the threshold? The "infrastructure" flag goes up for me
when I see the same problem coming up again and again over several
unique applications.  Pagination, to me, is one of those patterns that
can be solved by the infrastructure. (Thank-you to those who have
implemented it in 0.11).

The question that still remains in my mind is whether or not the
pattern of storing page numbers in the session is as common to others
as it is for me.  If so, it seems that the paginator should handle
this without too much fuss.

In looking at the problem, I wonder if there any chance that the
session could be (optionally) split into controller-specific
namespaces?  I attempted this once as an application add-on, but
didn''t get much of a response.  For example, what if we could specify

@controller_session[''list''][''page'']

where ''list'' is the view and ''page'' is the
stored value for the page
to be listed.

@controller_session would be a shortcut hash in the controller and the view for:

@session[controller.name]

thus allowing each controller to have its own namespace in the session
(so as not to confuse, for example, which of several "list" actions
the "page" parameter is for).  With these controller-specific session
namespaces, we would be able to retrieve the appropriate data to
render the view as the web user last saw it.  In addition, the
paginator would be able to rely on that data to show the correct page
without a ?page=n floating around everywhere.

Duane Johnson
(canadaduane)

P.S.  While I''m on it, it would be handy to say
@controller_session.retrieve and have each of the values injected into
the instance variable scope.  So, for example, if
@session[''CustomersController''][''list''][''page'']
= 3, then
@controller_session.retrieve (within the CustomersController class)
would result in @list[''page''] being available in the
controller and
view.  Thoughts?

On Wed, 23 Mar 2005 23:50:16 -0500, Jeremy Huffman
<jeremy-S3UG9Ld25dVMf0S0rWojDQC/G2K4zDHf@public.gmane.org>
wrote:
> 
> 
> Jeremy Kemper wrote:
> 
> >Jeremy Huffman wrote:
> >
> >
> >>Please explain more specifically how you think pagination belongs
to the
> >>application domain. Which domain is it that you think pagination
belongs
> >>to?
> >>
> >>
> >
> >My point is that Rails is here to help us build apps.  It is not the
app
> >itself.  There''s a fine line there, and I''m trying to
point it out: what
> >is app and what is infrastructure?
> >
> >
> >
> Certainly that is a very valid question. To me, "what is the app"
is
> found in the business requirements document, or software spec, or UI
> design, or the product concept.
> 
> As an application designer I want to spend time on data definition,
> business logic, workflow logic and screen layouts. There is no value add
> in me writing a pager, or in me writing an internationalization system
> or a bunch of javascripts to do client-side validations anymore than
> there is a value add in me writing my own database system. I simply want
> to specify how those components should work together to realize my
> design goals.
> 
> If someone said they wanted to put in a module to handle shopping carts
> or calculate tariffs or capitalize equipment purchases I would line up
> on your side.
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>