Dynamically serving contents for an iFrame

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Dynamically serving contents for an iFrame

jtuchel
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.


I see two areas which could be wrong:

a) The way the callback method changes the response to server the images
/ pdfs
   I found some old messages on this list
(http://forum.world.st/Usage-of-WAIframeTag-tp88208.html) that use
returnResponse: , which is deprecated and even is not present in Pharo 3
any more.

b) the way I try to update the iframe by changing its src attribute

     If I use set a static url in the .attr("src", someStaticUrl), the
new contents are shown as expected, so I guess the problem lies in the
callback somewhere...

Any ideas?


Joachim



--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Dynamically serving contents for an iFrame

Philippe Marschall
On Tue, May 12, 2015 at 4:25 PM, [hidden email]
<[hidden email]> 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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Dynamically serving contents for an iFrame

jtuchel
H iPhilippe,

once again you nailed it.

At first it didn't work when I did this:


     self requestContext respond: [:resp |
         resp
             inlineWithFileName: aWAFile fileName;
             document: aWAFile contents mimeType: aWAFile contentType
fileName: aWAFile fileName;
             doNotCache]

Then I tried:

     self requestContext respond: [:resp |
         resp
             inlineWithFileName: aWAFile fileName;
             document: aWAFile contents mimeType: aWAFile contentType;
             doNotCache]


And it does work now.


In the first situation the Content-Disposition header was always
"attachment; filename=".
I'm not sure if that is a bug or not. Just wanted to let you know.

Again: Thank you very much!!!

Maybe we can have some Vino in Brescia? At least one glass is on me!


Joachim





Am 12.05.15 um 19:27 schrieb Philippe Marschall:

> On Tue, May 12, 2015 at 4:25 PM, [hidden email]
> <[hidden email]> 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
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>


--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Dynamically serving contents for an iFrame

Philippe Marschall
On Tue, May 12, 2015 at 9:07 PM, [hidden email]
<[hidden email]> wrote:

> H iPhilippe,
>
> once again you nailed it.
>
> At first it didn't work when I did this:
>
>
>     self requestContext respond: [:resp |
>         resp
>             inlineWithFileName: aWAFile fileName;
>             document: aWAFile contents mimeType: aWAFile contentType
> fileName: aWAFile fileName;
>             doNotCache]
>
> Then I tried:
>
>     self requestContext respond: [:resp |
>         resp
>             inlineWithFileName: aWAFile fileName;
>             document: aWAFile contents mimeType: aWAFile contentType;
>             doNotCache]
>
>
> And it does work now.
>
>
> In the first situation the Content-Disposition header was always
> "attachment; filename=".
> I'm not sure if that is a bug or not. Just wanted to let you know.

This is a feature. "attachment" causes the download dialog to open,
"inline" just displays it. #fileName: triggers "attachement;
filename=".

> Again: Thank you very much!!!
>
> Maybe we can have some Vino in Brescia? At least one glass is on me!

:-)

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside