You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Pete Poulos <pe...@gmail.com> on 2009/07/18 20:40:10 UTC
How to implement paginated search results
Hi,
I have a search page where users enter in a set of search criteria and
are then redirected to a search results page. I don't want to display
all of results in one page, so I am working on implementing a
paginated navigation bar along the top of the page which looks
something like the following:
[first] [prev] [1] [2] 3 [4] [5] ... [9] [10] [next] [last]
>From what I can tell, to make this work I need to pass the search
criteria around to each of these pages so that it can re-run the
database query using a different offset into the results. However, I
am not sure what my options are much less which one is the best (this
is the primary question of this email). Let me add that the user must
be able to have several searches running at the same time in different
tabs.
So far, I've come up with the following ideas:
Session
Store the search criteria in the users session. From what I can tell
this won't work because when the user starts a new search in a new tab
the new search criteria will replace the search criteria used by the
tabs and then those tabs will begin returning results from the new
search...
Page Context
Store the search criteria in the page context (by encoding it into a
string representation?). It seems like a large number of sites store
their search criteria into the pages URL in one manner or another,
however this results in some rather long and ugly URLs (on the bright
side, the user can bookmark their searches and come back to them,
right?). Also, I believe that I would have to be careful how I
implemented this so that the search results page isn't open to SQL
Injection attacks right?
Page Context using a search ID
Instead of storing the search criteria itself in the context, give it
a unique ID and store that ID into the context. The search criteria
would then be stored in a local map or into the database. However,
how do you determine when the user is done with that particular search
and flush its criteria from the data store?
This seems like a fairly common thing to want to do on a website, is
there some sort of Tapestry Patterns page that has best practices for
common things like this?
PS: please share with me other options I haven't considered. I would
like to learn what other options Tapestry provides for situations like
this one.
Thanks in advance,
pete.poulos@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: How to implement paginated search results
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 18 Jul 2009 17:23:52 -0300, Pete Poulos <pe...@gmail.com>
escreveu:
> Thanks for the reply Thiago,
You're welcome!
> How would you set it up? If I have variable number of search criteria
> (the user can leave some criteria empty, also some searches I've seen
> let users add new criteria rows), wouldn't I need to have some sort of
> key value pair listing? Or would you simply map all values as though
> they had entered something? My search page will end up being fairly
> complex.
As you said, there are at least two options: to put all parameters in the
context, used or not (Tapestry already encodes null as $N, so you don't
have to worry about it) or use some name/value scheme. This was discussed
some time ago in this list. The thread can be found here:
http://www.nabble.com/T5%3A-Passing-named-structured-type-params-in-URLs--td23453229.html).
Warning: the thread has two pages. Read them both.
> In particular, could you show an example URL for the page you might
> generate (ie, the alternative representation to the "?a=1&b=2" example
> you have given?
There's no easy way to make Tapestry generate have ?a=1 parameters and use
them as the page activation context. Anyway, they're quite ugly.
> I assume you don't mean "pagename/1/2/" because then
> you can't deal with a variable argument list
You can deal with a variable argument list. Just use EventContext as the
parameter of your onActivate method:
public void onActivate(EventContext context).
> (you would have to encode
> every search parameter even if the user hasn't entered it right?).
In this scenario, you're right, because you wouldn't be able to know what
value was passed to what parameter.
> Maybe something like "pagename/a=1/b=2"?
Tapestry would probably encode '=' in some way, so that's not the best
option.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: How to implement paginated search results
Posted by Pete Poulos <pe...@gmail.com>.
Thanks for the reply Thiago,
I have a question about this item:
>> Page Context
>> Store the search criteria in the page context (by encoding it into a
>> string representation?). It seems like a large number of sites store
>> their search criteria into the pages URL in one manner or another,
>> however this results in some rather long and ugly URLs
>
> IMHO, this isn't ugly, at least with a not large number of parameters. And
> Tapestry's activation context is way prettier than normal parameters
> (?a=1&b=2). The page context is exactly what I would choose in this
> scenario.
How would you set it up? If I have variable number of search criteria
(the user can leave some criteria empty, also some searches I've seen
let users add new criteria rows), wouldn't I need to have some sort of
key value pair listing? Or would you simply map all values as though
they had entered something? My search page will end up being fairly
complex.
In particular, could you show an example URL for the page you might
generate (ie, the alternative representation to the "?a=1&b=2" example
you have given? I assume you don't mean "pagename/1/2/" because then
you can't deal with a variable argument list (you would have to encode
every search parameter even if the user hasn't entered it right?).
Maybe something like "pagename/a=1/b=2"?
Thanks again,
pete.poulos@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: How to implement paginated search results
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Sat, 18 Jul 2009 15:40:10 -0300, Pete Poulos <pe...@gmail.com>
escreveu:
> Hi,
Hi!
> Session
> Store the search criteria in the users session. From what I can tell
> this won't work because when the user starts a new search in a new tab
> the new search criteria will replace the search criteria used by the
> tabs and then those tabs will begin returning results from the new
> search...
You're right.
> Page Context
> Store the search criteria in the page context (by encoding it into a
> string representation?). It seems like a large number of sites store
> their search criteria into the pages URL in one manner or another,
> however this results in some rather long and ugly URLs
IMHO, this isn't ugly, at least with a not large number of parameters. And
Tapestry's activation context is way prettier than normal parameters
(?a=1&b=2). The page context is exactly what I would choose in this
scenario.
> (on the bright
> side, the user can bookmark their searches and come back to them,
> right?).
Right. ;)
> Also, I believe that I would have to be careful how I
> implemented this so that the search results page isn't open to SQL
> Injection attacks right?
Not right. SQL injection is a database issue, not a Web layer one. Your
database access classes must deal with sanitizing inputs, not Tapestry
page classes. By the way, if you use JDBC, using PreparedStatement solves
the SQL Injection problem completely. If you use Hibernate or some JPA
implementation, you don't even need to worry about it, because they use
PreparedStatements.
Obligatory XKCD reference: http://xkcd.com/327/
> This seems like a fairly common thing to want to do on a website, is
> there some sort of Tapestry Patterns page that has best practices for
> common things like this?
There isn't an specific Tapestry Patterns page, but the Tapestry wiki and
Geoff's JumpStart (http://jumpstart.doublenegative.com.au/) are good
places to begin searching for examples. Anyway, that's a very good idea. :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org