Hi Dhanji,
> Because you can issue a redirection without returning an output
> representation.
>
> Right, this is why I doubled back on my suggestion and was
> wondering if Representation<T> is the correct artifact for
> getRedirectLocation().
Ok, also agree that Representation<T> should contain a "contentLocation" or
"redirectLocation" property. I suggest that this is added as a property of a
new Context (or RWSContext) class (unifying existing HttpContext,
HttpRequestContext and HttpResponseContext interfaces as well as the
HttpResponse class).
> > This seems to indicate that the response content is to be
> > ignored, which makes me wonder if Representation<T> is the
> > correct artifact to be supporting "Location." Just
> wondering...
>
> Even if I think redirects won't have output
> representation in most cases,
> I'm not sure that the spec prevents that.
>
> What would the alternative be? A second wrapper? or a
> derivative of Representation<T> (ugh)?
The suggested Context class with a "redirectRef" property or similar should
do it.
> In the current api--it looks like this is done via the
> HttpResponse object, added as a keyed string to the header
> map. Im not hot on this approach either.
Agreed. I also suggested to have shortcut methods like:
// Redirection methods
void redirectPermanent(uri);
void redirectSeeOther(uri);
void redirectTemporary(uri);
They would set both the "redirectRef" and the status at the same time.
> In one of our web frameworks, we have an event handler on a
> page (which handles hyperlink clicks for instance) that
> returns either the target page (equivalent of content) or a
> client-side redirect (interpreted and executed as
> response.sendRedirect(..) by the framework--i.e. the
> "location" header). In this case, I use a transparent wrapper
> with a static utility:
>
> @OnEvent
> public Object nextPage() {
> return NextPage; //standard case
> }
>
>
> @OnEvent
> public Object nextPage() {
> return Redirect.to("http://...."); //redirect case
> }
>
>
> The downsides here are the use of the static utility and the
> ugly (Object) return type. But it is certainly superior to
> throwing an exception.
I'm not too fond either of the idea to use exceptions to express
redirections. Hopefully the Context class, with potentially some
complimentary redirection annotations will be a better solution.
Best regards,
Jerome