Am Montag, den 17.12.2007, 15:06 -0800 schrieb Padraic Hannon: > I can see the distinction between application and resource type > specific handling, however, given that multiple apps may handle the > same resource types differently and thus have different exception > handling needs how do you see this working?
I think, different applications should use different resource types. These may be easily be managed as values of the sling:resourceType property, using the primary node type name is just in fact just a fallback, default option. > How do you feel about > using the script path (which I guess is resource type specific?) to > use as the tree from which one could look for 404.esp and other such > files? As I said, this is an approach worth considering. Regards Felix > > -paddy > > On Dec 17, 2007, at 2:22 PM, Felix Meschberger wrote: > > > 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 > >>> > >> > >> > >> > >
