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
