Microsoft's IE uses non-standard techniques to determine the type of a file. To bend it to our will, we've found that the generation program needs to be named with a '.pdf' extension. This, of course, makes it a bit difficult to embed in a dtml call. (As a form action, it works...) What I have is an external method that manages the interfact to HTMLDOC by building a html file, sending it to HTMLDOC, gathering the result, and returning it with appropriate headers to the client. If I use a form to set up parameters to the external method and <form action="doit.pdf()"> .. </form> it works fine. Of course, <dtml-varB expr="doit.pdf()"> doesn't.
--On Montag, 7. Juli 2003 10:31 Uhr -0700 Dennis Allison <allison@sumeru.stanford.EDU> wrote:
Microsoft's IE uses non-standard techniques to determine the type of a file. To bend it to our will, we've found that the generation program needs to be named with a '.pdf' extension. This, of course, makes it a bit difficult to embed in a dtml call. (As a form action, it works...)
What I have is an external method that manages the interfact to HTMLDOC by building a html file, sending it to HTMLDOC, gathering the result, and returning it with appropriate headers to the client.
If I use a form to set up parameters to the external method and
<form action="doit.pdf()">
doit.pdf() as action parameter looks extremely odd. This will never work. -aj
Oops... You're right. The working version uses <form action="doit.pdf"> where doit.pdf is an External Procedure that does the pdf creation. On Mon, 7 Jul 2003, Andreas Jung wrote:
--On Montag, 7. Juli 2003 10:31 Uhr -0700 Dennis Allison <allison@sumeru.stanford.EDU> wrote:
Microsoft's IE uses non-standard techniques to determine the type of a file. To bend it to our will, we've found that the generation program needs to be named with a '.pdf' extension. This, of course, makes it a bit difficult to embed in a dtml call. (As a form action, it works...)
What I have is an external method that manages the interfact to HTMLDOC by building a html file, sending it to HTMLDOC, gathering the result, and returning it with appropriate headers to the client.
If I use a form to set up parameters to the external method and
<form action="doit.pdf()">
doit.pdf() as action parameter looks extremely odd. This will never work.
-aj
If I use a form to set up parameters to the external method and
<form action="doit.pdf()"> .. </form>
it works fine. Of course,
<dtml-var expr="doit.pdf()">
doesn't.
One of the problems that let to the "path syntax" of TALES. As such, this is one of the old, bad, Zopisms I'm about to explain. If you want to call something with dots in it in Python syntax, you have to look it up in the namespace dictionary. The namespace dictionary is mysteriously named '_'. No, that's not a crappy emoticon, it's an underscore, in quotes (which is the STX code markup.) And you have to use strings to look up a name in a dictionary. So the lookup looks like:: _['nameofthing'] Also available is 'getitem' on the namespace variable, if that seems less insane:: _.getitem('nomeofthing') So your code, in DTML, will look like:: <dtml-var expr="_['doit.pdf']"> --jcc
Thanks. I'd surpressed that idiom :-) but I think it'll do the job. -d On Mon, 7 Jul 2003, J Cameron Cooper wrote:
If I use a form to set up parameters to the external method and
<form action="doit.pdf()"> .. </form>
it works fine. Of course,
<dtml-var expr="doit.pdf()">
doesn't.
One of the problems that let to the "path syntax" of TALES. As such, this is one of the old, bad, Zopisms I'm about to explain.
If you want to call something with dots in it in Python syntax, you have to look it up in the namespace dictionary. The namespace dictionary is mysteriously named '_'. No, that's not a crappy emoticon, it's an underscore, in quotes (which is the STX code markup.) And you have to use strings to look up a name in a dictionary. So the lookup looks like::
_['nameofthing']
Also available is 'getitem' on the namespace variable, if that seems less insane::
_.getitem('nomeofthing')
So your code, in DTML, will look like::
<dtml-var expr="_['doit.pdf']">
--jcc
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Dennis Allison wrote:
Microsoft's IE uses non-standard techniques to determine the type of a file. To bend it to our will, we've found that the generation program needs to be named with a '.pdf' extension. This, of course, makes it a bit difficult to embed in a dtml call. (As a form action, it works...)
What I have is an external method that manages the interfact to HTMLDOC by building a html file, sending it to HTMLDOC, gathering the result, and returning it with appropriate headers to the client.
If I use a form to set up parameters to the external method and
<form action="doit.pdf()"> .. </form>
it works fine. Of course,
<dtml-varB expr="doit.pdf()">
doesn't.
Can't you just have the External Method use calls to setHeader to set the Content-type of the returned document. I don't test much with IE, but surely it will obey the Content-type header? (Additionally, you can use "Content-dispostion" to set the filename to beautify that a bit also). JZ
Yes, I set them properly. Unfortunately IE ignores them <sigh!>. On Mon, 7 Jul 2003, John Ziniti wrote:
Dennis Allison wrote:
Microsoft's IE uses non-standard techniques to determine the type of a file. To bend it to our will, we've found that the generation program needs to be named with a '.pdf' extension. This, of course, makes it a bit difficult to embed in a dtml call. (As a form action, it works...)
What I have is an external method that manages the interfact to HTMLDOC by building a html file, sending it to HTMLDOC, gathering the result, and returning it with appropriate headers to the client.
If I use a form to set up parameters to the external method and
<form action="doit.pdf()"> .. </form>
it works fine. Of course,
<dtml-varB expr="doit.pdf()">
doesn't.
Can't you just have the External Method use calls to setHeader to set the Content-type of the returned document. I don't test much with IE, but surely it will obey the Content-type header? (Additionally, you can use "Content-dispostion" to set the filename to beautify that a bit also).
JZ
On Mon, Jul 07 2003 (10:55:48 -0700), Dennis Allison wrote:
Yes, I set them properly. Unfortunately IE ignores them <sigh!>.
Some time ago I've had similar problems with MSIE 6 downloading a dynamically created Excel document. Eventually, I've been able to solve it as follows. Unfortunately, it's not Zope but HTML::Mason, but you might be able to adapt it to meed your demands ;-) The component is called "dumpExcel.mhtml", so it's not necessary to give it an .xls extension. # Clear Mason buffer and HTTP headers. $m->clear_buffer(); $r->headers_out->clear(); # Set the content type and filename. $r->content_type("application/vnd.ms-excel"); $r->header_out("Content-disposition", 'inline;filename="Data.xls"'); # Internet Explorer 6 SP1 blows up when it encounters an "Expires" # HTTP header with a past date. The content of "Expires" is set to # time() - 1 hour when calling no_cache(1). Disable this behaviour. $r->no_cache(0); # Send the Response headers (Doh). $r->send_http_header(); # Write the response body ... HTH, Toni
participants (5)
-
Andreas Jung -
Dennis Allison -
J Cameron Cooper -
John Ziniti -
Toni Andjelkovic