Thanks for all helps.
On Mon, Aug 7, 2017, at 08:26 PM, André Warnier (tomcat) wrote: > On 07.08.2017 13:18, 风河 wrote: > > Hi, > > > > for this like request: > > curlhttp://dns-api.org/AAAA/dns-api.org > > > > in Dancer we could write: > > > > get '/:type/:domain/?' => sub { > > > > my $rtype = params->{ 'type' }; > > my $domain = params->{ 'domain' }; > > > > > > But in a MP handler, how could we get the similiar result, treating request > > path as > > GET/POST arguments? > > > > Well, fundamentally you could not treat the request path, transparently, > as a GET/POST > argument. That is precisely the kind of thing which a framework such as > Dancer allows you > to do : "abstracting" the fundamental difference which exists at the HTTP > level (and the > Apache httpd level) between a request path and e.g. the parameters in a > query string, and > make them "kind of look the same" to an application, using some elegant > syntax. > > In a mod_perl handler, you would do this : > > my $r = shift; # Request object > my $uri = $r->uri; # gets "/AAAA/dns-api.org" > my ($nothing,$type,$domain) = split('/',$uri); > > # or, if you insist on treating the HTTP request path parts as > "arguments" : > my @args = split('/',$uri); > @args = grep(!~#/#,@args); > my $params = { > 'type' => $args[0], > 'domain' => $args[1], > }; > # (I'm sure there is a more elegant way to do this) > > mod_perl is not a framework. It gives you access from perl to the Apache > internals, as > they are deep down, but it does not "abstract" anything. For Apache > "/AAAA/dns-api.org" is > a request URI, it is not "GET/POST arguments". If this URI does not > contain a "?", then > the whole URI is a path. If it does contain a "?", then the part before > the "?" is a path, > and the part after it is a query-string, which may or may not contain > key/value pairs > which could be "parameters". Those are the underlying "apache objects", > when apache has > parsed the request. > mod_perl gives you access to these URI, path, and query-string objects of > apache, but it > does not "abstract" them further. > > Dancer (and other frameworks) are different : their users want some way > by which they can > treat path components as "arguments" ? so let's provide them with some > way of doing this, > elegantly if possible. But behind the scenes, they do exactly as above. > It's just that as > a user, you don't see that. > >
