Felix Meschberger wrote:
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.
Yepp, exactly that's what I meant in my description, so my suggestion is
to look for (leaving out all other posibilities):
/libs/sling/sample/sample.print.a4.esp
/apps/sling/sample/sample.print.a4.esp
/libs/sling/sample/sample.esp
/apps/sling/sample/sample.esp
The first search already succeeds, we're finished.
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.
Yes, me, too. That's why I asked for a description :)
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.
Hmm, ok, I mean we can start with the simplest impl and improve later
on, but I think that the "use the first match" algorithm should be the
fastest.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
