Hi, Am Freitag, den 18.04.2008, 15:53 +0200 schrieb Carsten Ziegeler: > 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
/apps comes before /libs (this is a detail) > > The first search already succeeds, we're finished. Factually, this is correct. Implementationwise we will not do it like this. Because we do not know the script extension beforehand, we cannot use direct access. We have to scan the child lists anyway. Regards Felix > > > > > 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
