> This is the same issue we face since updating to 1.6. We have a > number of pages where we have .doc and .xls attachments. The desired > behavior would be to click the link and have it start downloading, as > the previous versions behaved and how most users come to expect > attachment links to work (not to be taken to a "cryptic" (as users > word, not mine) page with complaining about the "chosen formatter").
The error msg is a bug. We have different levels of embedding support and for that mimetype it seems to be erroneous. > Any way to revert this behavior? [[attachment:xxx.csv|label|&do=get]] in 1.6.1 overrides the default do=view argument. I hope we can further improve the looks of the default target page shown, so that the download link there is rendered a bit more visible, and also improve the implementation in other ways. But please note that this change in default behaviour of moin was a strategic one: At some point in the hopefully not too distant future, we will have a new backend, able to store revisioned items of arbitrary mimetype (wiki-text pages, misc. mimetype files) and the mimetype and other stuff will get stored into separate meta data. Most of the current ugly AttachFile code will then be killed and replaced by generic code. A consequence of this will be that the default action will apply for wiki-text items as well as for other items. The default action is "show", expected to make a rendered view of the item (in case of wiki-text it is parsed and rendered to the usual nice html output, in case of another mimetype, e.g. pdf, all moin can do to "render" it is to embed it using an <object> tag, for some text mimetypes, we can use our parsers to render them). In any case, "show" will not trigger a download of the raw item, that will be another (non-default) action and that will also be available to download wiki-text items. In future, when items have meta data available, the "show" action of some non-text item could also show some meta data, like file size, file mimetype, file comment, etc. Pictures could have some sort of frame around them and that metadata right besides it. As another consequence of this change, the stuff now called "attachment link" [[attachment:foo.txt|Foo Text]] will then be a normal (sub-)item link [[/foo.txt|Foo text sub-item]]. A small step in that direction is also already present in 1.6 by requiring double square brackets around attachments so we will just have to remove "attachment:" (and add a / for the usual case) in the wiki text for the future change. I am currently considering doing another small step in that direction, that even fixes a current problem with non-ascii filenames for non-firefox browsers: to move the attachment filename (currently in the query string as &target=foo.txt) to the path info, so it looks like http://server/PageName/foo.txt?action=AttachFile&do=get for example. It seems like most browsers handle non-ASCII filenames happily if they appear as last path segment. That method of putting the filename into the path of the url is exactly what that future change will also do naturally. If it is just a mimetype sub-item then, of course the url will also just look like a sub-page url looks now. Of course ?action=AttachFile&do=get will get replaced by something simpler then, e.g. ?action=save (or 'get' or 'raw' ...). ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Moin-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/moin-user
