Hi, -1
If it would just be the ScriptResolver being interested in this information, then I might agree. But this is not the case. I already proposed extending the ServletResolver to also take selectors, method and extension into account [1]. In addition, scripts and servlets might as well be interested. So I would keep this resolution at the framework level and provide the data as the RequestPathInfo object. Implementation-wise the ResourceResolver already does the proposed thing of just cutting the request URI in two pieces. In microsling the further split is implemented by the MicroslingRequestPathInfo class. Regards Felix [1] http://www.mail-archive.com/[email protected]/msg00924.html Am Donnerstag, den 22.11.2007, 10:29 +0100 schrieb Bertrand Delacretaz: > On Nov 21, 2007 12:48 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > > > ...I would only split the URI (path) to two parts, the resource path and > > anything that comes after that. Basically, the resolver would start > > with a context node and a URI path (without any leading parts like the > > webapp or servlet path removed) and walk down the node hierarchy using > > segments of the given URI path until no matching node is found. The > > result of this resolution is a new context node and the remaining > > unresolved part of the URI path.... > > Ok > > > ...leave it up to a default servlet like > > SlingScriptServlet, that would construct the /RT/ME.EXT path using the > > remaining path info from step 1 above and recursively call the > > resolution process using /sling/scripts as the context to find an > > appropriate script node. > > I like the idea: split the URL in two parts only at the Sling > framework level, and leave it up to the ScriptResolver to combine the > resource type, method name, remaining path and extension to find a > processing script. > > The change is not hard to implement, and it simplifies the Sling > request processing, so I'm +1 on implementing it. > > What do others think? > > -Bertrand
