Sorry I haven't made this change yet. I've been going back and forth over it in my head and can't make up my mind as to whether the controller or the transform should have priority over setting headers. I can see both sides: it makes sense for the controller to have final control because this is generally what the end user is writing and it makes it more customizable for them, but then again it seems like sort of a domain-crossing issue.
Theoretically the controller shouldn't know or care what the views and transforms or doing--all it is responsible for is preparing a model and passing it on. Imagine a case where you have a view that makes a pdf with opt-fop, then you decide sometime down the road you want to zip the pdf instead of sending it straight to the browser--you could just make an opt-zip transform, add it to the transform chain, and it would be responsible for setting the content-disposition header to application/zip (or whatever it is) and you would be set--no need to change the controller. If the controller has final say over the content-disposition header, you would need to add opt-zip and change the controller. So who has final say? I really can't make up my mind, though I must admit after giving it more thought I am leaning towards the transform node. If you don't set the filename attribute on the transform, the transform won't do anything with the headers and your controller can set that header, but if you do add that attribute, maybe the transform should override the controller. Anyone else have any additional thoughts? --jim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Moulton Sent: Monday, July 22, 2002 6:21 PM To: [EMAIL PROTECTED] Subject: Re: [Mav-user] Opt-fop and Content-Disposition header Jim, Thanks for the quick response, I should of realized that I can set the header from my controllers. However this made me think about times when there is no controller present. For cases like these, I think the aformentioned solution of adding the content-type and filename attributes is perfect. I also agree that if the controller sets the content-disposition header then that should take presedent over anything in the mav config. -Mike On 7/22/02 9:04 AM, "jim moore" <[EMAIL PROTECTED]> wrote: > Right now it is possible to set the content-dispostion header directly from > the controller. You can get the Response from the ControllerContext and then > just call response.setHeader() on it. Even when the repsonse is wrapped, the > setHeader() calls are passed through to the real underlying response. I > think this is pretty straightforward and intuitive, so I don't think there > is really a need to change it (though I am open to hearing other thoughts on > this). > > If people still think its worthwhile to have this defined in maverick.xml, I > have a couple of ideas. We could add two optional attributes to the fop > transform node: filename and content-type. Filename is pretty > self-explanatory. Content-type would take either "inline" (which would be > the default) and "attachment". Together these two would produce a > content-disposition header something like: > > Content-disposition: attachment; filename=myfile.pdf > > So you would have a node that looked something like: > > <transform type="fop" output="pdf" content-type="attachment" > filename="myfile.pdf"/> > > Even if we add this, I still think the controller should take precedence. > Since it runs before the transform, opt-fop could check for the presence of > the content-disposition header. It would only set it if it didn't find it. > Does this make sense? > > What are everyone's thoughts? Do you think setting the header from the > controller is sufficient, or should we add these params to the transform > node? > > --jim ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
