#4 — index_html vs. download in conjuction with pdf anchors
| State | Resolved |
|---|---|
| Version: | 1.0 |
| Area | Functionality |
| Issue type | Patch |
| Severity | Low |
| Submitted by | Alexander Pilz |
| Submitted on | Sep 11, 2008 |
| Responsible | Andreas Zeidler |
| Target release: | 1.0 |
Last modified on
Nov 06, 2009
by
Andreas Zeidler
In current trunk (rev22526) of content.py the index_html method always returns the results of field.download(..) for file content. As a result, files are never displayed "inline" because the Content-disposition gets set to "attachement".
def index_html(self, REQUEST, RESPONSE):
""" download the file inline or as an attachment """
field = self.getPrimaryField()
if IATBlobImage.providedBy(self):
return field.index_html(self, REQUEST, RESPONSE)
else:
return field.download(self, REQUEST, RESPONSE)
If inline display is wanted for some reason (e.g. pdf anchors work only if pdf is displayed inline), it works with ATContentType File, but doesn't work with ATBlob.
ATContentTypes (version shipped with Plone 3.1) handle this in content/file.py line 107ff by checking, if the content_type is in a list of "inlineMimetypes". If so, it returns index_html(..), download(..) otherwise.
Would it be possible to keep that feature? The following patch re-adds the behavior:
from Products.ATContentTypes.content.file import ATFile
...
def index_html(self, REQUEST, RESPONSE):
""" download the file inline """
field = self.getPrimaryField()
if field.getContentType(self) in ATFile.inlineMimetypes:
# return the PDF and Office file formats inline
return field.index_html(self, REQUEST, RESPONSE)
return field.download(self, REQUEST, RESPONSE)
def index_html(self, REQUEST, RESPONSE):
""" download the file inline or as an attachment """
field = self.getPrimaryField()
if IATBlobImage.providedBy(self):
return field.index_html(self, REQUEST, RESPONSE)
else:
return field.download(self, REQUEST, RESPONSE)
If inline display is wanted for some reason (e.g. pdf anchors work only if pdf is displayed inline), it works with ATContentType File, but doesn't work with ATBlob.
ATContentTypes (version shipped with Plone 3.1) handle this in content/file.py line 107ff by checking, if the content_type is in a list of "inlineMimetypes". If so, it returns index_html(..), download(..) otherwise.
Would it be possible to keep that feature? The following patch re-adds the behavior:
from Products.ATContentTypes.content.file import ATFile
...
def index_html(self, REQUEST, RESPONSE):
""" download the file inline """
field = self.getPrimaryField()
if field.getContentType(self) in ATFile.inlineMimetypes:
# return the PDF and Office file formats inline
return field.index_html(self, REQUEST, RESPONSE)
return field.download(self, REQUEST, RESPONSE)
Added byAndreas ZeidleronSep 23, 2008 10:24 AM
yes, that was actually on my todo-list, but apparently got lost somewhere. thanks for the reminder (and patch :))!
Issue state:
unconfirmed
→
open
Responsible manager:
(UNASSIGNED)
→
witsch
andi
Added byAlexander PilzonDec 19, 2008 12:07 PM
We just found another problem with the content disposition. When we use a flash blob file, it is obviously not in the list of inlineMimetypes, so it will be offered as download. This confuses at least internet explorer and safari which will not display the flash. Firefox seems to work this around somehow.
This leads me to the thought why index_html ever should call field.download instead of always using field.index_html and let the browser decide what to do with the content? The fact that there is something like ATFile.inlineMimetypes indicates that someone had a good reason to handle it this way.
Added byAndreas ZeidleronMay 08, 2009 03:22 PM
up'ing priority as this will have to be resolved for the first release candidate...
Severity:
Medium
→
Important
Target release:
None
→
1.0
Added byAlexander PilzonMay 12, 2009 01:19 PM
I would be happy to assist in fixing that. My view is that it should always use field.index_html. I am just unsure how to investigate on the reasons for perhaps using field.download.If there is anything I can do to help, let me know :)
Added byAndreas ZeidleronMay 12, 2009 09:39 PM
thanks for the offer! i'll probably get back to it soon... :) however, for now i'll try to focus getting out another beta first (mainly because of http://plone.org/products/plone.app.blob/issues/7).but i will check you added the `inlineMimetypes` code originally in order to find out about the motivation. i suppose it was tiran, though, which might make this harder. we'll see...
Added byDavid GlickonJul 14, 2009 03:14 AM
By the way, you get bonus points if you end up making the list of inlineMimetypes configurable through the web. ;)
Added byAndreas ZeidleronJul 14, 2009 09:13 AM
sure, hardcoding is so 80s... otoh, persistence ftw? %)anyway, we should first find out why the list was added in the first place or if we can perhaps get away with alex's suggestion (always using `index_html` and letting the browser decide). i'll dig through svn, but kinda expect tiran added it — perhaps hanno knows something...
Added byMartin AspelionSep 04, 2009 04:22 AM
I've just added this patch (slightly modified to accept ATImage) due to an urgent client requirement. :)Issue state:
Confirmed
→
In progress
Leaving the ticket open because we probably want a test and we probably want it to be configurable in the end. Just not right now. :)
Added byAndreas ZeidleronSep 30, 2009 12:03 PM
for reference, the fix was in http://dev.plone.org/plone/changeset/29550Severity:
Important
→
Low
i'll leave the ticket open as it still needs a test and potentially a way of making the list configurable as martin correctly pointed out... :)
Added byAndreas ZeidleronNov 06, 2009 02:50 PM
tests added in http://dev.plone.org/plone/changeset/31151, ticket done... :)
Issue state:
In progress
→
Resolved
No responses can be added.
If you can, please log in before submitting a reaction.