Felix Meschberger wrote:
This is just beginning and we generate a whole lot of combinations (task
for the student: How many, actually ? ) and we not even started using
the selector as dot-separated instead of a relative path (slash
separated).
Don't get me wrong: I am all for simplifying matters. But for now we are
merely adding more options.... And this is not simplifying at all.
Yes, that were exactly my fears with the proposal as well. And that's
why I suggested to change the current solution by using file names
instead of paths :)
So here is my proposal: We don't search a subtree below the resource
type path anymore but expect the scripts to all be in the same folder.
That is the selector string is used as is as a file name part. To find a
script we apply a longest substring match. The generic script name would
then be:
{pathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{extension}.*
where:
{pathPrefix} - search path prefix, e.g. /apps
{resourceTypePath} - resource type converted to path, e.g.
sling/sample
{resourceTypeLabel} - last part of resource type converted, e.g.
sample
{selectorString} - the selector string, e.g. print.a4
{extension} - the request extension, e.g. html, but may also
be GET
* - any script extension
The implementation is probably very easy: We just find a script whose
name has the most specific match in terms of selectorString and
extension. Because all scripts are looked up in the same parent node, we
can just get a single listing and look for the best match. (working on
subtrees we have to access pretty exhaustive with multiple listings etc.
Yes, this looks good to me and makes everything simpler.
This is, of course, not compatible with what we do currently (with
respect to selectors). But I am convinced, that we have to make a
concession on one end to get the other end. We cannot easily get all.
Exactly, that's why I wanted to discuss this before a release :)
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
