> Apologies for coming in part way through this, but I have the same
> issue as Rick,
I guess many people have. So I hope someone finds a good way to handle
it - one that we can also use for future moin.
> 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.
Oh, we have that:
[[foo]] or [[attachment:foo]] links to a rendering of foo.
{{foo}} or {{attachment:foo}} tries to render it in-place
("transclude").
But the problem you all have is that you want to link (thus, it is the
upper syntax), but not to the rendering URL of the item, but to the raw
download URL of it (so a modifier is needed, that is this "&do=get"
thing).
> So I assume we are limiting ourselves to links (which render as <a
> href>).
Yes.
> 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
> straightforward.
You can't do that in general or a clicking a link to a wiki page
(mimetype will be something like text/x-moin-wiki) will trigger its
download as a text file (definitely not what you usually want, you want
a rendering of it :).
> 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?
I described the essential part in my last post here.
It is just that we will have only one basic type of thing in future
moin: a item.
That item will have revisions.
Revisions have data and metadata.
Metadata includes stuff like editor, acls, mimetype, etc.
Data is just the raw data (e.g. a pdf, png or text of a wiki page).
Rendering of links to items should not depend on target mimetype (see
last post), the link by default links to a rendering of the item (how
exactly a item is rendered after you followed that link is of course
dependant on the mimetype of it, text/x-moin-wiki will be rendered as
usual, image/* might show some scaled view, application/zip might
display a listing of zip file directory, application/foo-bar might just
show some download button and some stuff from the metadata/history).
Note: that's just a braindump. We already have the storage code, but the
user interface has yet to get coded (currently there is just some
compatibility code and AttachFile is not removed yet).
You can find some more details on the wiki, search for ChristopherDenter
or Storage Refactoring.
The new storage code is there: http://hg.moinmo.in/moin/1.8-storage/ (do
ignore the "1.8" in it, that just means that the code is based on 1.8,
not that it will be released as 1.8).
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Moin-user mailing list
Moin-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/moin-user
