[Dancer-users] Exploring Best Practices for Route Definition

Иван Бессарабов ivan at bessarabov.ru
Thu May 5 09:35:16 CEST 2011

I myself write routs like this:

any ['get', 'post'] => '/settings/keys' => sub {
    # ...
    template 'settings_keys', {data => $v};

get qr{^/settings/keys/$} => sub {
    redirect "/settings/keys";

This doesn't solve the problem with url with parameters in it
("/settings/keys/?a=1" will return 404), and you should write 2 route
for every page, but this is sufficient.

I don't think the 404 because of the absence of the last slash is a
huge problem: the users doesn't write urls by hand, they clicks the
links. And if the navigation on the site is good the user don't need
to change url by hand.

2011/5/4 Brian E. Lozier <brian at massassi.com>:
> On Wed, May 4, 2011 at 12:42 PM, J. Bobby Lopez <jbl at jbldata.com> wrote:
>> Hello Dancers,
>> I recently asked a question on #dancer regarding how to deal with trailing
>> slashes on routes.  There was a brief discussion which resulted, and I've
>> copied the the discussion below in order to get some more input on the
>> matter.
>> (with permission from gnusosa) please see the discussion below:
>> ----------irc.perl.org------#dancer------------------------
>> 14:54 < jbl> curious how others treat the difference between 'route' and
>> 'route/' in dancer. I'm often using
>> '/some/route', but then if a user tries to access the app with
>> http://site.com/some/route/' (with the trailing
>> slash) it gives a 404 by default. What's the usual cure for this problem?
>> 14:55 < gnusosa> jbl: Good Question.
>> 14:59 < gnusosa> jbl: This is going to happen since the slash "/" is the one
>> that difference the route from the route/
>> 15:02 < jbl> right
>> 15:03 < jbl> I'm just wondering if I should add a wildcard or redirect to
>> catch trailing slashes, or if there is a setting
>> somewhere that checks if there are no other characters after the slash, to
>> just treat it as base route
>> 15:03 < jbl> not sure I'm being clear on that :\
>> 15:04 < jbl> I think I saw the use of regexs for routes somewhere, that
>> might be a good option
>> 15:06 < jbl> to do something like: get '/myroute[/]*$'
>> 15:07 < jbl> or maybe even just strip the trailing slashes using a 'before'
>> statement
>> 15:07 < gnusosa> jbl: Probably.
>> 15:07 < jbl> curse of tmtowtdi
>> 15:08 < gnusosa> jbl: But all of these seems like too much hassle.
>> 15:08 < gnusosa> jbl: What is the problem with sending some people to 404 :P
>> 15:10 < jbl> I guess that if the URL doesn't have an extension "/route.cgi"
>> then some people (maybe just me) may feel that
>>   URL is incomplete/incorrect/odd somehow. I guess they could go to a 404 if
>> they type in the URL manually
>> 15:11 < jbl> no real harm in that as long as the real URL works
>> 15:11 < jbl> just feels off
>> 15:11 < gnusosa> jbl: umm I understand now.
>> 15:12 < jbl> and I remember at some point (back in the day) it was good
>> practice to end URLs with a slash, if it wasn't
>> going to a 'file'
>> 15:16 < gnusosa> jbl: You should email the mailing list
>> dancer-users at perldancer.org with this issue. Best practices in the
>> routes are a big deal.
>> ------------------------------------
> I think ultimately you do not want two different URLs pointing to the
> same content.  There are tons of articles on google webmaster blog
> about this.  It's considered duplicate content when you have two urls
> that return the same thing.  While it's not (alone) necessarily bad,
> it's better to have a single URL for each unique piece of content.  I
> think you should pick the one you like and make sure you always link
> to the correct URL.  If people are typing in URLs and getting it
> wrong, serve up a 404 page (with a real 404 return code) and link them
> to the right URL.  Or 301 redirect to the right url if you can
> determine it.
> _______________________________________________
> Dancer-users mailing list
> Dancer-users at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

More information about the Dancer-users mailing list