Re issue 1): we could have a 404 handler script that kicks in when a non-existing resource is requested. This script could decide what to do (because the desired behaviour is app specific). For your blog example of for a wiki one might want to create a node. But for some apps one might not want to do that and rather return a 404 (see our discussion about truncating URLs until a resource is found). That way we would not need a special handling for "*" (which leaves us with the chicken and egg only)
Michael On 12/12/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > > 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 > -- Michael Marth, http://dev.day.com
