Am Mittwoch, den 12.12.2007, 17:52 +0100 schrieb Michael Marth: > 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)
This proposal shares the same weakness as the initial one: It is location sensitive and assumes an application is (or the nodes of an application are) bound to a certain path. This is wrong, though: The nodes of applications are bound by their resource type. So we should thrive for a solution, which binds the requested URI to a resource type. This is not against having application specific error handlers, but "application specific" means "resource type specific". Regards Felix > > 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 > > > > >
