On 6/22/07, Bill de hOra <bill_at_dehora.net> wrote:
>
>
> Indeed. For me to add
>
> @UriTemplate("hello%20world")
>
> means I need to know the escape sequence as I type. The doing this
>
> @UriTemplate("hello world")
We're not talking about changing the URI template to auto-code. Just the URI
parameter that is extracted after the jsr311 algorithm has *already* run on
the URI and extracted the params.
will be an exception (?), as it's not legal syntax.
>
> OTOH, auto-encoding will surely confuse someone. That said, do people
> expect a programmatic API to do de/encode? I can't think of a web
> framework that does that (surely servlets don't handle escaping in
> servlet-mapping?).
Absolutely they do, at the equivalent point--a request parameter in a
servlet is available to me as "hello world" but in form method=get actually
comes in as "param=hello%20world"
Again, the framework has already *parsed* the URI, it is the
post-parse-pre-dispatch step we're talking about:
@HttpMethod(GET)
public void doGet(@URIParam("name") String name) {
//...
}
Afaics we have already abstracted away any semblance of working with or
"like" HTTP at this point, it's all in Java now and the @URIParam annotation
is simply a high-level convenience to access the URI. It is completely
feasible for programmers who are unhappy with the high-level abstraction to
do something like:
@HttpMethod(GET)
public void doGet(HttpRequest req) {
myDecodeLogic(req.getUri());
//etc.
}
However, Mark's point is well taken in that I can see how this behavior is
*apparently* inconsistent and more apparently (!) so across specs. Is there
some way we can provide a utility that makes it more explicit or extend the
current one to be more lucid?
@DecodedParam(...)
ParamUtils.decode(...)
...?
Dhanji.