On 2008-01-09 16:20:39 -0700, Malcolm Tredinnick <[EMAIL PROTECTED]> said:
> > > On Wed, 2008-01-09 at 14:04 -0700, Brian Rosner wrote: >> On 2008-01-08 18:46:02 -0700, Malcolm Tredinnick >> <[EMAIL PROTECTED]> said: >> >>> >>> >>> On Tue, 2008-01-08 at 18:40 -0700, Brian Rosner wrote: >>> [...] >>> >>>> To write a patch I created a new widget named BoundFileInput that >>>> inherits from MultiWidget to display the FileInput and HiddenInput >>>> widgets. The FileInput widget works the same as it does now. The >>>> HiddenInput widget maintains the data that came from the model. As I >>>> understand it this is how it used to work in oldforms, but perhaps just >>>> the admin in trunk. >>> >>> I'd prefer that we worked out a way to get the initial data passed >>> through. Sticking this in a hidden field would mean that you pretty much >>> always have to include some kind of security hash as well to avoid the >>> hidden field value being changed. This is why Russell's improvements for >>> file uploading in newforms were a slightly better design. >> >> Ok, that makes more sense. I had a feeling I was taking the wrong >> approach. I hadn't seen his proposal, perhaps I should have done a bit >> more research ;) Should FileField be special cased for initial data or >> make a global change to all fields? > > I'd special-case FileField, since all the related field (ImageField, any > custom upload fields) will be subclasses of that. More specifically, > it's really keyed off the HTML widget, since it's only the file upload > widget that has this particular problem. Without looking at the code, I > couldn't say if it's better to do test the widget type or the formfield > type, but the former is probably more robust, if you can do it. I have attached a possible patch to the ticket [1]. I would argue that the widget really doesn't play a role in this issue. The only thing the widget is doing is rendering the data passed into it which is either from request.POST or initial data. While it does know how to retreive its data from request.POST that would only be because of some way it decided to handle the data in the HTML. Let me know if I am missing that logic somewhere. My patch is grabbing the initial data and throwing it at the clean method of the FileField to ensure it is properly cleaned. Then based on its clean value save_form_data of the model FileField is able to determine with a check type check whether or not to save the file. One thing I want to point out here, which is described in the tests, is when the file changes there is no garbage collection of the previous file. I wasn't sure if this should be done by Django, the user or at all. Also, fields such as ComboField and MultiValueField probably need to be made aware of initial data if there is a FileField/ImageField among its fields. [1]: http://code.djangoproject.com/ticket/6302 > > Regards, > Malcolm -- Brian Rosner http://oebfare.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
