[ 
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:
   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]

Reply via email to