Re: Inclusion of easy-thumbnails into Django Contrib

Actually, that really did sound negative. Sorry :) Is there a trac ticket open to address this issue? Generally it'd be better to get discussion happening over a ticket and if there are serious issues that need to be addressed then they can be discussed here. I know it'd be nice to get things

Re: Inclusion of easy-thumbnails into Django Contrib

I don't want to sound negative, but answering your own question before anyone else can doesn't change the answer ;) D On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma wrote: > Is there any plans to incorporate > http://github.com/SmileyChris/easy-thumbnails/ > into

Inclusion of easy-thumbnails into Django Contrib

Is there any plans to incorporate http://github.com/SmileyChris/easy-thumbnails/ into django.contrib? I have seen so many apps/libraries come into and go out of existence (http://code.djangoproject.com/wiki/ThumbNails for instance mentions sorl-thumbnails which is no longer being developed). I

Re: Document direct API usage of FileField and ImageField

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

Re: [RFC] HttpResponse: streaming, freeze API (v2)

Hi Santiago, On Wed, Sep 15, 2010 at 04:34:42PM -0300, Santiago Perez wrote: > In the cases where you want to prevent server-side caching but are ok > with client-side caching, couldn't you freeze the 'Cache-Control' > header to another value and set all necessary headers to get the > caching you

Re: Document direct API usage of FileField and ImageField

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

Re: [RFC] HttpResponse: streaming, freeze API (v2)

In the cases where you want to prevent server-side caching but are ok with client-side caching, couldn't you freeze the 'Cache-Control' header to another value and set all necessary headers to get the caching you want? Would that work? On Wed, Sep 15, 2010 at 3:03 PM, Forest Bond

Re: Document direct API usage of FileField and ImageField

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

Document direct API usage of FileField and ImageField

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:

Re: HttpResponse: freeze API, read_once

Hi Tai, On Tue, Sep 14, 2010 at 09:25:36PM -0700, Tai Lee wrote: > I'm going to try and preempt a possible objection that has been raised > in previous discussions on this subject. > > Won't this change require a lot of repetitive logic to be shifted into > middleware functions? All middleware

[RFC] HttpResponse: streaming, freeze API (v2)

Hi, I've gone through each of the use cases that I'm aware of and evaluated how well the previous proposal handled each. While doing this I came to the conclusion that the "read_once" attribute was poorly named and as such semantically ambiguous since all iterator content should only be read