Hi,
Am Freitag, den 18.04.2008, 15:21 +0200 schrieb Carsten Ziegeler:
> > I was in fact thinking of calculating a weight value for each script
> > path and take the one with the greatest value. But I think, it is
> > probably even better to make use of the Comparable interface (or
> > Comparator depending on the actual implementation) and be able to just
> > compare two objects representing the scripts and using the "higher" one.
> >
> Hmm, I know that we can cache the results, but isn't this too expensive?
> (First searching all configured paths - there could be more than two
> and then use the best result).
> For a given search path we have a well-defined search order for the
> script (as outlined in the bug), so we make this the outer loop and the
> inner loop iterates over the configured scripts. As soon as a script is
> found, we can use that.
We probably do not want to do that. Consider two scripts
/apps/sling/sample/sample.esp
/libs/sling/sample/sample.print.a4.esp
Now, we probably want to use the latter script and not the first one
because the latter is more specific to the request.
I agree, that today, the former script (sample.esp) is in fact selected.
But this is probably wrong. And it is probably such a strange case, that
noone stumbled upon it for now. But nevertheless, I consider today's
behviour wrong.
Regarding cost: The cost incurrence we have to do a full check is a
child listing per search path entry and some string operations on each
entry. This is opposed to today where we have child list entries per
selector (if we have selectors), though we might not completely walk all
listings.
So, even though we do more on the child listings, we have less listings.
I think, this is probably bearable ... But request logger might show
more or even some performance analysis.
Regards
Felix
