[mp2] $r->rpath

[Stas Bekman <st...@stason.org>]

I've noticed that we have planned to add the missing rpath() method post-2.0, 
but we don't even provide a backcompat function. It's a custom convenience 
method provided by mp1.

=item rpath

Returns the I<path> minus I<path_info>.

  my $path = $uri->rpath;

and xs:

SV *
rpath(uri)
     Apache::URI uri

     CODE:
     RETVAL = Nullsv;

     if(uri->path_info) {
	int uri_len = strlen(uri->uri.path);
         int n = strlen(uri->path_info);
	int set = uri_len - n;
	if(set > 0)
	    RETVAL = newSVpv(uri->uri.path, set);
     }
     else {
         if (uri->uri.path) {
             RETVAL = newSVpv(uri->uri.path, 0);
         }
     }

     OUTPUT:
     RETVAL

It should be trivial to add it, but I'm not sure where it belongs. Since 
path_info (which it needs to get rpath) is a request_rec member, rpath can't 
belong to APR::URI, as the latter is non-specific to Apache. So the only thing 
I can think of is to make it $r->rpath, but we won't be able to provide a 
back-compat function which was called on Apache::URI object, since there is no 
$r object (well, unless +GlobalRequest is on).


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: [mp2] $r->rpath

[Stas Bekman <st...@stason.org>]

Stas Bekman wrote:
> I've noticed that we have planned to add the missing rpath() method 
> post-2.0, but we don't even provide a backcompat function. It's a custom 
> convenience method provided by mp1.
[...]
> It should be trivial to add it, but I'm not sure where it belongs. Since 
> path_info (which it needs to get rpath) is a request_rec member, rpath 
> can't belong to APR::URI, as the latter is non-specific to Apache. So 
> the only thing I can think of is to make it $r->rpath, but we won't be 
> able to provide a back-compat function which was called on Apache::URI 
> object, since there is no $r object (well, unless +GlobalRequest is on).

Actually it's possible to have $uri->rpath, if $uri is returned by parsed_uri, 
since it uses modperl_uri_t which is a "subclass" of apr_uri_t:

/* subclass apr_uri_t */
typedef struct {
     apr_uri_t uri;
     apr_pool_t *pool;
     char *path_info;
} modperl_uri_t;

So it still looks like apr_uri_t but it has more info inside.

static MP_INLINE
apr_uri_t *mpxs_Apache__RequestRec_parsed_uri(request_rec *r)
{
     modperl_uri_t *uri = modperl_uri_new(r->pool);

     uri->uri = r->parsed_uri;
     uri->path_info = r->path_info;

     return (apr_uri_t *)uri;
}

So I suppose it should belong to the APR::URI manpage, but explicitly document 
that it is available only when called on an object returned by $r->parsed_uri.

And later on we may add the path_info accessor as well, so one will be able to 
get/set it, and by setting it, making rpath() working in a non-Apache 
environment too. Though it may be confused with the existing $r->path_info.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org