How about this:
public interface ResourceResolver {
void resolveResource(SlingRequestContext context) throws
SlingException;
}
The resolver would set the Resource and SlingRequestPathInfo on the
context immediately. And I think, the SlingRequestContext probably needs
a "backlink" to the request it belongs to, which would also help making
the RequestParameterMap generation lazy.
Such, we could also drop the SlingRequestPathInfoParser as the (default)
ResourceResolver would by backtracking the path be able to keep track of
the path parts and create a SlingRequestPathInfo object as a byproduct.
Or is this a bad idea ?
Regards
Felix
Am Donnerstag, den 18.10.2007, 13:35 +0200 schrieb Bertrand Delacretaz:
> Hi,
>
> I'm starting work on SLING-60, and I think I'll add this new interface
> to the microsling.api package:
>
> public interface ResourceResolver {
>
> Result resolveResource(HttpServletRequest req) throws Exception;
>
> public static class Result {
> ...
> public Resource getResource();
>
> // Indicates which part of the request URI path
> // was used to resolve the resource (see SLING-60)
> // This is usually the Resource's JCR path, but I have
> // this vague feeling that decoupling them might be
> // good (if only to expose this method here)
> public String getResolutionPath();
> }
> }
>
> In this way the (to be improved) SlingRequestPathInfoParser stays
> decoupled, SlingRequestContext will pass it the above
> getResolutionPath() so that the selectors, extensions and suffix take
> the actual path used for resource resolution into account.
>
> Comments are welcome (before it's too late ;-)
>
> -Bertrand
