Submitted by : simon at: 2003-10-26T21:31:45+00:00 (14 years ago)
Name :
Category : Severity : Status :
Optional subject :  
Optional comment :

I infer from observed behavior that attachments are stored simply with the topic pages. A consequence is that only one attachment with each name can exist. It is, however, not unlikely that different topics should have different attachments, but with the same name. Attachments are not, I believe, like topics that should be cross linked whenever they are referenced.

My suggestion is to maintain a separate attachment folder per topic page to avoid surprises.

SimonMichael, 2002/12/08 04:26 GMT (via web):
We have that patch somewhere on the wiki (FranOReilly's AssociateUploadsWithWikiPages), and several people liked it. As for making it the default I'm not yet sure the added complexity is justified. What if uploaded files just got renamed slightly in the event of a collision ? Similar to what zope and windows do when you paste a duplicate.

PieterB, 2002/12/08 23:07 GMT (via web):
I favor an approach similar to MailMan?. Mailman uses the following format:

archives/private/<listname>/attachments/YYYYMMDD/<msgid-hash>/<files>

For more information see Mailman/Handlers/Scrubber.py

ThomasWeigert, 2002/12/09 21:58 GMT (via web):
Not sure what you are suggesting, PieterB. All that is proposed is to make the namespace for attachments unique to a wiki page. No more is required, and any further breaking up of the namespace would be in the way...

SimonMichael, 2002/12/09 22:12 GMT (via web):
I don't think we need to remember each version of a file uploaded to a page. Of course if the naming were configurable you could let the admin decide. Here's another scheme: wikifolder/pagename_filename. Problems: filenames would need to be zope-id-safe, or changed to be so (that's probably true now). If the page is renamed, do you rename all it's uploads, and all the links to the file on other pages.

SimonMichael, 2002/12/09 22:20 GMT (via web):
A variant of my first suggestion: upload files with their original names if possible, and only if there's a collision, append _YYYYMMDDhhmm? (but try to preserve the suffix).

As long as collisions are handled somehow, I tend to think it's simpler/more usable to treat these as shared uploads to the wiki, not attachments in the scope of a page.

SimonMichael, 2002/12/09 22:22 GMT (via web):
Another: append .2, .3 as needed before the suffix.

ThomasWeigert, 2002/12/09 22:29 GMT (via web):
Just an example of the problem: I had an attachment associated with http://zwiki.org/IssueNo0386 and had experimented with this file later on a different page. Now I find that attachment in the issue tracker has been changed to the one I experimented with. What a surprise!

Anyway, attachments belong to the scope of the page. Changing filenames, etc., is just a pure man's version of accomplishing this. This is really not a discussion about how to manage collision, but about the data model that underpins zwiki. Attachments, icons, etc., anything that is part of the contents of the page, belongs in the scope of the page. The pages themselves are in a flat namespace, however, to facilitate linking.

Note, however, that you will find many wikis experimenting with hierarchical namespaces or, at least, multiple namespaces to create better organization and/or performance...

SimonMichael, 2002/12/09 22:40 GMT (via web):
Yes, including this one (SubWiki, NameSpaces).

Thomas, you are right, this is about the data model. I wouldn't find your example surprising because I'm expecting the shared filespace model. I believe SqueakSwiki? works this way. Note your attachment wouldn't change if we gave collisions a new name (but then how do you update the original file, except via the ZMI).

I'm most interested in which behaviour is the best out-of-the box default - the least surprising and simplest to use and to maintain. The per-page file space may yet turn out to be it.

ThomasWeigert, 2002/12/10 04:37 GMT (via web):
I guess the data model is something the user needs to be taught. What I have learned about Wikis is that they are for a graph of pages (topics) arbitrarily connected by links derived from wiki names. I think of the pages as units. That unit includes the content of the page, any images that might be on the page, as well as any attachments associated with the page. I don't expect to get a link into a page without doing something special. And I don't expect the attachment to be accessible in any other way either.

I think that you are after two things that get mixed up: (i) we want to be able to link from within a page to some other content. For example, we might want to show an image at an accessible location. (ii) we want to be able to attach other documents to a page as ancilliary information.

I believe these two issues are best kept separate. Allow to place globally accessible images, documents, etc., on the wiki, but also allow information specific to a page.

I guess this is really at the heart of our discussion. I was expecting (ii), but you were thinking of (i). Both are useful and needed. Maybe I was mislead by my past experience with wikis to interpret "Upload file or image" to mean "attach to this page" whereas it is implemented as "upload to global location and reference from here". What is confusing is that this is done from the edit pane of a page where one thinks one is editing local information about the page?

JohnGreenaway, 2002/12/10 09:11 GMT (via web):
We made uploads rename themselves pagename_uploadname. It makes far more sense to users that they are attaching an item to the page rather than to the wiki. Did this after having to explain a couple of times that there could only be one "index.html" uploaded across the whole site and realising how daft it sounded. If the upload is associated with a page, say with the prefix, then it's also fairly simple to add a bit of code to the page footer that scans for that page's attachments and presents them at the bottom of the page with a nice little paperclip icon. People are used to the way email & attachments work so we might as well leverage that "built in" recognition.

ThomasWeigert, 2002/12/10 21:33 GMT (via web):
Exactly. Look at http://twiki.org how attachments are handled in that twiki: Once you attach a document, it shows up at the bottom of the page in a form, together with some commments and an icon indicating what it is. You can reupload a document (replace an existing document by a newer one; albeit the version history is kept), delete an attachment, etc. There is also an extension to allow uploading of multiple attachments at a time. Your suggestion of using the paper clip icon is a good one as well.

SimonMichael, 2002/12/10 23:16 GMT (via web):
Ok, I paid twiki.org a visit. Lots of features over there. Anything I do will need to be much simpler, or of course if I saw a zwiki site which did this nicely I might just merge it in. I think there's more than one right way to do this and zwiki will need to stay open-minded. A PluginAPI? would be a nice thing.

Note since we do ftp everywhere, we'd like our uploads/attachments to play nicely with ftp.

I like the simplicity of pagename_filename but if I think about people wanting to manage attachments I lean towards pagename_files/filename so you can just give them a plone file management view on that folder.

Discussion Page request --DeanGoodmanson, 2003/03/21 16:40 GMT
Discussion page for this issue requested.

I'd like to be able to set this up so all file uploads are saved on the file system, not the ZODB, in a plain ZWiki (not CMF,Plone) implementation.