You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2007/10/26 11:39:31 UTC
[RT] ScriptResolver
The proposed SlingScriptResolver is currenly only able to resolve a
script based on the current sling request.
I think it makes sense to be able to resolve a script based on a path.
A possible use case for this is to invoke some helper scripts during
request processing, for example if I want to call some javascript script
to do some funky stuff from within my java based component etc.
I have no good idea how the method signature should look like? If it
should take a path or a Resource?
WDYT?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ScriptResolver
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Bertrand,
> As Felix indicates, we have designed something like this in the API
> (although it's not yet implemented in microsling) with the
> RequestDispatcherOptions class, which is just a Map of options.
>
> This allows you to render either the current Resource, or another one,
> and override its resource type, selectors or suffix.
>
> Would this provide what you need?
>
> One thing that's different from your proposal is that to render using
> the "mix:versionable" aspect, for example, you'd currently need to
> specify the full path of the mix:versionable script or servlet, like
> /sling/scripts/NODETYPES/mix/versionable. We might want to think of a
> better way of doing that, maybe specifying "nodetypes:mix:versionable"
> as the forced resource type.
I will have to have a look at this class, then we can find an
convenience method that works just by specifying the nodetype (and
that does nothing if there is no script or servlet for this nodetype)
>
>
>> ...Open questions for me are following:
>> ...- 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....
>
> Not sure what you mean, what's your use case or XSLT equivalent?
There is no direct XSLT equivalent, except something like having two
templates, one matching //a and one //a[@a] where the first will only
match for a given "a" element if the second does not match (i.e. there
is no better match)
regards,
Lars
Re: [RT] ScriptResolver
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Lars,
On 10/30/07, Lars Trieloff <la...@trieloff.net> wrote:
> ...Thinking of XSLT, this is similar to <xsl:apply-templates />...
hehe, you obviously found the right analogy to get my attention ;-)
> ...My proposal would be to add
>
> Sling.handle()
> Sling.handle(type)
> Sling.handle(type, selector)..
As Felix indicates, we have designed something like this in the API
(although it's not yet implemented in microsling) with the
RequestDispatcherOptions class, which is just a Map of options.
This allows you to render either the current Resource, or another one,
and override its resource type, selectors or suffix.
Would this provide what you need?
One thing that's different from your proposal is that to render using
the "mix:versionable" aspect, for example, you'd currently need to
specify the full path of the mix:versionable script or servlet, like
/sling/scripts/NODETYPES/mix/versionable. We might want to think of a
better way of doing that, maybe specifying "nodetypes:mix:versionable"
as the forced resource type.
> ...Open questions for me are following:
> ...- 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....
Not sure what you mean, what's your use case or XSLT equivalent?
-Bertrand
Re: [RT] ScriptResolver
Posted by Padraic Hannon <pi...@wasabicowboy.com>.
I think that folks at this point tend to frown on using servlets for
rendering. JSP, Velocity, and Freemarker (perhaps ESP ;-) are better
suited for that. Pure servlets, imho, should be used for front
controllers and other such applications but should not do any display
rendering.
-paddy
On Oct 31, 2007, at 2:32 PM, Lars Trieloff wrote:
> Hi Felix,
>
> I see scripts mainly as a mechanism to express rendering/behavior
> and servlets serve the same purpose, so from my level of
> abstraction, there is no conceptual difference.
>
> Lars
>
> Am 31.10.2007 um 22:27 schrieb Felix Meschberger:
>
>> Hi Lars,
>>
>> Am Mittwoch, den 31.10.2007, 22:01 +0100 schrieb Lars Trieloff:
>>> Is there a conceptual difference between servlets and scripts?
>>
>> Yes and no :-) On the one hand scripts are just a special case of
>> servlets. But then scripts are loaded differently that servlets.
>>
>> Servlets are registered with the ServletResolver (either manually
>> as in
>> microsling or through the OSGi service registry as in Sling) while
>> scripts are dynamically resolved.
>>
>> So, this is how the ServletResolver works:
>>
>> 1. Find a servlet for the resource type
>> 2. Find a script for the request (mostly by the resource type again)
>> (this step delegates to the ScriptResolver)
>> 3. Fall back to the default servlet
>>
>> So, any solution involving the ServletResolver is inherently more
>> powerful than solutions limited to involve the ScriptResolver only.
>> In
>> fact, we should not directly use the ScriptResolver and leave this to
>> the ServletResolver.
>>
>> Regards
>> Felix
>>
Re: [RT] ScriptResolver
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Felix,
I see scripts mainly as a mechanism to express rendering/behavior and
servlets serve the same purpose, so from my level of abstraction,
there is no conceptual difference.
Lars
Am 31.10.2007 um 22:27 schrieb Felix Meschberger:
> Hi Lars,
>
> Am Mittwoch, den 31.10.2007, 22:01 +0100 schrieb Lars Trieloff:
>> Is there a conceptual difference between servlets and scripts?
>
> Yes and no :-) On the one hand scripts are just a special case of
> servlets. But then scripts are loaded differently that servlets.
>
> Servlets are registered with the ServletResolver (either manually as
> in
> microsling or through the OSGi service registry as in Sling) while
> scripts are dynamically resolved.
>
> So, this is how the ServletResolver works:
>
> 1. Find a servlet for the resource type
> 2. Find a script for the request (mostly by the resource type again)
> (this step delegates to the ScriptResolver)
> 3. Fall back to the default servlet
>
> So, any solution involving the ServletResolver is inherently more
> powerful than solutions limited to involve the ScriptResolver only. In
> fact, we should not directly use the ScriptResolver and leave this to
> the ServletResolver.
>
> Regards
> Felix
>
Re: [RT] ScriptResolver
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Am Mittwoch, den 31.10.2007, 22:01 +0100 schrieb Lars Trieloff:
> Is there a conceptual difference between servlets and scripts?
Yes and no :-) On the one hand scripts are just a special case of
servlets. But then scripts are loaded differently that servlets.
Servlets are registered with the ServletResolver (either manually as in
microsling or through the OSGi service registry as in Sling) while
scripts are dynamically resolved.
So, this is how the ServletResolver works:
1. Find a servlet for the resource type
2. Find a script for the request (mostly by the resource type again)
(this step delegates to the ScriptResolver)
3. Fall back to the default servlet
So, any solution involving the ServletResolver is inherently more
powerful than solutions limited to involve the ScriptResolver only. In
fact, we should not directly use the ScriptResolver and leave this to
the ServletResolver.
Regards
Felix
Re: [RT] ScriptResolver
Posted by Lars Trieloff <la...@trieloff.net>.
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
Re: [RT] ScriptResolver
Posted by Felix Meschberger <fm...@gmail.com>.
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
Re: [RT] ScriptResolver
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Betrand,
this is what we want:
>> ...I still think having a
>> level of inheriance and aspect-orientation in rendering is something
>> we want, because it eases the development process....
>
> I agree that this might be useful in some cases - but do you think we
> can achieve this efficiently and simply with a path-based system for
> selecting scripts? I fear that it might be very hard to find rules for
> conflict resolution and priorities that work for all users.
What about doing it this way:
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)
Thinking of XSLT, this is similar to <xsl:apply-templates />
Continuing to think about XSLT, what is the equivalent of <xsl:apply-
imports /> that is used in XSLT to build complex modular stylesheets?
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.
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.
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.
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()
- 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.
regards,
Lars
Re: [RT] ScriptResolver
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/30/07, Lars Trieloff <la...@trieloff.net> wrote:
> ...I still think having a
> level of inheriance and aspect-orientation in rendering is something
> we want, because it eases the development process....
I agree that this might be useful in some cases - but do you think we
can achieve this efficiently and simply with a path-based system for
selecting scripts? I fear that it might be very hard to find rules for
conflict resolution and priorities that work for all users.
An alternative might be a kind of "meta-script" that, if present in
the path where Sling starts looking for scripts, allows more flexible
script/servlet selection: the ScriptResolver would execute or
interpret that script, if it finds it, instead of using its default
resolution mechanism.
Something like the Cocoon sitemap mechanism, but local to the
slingResourceType (or nodetype) path to keep things simple, and only
concerned about script resolution.
Without having looked at all the possible use-cases, I have a gut
feeling that keeping the ScriptResolver simple, yet allowing scripted
overrides, might be the best mix of simplicity and power.
-Bertrand
Re: [RT] ScriptResolver
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Felix,
>> The first candidate is the path denoted by slingResouceType. If this
>> is not set, we resort to the primaryNode type.
>
> In fact, this is overkill as the slingResourceType is intended to be
> either set from a property or the primary node type if there is no
> such
> property. So just checking the SlingResourceType suffices it.
Ok. So this describes what microsling already does.
>> If there is no script
>> available, we build a graph of declaredSuperTypes and use the first
>> matching script.
>>
>> If two nodes in the graph have the same distance to the primaryType,
>> following rules are applied:
>> 1) nt:base has precedence over nt:unstructured
>
> I agree with David, that we should probably prefer nt:unstructured
> over
> nt:base as nt:base is the mother of all types
>
>> 2) built-in node types have precedence over nt:base
>
> In short: nt:base is only used as a last ressort and as such has
> lowest
> weight of all (taking my above note into account)
Agreed.
>
>
>> 3) user-defined node types have precedence over built-in node types
>
> If you can decide, which node types are user-defined and which are
> built-in and what you mean by "built-in"... This is somewhat hard to
> define as it may be the node types defined by the spec, or those
> additional node types defined by Jackrabbit or even those node types
> defined by Sling ...
JCR Spec < Jackrabbit < Sling < User-defined
>
>> 4) an alphabetical precedence ordering takes place
>
> Well, this is sort of like trying to resolve and unresolvable issue:
> As
> the order of mixins of a node as well as the order the supertype
> declaration of a node type definition is not defined, trying to add an
> order is fragile ... And just using alphabetic ordering does not
> make it
> any better: you will come up with types such as 000xyz:000file.
Right. But alphabetic ordering is something everybody can understand,
this is why I chose it.
>
>
>>
>> In the case of a defined slingResourceType, we deal with mixins in
>> the
>> following way: if there are sub-folders in the folder denoted by the
>> slingResourceType that have a naming pattern that matches the
>> declared
>> mixin types, descend into these folders and try to find a script. A
>> deeper descend beats a more shallow descend, so for instance
>> /mix/referenceable/mix/versionable beats /mix/referenceable if two
>> scripts are found at the same level, the precedence rules expressed
>> above take place, so that
>> /mix/versionable/mix/userdefined beats /mix/referenceable/mix/
>> versionable because of rule 3)
>
> Do you think, that rendering will be so much different for a node
> depending on whether it is versionable as to warrant a separate
> script ?
Yes. You could think of these mixin-specific scripts as aspect-
oriented rendering. For example combining a mix:versionable with a
history-selector could result in a generic history visualization or a
mix:referenceable with a permalink-selector into a permalink
representation.
> BTW: Is it correct that the path build order is alphabetical by mixin
> type name. This would probably make sense in this situation (much more
> than above in step 4).
No. The algorithm is descending the tree and finding the deepest node.
For nodes with same depth, the rules described above apply.
> Overall, I have to admit, that I come to think this is overkill :-)
> and
> it tends to get so complicated that (1) no-one will probably
> understand
> it and (2) it will be so expensive to calculate as to take the server
> down. So I would rather stay simple, clean and probably not as
> flexible
> as you propose at least in microsling.
It is probably too complicated, I agree. But I still think having a
level of inheriance and aspect-orientation in rendering is something
we want, because it eases the development process.
You can simply define a default rendering for a wiki page and override
this for special incarnations of wiki pages. And you could define a
default history-rendering for versionable resources and override this
only if necessary.
I think in most cases the resolution algorithm will come to an end
after a few iterations, what I outlined above are only the edge-cases.
Lars
Re: [RT] ScriptResolver
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Thanks for elaborating and also the nice illustration, it helps alot.
Am Montag, den 29.10.2007, 11:25 +0100 schrieb Lars Trieloff:
> For script resolution, we create a weighted list of candidate paths.
> As soon as a script is found in a candidate path, we start looking for
> refinements, or mixin-specific scripts.
So far, so (almost) good. See my comments further ahead.
> The first candidate is the path denoted by slingResouceType. If this
> is not set, we resort to the primaryNode type.
In fact, this is overkill as the slingResourceType is intended to be
either set from a property or the primary node type if there is no such
property. So just checking the SlingResourceType suffices it.
> If there is no script
> available, we build a graph of declaredSuperTypes and use the first
> matching script.
>
> If two nodes in the graph have the same distance to the primaryType,
> following rules are applied:
> 1) nt:base has precedence over nt:unstructured
I agree with David, that we should probably prefer nt:unstructured over
nt:base as nt:base is the mother of all types
> 2) built-in node types have precedence over nt:base
In short: nt:base is only used as a last ressort and as such has lowest
weight of all (taking my above note into account)
> 3) user-defined node types have precedence over built-in node types
If you can decide, which node types are user-defined and which are
built-in and what you mean by "built-in"... This is somewhat hard to
define as it may be the node types defined by the spec, or those
additional node types defined by Jackrabbit or even those node types
defined by Sling ...
> 4) an alphabetical precedence ordering takes place
Well, this is sort of like trying to resolve and unresolvable issue: As
the order of mixins of a node as well as the order the supertype
declaration of a node type definition is not defined, trying to add an
order is fragile ... And just using alphabetic ordering does not make it
any better: you will come up with types such as 000xyz:000file.
>
> In the case of a defined slingResourceType, we deal with mixins in the
> following way: if there are sub-folders in the folder denoted by the
> slingResourceType that have a naming pattern that matches the declared
> mixin types, descend into these folders and try to find a script. A
> deeper descend beats a more shallow descend, so for instance
> /mix/referenceable/mix/versionable beats /mix/referenceable if two
> scripts are found at the same level, the precedence rules expressed
> above take place, so that
> /mix/versionable/mix/userdefined beats /mix/referenceable/mix/
> versionable because of rule 3)
Do you think, that rendering will be so much different for a node
depending on whether it is versionable as to warrant a separate script ?
BTW: Is it correct that the path build order is alphabetical by mixin
type name. This would probably make sense in this situation (much more
than above in step 4).
Overall, I have to admit, that I come to think this is overkill :-) and
it tends to get so complicated that (1) no-one will probably understand
it and (2) it will be so expensive to calculate as to take the server
down. So I would rather stay simple, clean and probably not as flexible
as you propose at least in microsling.
In Sling I would propose to also provide a simple default implementation
just taking the slingResourceType into account. More complex
implementations can still be devised and tried on Sling by just
replacing the default implementation by a complex implementation.
Regards
Felix
Re: [RT] ScriptResolver
Posted by David Nuescheler <da...@day.com>.
hi lars,
thanks a lot for the illustration. i think this is a great
approach. i would like to ask a couple of detailed questions
though.
> If two nodes in the graph have the same distance to the primaryType,
> following rules are applied:
> 1) nt:base has precedence over nt:unstructured
really? my gut feel would have been the other way around...
i haven't thought it through though...
did you have a particular rationale that you can share?
> 2) built-in node types have precedence over nt:base
since nt:base is the "mother" all built-in nodes i think
i can agree to the sentence pre-pending "other " ;)
> 3) user-defined node types have precedence over built-in node types
ack.
> 4) an alphabetical precedence ordering takes place
it sounds like this is so arbitrary that i would probably
just opt for a quick "implementation" defined (==undefined)
resolution instead of sorting. what do you think?
did you mean to specify a resolution order by
(1) - (4) or is the sequence of the rules arbitrary.
regards,
david
Re: [RT] ScriptResolver
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Felix,
>>
>> What I would like to work out is how an intelligent script resolution
>> could work that allows multiple levels of fallbacks and that supports
>> mixin types.
>
> Cool, would be very interested in such an approach.
Out of my head, here is how I would do it (for an illustration, see http://weblogs.goshaky.com/weblogs/lars/resource/scriptresolution.png)
:
For script resolution, we create a weighted list of candidate paths.
As soon as a script is found in a candidate path, we start looking for
refinements, or mixin-specific scripts.
The first candidate is the path denoted by slingResouceType. If this
is not set, we resort to the primaryNode type. If there is no script
available, we build a graph of declaredSuperTypes and use the first
matching script.
If two nodes in the graph have the same distance to the primaryType,
following rules are applied:
1) nt:base has precedence over nt:unstructured
2) built-in node types have precedence over nt:base
3) user-defined node types have precedence over built-in node types
4) an alphabetical precedence ordering takes place
In the case of a defined slingResourceType, we deal with mixins in the
following way: if there are sub-folders in the folder denoted by the
slingResourceType that have a naming pattern that matches the declared
mixin types, descend into these folders and try to find a script. A
deeper descend beats a more shallow descend, so for instance
/mix/referenceable/mix/versionable beats /mix/referenceable if two
scripts are found at the same level, the precedence rules expressed
above take place, so that
/mix/versionable/mix/userdefined beats /mix/referenceable/mix/
versionable because of rule 3)
regards,
Lars
Re: [RT] ScriptResolver
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 26.10.2007, 12:44 +0200 schrieb Lars Trieloff:
> Hi,
> I think the script resolver should resolve scripts based primarily on
> the content. This means based on the sling-content type, the Jcr
> content type, including mixin types and only secondarily based on
> attributes of the request like selectors.
Agreed and this is actually how it is implemented in microsling and will
be done in Sling, too.
>
> What I would like to work out is how an intelligent script resolution
> could work that allows multiple levels of fallbacks and that supports
> mixin types.
Cool, would be very interested in such an approach.
Regards
Felix
Re: [RT] ScriptResolver
Posted by Lars Trieloff <la...@trieloff.net>.
Hi,
I think the script resolver should resolve scripts based primarily on
the content. This means based on the sling-content type, the Jcr
content type, including mixin types and only secondarily based on
attributes of the request like selectors.
What I would like to work out is how an intelligent script resolution
could work that allows multiple levels of fallbacks and that supports
mixin types.
Lars
On Oct 26, 2007, at 11:39 AM, Carsten Ziegeler <cz...@apache.org>
wrote:
> The proposed SlingScriptResolver is currenly only able to resolve a
> script based on the current sling request.
>
> I think it makes sense to be able to resolve a script based on a path.
> A possible use case for this is to invoke some helper scripts during
> request processing, for example if I want to call some javascript
> script
> to do some funky stuff from within my java based component etc.
>
> I have no good idea how the method signature should look like? If it
> should take a path or a Resource?
>
> WDYT?
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: [RT] ScriptResolver
Posted by Felix Meschberger <fm...@gmail.com>.
Am Freitag, den 26.10.2007, 14:45 +0200 schrieb Bertrand Delacretaz:
> On 10/26/07, Carsten Ziegeler <cz...@apache.org> wrote:
>
> > ...If we then have a mechanism to detect a specific ScriptEngine, I could
> > implement my use case by looking up the ScriptEngine I want (as I know I
> > want the javascript or the jruby or whatever script engine),
> > instantiating a script object, setting the script engine, setting a
> > reader and then I can invoke the script engine with this....
>
> I had something different in mind, for the use-case "find and execute
> a Script which is not related to a Request".
>
> 1. Give ScriptResolver the path of the script that you want to load.
> The ScriptResolver might use search paths a la unix PATH.
That would be the signature taking a (relative) path.
>
> 2. If the path doesn't include an extension, ScriptResolver tries the
> extensions provided by the list of available ScriptEngines.
Not sure, where we should do this kind of resolution, yet MS-DOS and its
descendants do this.
>
> 3. If the path includes the extension (or once 2. has selected one),
> return the Script object.
>
> 4. Execute the script returned by the ScriptResolver, using
> Script.getEngine.eval(XYZ)
>
> XYZ can either be a Request/Response, or a Reader/Writer, depending on
> the execution environment.
In fact, the signature for eval is eval(Script, Map<String, Object>). So
to actually call a script you are not really bound to request/response.
Maybe we might want to define an additional signature to specify the
output - should it be a stream or a writer ?
>
> I think the main difference in my case is that the ScriptEngine
> resolution happens inside the ScriptResolver, and the Script provides
> you the suitable ScriptEngine.
>
> -Bertrand
Re: [RT] ScriptResolver
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/26/07, Carsten Ziegeler <cz...@apache.org> wrote:
> ...this comes down to the question of whether you need script
> resolution for these use cases or not....
Even having search paths is a kind of "resolution", so I think that makes sense.
-Bertrand
Re: [RT] ScriptResolver
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> On 10/26/07, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> ...If we then have a mechanism to detect a specific ScriptEngine, I could
>> implement my use case by looking up the ScriptEngine I want (as I know I
>> want the javascript or the jruby or whatever script engine),
>> instantiating a script object, setting the script engine, setting a
>> reader and then I can invoke the script engine with this....
>
> I had something different in mind, for the use-case "find and execute
> a Script which is not related to a Request".
>
> 1. Give ScriptResolver the path of the script that you want to load.
> The ScriptResolver might use search paths a la unix PATH.
>
> 2. If the path doesn't include an extension, ScriptResolver tries the
> extensions provided by the list of available ScriptEngines.
>
> 3. If the path includes the extension (or once 2. has selected one),
> return the Script object.
>
> 4. Execute the script returned by the ScriptResolver, using
> Script.getEngine.eval(XYZ)
>
> XYZ can either be a Request/Response, or a Reader/Writer, depending on
> the execution environment.
>
> I think the main difference in my case is that the ScriptEngine
> resolution happens inside the ScriptResolver, and the Script provides
> you the suitable ScriptEngine.
>
Yes, and this comes down to the question of whether you need script
resolution
for these use cases or not. The use case I can currently think of do not
require resolution as I know where the script exactly is and what engine
should be used.
But I think we can still do both without imposing too much changes:
making the script a bean, add a lookup mechanism for script engines
(which should be really simple) and then we can still add the method you
suggest above.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ScriptResolver
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/26/07, Carsten Ziegeler <cz...@apache.org> wrote:
> ...If we then have a mechanism to detect a specific ScriptEngine, I could
> implement my use case by looking up the ScriptEngine I want (as I know I
> want the javascript or the jruby or whatever script engine),
> instantiating a script object, setting the script engine, setting a
> reader and then I can invoke the script engine with this....
I had something different in mind, for the use-case "find and execute
a Script which is not related to a Request".
1. Give ScriptResolver the path of the script that you want to load.
The ScriptResolver might use search paths a la unix PATH.
2. If the path doesn't include an extension, ScriptResolver tries the
extensions provided by the list of available ScriptEngines.
3. If the path includes the extension (or once 2. has selected one),
return the Script object.
4. Execute the script returned by the ScriptResolver, using
Script.getEngine.eval(XYZ)
XYZ can either be a Request/Response, or a Reader/Writer, depending on
the execution environment.
I think the main difference in my case is that the ScriptEngine
resolution happens inside the ScriptResolver, and the Script provides
you the suitable ScriptEngine.
-Bertrand
Re: [RT] ScriptResolver
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger schrieb:
> Hi,
>
> Am Freitag, den 26.10.2007, 11:39 +0200 schrieb Carsten Ziegeler:
>> The proposed SlingScriptResolver is currenly only able to resolve a
>> script based on the current sling request.
>>
>> I think it makes sense to be able to resolve a script based on a path.
>> A possible use case for this is to invoke some helper scripts during
>> request processing, for example if I want to call some javascript script
>> to do some funky stuff from within my java based component etc.
>>
>> I have no good idea how the method signature should look like? If it
>> should take a path or a Resource?
>
> I thought about this, too, and in fact temporarily had a signature
> taking a path, which would probably have been the exact script path.
> This would probably make sense.
>
> In addition, I could imagine, that theoretically, other signatures like
> taking a Resource and/or RequestPathInfo would be interesting - but I
> have no clue where to stop adding signatues :-)
:)
> That is why, I actually dropped the method with the path signature and
> just left the one taking the request object.
Hmm, ok, perhaps we can take another approach. The current Script
interface is actually just a container for some objects, so we could
make a simple bean out of it.
If we then have a mechanism to detect a specific ScriptEngine, I could
implement my use case by looking up the ScriptEngine I want (as I know I
want the javascript or the jruby or whatever script engine),
instantiating a script object, setting the script engine, setting a
reader and then I can invoke the script engine with this.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] ScriptResolver
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 26.10.2007, 11:39 +0200 schrieb Carsten Ziegeler:
> The proposed SlingScriptResolver is currenly only able to resolve a
> script based on the current sling request.
>
> I think it makes sense to be able to resolve a script based on a path.
> A possible use case for this is to invoke some helper scripts during
> request processing, for example if I want to call some javascript script
> to do some funky stuff from within my java based component etc.
>
> I have no good idea how the method signature should look like? If it
> should take a path or a Resource?
I thought about this, too, and in fact temporarily had a signature
taking a path, which would probably have been the exact script path.
This would probably make sense.
In addition, I could imagine, that theoretically, other signatures like
taking a Resource and/or RequestPathInfo would be interesting - but I
have no clue where to stop adding signatues :-)
That is why, I actually dropped the method with the path signature and
just left the one taking the request object.
Regards
Felix