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 [EMAIL PROTECTED]
