[Moin-user] moin 1.6 attachments behaviour

[Thomas Waldmann]

Hi Neal,

> Looks like the bug where my attachments don't directly cause download
> (unless written as 
> [[attachment:bla.csv|blah.cs|&do=get]]
> )
> is not fixed in 1.6.2

That's intended, not a bug.

Pages and attachments will be unified to "items with a mimetype".

E.g. a wiki page could be a item of type text/x-moin-wiki that contains 
some raw wiki markup.

If you link to that page (that item) and click on the link, you will get 
a rendered view of that item (currently called "action=show" [default]).

Note: It won't download the raw wiki markup into your browser or onto 
your hard disk.

The same is true for attachments now: by default, you get a "rendered" 
view of them if you just link to them and follow the link, not a direct 
download of the item.

Currently that view is rather simple (just the download link + a view of 
the item below), but for the future I see some more enhanced renderers, 
showing some metadata in this rendered view, so it will be more useful 
than now with just the old AttachFile code.

Also, that [[attachment:foo.txt]] markup will get (automatically) 
converted to just [[/foo.txt]] (a sub-item of the current one, like 
attachments currently being stored logically below a page) as soon as we 
have the new storage backend that is capable of storing mimetype objects.

As you see, there is no "attachment:" any more after that change, so we 
won't be easily able to create a different link.

Of course you still can do something like [[target|label|special 
params]] then, there is just no "attachment magic" any more.

A side effect of this change will be that "attachment file names" move 
to PATH_INFO, e.g. http://server/WikiPage/file.png and this will fix the 
annoyance of non-ascii character handling (we can't currently do it so 
that it works for any browser). We maybe will have this URL change in 
advance as it is not dependent on the backend change (but it makes even 
more sense WITH it).

Cheers,

Thomas