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...@gmail.com> on 2008/01/29 11:50:57 UTC
Some more Sling API stuff
Hi all,
In addition to the changes of last week introducing the Adapter
framework, I would like to modify the ResourceResolver API as stipulated
in [2] and described in [1].
The consequence of this change would be that (1) the PathResolver
interface of the jcr/resolver project would be dropped, as the
ResourceResolver interface defines the API and (2) the search path
handling currently located in the sling/servlet-resolver project is
moved to be a core functionality of the ResourceResolver and thus be
usable to other users in need of realtive path resolution.
WDYT ?
Regards
Felix
[1] http://incubator.apache.org/sling/site/resources.html
[2] http://issues.apache.org/jira/browse/SLING-198
Re: Some more Sling API stuff
Posted by Philipp Koch <ph...@day.com>.
that means that the PathResolver.pathToURL(Resource res) will be
replaced by ResourceResolver.map(String path)?
the current pathToUrl method is currently useless because the path to
url resolving only works for a given resource eg. /a/b/c but not for a
path like /a/b/c.gif (also addresses /a/b/c but invokes a script for
gif image generation (as example)) because of the fact the only the
resource can be passed (which does not know anything about its
"extension" (.gif))...
the suggestion sounds good to me (i hope that this will be the last
change regarding pathToUrl mapping (regarding api)
regards,
philipp
On 1/29/08, Tobias Bocanegra <to...@day.com> wrote:
> +1 good idea
>
>
> On 1/29/08, Felix Meschberger <fm...@gmail.com> wrote:
> > Hi all,
> >
> > In addition to the changes of last week introducing the Adapter
> > framework, I would like to modify the ResourceResolver API as stipulated
> > in [2] and described in [1].
> >
> > The consequence of this change would be that (1) the PathResolver
> > interface of the jcr/resolver project would be dropped, as the
> > ResourceResolver interface defines the API and (2) the search path
> > handling currently located in the sling/servlet-resolver project is
> > moved to be a core functionality of the ResourceResolver and thus be
> > usable to other users in need of realtive path resolution.
> >
> > WDYT ?
> >
> > Regards
> > Felix
> >
> >
> > [1] http://incubator.apache.org/sling/site/resources.html
> > [2] http://issues.apache.org/jira/browse/SLING-198
> >
> >
>
>
>
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
Re: Some more Sling API stuff
Posted by Tobias Bocanegra <to...@day.com>.
+1 good idea
On 1/29/08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi all,
>
> In addition to the changes of last week introducing the Adapter
> framework, I would like to modify the ResourceResolver API as stipulated
> in [2] and described in [1].
>
> The consequence of this change would be that (1) the PathResolver
> interface of the jcr/resolver project would be dropped, as the
> ResourceResolver interface defines the API and (2) the search path
> handling currently located in the sling/servlet-resolver project is
> moved to be a core functionality of the ResourceResolver and thus be
> usable to other users in need of realtive path resolution.
>
> WDYT ?
>
> Regards
> Felix
>
>
> [1] http://incubator.apache.org/sling/site/resources.html
> [2] http://issues.apache.org/jira/browse/SLING-198
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---