Re: [Catalyst] Using URL for /search/parameters: bad idea?

[Shantanu Bhadoria]

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  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 
>wrote:
>
>> On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn 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/
>>
>>
>
>
>-- 
>"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?

[Kieren Diment]

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  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?

[will trillich]

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 wrote:

> On Mon, Sep 26, 2011 at 5:29 PM, Marius Olsthoorn 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/
>
>


-- 
"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?

[Andrew Rodland]

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

[Marius Olsthoorn]

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
 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/

[Catalyst] Using URL for /search/parameters: bad idea?

[will trillich]

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/

[Catalyst] CatalystX::Declare compilation error

[Alan Humphrey]

Hi -

I'm using CatalystX::Declare in my Controller.  All was well until I tried
to define a method with named parameters:

method repository( :$ctx, :$action, :$master_image_id ) {
   
}

Now I'm getting a compilation error:

Couldn't load class (BirdWeb::Admin) because: Cannot delegate
meta_type_constraint to tc because the value of type_constraints is not
defined at /usr/local/lib/perl/5.10.1/Moose/Meta/Method/Delegation.pm line
99

Parse::Method::Signatures::Param::meta_type_constraint('MooseX::Traits::__ANON__::SERIAL::230=HASH(0xd8d2ea8)')
called at
/usr/local/share/perl/5.10.1/CatalystX/Declare/Controller/Meta/TypeConstraintMapping.pm
line 76

CatalystX::Declare::Controller::Meta::TypeConstraintMapping::add_method('CODE(0xd765ce0)',
'Moose::Meta::Class::__ANON__::SERIAL::7=HASH(0xd70e6b8)', 'repository',
'MooseX::Method::Signatures::Meta::Method=HASH(0xd90d190)') called at
/usr/local/lib/perl/5.10.1/Class/MOP/Method/Wrapped.pm line 162

Class::MOP::Method::Wrapped::__ANON__('Moose::Meta::Class::__ANON__::SERIAL::7=HASH(0xd70e6b8)',
'repository', 'MooseX::Method::Signatures::Meta::Method=HASH(0xd90d190)')
called at /usr/local/lib/perl/5.10.1/Class/MOP/Method/Wrapped.pm line 91

Moose::Meta::Class::__ANON__::SERIAL::7::add_method('Moose::Meta::Class::__ANON__::SERIAL::7=HASH(0xd70e6b8)',
'repository', 'MooseX::Method::Signatures::Meta::Method=HASH(0xd90d190)')
called at
/usr/local/share/perl/5.10.1/MooseX/Declare/Syntax/Keyword/Method.pm line 20

MooseX::Declare::Syntax::Keyword::Method::register_method_declaration('MooseX::Declare::Syntax::Keyword::Method=HASH(0xd6fe8e0)',
'Moose::Meta::Class::__ANON__::SERIAL::7=HASH(0xd70e6b8)', 'repository',
'MooseX::Method::Signatures::Meta::Method=HASH(0xd90d190)') called at
/usr/local/share/perl/5.10.1/MooseX/Declare/Syntax/MethodDeclaration.pm line
43

MooseX::Declare::Syntax::MethodDeclaration::__ANON__('Moose::Meta::Class::__ANON__::SERIAL::7=HASH(0xd70e6b8)',
'repository', 'MooseX::Method::Signatures::Meta::Method=HASH(0xd90d190)')
called at /usr/local/share/perl/5.10.1/MooseX/Method/Signatures.pm line 319
MooseX::Method::Signatures::__ANON__('CODE(0xd89e208)', 'repository')
called at
/home/alanh/src/birdwebadmin/script/../lib/BirdWeb/Admin/Controller/Images.pm
line 251
Catalyst::Utils::__ANON__() called at
/usr/local/share/perl/5.10.1/MooseX/Declare/Syntax/MooseSetup.pm line 81
MooseX::Declare::Syntax::MooseSetup::__ANON__('CODE(0xd6a9808)') called
at
/home/alanh/src/birdwebadmin/script/../lib/BirdWeb/Admin/Controller/Images.pm
line 252
require BirdWeb/Admin/Controller/Images.pm called at
/usr/local/share/perl/5.10.1/Catalyst/Utils.pm line 287
eval {...} called at /usr/local/share/perl/5.10.1/Catalyst/Utils.pm line
287

Catalyst::Utils::ensure_class_loaded('BirdWeb::Admin::Controller::Images',
'HASH(0xc6356b8)') called at /usr/local/share/perl/5.10.1/Catalyst.pm line
2473
Catalyst::setup_components('BirdWeb::Admin') called at
/usr/local/share/perl/5.10.1/Catalyst.pm line 1190



If I don't use named parameters all is well.

I just upgraded Catalyst::Devel, Moose, CatalystX::Declare, and
MooseX::Declare to the latest versions of each.

Any ideas?

- Alan
___
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/