Mailing List Archive: Catalyst: Users

Using URL for /search/parameters: bad idea?

Index | Next | Previous | View Threaded

will.trillich at serensoft

Sep 26, 2011, 10:07 AM

Post #1 of 6 (193 views)
Permalink

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
Actions"<http://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

olsthrn at gmail

Sep 26, 2011, 2:29 PM

Post #2 of 6 (182 views)
Permalink

Re: Using URL for /search/parameters: bad idea? [In reply to]

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=42&product=23
or
/incident/search?manager=42&product=23

Marius

On Mon, Sep 26, 2011 at 7:07 PM, will trillich
<will.trillich [at] serensoft> 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 [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

andrew at cleverdomain

Sep 26, 2011, 5:47 PM

Post #3 of 6 (179 views)
Permalink

Re: Using URL for /search/parameters: bad idea? [In reply to]

On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn <olsthrn [at] gmail> 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?

will.trillich at serensoft

Sep 26, 2011, 6:01 PM

Post #4 of 6 (180 views)
Permalink

Re: Using URL for /search/parameters: bad idea? [In reply to]

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 <andrew [at] cleverdomain>wrote:

> On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn <olsthrn [at] gmail>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 [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst [at] lists/
> 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

diment at gmail

Sep 26, 2011, 6:02 PM

Post #5 of 6 (183 views)
Permalink

Re: Using URL for /search/parameters: bad idea? [In reply to]

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 <olsthrn [at] gmail> 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 [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

shantanu.bhadoria at gmail

Sep 26, 2011, 8:43 PM

Post #6 of 6 (177 views)
Permalink

Re: Using URL for /search/parameters: bad idea? [In reply to]

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.trillich [at] serensoft> 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 <andrew [at] cleverdomain>wrote:
>
>> On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn <olsthrn [at] gmail>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 [at] lists
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive:
>> http://www.mail-archive.com/catalyst [at] lists/
>> 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 [at] lists
>Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
>Dev site: http://dev.catalyst.perl.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads