[Seaside] Dynamically serving contents for an iFrame

[Philippe Marschall]

On Tue, May 12, 2015 at 4:25 PM, jtuchel at objektfabrik.de
<jtuchel at objektfabrik.de> wrote:
> Hi there,
>
> I am having trouble changing the contents of an iFrame with contents are
> generated "dynamically".
>
> What I want the page to do is change the contents of an iFrame when the user
> clicks a link. There is an unorderedList of links that each represent a
> document that can be displayed in the iFrame. The use of iFrames seems to be
> the only way to display PDF documents inline in the document.
>
> Here is how far I got after quite some fiddling and trial&error:
>
> first, in my renderContentOn: I bind an onclick handler to each link that
> updates the src attribute of the iFrame:
>
>     fileCallback :=
>
>         html callbacks store: (WAActionCallback on: [self deliverFile]).
>
>     html document addLoadScript: (
>
>         '$(".documentLink").each(function(idx)
> {$(this).click(function(event){
>
>                 $(".documentView iFrame").attr("src", "%1" + "&file=" +
> $(this).text());
>
>                 event.preventDefault();})})'
>
>             bindWith: (html actionUrl withField: fileCallback))
>
>
>
> The callback method looks like this:
>
> deliverFile
>
>     |  dateiName fields req aWAFile response document |
>
>     req := self requestContext request.
>
>     fields := req fields.
>
>     dateiName := (fields at: 'file').
>
>     aWAFile := "stuff that fetches the WAFile from a DB"
>
>
>     self requestContext respond: [:resp |
>
>         resp
>
>             document: aWAFile contents mimeType: aWAFile contentType
> fileName: aWAFile fileName]
>
>
> This almost works.
>
> When I click on the link, the src attribute of the iframe is being updated
> and the callback method is invoked. The file is served and is exactly the
> PDF document I expect.
>
> BUT: instead of the iframe updating with the contents, the web browser asks
> me whether I want to save the file or open it with an some local
> application. That is of course not the expected behavior.

Have you tried the following HTTP header

Content-Disposition: inline

Cheers
Philippe