On Fri, Apr 18, 2008 at 9:56 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> >
> ...{scriptPathPrefix}/{resourceTypePath}/{resourceTypeLabel}.{selectorString}.{requestMethod}.{requestExtension}.{scriptExtension}.
>
> +1
>
> My concern now is, how do we weight these parts:
>
> {scriptPathPrefix}/{resourceTypePath} - Required, scripts will
> otherwise not be found
ok
> {resourceTypeLabel} - optional, resolve doesn't care, that is no
> preference
I'd make it required, to avoid having too many options. We can always
make it optional later, while the opposite would not be
backwards-compatible.
> {selectorString} - Better is longer match
ok
> {requestMethod} - Better is to have it, required for non-GET
> {requestExtension} - Better is to have it
I'd use my suggested rules as the only options here:
rule A)
{requestMethod}.{requestExtension} == "GET.html" -> required to use an
empty string
rule B)
{requestMethod} != "GET" or "HEAD" -> {requestExtension} is optional
I think this reduces the set of possible combinations, and the rules
are based on safe vs. unsafe http methods, so that's not too bad.
> {scriptExtension} - resolve only cares insofar as to find a ScriptEngine
ok
>
> Now, given a GET request to bar.print.a4.html, what is the priority
> order for the following (porential) script names ?
>
> (1) .../print.esp
> (2) .../print.a4.esp
> (3) .../print.html.esp
> (4) .../print.GET.html.esp
> (5) .../print.a4.html.esp
> (6) .../print.a4.GET.html.esp
>
> It would probably be (6) - (5) - (2) - (4) - (3) - (1)
Yes, more specific names should always win over less-specific ones.
But with my above suggested rules, only the following names would be
allowed (in priority order):
print.a4.esp
print.esp
This is a good example of how my rule A) reduces the number of
possible combinations, that does not matter too much for the
implementation, but it's IMHO easier to explain.
-Bertrand
