You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org> on 2005/09/09 14:34:36 UTC
[jira] Assigned: (TAPESTRY-569) WebResponse does not expose a way to set headers
[ http://issues.apache.org/jira/browse/TAPESTRY-569?page=all ]
Howard M. Lewis Ship reassigned TAPESTRY-569:
---------------------------------------------
Assign To: Howard M. Lewis Ship
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org