Re: Chickens, eggs and stars

[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? 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?

-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