You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@adobe.com> on 2013/01/10 09:44:58 UTC

Enhancing the RequestPathInfo

Hi all

The RequestPathInfo object (retrieved from SlingHttpServletRequest.getRequestPathInfo()) allows access to decomposed request path information. One piece of which is the request suffix which is the part of the URL path after the resource address (incl. selectors and extension).

Often times such a suffix is used as a secondary resource address, mostly in administrative console contexts. If would be helpful to be able to get a resource addressed by the suffix directly from the RequestPathInfo project to prevent error-prone template code all-over.

For details see also SLING-2670 [1]. I have also attached a complete patch there including the API change, the implementation and the increment in the API export version.

The consequence of this API change is, that all implementors of the org.apache.sling.api.request package have to be updated. Looking at the package this is mostly Sling core stuff plus implementors of the SlingRequestListener interface.

WDYT ?

Regards
Felix

[1] https://issues.apache.org/jira/browse/SLING-2670

RE: Enhancing the RequestPathInfo

Posted by Jeff Young <je...@adobe.com>.
+1

Jeff.


> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> Sent: 10 January 2013 08:45
> To: dev@sling.apache.org
> Subject: Enhancing the RequestPathInfo
> 
> Hi all
> 
> The RequestPathInfo object (retrieved from
> SlingHttpServletRequest.getRequestPathInfo()) allows access to decomposed
> request path information. One piece of which is the request suffix which is
> the part of the URL path after the resource address (incl. selectors and
> extension).
> 
> Often times such a suffix is used as a secondary resource address, mostly in
> administrative console contexts. If would be helpful to be able to get a
> resource addressed by the suffix directly from the RequestPathInfo project to
> prevent error-prone template code all-over.
> 
> For details see also SLING-2670 [1]. I have also attached a complete patch
> there including the API change, the implementation and the increment in the
> API export version.
> 
> The consequence of this API change is, that all implementors of the
> org.apache.sling.api.request package have to be updated. Looking at the
> package this is mostly Sling core stuff plus implementors of the
> SlingRequestListener interface.
> 
> WDYT ?
> 
> Regards
> Felix
> 
> [1] https://issues.apache.org/jira/browse/SLING-2670

Re: Enhancing the RequestPathInfo

Posted by Dascalita Dragos <dd...@gmail.com>.
++1.
I was just working on this these days, on same scenario with admin widgets.
I was initially thinking to use query params, but I've ended up with
suffix, just like you suggest.

The patch in the SLIGN bug is interesting, and it integrates nice with
Sling.

Dragos Dascalita Haut



On Thu, Jan 10, 2013 at 11:42 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:

> On Thu, Jan 10, 2013 at 9:44 AM, Felix Meschberger <fm...@adobe.com>
> wrote:
> > ...For details see also SLING-2670 [1]. I have also attached a complete
> patch there...
>
> Works for me, patch looks good, thanks!
>
> -Bertrand
>

Re: Enhancing the RequestPathInfo

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jan 10, 2013 at 9:44 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...For details see also SLING-2670 [1]. I have also attached a complete patch there...

Works for me, patch looks good, thanks!

-Bertrand