tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <tapestry-...@jakarta.apache.org>
Subject [jira] Commented: (TAPESTRY-569) WebResponse does not expose a way to set headers
Date Mon, 12 Sep 2005 00:45:36 GMT
    [ http://issues.apache.org/jira/browse/TAPESTRY-569?page=comments#action_12323204 ] 

Howard M. Lewis Ship commented on TAPESTRY-569:

I've added setHeader() and setIntHeader().  I'm conferring with Mind Bridge about the last
issue (getMimeType() vs. toString() ).

> WebResponse does not expose a way to set headers
> ------------------------------------------------
>          Key: TAPESTRY-569
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-569
>      Project: Tapestry
>         Type: Bug
>   Components: Framework
>     Versions: 4.0
>     Reporter: Cherry Development
>     Assignee: Howard M. Lewis Ship

> I'm trying to puzzle over this one...
> The HttpServletResponse object has been made completely inaccessible through any non-depricated
part of the Tapestry API.  Instead we have the WebResponse object.  The WebResponse has a
convenience method for setting date headers on it, but absolutely no way to set headers that
are NOT dates.  Why would we be given access to set headers that should be formatted as dates,
but not any others?
> I've been searching on the forums and mailing list and I've seen several requests for
this sort of functionality.  So far, it seems the only supported way of doing this in Tapestry
4 is to create a new hivemind service so that it can access the tapestry.globals.HttpServletResponse
hivemind service.  Now, suddenly, we're being dropped into a much lower-level API and one
I'm completely unfamiliar with, Hivemind, just so that I can stream a file to the user, which
requires me to be able to set arbitrary headers.  It seems that if this is a conscious decision,
that would mean that the scope of what Tapestry allows the developer to do, without having
to resort to a lower-level API (which is beyond the scope of Hibernate itself) no longer includes
being able to stream files.  I've also read that one of Howard's stated goals in using IoC
is to expose the developer to fewer and fewer API's.  Now, I'm finding that I'm being forced
to be exposed to ANOTHER API, just to do something that I was able to take for granted in
Tapestry 3.0.  It's possible that a dedicated, built-in Tapestry service that represents a
higher-level interface for being able to send files to a user might be more appropriate to
the long-term goals of the project, so long as it hides the details of Hivemind.  I am classifying
this as a Major priority bug, since it represents a regression of functionality in the scope
of the Tapestry projcet,  without a simple workaround.  In the meantime, I'll have to use
the deprecated RequestContext to get a handle to the raw HttpServletResponse object.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message