Hi all,
Am Mittwoch, den 12.12.2007, 17:00 +0100 schrieb Bertrand Delacretaz:
> 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.
The classical bootstrap problem. In Sling we solved this with a initial
content load support in the jcr/resource project. With the recent
addition of the ResourceProvider interface in the jcr/resource project,
the content loader might be replaced by this mechanism in that the
content is directly loaded from the bundle. But this is a different
track....
> - o -
>
> ISSUE 1: Chicken and egg problem, resource not found intially -> map *
> to SyntheticResource
I basically agree. The use of a synthetic resource is a good idea to
solve this problem. Also having this kind of SyntheticResourceProvider
seems reasonable. Yet, I find the solution awkward.
I would propose a slightly modified variant: An entry in the in the
SyntheticResourceProvider is a tuple consisting of a regular expression
for path mapping and a resource type, that is
(regexp, resourceType)
If the regexp matches, a SyntheticResource is created as follows:
- Match group 1 (aka $1) of the regexp is used as the resource path
- resourceType of the matching tuple is used as the resource type
- Everything from the start of the path upto the end of the match
group
1 is taken as the RESOLUTION_PATH of the resource.
Example: Consider the configuration
( "/content(/.*/posts)", "blog:posts" )
applied to the request path "/content/linotype/posts.html", this
would
result in the following settings for the SyntheticResource:
resource path : "/linotype/posts"
resource type : "blog:posts"
RESOLUTION_PATH : "/content/linotype/posts"
This helps in multiple ways:
- we know exactly which resource was actually requested
- we have a resource type
- we can resolve other parts of the request such as the extension
etc.
> - o -
>
> ISSUE 2: Mapping a SyntheticResource to a rendering script -> resource
> path-based script resolution
The problem of selecting the rendering script (or servlet) is solved by
the solution to ISSUE 1 as we already have a resource type and therefore
can go on as always. No special casing here ....
> - o -
>
> ISSUE 3: Rendering a Property uses the Resource-path based script
> resolution, not good
The problem is, that it was once decided, that properties would never be
addressed directly ...
I would solve this problem such that the resource resolver would (a)
accept addressed properties and (b) the resource type of the property
resource is the resource type of the parent node. Of course a property
resource would return the property and not the parent node.
So, we can easily manage the directly addressed properties just like
nodes, except that the rendering scripts might be required to be
prepared to handle a Property instread of just a Node.
The core point I want to mention is, that the Resource is central point
in Sling request processing, where the resource type is used to select
actors. If we stay in this concept of a Resource with a resource type,
we do not need to implement any special casing but can just keep going.
WDYT ?
Regards
Felix
