On 4/11/07, Jerome Louvel <jerome.louvel_at_noelios.com> wrote:
>
>
> > Why not have both on the Representation<T> interface?
> > getContentLocation() and getRedirectLocation().
>
> 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().
> 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)?
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.
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.