Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Better names for SCRIPT_NAME/PATH_INFO in a web framework?

by Dallaylaen (Hermit)
on Dec 02, 2017 at 18:42 UTC ( #1204756=perlmeditation: print w/replies, xml ) Need Help??

Hello dear esteemed monks,

My toy framework called MVC::Neaf has crawled to 0.20 milestone. EDIT And it's got some misleading method names in it which I would like to correct.

One thing I'm struggling to grasp is how to call requested path's fragments - the part that matched the current controller and whatever follows that path. The current convention is as follows:

  • script_name is the part of the path that matched current route, not the name of the script or the raw stuff from PSGI request.
  • path_info is anything that follows that matching part, for instance a wiki article name.
  • path_info_split is a newer version that takes regular expression capture groups into account.

The overall /EDIT syntax, though still evolving, looks like follows now:

use strict; use warnings; use MVC::Neaf qw(:sugar); get + post '/some/path' => sub { my $req = shift; my $foo = $req->param( foo ); my $bar = $req->param( bar => '\w+' ) # no params w/o validation or die 404; # render a "not found" page my ($from, $to) = $req->path_info_split; $req->script_name; # '/some/path' # frobnicate my $data = frobnicate( $bar, $from .. $to ); return { result => $data, foo => $foo, }; }, default => { -view => 'TT', # JS is the default which generates JSON -template => 'some_file.tt', title => 'My mega new application', version => '0.42', }, param_regex => { foo => '\d+' }, path_info_regex => '(\d+)/(\d+)'; # Hitting /some/path would trigger roughly something like follows # (assuming the controller doesn't die/redirect/stop otherwise) # $my_template->process( 'some_file.tt', { # title => ..., # version => ..., # result => ..., # # whatever else controller returned # } ); neaf->run;

Some working examples exist in the distro.

I know everyone else is using routes of form '/foo/:bar' these days but I don't really like it (although support may be added in the end). The reason is there are a number of formats (:foo, *bar, #baz) and they still don't cover all needed cases ([0-9]+ being the most obvious one).

Now I feel like like these SCRIPT_NAME and PATH_INFO dating back into past century are awkward. My proposal is to rename this stuff completely:

  • $req->route() stands for the route that matched (Dancer does like that already).
  • $req->suffix() returns the URI capture groups if any were defined.
  • suffix => qr/(...)and(...)/ is the corresponding route parameter.
  • get '/article/(\d+)/(\d\d)/(\d\d)/(.*)' => ... - I'm also thinking about adding capture groups right into the path (w/o suffix parameter) but that'd be hard to undo so I'm holding it back.
  • param => \%spec is the predefined regular expression hash for $req->param( "name" ); (Neaf explicitly forbids unvalidated params and cookies, much like perl -T does).

This scheme looks consistent and clear to me, but maybe I'm missing something. Does that look like a syntax you'd like to try out? What would you like to be added/removed? What is causing surprise and awkwardness here?

Thank you,

Replies are listed 'Best First'.
Re: Better names for SCRIPT_NAME/PATH_INFO in a web framework?
by beech (Vicar) on Dec 02, 2017 at 22:24 UTC

    Hi,

    I applaud you for trying to think through this stuff, it is kind of difficult to just jump into stuff like this

    Now I feel like like these SCRIPT_NAME and PATH_INFO dating back into past century are awkward. My proposal is to rename this stuff completely:

    Don't rename, add new names?

    Have you seen https://metacpan.org/pod/Plack::Request#path_info/script_name,

    script_name seems like route_name, path_info might be route_raw ... but does a user need these? Does a user only need https://metacpan.org/pod/Mojolicious::Controller#url_for?

     

     get + post is cute, but looks like it should be get_post -- but you probably heard about that already :)

     

    What is causing surprise and awkwardness here?

    Separation of concerns (everything, difficult to just jump in)?

    For example ->suffix makes no sense

    While ->route_suffix sounds like a better name, the purpose of knowing a suffix is a mystery -- why would a new user of your module need that?

    Does route return a route object? Something like Routes::Tiny::Match?

     

    I think you're too close to your code, and I'm too far far far away :)

      Hi,

      Thank you.

      Have you seen https://metacpan.org/pod/Plack::Request#path_info/script_name?

      After re-reading the Plack::Request docs, I'm struggling to understand why did I pick such misleading names in the first place. What I'm talking about here has nothing to do with peeking at low level/raw stuff.

      So in neaf, the current convention is as follows:

      • script_name is the part of the path that matched current route, not the name of the script or the raw stuff from PSGI request.
      • path_info is anything that follows that matching part, for instance a wiki article name.
      • path_info_split is a newer version that takes regular expression capture groups into account.

      This is arguably horrible and misleading. I would like to get rid of the middle part as it's superseded by the last one, and come up with sane names for (1) the part of path that matched current route and (2) the capture groups found in the remainder of the path. Other frameworks use param aliases for (2), except for sinatra (ruby) that calls it splat. The param approach doesn't play nicely with my "regexp filters everywhere" approach.

      get_post

      Could as well be put + patch. It's only delete that spoils everything and I have to maintain an any variant anyway.

      Does route return a route object? Something like Routes::Tiny::Match?

      I was thinking that route() should be a string, just the part of the path mathing current route. Apparently it's not the case with Dancer, so it's a misleading name after all. And I was also thinking about endpoint() method for providing the route details object, but it's not even in TODO yet.

      route_suffix

      Nice, although maybe a bit long.

      I think you're too close to your code, and I'm too far far far away :)

      This is why I have to ask. I need an outside view.

Re: Better names for SCRIPT_NAME/PATH_INFO in a web framework?
by RonW (Vicar) on Dec 07, 2017 at 20:40 UTC
    script_name is the part of the path that matched current route, not the name of the script or the raw stuff from PSGI request.

    I suggest route_name as this implies the value is a string rather than an object. Also, it emphasizes that it is the route and not the script.

    path_info is anything that follows that matching part, for instance a wiki article name.

    Even many years ago, I never liked path_info but it was the convention and I never thought of a better alternative. Even now, I'm not sure if there's a better name and it does fit with historical convention. Maybe route_params, but just params (or param) could be confusing. I'm not sure if there is a good enough alternative to justify not using the already familiar path_info (despite that I never liked the name).

    Sometimes there are good reasons to not follow historical convention. Other times, not. Most cases, a minor change to convention is the better choice. Changing script_name to route_name falls under this 3rd category.

      Thank you!

      route_name is definitely worth a shot. I'm also thinking about route_path, preparing ground for $request->route->path even though the latter is far, far ahead.

      route_param(s) evokes thoughts about the parameters of the route itself, not sure... Although I have a lot of other param's there, so one more won't hurt...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1204756]
Approved by holli
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (4)
As of 2018-07-23 17:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?















    Results (472 votes). Check out past polls.

    Notices?