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 2007/10/18 16:15:33 UTC
ResourceResolver and Resource
Hi all,
The current Component API contains the following methods in the
SlingRequest interface:
// return the main content of the current request
Content getContent();
// return a content address by path
Content getContent(String path) throws SlingException;
// list the children of the named content
Enumeration<Content> getChildren(Content content) throws
SlingException;
Presuming that we drop the SlingRequest interface in favor of some
SlingRequestContext, which should just be a bean available as a request
attribute, we probably need some replacement API for these methods. I
could imagine the following solutions:
(1) Enhance the propsed ResourceResolver interface
// return the Resource addressed by the request (already
proposed)
Resource getResource(ServletRequest request);
// return the Resource addressed by path, relative path resolved
// relative to the given resource
Resource getResource(Resource base, String path) throws
SlingException;
// list the children of the named Resource
Iterator<Resource> listChildren(Resource resource) throws
SlingException;
(2) Enhance the Resource interface by adding the following methods
// return the resource addressed by the path
// relative paths resolved relative to this resource
Resource getResource(String path) throws SlingException;
// list the children of this resource
Iterator<Resource> listChildren() throws SlingException;
(3) Enhance the SlingRequestContext by methods:
// return the Resource addressed by path, relative path resolved
// relative to the request's main resource
Resource getResource(ServletRequest request, String path) throws
SlingException;
// list the children of the named Resource
Iterator<Resource> listChildren(Resource resource) throws
SlingException;
The first solution clearly detaches the Resource from the
ResourceResolver on the other hand requires clients to get at the
ResourceResolver somehow (Probably as another field in the
SlingRequestContext ?).
The third solution does not seem right as it breaks the idea that
SlingRequestContext should probably be just a bean.
I most like the second solution as it looks similar to what java.io.File
does. There is one catch, tough, with this solution: The Resource
returned must have a link into the ResourceResolver.
WDYT ?
Regards
Felix
Re: ResourceResolver and Resource
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger schrieb:
> Hi all,
>
> The current Component API contains the following methods in the
> SlingRequest interface:
>
> // return the main content of the current request
> Content getContent();
> // return a content address by path
> Content getContent(String path) throws SlingException;
> // list the children of the named content
> Enumeration<Content> getChildren(Content content) throws
> SlingException;
>
> Presuming that we drop the SlingRequest interface in favor of some
> SlingRequestContext, which should just be a bean available as a request
> attribute, we probably need some replacement API for these methods. I
> could imagine the following solutions:
>
> (1) Enhance the propsed ResourceResolver interface
>
> // return the Resource addressed by the request (already
> proposed)
> Resource getResource(ServletRequest request);
> // return the Resource addressed by path, relative path resolved
> // relative to the given resource
> Resource getResource(Resource base, String path) throws
> SlingException;
> // list the children of the named Resource
> Iterator<Resource> listChildren(Resource resource) throws
> SlingException;
>
> (2) Enhance the Resource interface by adding the following methods
>
> // return the resource addressed by the path
> // relative paths resolved relative to this resource
> Resource getResource(String path) throws SlingException;
> // list the children of this resource
> Iterator<Resource> listChildren() throws SlingException;
>
> (3) Enhance the SlingRequestContext by methods:
>
> // return the Resource addressed by path, relative path resolved
> // relative to the request's main resource
> Resource getResource(ServletRequest request, String path) throws
> SlingException;
> // list the children of the named Resource
> Iterator<Resource> listChildren(Resource resource) throws
> SlingException;
>
> The first solution clearly detaches the Resource from the
> ResourceResolver on the other hand requires clients to get at the
> ResourceResolver somehow (Probably as another field in the
> SlingRequestContext ?).
>
> The third solution does not seem right as it breaks the idea that
> SlingRequestContext should probably be just a bean.
>
> I most like the second solution as it looks similar to what java.io.File
> does. There is one catch, tough, with this solution: The Resource
> returned must have a link into the ResourceResolver.
>
> WDYT ?
>
I think the second solution is best and I don't see a problem with the
internal reference from a resource implementation. In the excalibur
sourceresolver stuff we are doing exactly the same :)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: ResourceResolver and Resource
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 18.10.2007, 17:12 +0200 schrieb Bertrand Delacretaz:
> I might agree about the relative resources, but why the children? And
> why just the children axis and not the full
> ancestors/descendants/siblings/next/previous axes?
Generally, there are two use cases: Access a resource and list the
(direct) children. Hence the two methods getResource(Resource, String)
and listChildren(Resource).
> If navigation between Resources is needed and that cannot be covered
> by JCR, I'd suggest making that a separate ResourceHierarchyNavigation
> interface.
This smells like "interface-itis" - another method, another
interface :-)
No I think, if we just ammend the existing interface, we would probably
be fine.
I agree, that we should keep the Resource lean and clean and hence these
methods belong to the ResourceResolver.
Regards
Felix
Re: ResourceResolver and Resource
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/18/07, Felix Meschberger <fm...@gmail.com> wrote:
> ...Well, thinking along these lines: Why do we need a Resource and
> ResourceResolver in the first place then ? .......
Technically, as we're limiting ourselves to JCR content, we don't
really need a Resource, you're right.
But currently the Resource does abstract the fact that a Node might be
mapped to an Object or not. The fact that the Resource interface is
small doesn't make it useless: it makes it beautiful ;-)
OTOH we *do* need the ResourceResolver interface very much: it
encapsulates our "rules" for finding a Resource that the current
request must process.
> ...Honestly, if we abstract the Resource, we also have to take the next
> step and abstract access to relative Resources and children....
I might agree about the relative resources, but why the children? And
why just the children axis and not the full
ancestors/descendants/siblings/next/previous axes?
If navigation between Resources is needed and that cannot be covered
by JCR, I'd suggest making that a separate ResourceHierarchyNavigation
interface.
-Bertrand
Re: ResourceResolver and Resource
Posted by Felix Meschberger <fm...@gmail.com>.
Am Donnerstag, den 18.10.2007, 16:36 +0200 schrieb Bertrand Delacretaz:
> On 10/18/07, Felix Meschberger <fm...@gmail.com> wrote:
>
> > ... // return the main content of the current request
> > Content getContent();
> > // return a content address by path
> > Content getContent(String path) throws SlingException;
> > // list the children of the named content
> > Enumeration<Content> getChildren(Content content) throws
> > SlingException;
> >...
>
> Why do we need this in the general case?
>
> If the Resource is a JCR node, that gives full access to JCR
> navigation features, which cover the above and much more (or am I
> missing something?).
Well, thinking along these lines: Why do we need a Resource and
ResourceResolver in the first place then ? ....
Honestly, if we abstract the Resource, we also have to take the next
step and abstract access to relative Resources and children.
> If this is needed for OCM-mapped objects only, then IMHO that's an OCM
> concern, which might warrant a helper class, but does not deserve
> adding stuff to our (currently lean and mean) Resource interface.
That's the reason why probably the second solution (relative and
children from the Resource) is not that good and the first (relative and
children from ResourceResolver) might be better. On the other hand the
second solution puts you in a context (the Resource) and does not force
you to you out-of-context information (the ResourceResolver again).
Regards
Felix
Re: ResourceResolver and Resource
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/18/07, Felix Meschberger <fm...@gmail.com> wrote:
> ... // return the main content of the current request
> Content getContent();
> // return a content address by path
> Content getContent(String path) throws SlingException;
> // list the children of the named content
> Enumeration<Content> getChildren(Content content) throws
> SlingException;
>...
Why do we need this in the general case?
If the Resource is a JCR node, that gives full access to JCR
navigation features, which cover the above and much more (or am I
missing something?).
If this is needed for OCM-mapped objects only, then IMHO that's an OCM
concern, which might warrant a helper class, but does not deserve
adding stuff to our (currently lean and mean) Resource interface.
-Bertrand