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
