Hi Felix,
Am 31.10.2007 um 08:54 schrieb Felix Meschberger:
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.
Nice.
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.
Not necessarily. I think an order can help, but if it makes no sense,
we should communicate that the order is non-deterministic. In either
case, script authors can react, however I agree that imposing an
alphabetic ordering might come with unintended side-effects like types
starting with 000.
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.
I do not agree. The script author is in control of calling
Sling.include or not, so he should be aware of the consequences.
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 ...
Good.
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.
Is there a conceptual difference between servlets and scripts?
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 ..
Good.
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.
We are not forced to do this. And if it makes no sense, we should
handle it in the order the repository returns for getSupertypes(),
which is nondeterminstic.
- 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 ...
I think the handle() idea is good for one use case: You have defined a
new type. There are scripts for a supertype of this type and you would
like to delegate the rendering to one of these supertypes. Then the
skipIfNext method delegates to a "sibling"-type if possible.
Lars
