[Moin-user] Changing default behavior on downloads.

Paul Moore p.f.moore at gmail.com
Tue Sep 30 06:31:12 EDT 2008

2008/9/30 Thomas Waldmann <tw-public at gmx.de>:
> I completely understand the point that you are making.
> But we should try to solve that in another way (suggestions welcome).
> Problem is:
> Even if we introduce some way to configure the default "do=" value (that
> would be possible, of course) for now, that would just delay the problem
> to a later moin release (2.0 or so).
> That is because attachments will be items on their own then (like pages
> will be also items of just some specific mimetype).
> AttachFile action will go away and will just be replaced by normal item
> rendering.
> Links to files will be just links to items (same as links to pages) and
> we will either provide a markup converter converting attachment:foo
> to /foo or emulation code for "attachment:".
> At the place where the link is rendered there will be no cheap way to
> know the target item mimetype (one would have to open target item
> metadata for all links to know the mimetype, that would be slow), thus
> link generation must be the same for page and file items.
> If you link to a page item, it is using "show" action [default],
> therefore it has to be the same for files (note that the concrete url
> param "action=show" or "do=view" (or just nothing because it is default)
> does not matter, the behaviour is the point).
> Also, even if we would find out the mimetype of the link target, what
> shall we do with it? What should be done depends on the capability of
> the user agent and on the intent of the user, e.g.:
> If it is a jpeg image - does the use want to download that foto or just
> look at it?
> If it is a pdf, does the user want to download it or render it within
> the browser - does he have a browser plugin?
> If it is some unified diff, just look at it or download it?
> Because of these undecidable issues (as far as moin is concerned, the
> user usually knows what he/she wants), I am rather thinking that we
> should not try to do magic depending on the target item mimetype, but
> just link to the "show" rendering (that rendering will also offer some
> option to download it).
> Well, and this is exactly what recent moin releases do.
> What I would like to have is a much more pretty "show rendering" than
> the rather ugly thing we have now. So help with layout and CSS is also
> welcome (CSS hates me :).
> Not sure though if the best time to improve this is now - maybe rather
> AFTER we merge the storage refactoring into main repo in a few months.
> The "show" rendering could also show some metadata of the item and maybe
> its recent history. For images, it could be some scaled rendering.

Apologies for coming in part way through this, but I have the same
issue as Rick, in that I have an internal Wiki where click-to-download
attachments are relatively common, and people want to keep that.

I am not 100% sure I follow your proposal here, but it seems obvious
to me that the choice between rendering inline, or linking to an
object, have to be different things. Whether a JPG is shown in the
page flow, or as a link to a JPG file, are different intents, and need
to be recognised in the markup (like <img> and <a href> in HTML).

So I assume we are limiting ourselves to links (which render as <a
href>). OK, so I click on that link. At that point, the target is
being fetched (that's the point!) and so checking its mimetype and
transmitting the file and its mimetype to the browser are

This seems so simple to me that I'm sure I have missed something. Can
you direct me to a document explaining how attachment links are
expected to work in 2.0?


More information about the Moin-user mailing list