Re: Class based generic views in 1.3?

On Jun 15, 5:10 pm, Patryk Zawadzki wrote: > If you don't mind, I'll talk a bit more to myself. While talking to self usually helps, IMHO, we have to speak to each other to get this in 1.3. Ben has taken the lead of this and published some code. I suggest we focus on

Re: Class based generic views in 1.3?

On Wed, Jun 16, 2010 at 9:24 AM, daonb wrote: > Actually, the current code is not that sure on the second point, > here's a line from base.py: > > view.request = request # FIXME: Maybe remove? Should this be > encouraged? > > As I see it, if we're cloning the view, it should

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

Hello. On 16/06/10 01:33, Graham Dumpleton wrote: > Paste has its own problems. Paste server itself does process > environment setup that isn't done by other WSGI hosting mechanisms. > Specifically, it initialises Python logging in a way suited to Paste > based applications. Like with Django

Re: 'exists' parameter for pre_save signal

On Jun 16, 4:51 am, Jeremy Dunck wrote: > On Tue, Jun 15, 2010 at 10:46 AM, George Sakkis > wrote: > > ...In the current save_base() > > implementation, pre_save is sent before the instance's existence is > > determined, so I'm not sure if postponing

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

On Jun 16, 7:32 pm, Gustavo Narea wrote: > Hello. > > On 16/06/10 01:33, Graham Dumpleton wrote: > > > Paste has its own problems. Paste server itself does process > > environment setup that isn't done by other WSGI hosting mechanisms. > > Specifically, it

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

On 16/06/10 10:48, Graham Dumpleton wrote: > But that will not happen if you use a different hosting mechanism. > Thus you end up with a fiddle as documented in: > > http://wiki.pylonshq.com/display/pylonscookbook/Logging+under+mod_wsgi > > The point I am making is that these hosting system

Re: Proposal: Replace django.contrib.formtools.wizard

Hi, Jacob Kaplan-Moss wrote: I couldn't tell from my quick play, though, if there were any backwards-incompatible changes. There's a fair bit of code churn (in a good way :), so before we could merge this I'd like a sense of what any backwards-compatibily concerns would be. There are some

Re: Proposal: Replace django.contrib.formtools.wizard

Hi, Harro wrote: We had a site where we needed a wizard with the ability to go back and forward and store files. Only allowing files in the last step really isn't an option imho, that just avoiding the problem ;-) I totally agree. But it is _one_ option to get around the problem. What we

Re: Proposal: Replace django.contrib.formtools.wizard

Hi, TiNo wrote: On Sat, May 29, 2010 at 22:07, Stephan Jäkel > wrote: I already discussed this ticket with Jannis during the sprints and hope to start a discussion here to find the right way to allow file uploads and see if my approach

Re: Proposal: Replace django.contrib.formtools.wizard

Hi, Harro wrote: +1 on the storage backend. Can the current filestorage backend be reused for this? I think yes, but will need some extensions for invalidation of files. But can be subclassed (already wrote a experimental backend for doing this) Cheers, -- You received this message

Allowing models to influence QuerySet.update

I know that queryset.update does not call .save() for each instance and I know why. I even agree with it :) However, I'd like to have a bit more control over what update() does, e.g. for auditing purposes. I know that I can simply write a few lines of code near every update() call to do what I

Re: ModelForms and ForeignKeys causing ValueError

Submitted here: http://code.djangoproject.com/ticket/13776 On Jun 14, 2:05 pm, Karen Tracey wrote: > On Mon, Jun 14, 2010 at 12:39 PM, Peter Bengtsson wrote: > > I'm happy to submit a ticket but wanted to check first that I'm doing > > the right thing. I

Re: Class based generic views in 1.3?

On 16 Jun 2010, at 08:24, daonb wrote: > > As I see it, if we're cloning the view, it should be encouraged. I > forked Ben's code and refactored it so that instead of having the > methods pass 'request' around, use self.request. I believe it made the > generic views more readable and it will

Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?

I have a modelform where I change the cleaned_data dict after I have run is_valid() and I'm not sure if this is the totally wrong way of doing things or if it's a bug. My code broke when I upgraded to 1.2 so it did work back in the 1.1 days. # models.py class Person(models.Model): name =

Re: Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?

On Jun 16, 4:22 pm, Peter Bengtsson wrote: > I have a modelform where I change the cleaned_data dict after I have > run is_valid() and I'm not sure if this is the totally wrong way of > doing things or if it's a bug. > My code broke when I upgraded to 1.2 so it did work back

Re: Should it be possible to change mymodelforminstance.cleaned_data after having run mymodelforminstance.is_valid()?

On 16 June 2010 13:53, George Sakkis wrote: > On Jun 16, 4:22 pm, Peter Bengtsson wrote: > >> I have a modelform where I change the cleaned_data dict after I have >> run is_valid() and I'm not sure if this is the totally wrong way of >> doing things or

Re: Class based generic views in 1.3?

Just wanted to add my $0.02; I’ve created a class-based views system for Django, which you can find at http://github.com/zacharyvoase/django-clsview (skip down to 'Examples' to see it in action). It solves the thread-safety problem, decoration is easy, pointing to views from the URLconf is

[GSOC] Query Refactor Update

Hey all, Another week's gone by (and remarkably quickly if I do say so myself). Since last we spoke I've gotten updates to work, basic filters, cleaned up some fun messes in the source code, added support for count(), tests for ForeignKeys, and began investigating more complex lookup types.

Re: Class based generic views in 1.3?

On Jun 16, 4:45 pm, Ben Firshman wrote: > > The request is passed round so methods look like views to decorators. > Magically dropping it for decorators seems a bit scary. :/ > The way I see it a good framework need to establish a clear contract with its user. In our case,

Re: Class based generic views in 1.3?

I have forked bfirsh's code as well on github: http://github.com/fitzgen/django-class-based-views I have changed the code to use __new__ rather than copying self. I have also merged in daonb's commit to make request implicit to all methods via

Re: Proposal: Replace django.contrib.formtools.wizard

Hi, Alex Gaynor wrote: My one comment (and we discussed this on IRC) is that this really should inherit from GenericView IMO, so it'd be nice if that landed before this. Agreed, many stuff in formwizard/classbased-views is duplicated. (I actually got the thread-safety bit from there).