Gang (especially Jacob), I made a lot of progress on FileField at the sprint, but I have a few things to go over before I submit a new patch for review.
Jacob, you recommended that, in the case of an FileField attribute that doesn't have a file with it, accessing the attribute should return None, like other fields do. Unfortunately, it dawned on me that, since obj.save_FOO_file() is being deprecated in favor of obj.FOO.save_file(), having obj.FOO be None sipmly won't work. It wouldn't allow save_file() to be available, so it'd be pretty difficult to actually save any files ... pretty much ever. What I've done so far is modify the file-related functions (except save_file) to raise an exception when called, if there's no filename set. I also implemented __nonzero__ so that "if obj.FOO:" works just fine. So, this approach works just fine, but it raises a couple questions. * Is it the "right" way to handle this case? If not, how else should it be done (without going back to save_FOO_file, that is) * What exception should be raised? These situations have always seemed a bit murky to me. TypeError perhaps? I don't think ValueError or AttributeError make sense, but I don't really know. Also, Jacob, you mentioned that delete_file should delete the file itself, but leave the database value intact. So basically, future calls to methods on obj.FOO would get a filename, and thus try to work, but would raise IOError (or some other backend-specific error), as the file doesn't exist. This is fine, but it sort of led me to another question. obj.save_FOO_file (and thus, obj.FOO.save_file) takes an optional "save" argument, which specifies whether the new filename should be committed to the record. Should delete_file take a similar argument, which would empty out the field in the database and clear out the filename from the object in memory. That might be outside the scope of this patch, so I'm fine if this gets put aside for now. I just wanted to make sure I asked. Now, as for securing filenames, Django currently uses os.path.basename to strip off any path information (including any '..' references). I've kept this, but only in the FileField interface. Individual backends wouldn't be responsible for that. I think that makes things a bit more flexible, so that Python code can access whatever locations it likes, while still protecting it from outside code. Is this the right way to handle all of this? As for tests, I started writing some up, and I think it'd be best to split them into tests for the filestorage system itself (using just FileSystemBackend, of course) and tests for the higher-level FileField interface. As always with tests, though, I'm not quite sure where to put them. The FileField side should presumably go in modeltests, but would the backend tests go in regressiontests? Or should they all stay together? I'll probably have more questions, but I think those cover everything that occurred to me on the flight home. -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
