[Catalyst] Using URL for /search/parameters: bad idea?
Catalystos: I'm implementing a search screen and I'm wondering how impractical it would be to have the URL be 'storage' for the parameters. Looking in the Cookbook under DRY Controllers with Chained Actionshttp://search.cpan.org/dist/Catalyst-Manual/lib/Catalyst/Manual/Cookbook.pod#DRY_Controllers_with_Chained_actions got me to thinking it may be feasible... For example: /incident/my/loc/37/closed/20110401-20110430 /incident/team/22/manager/138/product/417 /incident/manager/138/product/417 Advantages: easy for the browser to bookmark and return to, later Disadvantages: chaining? other? If using the URL is a bad way to 'store' the search parameters, what's a good way to cache them in the session info? -- The very nucleus of Character: to do what you know you should do, when you don't want to do it. Stephen Covey ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Using URL for /search/parameters: bad idea?
Hi, Consider using the query part of the URI to represent the search. Browsers are very good at bookmarking these :) If you have duplication, use the classic way of removing it, by putting functionality in a third module or role. Example /incident/?manager=42product=23 or /incident/search?manager=42product=23 Marius On Mon, Sep 26, 2011 at 7:07 PM, will trillich will.trill...@serensoft.com wrote: Catalystos: I'm implementing a search screen and I'm wondering how impractical it would be to have the URL be 'storage' for the parameters. Looking in the Cookbook under DRY Controllers with Chained Actions got me to thinking it may be feasible... For example: /incident/my/loc/37/closed/20110401-20110430 /incident/team/22/manager/138/product/417 /incident/manager/138/product/417 Advantages: easy for the browser to bookmark and return to, later Disadvantages: chaining? other? If using the URL is a bad way to 'store' the search parameters, what's a good way to cache them in the session info? -- The very nucleus of Character: to do what you know you should do, when you don't want to do it. Stephen Covey ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Using URL for /search/parameters: bad idea?
On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn olst...@gmail.com wrote: Hi, Consider using the query part of the URI to represent the search. Browsers are very good at bookmarking these :) What in the world is that supposed to mean? Are browsers *bad* at saving bookmarks for other kinds of URLs? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Using URL for /search/parameters: bad idea?
When the search-screen has a dozen or more fields (client requirements),
it's more likely that we use a POST instead of a GET. Bookmarking THAT ain't
so easy.
So instead of reiterating the original question, let me ask a related
question:
What's a good way to cache a search (so the user can page-up/page-down)? Can
we just
$c-session( search_rs = $rs-search({%params}) )
I imagine that would take up a lot of space in the session record, but maybe
that's not much of a consideration...
...or is there a straightforward way to serialize the search parameters?
What's the consensus on this?
On Tue, Sep 27, 2011 at 12:47 AM, Andrew Rodland and...@cleverdomain.orgwrote:
On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn olst...@gmail.comwrote:
Hi,
Consider using the query part of the URI to represent the search.
Browsers are very good at bookmarking these :)
What in the world is that supposed to mean? Are browsers *bad* at saving
bookmarks for other kinds of URLs?
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
--
The very nucleus of Character: to do what you know you should do, when you
don't want to do it. Stephen Covey
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Using URL for /search/parameters: bad idea?
Kieren Diment PhD Candidate Health Informatics Research Lab, Faculty of Informatics, University of Wollongong Tel: +61 4221 3952 On 27/09/2011, at 10:47 AM, Andrew Rodland wrote: On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn olst...@gmail.com wrote: Hi, Consider using the query part of the URI to represent the search. Browsers are very good at bookmarking these :) What in the world is that supposed to mean? Are browsers *bad* at saving bookmarks for other kinds of URLs? What he means is a GET request can be bookmarked and have it's state recalled. A POST request on the other hand hides the state required to make the request from teh URL. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Using URL for /search/parameters: bad idea?
If you are using GET params for search, your search result itself becomes
identifiable as a distinct url. This kinda search result can be optimised in a
lot of ways. The best way IMHO is using a reverse proxy server to cache it
based on the url with a apt ttl.
-Shantanu
Sent from Samsung tablet
will trillich will.trill...@serensoft.com wrote:
When the search-screen has a dozen or more fields (client requirements),
it's more likely that we use a POST instead of a GET. Bookmarking THAT ain't
so easy.
So instead of reiterating the original question, let me ask a related
question:
What's a good way to cache a search (so the user can page-up/page-down)? Can
we just
$c-session( search_rs = $rs-search({%params}) )
I imagine that would take up a lot of space in the session record, but maybe
that's not much of a consideration...
...or is there a straightforward way to serialize the search parameters?
What's the consensus on this?
On Tue, Sep 27, 2011 at 12:47 AM, Andrew Rodland
and...@cleverdomain.orgwrote:
On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn olst...@gmail.comwrote:
Hi,
Consider using the query part of the URI to represent the search.
Browsers are very good at bookmarking these :)
What in the world is that supposed to mean? Are browsers *bad* at saving
bookmarks for other kinds of URLs?
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
--
The very nucleus of Character: to do what you know you should do, when you
don't want to do it. Stephen Covey
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
