Re: [Catalyst] Catalyst Actions precedence
On 2013-02-28 10:53, Kieren Diment wrote: > > On 28/02/2013, at 8:25 PM, Nick Anderson wrote: > >> Hi Trevor, >> >> Many thanks for clarifying that. I guess I was hoping for some reliable and >> predictable outcome for ambiguous requests but it seems the statement "Don't >> do this" in the URL Path handling section does indeed sum it up! And >> although it does not explicitly mention chained actions, I presume any URL >> path ambiguity should/must be avoided. >> > I think making it clear(er?) in the docs that if you're using Chained in a > controller you shouldn't use any other dispatch type would be useful. Where > is the correct place for that to go? > >> What I was trying to achieve was a catch-all facility for requests other >> than application defined actions, up to root level (i.e. for user-specified >> URLs which are then looked up in a database). For the life of me I can't >> remember why I avoided using the "default" action to achieve this, probably >> because I thought being more specific (even just by using a wildcard chain) >> was the most appropriate way to approach it and more structured. > > My preference is to keep Controller::Root very bare, but keep a default (i.e. > 404) handler in there, and an index type action. I'd suggest adding actions for those errors to the generated root controller when creating new apps. > > >> I presume then, that having a /*/... wildcard action to catch everything >> else is not advisable? Is using the default action the preferred method then >> to allow for unknown/dynamic URLs where an application defined action is >> unavailable? > > The usual thing to do with default is to catch 404 errors. > > > ___ > 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/ *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ 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] Catalyst Actions precedence
On 28/02/2013, at 21:43, Nick Anderson wrote: > > >>> I presume then, that having a /*/... wildcard action to catch everything >>> else is not advisable? Is using the default action the preferred method >>> then to allow for unknown/dynamic URLs where an application defined action >>> is unavailable? >> >> The usual thing to do with default is to catch 404 errors. >> >> > > If the default action should only really be used for 404 errors, how should > one cater for URLs where the full path is dynamic and no part of it matches a > controller (chained) action? Is this inadvisable? > No, I said the usual thing. If you want to do something else, that's probably fine too. > For example, I started having: > > /pages/mypage1 > > with the controller/action match on "pages". But then I decided that it would > be nicer to eliminate the "pages" part (indeed one of my clients expressly > requested it be removed!): You could alter the controller namespace, or the path part the chain matches, or make a base controller to remap specific controllers. > > /mypage1 > > > Thanks, > > Nick > > ___ > 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] Catalyst Actions precedence
I presume then, that having a /*/... wildcard action to catch everything else is not advisable? Is using the default action the preferred method then to allow for unknown/dynamic URLs where an application defined action is unavailable? The usual thing to do with default is to catch 404 errors. If the default action should only really be used for 404 errors, how should one cater for URLs where the full path is dynamic and no part of it matches a controller (chained) action? Is this inadvisable? For example, I started having: /pages/mypage1 with the controller/action match on "pages". But then I decided that it would be nicer to eliminate the "pages" part (indeed one of my clients expressly requested it be removed!): /mypage1 Thanks, Nick ___ 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] Catalyst Actions precedence
On 28/02/2013, at 8:25 PM, Nick Anderson wrote: > > Hi Trevor, > > Many thanks for clarifying that. I guess I was hoping for some reliable and > predictable outcome for ambiguous requests but it seems the statement "Don't > do this" in the URL Path handling section does indeed sum it up! And although > it does not explicitly mention chained actions, I presume any URL path > ambiguity should/must be avoided. > I think making it clear(er?) in the docs that if you're using Chained in a controller you shouldn't use any other dispatch type would be useful. Where is the correct place for that to go? > What I was trying to achieve was a catch-all facility for requests other than > application defined actions, up to root level (i.e. for user-specified URLs > which are then looked up in a database). For the life of me I can't remember > why I avoided using the "default" action to achieve this, probably because I > thought being more specific (even just by using a wildcard chain) was the > most appropriate way to approach it and more structured. My preference is to keep Controller::Root very bare, but keep a default (i.e. 404) handler in there, and an index type action. > > I presume then, that having a /*/... wildcard action to catch everything else > is not advisable? Is using the default action the preferred method then to > allow for unknown/dynamic URLs where an application defined action is > unavailable? The usual thing to do with default is to catch 404 errors. ___ 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] Catalyst Actions precedence
Hi Trevor,
Many thanks for clarifying that. I guess I was hoping for some reliable
and predictable outcome for ambiguous requests but it seems the
statement "Don't do this" in the URL Path handling section does indeed
sum it up! And although it does not explicitly mention chained actions,
I presume any URL path ambiguity should/must be avoided.
What I was trying to achieve was a catch-all facility for requests other
than application defined actions, up to root level (i.e. for
user-specified URLs which are then looked up in a database). For the
life of me I can't remember why I avoided using the "default" action to
achieve this, probably because I thought being more specific (even just
by using a wildcard chain) was the most appropriate way to approach it
and more structured.
I presume then, that having a /*/... wildcard action to catch everything
else is not advisable? Is using the default action the preferred method
then to allow for unknown/dynamic URLs where an application defined
action is unavailable?
Thank you
Nick
On 27/02/13 22:34, Trevor Leffler wrote:
Hi Nick,
The best answer I've been able to find is "Don't Do This" from here:
https://metacpan.org/module/Catalyst::Manual::Intro#URL-Path-Handling
"Beware! If you write two matchers, that match the same path, with the
same specificity (that is, they match the same quantity of the path),
there's no guarantee which will actually get called."
So you're right in your confusion with the scenario you wrote up: why
do action0 and actionx get matched, but action1 is ignored in favor of
(:Chained) pages? Kieren's answer sort of side-stepped the issue by
inferring that all this goes away when you use the same matching
system, :Chained. By leveling the playing field it all works as you
would expect. I just (re-)skimmed the dwarves example, and
unfortunately it doesn't explicitly say *not* to mix :Chained with
other dispatch types.
The Manual's summary statement above might also have been: "Once you
go :Chained, go :Chained all the way." Or at least don't have a
wildcard chained action like pages() along with non-chained actions
and expect things to work predictably... ;)
--Trevor
On 02/27/2013 01:20 PM, Nick Anderson wrote:
Hi,
please could someone explain how Catalyst determines the precedence of
actions, specifically in relation to the following simple chained
example. It doesn't behave in the way I would expect for requests
numbered 4 and 6:
1. http://127.0.0.1:3001/action0 => Matched action 0
2. http://127.0.0.1:3001/action0/abc => Matched XPages / pages
3. http://127.0.0.1:3001/action1 => Matched XPages / pages
4. http://127.0.0.1:3001/action1/abc => Matched XPages / pages
5. http://127.0.0.1:3001/actionx => Matched action x
6. http://127.0.0.1:3001/actionx/abc => Matched XPages / pages
The controllers are detailed below:
package TestApp::Controller::Root;
use Moose;
use namespace::autoclean;
BEGIN { extends 'Catalyst::Controller' }
__PACKAGE__->config(namespace => '');
sub site_base :Chained :PathPart('') :CaptureArgs(0) {
my ($self,$c ) = @_;
}
sub action0 :Path('action0') :Args(0) {
my ($self,$c ) = @_;
$c->response->body( "Matched action 0" );
}
sub action1 :Path('action1') :Args(1) {
my ($self,$c ) = @_;
$c->response->body( "Matched action 1" );
}
sub actionx :Path('actionx') :Args() {
my ($self,$c ) = @_;
$c->response->body( "Matched action x" );
}
sub end : ActionClass('RenderView') {}
__PACKAGE__->meta->make_immutable;
1;
package TestApp::Controller::XPages;
use Moose;
use namespace::autoclean;
BEGIN {extends 'Catalyst::Controller'; }
sub base : Chained( '/site_base' ) : PathPart('') : CaptureArgs( 1 ) {
my ( $self, $c ) = @_;
}
sub pages : Chained( 'base' ) : PathPart('') : Args() {
my ( $self, $c ) = @_;
$c->response->body('Matched XPages / pages');
}
__PACKAGE__->meta->make_immutable;
1;
Thanks for any help you can give
Nick Anderson
___
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/
___
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] Catalyst Actions precedence
Hi Nick,
The best answer I've been able to find is "Don't Do This" from here:
https://metacpan.org/module/Catalyst::Manual::Intro#URL-Path-Handling
"Beware! If you write two matchers, that match the same path, with the
same specificity (that is, they match the same quantity of the path),
there's no guarantee which will actually get called."
So you're right in your confusion with the scenario you wrote up: why do
action0 and actionx get matched, but action1 is ignored in favor of
(:Chained) pages? Kieren's answer sort of side-stepped the issue by
inferring that all this goes away when you use the same matching system,
:Chained. By leveling the playing field it all works as you would
expect. I just (re-)skimmed the dwarves example, and unfortunately it
doesn't explicitly say *not* to mix :Chained with other dispatch types.
The Manual's summary statement above might also have been: "Once you go
:Chained, go :Chained all the way." Or at least don't have a wildcard
chained action like pages() along with non-chained actions and expect
things to work predictably... ;)
--Trevor
On 02/27/2013 01:20 PM, Nick Anderson wrote:
Hi,
please could someone explain how Catalyst determines the precedence of
actions, specifically in relation to the following simple chained
example. It doesn't behave in the way I would expect for requests
numbered 4 and 6:
1. http://127.0.0.1:3001/action0 => Matched action 0
2. http://127.0.0.1:3001/action0/abc => Matched XPages / pages
3. http://127.0.0.1:3001/action1 => Matched XPages / pages
4. http://127.0.0.1:3001/action1/abc => Matched XPages / pages
5. http://127.0.0.1:3001/actionx => Matched action x
6. http://127.0.0.1:3001/actionx/abc => Matched XPages / pages
The controllers are detailed below:
package TestApp::Controller::Root;
use Moose;
use namespace::autoclean;
BEGIN { extends 'Catalyst::Controller' }
__PACKAGE__->config(namespace => '');
sub site_base :Chained :PathPart('') :CaptureArgs(0) {
my ($self,$c ) = @_;
}
sub action0 :Path('action0') :Args(0) {
my ($self,$c ) = @_;
$c->response->body( "Matched action 0" );
}
sub action1 :Path('action1') :Args(1) {
my ($self,$c ) = @_;
$c->response->body( "Matched action 1" );
}
sub actionx :Path('actionx') :Args() {
my ($self,$c ) = @_;
$c->response->body( "Matched action x" );
}
sub end : ActionClass('RenderView') {}
__PACKAGE__->meta->make_immutable;
1;
package TestApp::Controller::XPages;
use Moose;
use namespace::autoclean;
BEGIN {extends 'Catalyst::Controller'; }
sub base : Chained( '/site_base' ) : PathPart('') : CaptureArgs( 1 ) {
my ( $self, $c ) = @_;
}
sub pages : Chained( 'base' ) : PathPart('') : Args() {
my ( $self, $c ) = @_;
$c->response->body('Matched XPages / pages');
}
__PACKAGE__->meta->make_immutable;
1;
Thanks for any help you can give
Nick Anderson
___
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] Catalyst Actions precedence
Hi Kieren,
Thanks for the quick reply.
I hadn't missed out chained("site_base"), as I didn't want those actions
to to be part of any chain. But what I did expect was the Args(1) action
(request 4) to behave in the same way as Args(0) (request 1) which it
doesn't and instead ends up going to the chained action in XPages. It
didn't seem consistent/predictable to me?
Thank you for the book link which will be useful. I do have a fairly
good understanding of the chained process but this specific example
seemed to throw up an anomaly where the request could equally be
satisfied by the chained action or the normal action but the chained
action took precedence except when 0 args were specified. Is Args(0) a
special case? Is there not an order of precedence for resolving requests
specified somewhere?
Thanks,
Nick
On 27/02/13 21:50, Kieren Diment wrote:
On 28/02/2013, at 8:20 AM, Nick Anderson wrote:
Hi,
please could someone explain how Catalyst determines the precedence of actions,
specifically in relation to the following simple chained example. It doesn't
behave in the way I would expect for requests numbered 4 and 6:
1. http://127.0.0.1:3001/action0 => Matched action 0
2. http://127.0.0.1:3001/action0/abc => Matched XPages / pages
3. http://127.0.0.1:3001/action1 => Matched XPages / pages
4. http://127.0.0.1:3001/action1/abc => Matched XPages / pages
5. http://127.0.0.1:3001/actionx => Matched action x
6. http://127.0.0.1:3001/actionx/abc => Matched XPages / pages
The controllers are detailed below:
package TestApp::Controller::Root;
use Moose;
use namespace::autoclean;
BEGIN { extends 'Catalyst::Controller' }
__PACKAGE__->config(namespace => '');
sub site_base :Chained :PathPart('') :CaptureArgs(0) {
my ($self,$c ) = @_;
}
You seem to have missed :Chained('site_base') from all the sub attributes below.
Check the DwarfChains app in the catalyst book code (chapter 7 available from -
http://www.apress.com/downloadable/download/sample/sample_id/205/ ) for an
example along the same lines of yours that works.
sub action0 :Path('action0') :Args(0) {
my ($self,$c ) = @_;
$c->response->body( "Matched action 0" );
}
sub action1 :Path('action1') :Args(1) {
my ($self,$c ) = @_;
$c->response->body( "Matched action 1" );
}
sub actionx :Path('actionx') :Args() {
my ($self,$c ) = @_;
$c->response->body( "Matched action x" );
}
sub end : ActionClass('RenderView') {}
__PACKAGE__->meta->make_immutable;
1;
package TestApp::Controller::XPages;
use Moose;
use namespace::autoclean;
BEGIN {extends 'Catalyst::Controller'; }
sub base : Chained( '/site_base' ) : PathPart('') : CaptureArgs( 1 ) {
my ( $self, $c ) = @_;
}
sub pages : Chained( 'base' ) : PathPart('') : Args() {
my ( $self, $c ) = @_;
$c->response->body('Matched XPages / pages');
}
__PACKAGE__->meta->make_immutable;
1;
Thanks for any help you can give
Nick Anderson
___
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/
___
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] Catalyst Actions precedence
On 28/02/2013, at 8:20 AM, Nick Anderson wrote:
> Hi,
>
> please could someone explain how Catalyst determines the precedence of
> actions, specifically in relation to the following simple chained example. It
> doesn't behave in the way I would expect for requests numbered 4 and 6:
>
> 1. http://127.0.0.1:3001/action0 => Matched action 0
> 2. http://127.0.0.1:3001/action0/abc => Matched XPages / pages
> 3. http://127.0.0.1:3001/action1 => Matched XPages / pages
> 4. http://127.0.0.1:3001/action1/abc => Matched XPages / pages
> 5. http://127.0.0.1:3001/actionx => Matched action x
> 6. http://127.0.0.1:3001/actionx/abc => Matched XPages / pages
>
> The controllers are detailed below:
>
> package TestApp::Controller::Root;
> use Moose;
> use namespace::autoclean;
>
> BEGIN { extends 'Catalyst::Controller' }
>
> __PACKAGE__->config(namespace => '');
>
> sub site_base :Chained :PathPart('') :CaptureArgs(0) {
>my ($self,$c ) = @_;
> }
>
You seem to have missed :Chained('site_base') from all the sub attributes below.
Check the DwarfChains app in the catalyst book code (chapter 7 available from -
http://www.apress.com/downloadable/download/sample/sample_id/205/ ) for an
example along the same lines of yours that works.
> sub action0 :Path('action0') :Args(0) {
>my ($self,$c ) = @_;
>$c->response->body( "Matched action 0" );
> }
>
> sub action1 :Path('action1') :Args(1) {
>my ($self,$c ) = @_;
>$c->response->body( "Matched action 1" );
> }
>
> sub actionx :Path('actionx') :Args() {
>my ($self,$c ) = @_;
>$c->response->body( "Matched action x" );
> }
>
> sub end : ActionClass('RenderView') {}
>
> __PACKAGE__->meta->make_immutable;
>
> 1;
>
> package TestApp::Controller::XPages;
> use Moose;
> use namespace::autoclean;
>
> BEGIN {extends 'Catalyst::Controller'; }
>
> sub base : Chained( '/site_base' ) : PathPart('') : CaptureArgs( 1 ) {
>my ( $self, $c ) = @_;
> }
>
> sub pages : Chained( 'base' ) : PathPart('') : Args() {
>my ( $self, $c ) = @_;
>$c->response->body('Matched XPages / pages');
> }
>
> __PACKAGE__->meta->make_immutable;
>
> 1;
>
>
> Thanks for any help you can give
>
> Nick Anderson
>
> ___
> 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] Catalyst Actions precedence
Hi,
please could someone explain how Catalyst determines the precedence of
actions, specifically in relation to the following simple chained
example. It doesn't behave in the way I would expect for requests
numbered 4 and 6:
1. http://127.0.0.1:3001/action0 => Matched action 0
2. http://127.0.0.1:3001/action0/abc => Matched XPages / pages
3. http://127.0.0.1:3001/action1 => Matched XPages / pages
4. http://127.0.0.1:3001/action1/abc => Matched XPages / pages
5. http://127.0.0.1:3001/actionx => Matched action x
6. http://127.0.0.1:3001/actionx/abc => Matched XPages / pages
The controllers are detailed below:
package TestApp::Controller::Root;
use Moose;
use namespace::autoclean;
BEGIN { extends 'Catalyst::Controller' }
__PACKAGE__->config(namespace => '');
sub site_base :Chained :PathPart('') :CaptureArgs(0) {
my ($self,$c ) = @_;
}
sub action0 :Path('action0') :Args(0) {
my ($self,$c ) = @_;
$c->response->body( "Matched action 0" );
}
sub action1 :Path('action1') :Args(1) {
my ($self,$c ) = @_;
$c->response->body( "Matched action 1" );
}
sub actionx :Path('actionx') :Args() {
my ($self,$c ) = @_;
$c->response->body( "Matched action x" );
}
sub end : ActionClass('RenderView') {}
__PACKAGE__->meta->make_immutable;
1;
package TestApp::Controller::XPages;
use Moose;
use namespace::autoclean;
BEGIN {extends 'Catalyst::Controller'; }
sub base : Chained( '/site_base' ) : PathPart('') : CaptureArgs( 1 ) {
my ( $self, $c ) = @_;
}
sub pages : Chained( 'base' ) : PathPart('') : Args() {
my ( $self, $c ) = @_;
$c->response->body('Matched XPages / pages');
}
__PACKAGE__->meta->make_immutable;
1;
Thanks for any help you can give
Nick Anderson
___
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/
