Now that I got your attention ;-) (warning: long read ahead)
I've been working with David Nuescheler in the last few days, fixing and improving a few things in microsling to allow him to build his cool "your blog in 15 minutes" demo for javapolis [1]. This has brought a few issues to our attention, I'll explain them here, comments are welcome. One important goal is being able to drop a microsling application (a set of scripts, templates and static files) in the JCR repository (via WebDAV), and start working without having to create any Nodes beforehand. - o - ISSUE 1: Chicken and egg problem, resource not found intially -> map * to SyntheticResource In one of the demos we create nodes under /content/linotype/posts So we direct people to http://locahost:port/content/linotype/posts.html - but there's no /content node yet, so the resource is not found. To solve this, SLING-129 implements SyntheticResource, and maps any URL ending in * to one (that should be configurable, hardcoded using regexps for now, see SyntheticResourceProvider). So now, http://localhost:port/content/linotype/posts/*.post.html resolves to a SyntheticResource, which is empty and has an empty resourceType. That page stores content under /content/linotype/posts, everything's fine (almost, see issue 2). - o - ISSUE 2: Mapping a SyntheticResource to a rendering script -> resource path-based script resolution By design, SyntheticResource has an empty resourceType. So we needed a way to map http://localhost:port/content/linotype/posts/*.post.html to a script, and that's where SLING-125 comes in: the collection of search paths for scripts now has an additional component based on the path of the resource only, irrelevant of the resource type (see examples in ScriptSearchPathsBuilderTest). In our case, for http://localhost:port/content/linotype/posts/*.post.html the additional search path is /apps/linotype Where /apps/ is a hardcoded (for now) prefix, and "linotype" is the second level of the resource path (that rule is also hardcoded, could be a configurable regexp). That works fine, now our posts/*.post.html URL maps to a SyntheticResource, and uses the script found in /apps/linotype/post/html.esp for rendering. Basing script resolution on a path, disregarding the (nonexistent in this case) resource type introduces more options in script rendering, which has drawbacks. We haven't found a better way at this point. - o - ISSUE 3: Rendering a Property uses the Resource-path based script resolution, not good SLING-133 implements GET access to JCR Properties, which is need for example to initialize <textarea> HTML elements directly from the browser. Problem is, with the resource path-based script resolution, a Property requested like /content/linotype/posts/mypost/text.html Is mapped to the script found at /apps/linotype/html.esp, due to the resource path based resolution described for issue 2. To fix this I introduced the somewhat ugly workaround of revision 603302. There's probably a better way. - o - I think it would be good to put our collective neurons to work on these issues. Being able to just drop some scripts in the repository to activate an application is very cool, but as described that raises some issues. We have solved them in simple ways for now, but there's probably room for improvement. -Bertrand [1] http://dev.day.com/microsling/content/blogs/main/microjax.html
