[Moin-user] attachment changes and the future

[Thomas Waldmann]

> 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' ...).