Re: Better names for SCRIPT_NAME/PATH_INFO in a web framework?

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

Comment on Re: Better names for SCRIPT_NAME/PATH_INFO in a web framework? Download Code

Replies are listed 'Best First'.
Re^2: Better names for SCRIPT_NAME/PATH_INFO in a web framework? by Dallaylaen (Chaplain) on Dec 03, 2017 at 00:47 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^2: Better names for SCRIPT_NAME/PATH_INFO in a web framework?
by Dallaylaen (Chaplain) on Dec 03, 2017 at 00:47 UTC

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.

[reply]