Hi,
Am Freitag, den 18.04.2008, 10:44 +0200 schrieb Bertrand Delacretaz:
> 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.
fine with me.
>
> > {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
At first sight, I could agree. But thinking again about how Servlets
would be merged into the Resource Tree view with their registration
properties for virtual path building, we should allow GET and/or html.
Otherwise a servlet could not be registered for, say, GET and POST
explicitly.
We should not treat html special in that we prevent it from being used
as part of the script name. Rather we make it optional; always. It is
then the responsibility of the script programmer to cope with the
situation.
>
> 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.
Yes. It is also easy to describe: The requestExtension is optional (all
the time actually, see above) while the requestMethod is required for
non-GET (and non-HEAD) only and optional for GET/HEAD requests. This
still reflects the separation of safe vs. unsafe methods.
Regards
Felix
>
> > {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
