I finally have some code to support multiple backends, but I'd like to ask a question and write some documentation before I create a ticket for it. I apologize in advance for such a long email, but there's a bit of backstory necessary to ask the question.
I was wondering about the intended use of get_FIELD_filename() and the impacts this patch would have on it. Currently, get_FIELD_filename() returns the absolute filesystem location of the file, which seems (to me) intended as a way to open() the file for specialty access, for instance by a view. However, this usefulness is only valid for the default FileSystemBackend. For an S3Backend (which I'm also building as a test of this system), this convenience would be lost, as simply returning a path wouldn't be enough to easily retrieve the file for read (or write) access. Even if a view author did want to write the extra code, it would no longer be portable to different environments, so file reading/editing wouldn't be a realistic option for distributable apps. So what I've done, and what I'd like comments on, is provide a special object in place of the existing string attribute, to enable portable access to the file on the backend. For existing templates, this will look the same as the existing field, as its __str__ simply returns the filename as it would have appeared before. But in views, this object has a few methods to replace the various get_FIELD_* methods currently employed. Some methods that are implemented include get_filename(), get_absolute_url() and get_filesize(). There is also an open(mode) method, which returns a file (or file-like) object ready for reading or writing, depending on the mode supplied. For the FIleSystemBackend, it returns a true file object for obvious reasons. For S3Backend, it returns an instance of a supplied RemoteFile class, which extends StringIO to provide portable read/write access to files, regardless of the backend in use. It handles writing by setting a dirty flag during its write() method, and pushing the file to the backend on close(), only if the dirty flag is set. So, for reading operations only, the file's contents are retrieved once, then destroyed with garbage collection when no longer in use, without touching the backend again. That was a long, roundabout way to get back to my real question, so here it is. Would this new object's open(mode) method suffice as a replacement for get_FIELD_filename()? The existing method is still available, so it won't break existing code, but it will only be of use for the FileSystemBackend. Anyone using a different backend will have to change any specialty code anyway. It should be as simple as replacing this first line to the second: fp = open(obj.get_data_filename(), 'rb') fp = obj.data.open() But that assumes that opening the file is the only reasonable use of get_FIELD_filename. Is there some other use for it that I'm not considering that might be hindered if people try to use a different backend? -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
