Mailing List Archive: Catalyst: Users

Handling a path of '/'

Index | Next | Previous | View Threaded

jguenther at gmail

Dec 1, 2005, 3:04 PM

Post #1 of 11 (1176 views)
Permalink

Handling a path of '/'

I'm trying to set up an application on Catalyst and am having some trouble
figuring out how the action handling system works. I have a method in my
base class called `display_menu() : Path('')', which I take it would handle
the empty path (i.e. a GET of ""). This method calls $c->detach('/menu'),
which displays the menu. This way, a user can get the menu by requestiong
'/' or '/menu'. This is what shows up in the debug output:

.--------------------------------------+---------------------------------------.
| Path |
Private |
+--------------------------------------+---------------------------------------+
| /admin |
/admin/display_menu |
| /admin/menu |
/admin/menu |
| /login |
/login/login |
| /logout |
/login/logout |
| /menu |
/menu |
'--------------------------------------+---------------------------------------'

Which looks just fine. The problem is, when I actually request '' (or '/'
for that matter) it doesn't match the action (or doesn't call it at least)

[Thu Dec 1 16:48:59 2005] [catalyst] [debug]
**********************************
[Thu Dec 1 16:48:59 2005] [catalyst] [debug] * Request 1 (0.010/s) [12726]
[Thu Dec 1 16:48:59 2005] [catalyst] [debug]
**********************************
[Thu Dec 1 16:48:59 2005] [catalyst] [debug] "GET" request for "" from "
10.114.18.52"
[Thu Dec 1 16:48:59 2005] [catalyst] [debug] Found sessionid
"e93efd746fd8396cb82be611d9d47a76" in cookie
[Thu Dec 1 16:48:59 2005] [catalyst] [debug] Found session
"e93efd746fd8396cb82be611d9d47a76"
[Thu Dec 1 16:48:59 2005] [catalyst] [debug] >> ::begin(SaskSAGE,
SaskSAGE=HASH(0x8ecdeb8))
[Thu Dec 1 16:48:59 2005] [catalyst] [debug] >> ::auto(SaskSAGE,
SaskSAGE=HASH(0x8ecdeb8))
[Thu Dec 1 16:48:59 2005] [catalyst] [debug] >> ::end(SaskSAGE,
SaskSAGE=HASH(0x8ecdeb8))
[Thu Dec 1 16:48:59 2005] [catalyst] [debug] No Mason component specified
for rendering
[Thu Dec 1 16:48:59 2005] [catalyst] [info] Request took 0.045487s (21.984
/s)
.------------------------------------------------------------------+-----------.
| Action |
Time |
+------------------------------------------------------------------+-----------+
| /begin |
0.000068s |
| /auto |
0.018356s |
| -> SaskSAGE::View::Mason->process |
0.000125s |
| /end |
0.001321s |
'------------------------------------------------------------------+-----------'

The lines starting with '>>' are just some tracing debug statements I put in
each method so I could see what was happening. As you can see,
display_menu() is never called. Yet if I comment that method out, Catalyst
calls the default() method, which gives a 404 error (as it should, as this
is how I have set up default()):

[Thu Dec 1 16:52:14 2005] [catalyst] [debug]
**********************************
[Thu Dec 1 16:52:14 2005] [catalyst] [debug] * Request 1 (0.200/s) [12730]
[Thu Dec 1 16:52:14 2005] [catalyst] [debug]
**********************************
[Thu Dec 1 16:52:14 2005] [catalyst] [debug] "GET" request for "" from "
10.114.18.52"
[Thu Dec 1 16:52:14 2005] [catalyst] [debug] Found sessionid
"e93efd746fd8396cb82be611d9d47a76" in cookie
[Thu Dec 1 16:52:14 2005] [catalyst] [debug] Found session
"e93efd746fd8396cb82be611d9d47a76"
[Thu Dec 1 16:52:14 2005] [catalyst] [debug] >> ::begin(SaskSAGE,
SaskSAGE=HASH(0x8ed1374))
[Thu Dec 1 16:52:14 2005] [catalyst] [debug] >> ::auto(SaskSAGE,
SaskSAGE=HASH(0x8ed1374))
[Thu Dec 1 16:52:14 2005] [catalyst] [debug] >> ::default(SaskSAGE,
SaskSAGE=HASH(0x8ed1374))
[Thu Dec 1 16:52:14 2005] [catalyst] [debug] >> ::end(SaskSAGE,
SaskSAGE=HASH(0x8ed1374))
[Thu Dec 1 16:52:14 2005] [catalyst] [debug] Rendering component
"/error/404.phtml"
[Thu Dec 1 16:52:14 2005] [catalyst] [info] Request took 0.034335s (29.125
/s)
.------------------------------------------------------------------+-----------.
| Action |
Time |
+------------------------------------------------------------------+-----------+
| /begin |
0.000065s |
| /auto |
0.010908s |
| /default |
0.000096s |
| -> SaskSAGE::View::Mason->process |
0.002537s |
| /end |
0.003393s |
'------------------------------------------------------------------+-----------'

Why isn't display_menu() being called when it is set to handle Path('')? I
tried doing something similar in a sub-controller (Admin::display_menu :
Path('')) and it worked exactly as I expected: doing a GET on "/admin"
called Admin::display_menu(), which detached to 'menu' which displayed the
admin menu.

[Thu Dec 1 16:57:53 2005] [catalyst] [debug]
**********************************
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] * Request 2 (0.006/s) [12730]
[Thu Dec 1 16:57:53 2005] [catalyst] [debug]
**********************************
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] "GET" request for "admin" from
"10.114.18.52"
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] Found sessionid
"e93efd746fd8396cb82be611d9d47a76" in cookie
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] Path is "admin"
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] Found session
"e93efd746fd8396cb82be611d9d47a76"
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] >> ::begin(SaskSAGE,
SaskSAGE=HASH(0x8f48d1c))
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] >> ::auto(SaskSAGE,
SaskSAGE=HASH(0x8f48d1c))
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] >>
Admin::auto(SaskSAGE::Controller::Admin=HASH(0x8814bd8),
SaskSAGE=HASH(0x8f48d1c))
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] >>
Admin::display_menu(SaskSAGE::Controller::Admin=HASH(0x8814bd8),
SaskSAGE=HASH(0x8f48d1c))
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] >>
Admin::menu(SaskSAGE::Controller::Admin=HASH(0x8814bd8),
SaskSAGE=HASH(0x8f48d1c))
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] >> ::end(SaskSAGE,
SaskSAGE=HASH(0x8f48d1c))
[Thu Dec 1 16:57:53 2005] [catalyst] [debug] Rendering component
"/admin.phtml"
[Thu Dec 1 16:57:53 2005] [catalyst] [info] Request took 0.033431s (29.912
/s)
.------------------------------------------------------------------+-----------.
| Action |
Time |
+------------------------------------------------------------------+-----------+
| /begin |
0.000063s |
| /auto |
0.007670s |
| /admin/auto |
0.000085s |
| -> /admin/menu |
0.009026s |
| /admin/display_menu |
0.009451s |
| -> SaskSAGE::View::Mason->process |
0.007321s |
| /end |
0.008182s |
'------------------------------------------------------------------+-----------'

Am I missing something? Any help would be appreciated.

chisel at herlpacker

Dec 1, 2005, 3:40 PM

Post #2 of 11 (1100 views)
Permalink

Re: Handling a path of '/' [In reply to]

On Thu, Dec 01, 2005 at 05:04:03PM -0600, Justin Guenther wrote:
> Am I missing something? Any help would be appreciated.

This sounds very much like the example I posted yesterday - about much
the same problem.

It's my understanding (and yesterday's example seems to back me up) that
you can use "sub index : Private { ... }" to catch '/' URLs.
In MyApp.pm it would catch http://server:3000/ and in MyApp::C::Foo it
would catch http://server:3000/foo/

I think (but haven't tested) that one way would be for you to have the
following in MyApp.pm:

sub index : Private {
my ($self, $c) = @_;
$c->response->redirect('/menu');
}

Skimming the docs, "$c->forward('/menu')" may also work in place of the
redirect.

I tend to take the lazy way out. My global default() redirects to 'the
default application action' [e.g. /client/list] and each controller
default usually redirects to the appropriate list view.

That way, any rubbish URLs that people use will result in seeing
something useful, instead of a 404.

Chisel
--
Chisel Wright
e: chisel[at]herlpacker.co.uk
w: http://www.herlpacker.co.uk/

No virus was found in this outgoing message as I didn't bother looking.

_______________________________________________
Catalyst mailing list
Catalyst[at]lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst

jguenther at gmail

Dec 1, 2005, 3:52 PM

Post #3 of 11 (1101 views)
Permalink

Re: Handling a path of '/' [In reply to]

On 12/1/05, Chisel Wright <chisel[at]herlpacker.co.uk> wrote:

> This sounds very much like the example I posted yesterday - about much
> the same problem.
>
> It's my understanding (and yesterday's example seems to back me up) that
> you can use "sub index : Private { ... }" to catch '/' URLs.
> In MyApp.pm it would catch http://server:3000/ and in MyApp::C::Foo it
> would catch http://server:3000/foo/
>
> I think (but haven't tested) that one way would be for you to have the
> following in MyApp.pm:
>
> sub index : Private {
> my ($self, $c) = @_;
> $c->response->redirect('/menu');
> }
>
> Skimming the docs, "$c->forward('/menu')" may also work in place of the
> redirect.

Ah yes. I replaced `sub display_menu : Path('')' with `sub index : Private'
and it seems to work just fine. Is there a particular reason why my original
method didn't work in the root, but did for sub-controllers? It seems like a
bug to me...

I tend to take the lazy way out. My global default() redirects to 'the
> default application action' [e.g. /client/list] and each controller
> default usually redirects to the appropriate list view.
>
> That way, any rubbish URLs that people use will result in seeing
> something useful, instead of a 404.
>
> Chisel
> --
> Chisel Wright
> e: chisel[at]herlpacker.co.uk
> w: http://www.herlpacker.co.uk/
>
> No virus was found in this outgoing message as I didn't bother looking.
>
> _______________________________________________
> Catalyst mailing list
> Catalyst[at]lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst
>

sri at oook

Dec 1, 2005, 6:03 PM

Post #4 of 11 (1102 views)
Permalink

Re: Handling a path of '/' [In reply to]

Fixed in trunk!

But, Path and index actions in the appclass are a very complicated
case which we actually don't really test, so be careful and/or
provide test patches.

--
sebastian

_______________________________________________
Catalyst mailing list
Catalyst[at]lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst

moseley at hank

Dec 1, 2005, 7:06 PM

Post #5 of 11 (1100 views)
Permalink

Re: Handling a path of '/' [In reply to]

On Fri, Dec 02, 2005 at 03:03:41AM +0100, Sebastian Riedel wrote:
> Fixed in trunk!
>
> But, Path and index actions in the appclass are a very complicated
> case which we actually don't really test, so be careful and/or
> provide test patches.

I just use default() in my App class for handling "/". Any reason why
using using Index or Path would be better?

--
Bill Moseley
moseley[at]hank.org

_______________________________________________
Catalyst mailing list
Catalyst[at]lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst

jguenther at gmail

Dec 1, 2005, 7:16 PM

Post #6 of 11 (1098 views)
Permalink

RE: Handling a path of '/' [In reply to]

> -----Original Message-----
> From: catalyst-bounces[at]lists.rawmode.org
> [mailto:catalyst-bounces[at]lists.rawmode.org] On Behalf Of Bill Moseley
> Sent: December 1, 2005 9:07 PM
> To: The elegant MVC web framework
> Subject: Re: [Catalyst] Handling a path of '/'
>
> I just use default() in my App class for handling "/". Any
> reason why using using Index or Path would be better?

I opted not to use default() for this since I wanted to be able to serve out
404 error pages for invalid paths.

>
> --
> Bill Moseley
> moseley[at]hank.org
>
>
> _______________________________________________
> Catalyst mailing list
> Catalyst[at]lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst

_______________________________________________
Catalyst mailing list
Catalyst[at]lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst

moseley at hank

Dec 1, 2005, 7:26 PM

Post #7 of 11 (1100 views)
Permalink

Re: Handling a path of '/' [In reply to]

On Thu, Dec 01, 2005 at 09:16:13PM -0600, Justin Guenther wrote:
> > -----Original Message-----
> > From: catalyst-bounces[at]lists.rawmode.org
> > [mailto:catalyst-bounces[at]lists.rawmode.org] On Behalf Of Bill Moseley
> > Sent: December 1, 2005 9:07 PM
> > To: The elegant MVC web framework
> > Subject: Re: [Catalyst] Handling a path of '/'
> >
> > I just use default() in my App class for handling "/". Any
> > reason why using using Index or Path would be better?
>
> I opted not to use default() for this since I wanted to be able to serve out
> 404 error pages for invalid paths.

Why couldn't you do that?

I just set $c->res->status( 404 ) and my end sub sees that and uses
error.tt to generate output.

I just did this an hour ago, so it's not well tested.

sub default : Private {

my ( $self, $c ) = @_;

$c->res->status( 404 ); # assume the worse

my $site = $c->config->{dirs} && $c->config->{dirs}{site}
? $c->config->{dirs}{site}
: File::Spec->catfile( $c->config->{root}, 'site' );

my $path = File::Spec->catfile( $site, $c->req->path );

# If there's no trailing slash then see if it's a directory
# Kind of defeats the purpose of using catfile... :P

unless ( $c->req->uri->path =~ m!/$! ) {

# It's a dir -- add a slash to path and redirect
if ( -d $path ) {
my $redirect = $c->req->uri->clone;
$redirect->path( $redirect->path . '/' );
return $c->res->redirect( $redirect );
}

} else { # uri ends in slash
$path .= '/index.html';
}

return unless $c->forward('/static/serve_path', [ $path ]);

if ( $c->res->body && $path =~ /\.html$/ ) {
$c->stash->{template} = $c->res->body;
$c->res->body( undef );
# $c->res->headers->remove_content_headers;
$c->res->headers->content_length( 0 ); # force recalc of body size
}

}

--
Bill Moseley
moseley[at]hank.org

_______________________________________________
Catalyst mailing list
Catalyst[at]lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst

sri at oook

Dec 1, 2005, 7:37 PM

Post #8 of 11 (1101 views)
Permalink

Re: Handling a path of '/' [In reply to]

Am 02.12.2005 um 04:26 schrieb Bill Moseley:

> On Thu, Dec 01, 2005 at 09:16:13PM -0600, Justin Guenther wrote:
>>> -----Original Message-----
>>> From: catalyst-bounces[at]lists.rawmode.org
>>> [mailto:catalyst-bounces[at]lists.rawmode.org] On Behalf Of Bill
>>> Moseley
>>> Sent: December 1, 2005 9:07 PM
>>> To: The elegant MVC web framework
>>> Subject: Re: [Catalyst] Handling a path of '/'
>>>
>>> I just use default() in my App class for handling "/". Any
>>> reason why using using Index or Path would be better?
>>
>> I opted not to use default() for this since I wanted to be able to
>> serve out
>> 404 error pages for invalid paths.
>
> Why couldn't you do that?

Yes, he could have used default(), but not index() to handle the root
itself!

sub index : Private { $_[1]->stash->{template} =
'welcome.tt' } # Handles only / (no args)

sub default : Private { $_[1]->stash->{template} =
'404.tt' } # Handles all 404s

Path('/') is more a dwim thing, no unique feature.

--
sebastian

_______________________________________________
Catalyst mailing list
Catalyst[at]lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst

pagaltzis at gmx

Dec 1, 2005, 10:02 PM

Post #9 of 11 (1101 views)
Permalink

Re: Handling a path of '/' [In reply to]

* Chisel Wright <chisel[at]herlpacker.co.uk> [2005-12-02 00:50]:
> I tend to take the lazy way out. My global default() redirects
> to 'the default application action' [e.g. /client/list] and
> each controller default usually redirects to the appropriate
> list view.
>
> That way, any rubbish URLs that people use will result in
> seeing something useful, instead of a 404.

That breaks HTTP. A search engine won’t know which URLs are good
and which are rubbish, f.ex. If you want people to see something
useful, send them a 302 to a good URL when they provide rubbish,
or make your 404 page smart enough to provide a link “you
probably meant such-n-such.”

Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;

_______________________________________________
Catalyst mailing list
Catalyst[at]lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst

mdrichards at gmail

Dec 2, 2005, 9:52 AM

Post #10 of 11 (1098 views)
Permalink

Re: Handling a path of '/' [In reply to]

On 12/1/05, A. Pagaltzis <pagaltzis[at]gmx.de> wrote:
>
> * Chisel Wright <chisel[at]herlpacker.co.uk> [2005-12-02 00:50]:
> > I tend to take the lazy way out. My global default() redirects
> > to 'the default application action' [e.g. /client/list] and
> > each controller default usually redirects to the appropriate
> > list view.
> >
> > That way, any rubbish URLs that people use will result in
> > seeing something useful, instead of a 404.
>
> That breaks HTTP. A search engine won't know which URLs are good
> and which are rubbish, f.ex. If you want people to see something
> useful, send them a 302 to a good URL when they provide rubbish,
> or make your 404 page smart enough to provide a link "you
> probably meant such-n-such."
>

Or send a 404 status and display the /client/list anyway. That way everybody
is happy.

pagaltzis at gmx

Dec 2, 2005, 2:54 PM

Post #11 of 11 (1096 views)
Permalink

Re: Handling a path of '/' [In reply to]

* Michael Richards <mdrichards[at]gmail.com> [2005-12-02 18:55]:
> On 12/1/05, A. Pagaltzis <pagaltzis[at]gmx.de> wrote:
> > That breaks HTTP. A search engine won't know which URLs are
> > good and which are rubbish, f.ex. If you want people to see
> > something useful, send them a 302 to a good URL when they
> > provide rubbish, or make your 404 page smart enough to
> > provide a link "you probably meant such-n-such."
>
> Or send a 404 status and display the /client/list anyway. That
> way everybody is happy.

Clever! On second thought, I’m not sure it’s a good idea though.
If people have no indication that their URL was bad they will
likely bookmark or publish such links. Sending them to the
correct URL means external pointers to your site are less likely
to point to bad URLs.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
Catalyst mailing list
Catalyst[at]lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com