Hi, On Nov 20, 2007 3:26 PM, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > 1. The URI is split in four parts (resource path, selectors, > extension, suffix), where "resource path" is the longest part of the > request path that matches a Node in the repository
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. > 2. A "resource type" is computed: if the node has a > "slingResourceType" Property (or is that sling:resourceType, now? > doesn't matter much for this discussion) its value is used, otherwise > the node type is converted to a valid JCR path, and used as the > resource type. No changes here. > 3. The ServletResolver looks for a Servlet that is configured to > handle this resource type (hardcoded in microsling to serve default > nt:file Nodes for example, OSGi-dynamic in Sling) No changes here, except see below on how I would push functionality from the Sling framework into the servlet level. > 4. If no Servlet is found, the ScriptResolver looks for a script, > building its path as follows: > > /sling/scripts/RT/ME.EXT I would remove this part from the resolution process within the Sling framework, and 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. > Let's see how you'd do that, if there's a simple way that still leads > to clear conventions I'm all ears. My idea would actually result in little or no change to the end user or an average Sling component developer (I'd still like to use slashes as separators instead of dots, but that's a minor concern), but would make the Sling internals more modular as the ScriptResolver would essentially become just another Sling servlet component. BR, Jukka Zitting
