[Moin-user] Changing default behavior on downloads.

[Thomas Waldmann]

> Thinking a little more on this, if we have normal and inline link
> types, and the general intention is for normal links to link to a
> "rendered" page, then I would argue strongly that a "raw" link type is
> needed, which does deliver the item data without rendering.

Assuming we do that and you use that markup to put 1 link to raw
download of some item on some page and the item is not linked from
anywhere else (could easily happen), how do you get to the UI of that
item?

I guess the only way would be rather uncomfortable via TitleIndex
(assuming we list items of all mimetypes there).

> 2. A raw link could be implemented as a macro. But so could the "rendered" case.
> 3. Having to use a macro for what is to me, the normal case, seems
> backward. But that's a preference issue.

Sure :) As I told some times already, it is not quite just preference.
There is a real problem for creating an UI with raw links.

> types should have a specific rendering action. (Question: for how many
> mime types do you see core Moin having custom rendering actions?

Well, that depends a bit on time and on how much people will help sooner
or later. That stuff will be pluggable, so I expect quite some people
will write the renderers they need personally (sure, you might write
none as you don't need any :).

For moin core development, I see those renderers will be developped
first:

 * all stuff that deals with some sort of text that we already have in
MoinMoin/parsers/* see
http://hg.moinmo.in/moin/1.8/file/tip/MoinMoin/parser/

  * note: rst and docbook long term future might depends on somebody
maintaining them (this is a general issue, not strictly related to this
discussion)

 * next thing will be a default fallback handler for */* or
application/octet-stream mimetype, just showing the UI with upload,
download, history and maybe some other metadata

This will get us going and will be a usable thing. The next easy step
is:

 * some image/* handler with scaling including some JPEG/ITCP metadata
(code already exists at another place)

 * application/zip (show zip directory, install moin packages - code
exists in AttachFile)

 * maybe a handler for twikidraw stuff 

Sooner or later:
 * PDF (there are browser plugins that render PDF within the browser -
if they stop to be total crap at some time in the future, that would be
nice)
 * stuff that is currently handled by EmbedObject (?)
 * audio/video multimedia metadata 
 * OpenOffice.org metadata (?)
 * plugins done by moin community for whatever they need
 
> assume the default rendering action would be some sort of attachment
> manager page?)

Rather a "item" UI that does everything that is generic for a single
item: history, delete, download, upload, show basic metadata.

If we can make the UI code exploit inheritance, that maybe would be the
base class with the more specific renderers just adding what they offer
additionally.

> Looking at URLs for a moment, I would say there should be a request
> parameter to force raw or "rendered" (I dislike this term, I'd rather
> say "custom page", but I'll stick with "rendered" as it's your term)
> behaviour. So
> 
>     http://server/...../MyPage?format=raw       -  would always
> generate raw data served with the item's mime type)
>     http://server/...../MyPage?format=rendered  - would generate a
> custom display page [1]
> 
> The unadorned URL http://server/...../MyPage would generate the
> rendered form for text/x-moin-wiki (and maybe other markup types), and
> the raw form for other mime types.

Sure, that's the idea. We already have that, it just needs to be unified
in a sane way (action=show [default] / action=raw vs. do=view / do = get
for AttachFile).

> I find it relevant that there are only two possible options that can
> apply to *all* mime types. These are "raw" and a download manager
> page.

For links yes, that is the kind of links we need.

The UI on the "rendered" display has more stuff, though: history,
delete, download, upload, show basic metadata.

> The "rendered" action can only ever apply to some mime types
> (abeit one of these is markup, which is by far the most common type).

No, above UI/rendering applies to all mimetypes. Some mimetypes will
offer more, but no mimetype will offer less.

Note that "rendering" an item does not necessarily mean that you see the
item data's content somehow. It could be also just rendering some of its
metadata and some UI functions.

> Maybe there should be *three* options - ?render=raw, ?render=manager
> and ?render=formatted,

Ugh, that would make linking even more complicated than it already is.
|-)

> with the default varying by mime type,

As I said, if link generation depends on target mimetype, it might get
very slow as there can be many links on a page...

> without ?render=, the user gets an "appropriate" result. On that
> basis, the discussion centres round what counts as "appropriate"

That's only the 2nd half of the problem.

> maybe just exposing that decision in the wiki config is sufficient,
> then I would use raw and formatted only with raw as default, and you
> would use formatted far more often, and manager as the default. This
> comes full circle to Rick's suggestion that we allow ?do=get vs
> ?do=view to be configurable,

As I already explained, that does not work that way.