On Mon, Jan 19, 2009 at 12:14 PM, Carsten Ziegeler <[email protected]> wrote:
> Felix Meschberger wrote:
>> ...So, the resource collector has now knowledge here and handling .java
>> scripts specially at this place is an absolute no-go (IMHO).
>>
> But what about delegating the resolution to the script engine? The
> script engine could do some weired resolution and return a set of
> resources that fit to this script engine. Now we could make this
> optional, so only if the script engine implements some marker interface
> the resolution is delegated to the engine. If not, the current default
> mechanism is used....
We're talking about resolution of scripts but what Sling actually
looks for is a Servlet to process the current request, Servlet which
can be created from a script (I know you know that Carsten, that's
just for the sake of clarity ;-)
So I don't think this can be fully delegated to the script engine -
OTOH, a key part of finding a script is in the
ResourceCollector.getWeightedResources method [1], and it seems
relatively easy to add an extension point there, to allow assigning
weights to scripts that are ignored by the standard resolution.
Something like
interface ScriptCandidateWeight {
/** If the plugin considers the scriptCandidate as valid for processing
the current request, return the corresponding weight */
public int getScriptCandidateWeight(
Resource scriptCandidate, String currentSelector, int numSelectors,
SlingHttpServletRequest request);
}
The java scripting engine then registers such a service to include
scripts like PathGET.java in the list of candidates.
-Bertrand
[1]
http://svn.apache.org/repos/asf/incubator/sling/trunk/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/helper/ResourceCollector.java
