2008/9/30 Thomas Waldmann <[EMAIL PROTECTED]>: > 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 straightforward. 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? Paul. ------------------------------------------------------------------------- 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
