[ 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
