Hi,
Am Dienstag, den 30.10.2007, 17:08 +0100 schrieb Lars Trieloff:
> In Sling, we already have a concept of delegation. This means, a
> resource delegates the rendering of the children to the children's
> scripts by calling
>
> Sling.include(path)
This is only one side of the medal. The other one is much more
interesting: You may include with dispatcher options:
Sling.include(path, options), which amongst other things may declare a
resource type overwrite. See below.
> My proposal would be to add
>
> Sling.handle()
> Sling.handle(type)
> Sling.handle(type, selector)
>
> to the API.
>
> Sling.handle() would simply delegate the rendering/script execution to
> all declared supertypes/mixins. Those that have a script (for this
> selector) execute it. You could also add Sling.handle() as a default
> fallback script, provided there is no script defined for
> slingResourceType.
I do not like this because it requires the definition of a processing
order, which would be deliberate such as ordering alphabetically. In
addition it will just blur some renderings into the current output,
which may or may not be correct depending on the context, which is not
known to the included scripts.
> Sling.handle(type) delegates rendering/script execution to the mixing
> or supertype specified. No script is defined for this type, nothing is
> done. This makes it possible to include a <%
> Sling.handle("mix:versionable") %> in the sidebar of the page,
> rendering the version history if there is one. It also serves the
> separation of concerns, as the main script only renders what it knows
> and mixin-specific scripts render mixin-specific content.
This is already possible today:
Map options = new HashMap();
options.put("forceResourceType", type);
sling.include(request.getResource().getURI(), options);
Adding such a method would then be just another helper ...
This in fact is even more powerful, than you desire as it does not limit
the code to be executed to scripts but does a complete servlet/script
selection for for the include.
>
> Sling.handle(type, selector) is basically the same, but allows the
> user to change the selector while delegating. It can be useful if you
> want to have different views of a mixin, giving you the same
> flexibility you have with the original content.
Same as above, except that you add a "replaceSelectors" option. And also
as above, this is just another helper ..
>
> With this approach you have both: inheritance in rendering through
> Sling.handle() and aspect-orientation through Sling.handle(type)
>
> This combines your meta-script idea with a handling of mixins, allows
> for an implementation that does not traverse the node tree or type
> graph and is easy to understand.
>
> Open questions for me are following:
> - do we want to establish a precedence order for Sling.handle()
We would have to. But as I said, such a thing would be deliberate and
hard to understand and use.
> - do we want to add something like Sling.skip() that will skip the
> execution of a script and Sling.skipIfNext() that skips the execution
> if and only if there is another script in the execution chain that
> does not skip.
I do not see a reason for such a thing as there is no such thing as a
predefined script execution chain - presuming we drop the handle() idea.
And then: How would you explain the skipIfNext method ? Should the
script have context information about the execution chain ...
Regards
Felix
