Re: FileField and ImageField

[Cristiano Coelho]

I have done some work here 
https://github.com/cristianocca/django/commit/4be936ba3031f95d34101a919648f4e8f7d7856a
And opened a ticket here https://code.djangoproject.com/ticket/26382
If someone's willing to take a look.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a309d9c3-6710-4fcd-8439-5102a030a35c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: FileField and ImageField

[Cristiano Coelho]

I agree with you, generate_filename should just call the field upload_to 
and then delegate the whole name generation to the storage.

There's another thing about file storage that is troubling me: 
https://github.com/django/django/blob/master/django/core/files/storage.py#L57

The docs state you are not suposed to override the save method and just 
implement _save, however, doing a complete random rename at the send pretty 
much forces you to always override save instead. That name replacement is 
probably to save the file name in a way you can easily create the URL, but 
again, that should be delegated to the storage.url method shouldn't it?

There's one more thing I noticed (gonna open a ticket about this one) is 
that the proxy class for FileField (FieldFile, what a name!) states in the 
docs that in order to call its save method you need a django File object 
rather than a simple file-like object, I can understand that's because the 
save method uses the .size property 
(https://github.com/django/django/blob/master/django/db/models/fields/files.py#L92)
 
to save the file size into a _size variable. It doesn't seem anywhere in 
the code the _size is being used as size is a property that gets the file 
size either from the storage class or the actual file. So removing that 
line, could also allow us to use normal files in the save method.

El miércoles, 16 de marzo de 2016, 23:41:58 (UTC-3), Josh Smeaton escribió:
>
> It seems like FileField should delegate some of these methods to an 
> underlying Storage backend, no? I don't know what the implications to 
> back-compat would be, but the idea seems like a sensible one to start with. 
> The storage backend API may need to grow some additional methods to 
> verify/validate paths and filenames or it might already have the correct 
> methods needed for FileField to work. Fields should do all of their 
> path/storage IO via their storage object though.
>
>
> On Thursday, 17 March 2016 12:16:00 UTC+11, Cristiano Coelho wrote:
>>
>> To add a bit more about this, it seems that FileField is really meant to 
>> be working with an OS file system, making it harder to use a custom Storage 
>> that sends data to somewhere like AWS S3 where basically everything is a 
>> file (there are no real folders, just key prefixes)
>>
>> These 3 functions inside FileField are the culprits:
>>
>> def get_directory_name(self):
>> return 
>> os.path.normpath(force_text(datetime.datetime.now().strftime(force_str(self.upload_to
>>
>> def get_filename(self, filename):
>> return 
>> os.path.normpath(self.storage.get_valid_name(os.path.basename(filename)))
>>
>> def generate_filename(self, instance, filename):
>> # If upload_to is a callable, make sure that the path it returns is
>> # passed through get_valid_name() of the underlying storage.
>> if callable(self.upload_to):
>> directory_name, filename = 
>> os.path.split(self.upload_to(instance, filename))
>> filename = self.storage.get_valid_name(filename)
>> return os.path.normpath(os.path.join(directory_name, filename))
>>
>> return os.path.join(self.get_directory_name(), 
>> self.get_filename(filename))
>>
>>
>>
>> They basically destroy any file name you give to it even with upload_to. 
>> This is not an issue on a storage that uses the underlying file system, but 
>> it might be quite an issue on different systems, in particular if file 
>> names are using slashes as prefixes.
>>
>> So what I did was to override it a bit:
>>
>> class S3FileField(FileField):
>>  
>> def generate_filename(self, instance, filename):
>> # If upload_to is a callable, make sure that the path it returns is
>> # passed through get_valid_name() of the underlying storage.
>> if callable(self.upload_to):
>> filename = self.upload_to(instance, filename)
>> filename = self.storage.get_valid_name(filename)
>> return filename
>>
>> return self.storage.get_valid_name(filename)
>>
>>
>> And all S3 issues gone! I wonder if this is the best way to do it. It 
>> would be great to have an additional keyword argument or something on the 
>> File (and image) fields to let the above functions know that they should 
>> not perform any OS operation on paths but seems like it would cause a lot 
>> of trouble.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0d07079b-789f-413f-a578-674fc6febaa6%40googlegroups.com.
For more options, visit ht

Re: FileField and ImageField

[Josh Smeaton]

It seems like FileField should delegate some of these methods to an 
underlying Storage backend, no? I don't know what the implications to 
back-compat would be, but the idea seems like a sensible one to start with. 
The storage backend API may need to grow some additional methods to 
verify/validate paths and filenames or it might already have the correct 
methods needed for FileField to work. Fields should do all of their 
path/storage IO via their storage object though.


On Thursday, 17 March 2016 12:16:00 UTC+11, Cristiano Coelho wrote:
>
> To add a bit more about this, it seems that FileField is really meant to 
> be working with an OS file system, making it harder to use a custom Storage 
> that sends data to somewhere like AWS S3 where basically everything is a 
> file (there are no real folders, just key prefixes)
>
> These 3 functions inside FileField are the culprits:
>
> def get_directory_name(self):
> return 
> os.path.normpath(force_text(datetime.datetime.now().strftime(force_str(self.upload_to
>
> def get_filename(self, filename):
> return 
> os.path.normpath(self.storage.get_valid_name(os.path.basename(filename)))
>
> def generate_filename(self, instance, filename):
> # If upload_to is a callable, make sure that the path it returns is
> # passed through get_valid_name() of the underlying storage.
> if callable(self.upload_to):
> directory_name, filename = os.path.split(self.upload_to(instance, 
> filename))
> filename = self.storage.get_valid_name(filename)
> return os.path.normpath(os.path.join(directory_name, filename))
>
> return os.path.join(self.get_directory_name(), 
> self.get_filename(filename))
>
>
>
> They basically destroy any file name you give to it even with upload_to. 
> This is not an issue on a storage that uses the underlying file system, but 
> it might be quite an issue on different systems, in particular if file 
> names are using slashes as prefixes.
>
> So what I did was to override it a bit:
>
> class S3FileField(FileField):
>  
> def generate_filename(self, instance, filename):
> # If upload_to is a callable, make sure that the path it returns is
> # passed through get_valid_name() of the underlying storage.
> if callable(self.upload_to):
> filename = self.upload_to(instance, filename)
> filename = self.storage.get_valid_name(filename)
> return filename
>
> return self.storage.get_valid_name(filename)
>
>
> And all S3 issues gone! I wonder if this is the best way to do it. It 
> would be great to have an additional keyword argument or something on the 
> File (and image) fields to let the above functions know that they should 
> not perform any OS operation on paths but seems like it would cause a lot 
> of trouble.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b1cbecc8-3cd0-455f-84bc-a87f079a418b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: FileField and ImageField

[Cristiano Coelho]

To add a bit more about this, it seems that FileField is really meant to be 
working with an OS file system, making it harder to use a custom Storage 
that sends data to somewhere like AWS S3 where basically everything is a 
file (there are no real folders, just key prefixes)

These 3 functions inside FileField are the culprits:

def get_directory_name(self):
return 
os.path.normpath(force_text(datetime.datetime.now().strftime(force_str(self.upload_to

def get_filename(self, filename):
return 
os.path.normpath(self.storage.get_valid_name(os.path.basename(filename)))

def generate_filename(self, instance, filename):
# If upload_to is a callable, make sure that the path it returns is
# passed through get_valid_name() of the underlying storage.
if callable(self.upload_to):
directory_name, filename = os.path.split(self.upload_to(instance, 
filename))
filename = self.storage.get_valid_name(filename)
return os.path.normpath(os.path.join(directory_name, filename))

return os.path.join(self.get_directory_name(), 
self.get_filename(filename))



They basically destroy any file name you give to it even with upload_to. 
This is not an issue on a storage that uses the underlying file system, but 
it might be quite an issue on different systems, in particular if file 
names are using slashes as prefixes.

So what I did was to override it a bit:

class S3FileField(FileField):
 
def generate_filename(self, instance, filename):
# If upload_to is a callable, make sure that the path it returns is
# passed through get_valid_name() of the underlying storage.
if callable(self.upload_to):
filename = self.upload_to(instance, filename)
filename = self.storage.get_valid_name(filename)
return filename

return self.storage.get_valid_name(filename)


And all S3 issues gone! I wonder if this is the best way to do it. It would 
be great to have an additional keyword argument or something on the File 
(and image) fields to let the above functions know that they should not 
perform any OS operation on paths but seems like it would cause a lot of 
trouble.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/04eea39c-311d-4055-a769-3a9830ce08f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

FileField and ImageField

[Cristiano Coelho]

I am recently trying to make an aws S3 storage (I know there are a few 
libraries in there but I needed some customization). The storage works fine 
so far!

However, there are some implementation details on FileField and ImageField, 
in particular the function 
generate_filename
https://github.com/django/django/blob/master/django/db/models/fields/files.py#L310

that is called before saving a model (and its file/image field). That code 
assumes the file uses standar file paths based on your current operative 
system. This creates quite some complications on S3 for example where all 
the paths to simulate folders uses a "/", so if you are in Windows and your 
file name is something like "hello/my/file.txt" it will overwrite your file 
name to be "hello\\my\\file.txt" which is something I don't want as I have 
explicitly created an upload_to callable to generate a very specific file 
name (and that it shouldn't be changed).
Looking deeper it seems like the whole FileField implementation relies on a 
directory and file structure, which might not be always right.

How easy would it be to add customization to this? Is your only option 
defining your own FileFilend and ImageField classes that override this 
method?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/35f921f4-9c22-40fa-bbea-ebfcb4c5d91f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: FileField and ImageField

[Josh Smeaton]

It seems like you have a pretty good grasp on the problems and possible 
solutions. I'm not familiar enough with storage backends and FileFields to 
provide much guidance so hopefully someone else can comment. Regarding the 
linked line in the save method which forces forward slashes, it seems that 
the FileSystemStorage should be doing that, rather than the base Storage 
class. It looks like Storage tries to do too much, so pushing some 
behaviour back down to FileSystemStorage seems correct. Again though, we 
have to be wary of backwards compatibility. You could offer opt-in to more 
correct behaviour while deprecating the status quo. Something like a 
`normalize_slashes = True` that can be flipped to False for brand new code.

On Thursday, 17 March 2016 14:30:43 UTC+11, Cristiano Coelho wrote:
>
> I agree with you, generate_filename should just call the field upload_to 
> and then delegate the whole name generation to the storage.
>
> There's another thing about file storage that is troubling me: 
> https://github.com/django/django/blob/master/django/core/files/storage.py#L57
>
> The docs state you are not suposed to override the save method and just 
> implement _save, however, doing a complete random rename at the send pretty 
> much forces you to always override save instead. That name replacement is 
> probably to save the file name in a way you can easily create the URL, but 
> again, that should be delegated to the storage.url method shouldn't it?
>
> There's one more thing I noticed (gonna open a ticket about this one) is 
> that the proxy class for FileField (FieldFile, what a name!) states in the 
> docs that in order to call its save method you need a django File object 
> rather than a simple file-like object, I can understand that's because the 
> save method uses the .size property (
> https://github.com/django/django/blob/master/django/db/models/fields/files.py#L92)
>  
> to save the file size into a _size variable. It doesn't seem anywhere in 
> the code the _size is being used as size is a property that gets the file 
> size either from the storage class or the actual file. So removing that 
> line, could also allow us to use normal files in the save method.
>
> El miércoles, 16 de marzo de 2016, 23:41:58 (UTC-3), Josh Smeaton escribió:
>>
>> It seems like FileField should delegate some of these methods to an 
>> underlying Storage backend, no? I don't know what the implications to 
>> back-compat would be, but the idea seems like a sensible one to start with. 
>> The storage backend API may need to grow some additional methods to 
>> verify/validate paths and filenames or it might already have the correct 
>> methods needed for FileField to work. Fields should do all of their 
>> path/storage IO via their storage object though.
>>
>>
>> On Thursday, 17 March 2016 12:16:00 UTC+11, Cristiano Coelho wrote:
>>>
>>> To add a bit more about this, it seems that FileField is really meant to 
>>> be working with an OS file system, making it harder to use a custom Storage 
>>> that sends data to somewhere like AWS S3 where basically everything is a 
>>> file (there are no real folders, just key prefixes)
>>>
>>> These 3 functions inside FileField are the culprits:
>>>
>>> def get_directory_name(self):
>>> return 
>>> os.path.normpath(force_text(datetime.datetime.now().strftime(force_str(self.upload_to
>>>
>>> def get_filename(self, filename):
>>> return 
>>> os.path.normpath(self.storage.get_valid_name(os.path.basename(filename)))
>>>
>>> def generate_filename(self, instance, filename):
>>> # If upload_to is a callable, make sure that the path it returns is
>>> # passed through get_valid_name() of the underlying storage.
>>> if callable(self.upload_to):
>>> directory_name, filename = 
>>> os.path.split(self.upload_to(instance, filename))
>>> filename = self.storage.get_valid_name(filename)
>>> return os.path.normpath(os.path.join(directory_name, filename))
>>>
>>> return os.path.join(self.get_directory_name(), 
>>> self.get_filename(filename))
>>>
>>>
>>>
>>> They basically destroy any file name you give to it even with upload_to. 
>>> This is not an issue on a storage that uses the underlying file system, but 
>>> it might be quite an issue on different systems, in particular if file 
>>> names are using slashes as prefixes.
>>>
>>> So what I did was to override it a bit:
>>>
>>> class S3FileField(FileField):
>>>  
>>> def generate_filename(self, instance, filename):
>>> # If upload_to is a callable, make sure that the path it returns is
>>> # passed through get_valid_name() of the underlying storage.
>>> if callable(self.upload_to):
>>> filename = self.upload_to(instance, filename)
>>> filename = self.storage.get_valid_name(filename)
>>> return filename
>>>
>>> return self.storage.get_valid_name(filename)
>>>
>>>
>>> 

Re: Document direct API usage of FileField and ImageField

[Owen Nelson]

Actually, I'm not sure what way to go with this.  All the info is there,
it's just spread around in a number of topics:

http://docs.djangoproject.com/en/dev/ref/files/file/

http://docs.djangoproject.com/en/dev/topics/http/file-uploads/

http://docs.djangoproject.com/en/dev/topics/files/

http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.FileField

I'd almost say the best way to explore file handling would be to add an
"extra credit" tutorial -- an extension of the poll app that serves as
django's HelloWorld.  Tricky thing is that there are a lot of moving
parts... the storage system, upload_to, serving static files (if using
./manage.py runserver), upload handlers, the concepts around the File
wrapper...  It's all a bit much for a newcomer to the project.


On Fri, Sep 17, 2010 at 2:11 PM, Owen Nelson  wrote:

> I'd love to pitch in on updating the docs for file handling :)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Document direct API usage of FileField and ImageField

[Owen Nelson]

I'd love to pitch in on updating the docs for file handling :)

Even though this kind of talk is better suited over on django-users,  here's
one way to skin a cat.
I had a view that displayed a model form (one of the fields was a
FileField).  I needed to alter the resolution of the uploaded image to make
sure it wasn't HUGE.

http://dpaste.org/oN2J/

In my case, I was resizing the original image *after* it had been stored
according to the file field's upload_to settings.
The 'image' I got from the form is basically a file object (
http://docs.djangoproject.com/en/dev/ref/files/file/) which is what I
tripped up on at first when putting this together.  You have to make sure
whatever you pass to ImageField as "contents" is an object that implements
that "File" interface, so to speak.  In the case of the upload from the
form, this was done for us, but if you have some random file on the
filesystem, you'd do something like this:

from django.core.files import File

tmpfile = File(open('/tmp/some-pic.jpg','rb'))
object.image.save('pic.jpg', tmpfile, save=True) # copy the image to
it's proper location and save the model instance when done.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Document direct API usage of FileField and ImageField

[Yo-Yo Ma]

I actually don't know how to do it myself. I'm still trying to put
some context to the Storage API, and file uploads in general. There
seems not to be a consensus on the best way to handle files in Django.
I figured I'd put the request up here so others don't run into the
same problem, but I've not solved my own problems in the meantime.
When I do, I'll make a patch for the docs.

I'm trying to allow a user to upload a single photo, and have it saved
as 2 different sized thumbnails, as well the original. Should I look
into using the Storage API directly?



On Sep 15, 5:52 pm, Russell Keith-Magee 
wrote:
> On Thu, Sep 16, 2010 at 2:28 AM, Yo-Yo Ma  wrote:
> > I think it might be a good idea to document the direct usage of the
> > FileField, and ImageField model fields.
>
> Sure -- sounds like a reasonable proposal to me. Open a ticket on Trac
> so the idea isn't forgotten.
>
> We also accept patches :-)
>
> Yours,
> Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Document direct API usage of FileField and ImageField

[Russell Keith-Magee]

On Thu, Sep 16, 2010 at 2:28 AM, Yo-Yo Ma  wrote:
> I think it might be a good idea to document the direct usage of the
> FileField, and ImageField model fields.

Sure -- sounds like a reasonable proposal to me. Open a ticket on Trac
so the idea isn't forgotten.

We also accept patches :-)

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Document direct API usage of FileField and ImageField

[Yo-Yo Ma]

BTW, ignore the PIL imports

On Sep 15, 12:28 pm, Yo-Yo Ma  wrote:
> I think it might be a good idea to document the direct usage of the
> FileField, and ImageField model fields.
>
> The docs make the assumption that everyone is using ModelForm to
> upload files. If I have a file on my hard drive and want to use it to
> populate the field, I would try something like:
>
> from PIL import Image, ImageFile
> image = open('/some/path/to/image.jpg', 'rb')
>
> instance = MyModel(
>     image=image,
>     title="Hello, World."
> )
>
> instance.save()
>
> The docs show examples of how to manually use models, but don't give
> any examples of how to do this when an image, or file is included in
> the mix.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Document direct API usage of FileField and ImageField

[Yo-Yo Ma]

I think it might be a good idea to document the direct usage of the
FileField, and ImageField model fields.

The docs make the assumption that everyone is using ModelForm to
upload files. If I have a file on my hard drive and want to use it to
populate the field, I would try something like:



from PIL import Image, ImageFile
image = open('/some/path/to/image.jpg', 'rb')

instance = MyModel(
image=image,
title="Hello, World."
)

instance.save()



The docs show examples of how to manually use models, but don't give
any examples of how to do this when an image, or file is included in
the mix.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ability to delete contents of FileField and ImageField in admin

[David Reynolds]

On 18 Aug 2008, at 2:56 pm, Brian Rosner wrote:

> Keep an eye on http://code.djangoproject.com/ticket/7048.


Thanks, Brian.
-- 
David Reynolds
[EMAIL PROTECTED]


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Ability to delete contents of FileField and ImageField in admin

[Brian Rosner]

On Mon, Aug 18, 2008 at 7:30 AM, David Reynolds
<[EMAIL PROTECTED]> wrote:
> I notice some discussion about this from a while back but as far as I
> can tell it has all gone quiet. This may be because it has been
> fixed, or possibly because it has been forgotten about. Can anyone
> give me a status update of whether or not it is possible to delete
> the contents of a FileField or ImageField from within the admin?

Keep an eye on http://code.djangoproject.com/ticket/7048.

-- 
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 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
-~--~~~~--~~--~--~---

Ability to delete contents of FileField and ImageField in admin

[David Reynolds]

Hi,

I notice some discussion about this from a while back but as far as I  
can tell it has all gone quiet. This may be because it has been  
fixed, or possibly because it has been forgotten about. Can anyone  
give me a status update of whether or not it is possible to delete  
the contents of a FileField or ImageField from within the admin?

Thanks,

David

-- 
David Reynolds
[EMAIL PROTECTED]


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #3297newforms: Implement FileField and ImageField

[[EMAIL PROTECTED]]

Added more tests now, seems to work fine.

On 21 Feb, 11:00, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> You use the latest patch?
>
> Still needs tests for required/not required/failed required/empty file/
> wrong encoding of form/valid image/invalid image for create and
> update.
>
> On 21 Feb, 01:36, Sandro Dentella <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 20, 2007 at 06:14:34PM -, [EMAIL PROTECTED] wrote:
>
> > > Could someone review this ticket?
>
> > I started using it last week. I /really, really/ needed it and it seems to
> > work fine in a version of create_update working with newforms, so that I use
> > it both with form_for_model and form_for_instance.
>
> > What is the testing you think you need?
>
> > I'd be glad to give feedback so that it can be pushed into svn.
>
> > sandro
> > *:-)
>
> > --
> > Sandro Dentella  *:-)http://www.tksql.org  TkSQL Home page 
> > - My GPL work


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #3297newforms: Implement FileField and ImageField

[[EMAIL PROTECTED]]

You use the latest patch?

Still needs tests for required/not required/failed required/empty file/
wrong encoding of form/valid image/invalid image for create and
update.

On 21 Feb, 01:36, Sandro Dentella <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 20, 2007 at 06:14:34PM -, [EMAIL PROTECTED] wrote:
>
> > Could someone review this ticket?
>
> I started using it last week. I /really, really/ needed it and it seems to
> work fine in a version of create_update working with newforms, so that I use
> it both with form_for_model and form_for_instance.
>
> What is the testing you think you need?
>
> I'd be glad to give feedback so that it can be pushed into svn.
>
> sandro
> *:-)
>
> --
> Sandro Dentella  *:-)http://www.tksql.org   TkSQL Home page - 
> My GPL work


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #3297newforms: Implement FileField and ImageField

[Sandro Dentella]

On Tue, Feb 20, 2007 at 06:14:34PM -, [EMAIL PROTECTED] wrote:
> 
> Could someone review this ticket?

I started using it last week. I /really, really/ needed it and it seems to
work fine in a version of create_update working with newforms, so that I use
it both with form_for_model and form_for_instance.

What is the testing you think you need?

I'd be glad to give feedback so that it can be pushed into svn.

sandro
*:-)

-- 
Sandro Dentella  *:-)
http://www.tksql.orgTkSQL Home page - My GPL work

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

#3297newforms: Implement FileField and ImageField

[[EMAIL PROTECTED]]

Could someone review this ticket?


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: proposal and patch: original_filename with FileField and ImageField

[tsuyuki makoto]

Ok, I just added a ticket(http://code.djangoproject.com/ticket/3119).
Forget this patch at this time.
Do you have any idea?

2006/12/4, tsuyuki makoto <[EMAIL PROTECTED]>:
> Hello django developers.
>
> Currently, FIleField and ImageField store file-system-safe file name.
> Imagine, if user upload a file named é.txt.
> Yes, File-system-safe file name is .txt or _.txt.
> It's not special case in Japan.
>
> I know Django says non dynamic contents should be served via apache-ish 
> server.
> But the other hand. Some client says file must have original name.
>
> So, I make FileField and ImageField to have their original file name
> like ImageField's width_field, height_field.
> And if original_filename_field is specified, Field encodes and stores
> file name as punycode.
> eg. input développement image.jpg:
>Field stores it dveloppement-image-kwa33c.jpg
>original_filename_field stores it développement image.jpg
>
> And I make file download generic view that uses original file name
>  if Field has original file name attribute.
>
> attention: patch encoding is utf8.
>
> usage:
> class TestModel(models.Model):
>   afile = 
> models.FileField(upload_to='afile',original_filename_field='orgname')
>   orgname = models.CharField(blank=True, maxlength=100)
>   class Admin:
>   pass
>
> (r'^file/(?P.*)/$','django.views.generic.simple.file_download', \
>
> dict(queryset=TestModel.objects.all(),file_field='afile')),

--~--~-~--~~~---~--~~
 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
-~--~~~~--~~--~--~---

proposal and patch: original_filename with FileField and ImageField

[tsuyuki makoto]

Hello django developers.

Currently, FIleField and ImageField store file-system-safe file name.
Imagine, if user upload a file named é.txt.
Yes, File-system-safe file name is .txt or _.txt.
It's not special case in Japan.

I know Django says non dynamic contents should be served via apache-ish server.
But the other hand. Some client says file must have original name.

So, I make FileField and ImageField to have their original file name
like ImageField's width_field, height_field.
And if original_filename_field is specified, Field encodes and stores
file name as punycode.
eg. input développement image.jpg:
   Field stores it dveloppement-image-kwa33c.jpg
   original_filename_field stores it développement image.jpg

And I make file download generic view that uses original file name
 if Field has original file name attribute.

attention: patch encoding is utf8.

usage:
class TestModel(models.Model):
  afile = models.FileField(upload_to='afile',original_filename_field='orgname')
  orgname = models.CharField(blank=True, maxlength=100)
  class Admin:
  pass

(r'^file/(?P.*)/$','django.views.generic.simple.file_download', \

dict(queryset=TestModel.objects.all(),file_field='afile')),


--~--~-~--~~~---~--~~
 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
-~--~~~~--~~--~--~---


filefield_and_dlgv.diff
Description: Binary data