Rick, 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. Cheers, Thomas ------------------------------------------------------------------------- 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
