On 5/17/07, Robert Coup <[EMAIL PROTECTED]> wrote: > Yeah, I just wonder whether for files/images its worth having a python > object that provides the methods, since there is other metadata besides > the python file object (like its name!) > > eg: > my_model.attachment.file <- python file object > my_model.attachment.filename <- filename as stored in db > my_model.attachment.url <- url to file
Well yeah, I didn't mean have it be just a file object with no other details. I was meaning it'd be a custom object that would have those attributes, but also had standard file methods that lazily called file system operations as necessary. Something like this: my_model.attachment.filename my_model.attachment.url my_model.attachment.read() my_model.attachment.write() Such that when .read() or .write() (or whatever else) are called, it open()s the file if it's not already open. That way, you could even do things like write out PDFs to disk, using ReportLab. p = canvas.Canvas(my_model.attachment) I suppose adding .file wouldn't be the end of the world, but it'd be more impressive without it, anyway. > Side effect is now that it's always lazy - if i pass in the text > "BANANA" it doesn't figure out its invalid before it's used later. > > Ideal case: > - it's lazy when loaded from the DB > - it's not lazy the rest of the time, so if i set an invalid value i > find out straight away. Well, I don't know what all formats can be used to instantiate GEOSGeometry, but you might be able to at least put together a regex to validate that it fits the format(s). But again, I don't know all you're doing, so I can't say whether that would suit your needs well enough. > I think in a few cases one might need to check whether things are valid, > or do some extra magic. > > I changed it so that if __set__ gets a valid object (eg. just > instantiated from __get__) then it does the srid-init. Maybe __get__ > could call out when its instantiating to a method on the field, which > can do extra initialisation. Hrm, very interesting. So the srid magic happens every time a new object is instantiated with __get__, as well as every time a new object is set directly, but never when just retrieving a previously cached object. I'll work with that a bit and see if that will do the trick. Looks very slick though. -Marty --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
