Django Unit Test on urls / views

Hello, I am want to write django 1.1 test case on fedora 12 x86_64. To test the url I want to session to be persistent so that the next test can use the same context. I can use client.login() method becoz in the application login is rewritten. If I directly use kwargs =

Re: Proposal: Revised form rendering

Hi Carl, On Jul 14, 11:44 am, Carl Meyer wrote: > > I totally agree with this. I think very similar results can be > achieved in the form-rendering system just with an optional parameter > to a "form/render_form" tag that specifies a "base path" for finding > template

Re: Proposal: Revised form rendering

Carl's proposal is exactly the kind of thing I was suggesting in my first response to this thread (only better thought out and stated more eloquently than I could have). Count me as a big +1 to it! Thanks, Eric Florenzano -- You received this message because you are subscribed to the Google

Re: Proposal: Revised form rendering

Hi Tai, On Jul 13, 8:42 pm, Tai Lee wrote: > I wouldn't like to see widget libraries being packaged up with > templates including conditional templates based on doctype. This seems > messy, not friendly to override in your own templates, and effectively > combining what

Re: Proposal: Revised form rendering

Hi Russ and Carl, On Jul 14, 5:55 am, Carl Meyer wrote: > Hi Russ, > > On Jul 13, 12:11 pm, Russell Keith-Magee > wrote: > > > My manifestation of this problem is slightly different -- it's the > > issue of how to ship a widget library that can

Re: Proposal: Revised form rendering

On Wed, 2010-07-14 at 00:11 +0800, Russell Keith-Magee wrote: > What exactly is your use case for something that designers want to > customize in the raw widget that widget.render() doesn't expose? That reminds me of one thing I'd very much like to see in any refactoring of form/widget handling.

Re: Proposal: Revised form rendering

Thanks for the thoughtful reply, Russ! Just a couple quick points: > As noted in my reply to Preston, this should easily possibly using > chrome; I'm not sure I see why you disagree. The new options may be > funcitonal, but from my reading of the HTML5 spec, they're functional > in terms of UX,

Re: Proposal: Revised form rendering

Hi Russ, On Jul 13, 12:11 pm, Russell Keith-Magee wrote: > I have exactly 0 mad skillz as a front end guy, but I know that rich, > pretty ajax widgets et al are necessary for a good user experience. My > goal, as a backend guy with limited frontend skills, was to find a

Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...

I think that what that http://docs.djangoproject.com/en/dev/releases/1.2/#modelform-is-valid... is saying is that if you don't want your instance to get modified by is_valid(), then when you initially create your ModelForm, you should pass in a copy of your instance. Something like this:

Re: Proposal: Revised form rendering

On Tue, Jul 13, 2010 at 3:24 AM, Carl Meyer wrote: > Hi Russ, > > First of all, thanks very much for this proposal! Form rendering has > been a major pain point for us (thus the existence of > django-form-utils), and improving it is tops on my 1.3 wishlist. I > will also

Advanced Permissions

Hello. My name is Nate. Myself and my friend Marco would like to upgrade django permissions. We would like to brainstorm here first to make sure that we design something that fits with django. If there are any other discussions about upgrading django permissions, kindly point me to them. We have

Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...

On Tue, 13 Jul 2010 02:10:03 -0700 (PDT) Margie wrote: > It's hard for me to believe that no other developers have encountered > this same problem (the problem of having a ModelForm saved at a point > in the code where you have no control). I did face the same problem

Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...

You are right, I should have tried out the trunk much earlier. And I agree that Python is a language for consenting adults (ad pretty much everything you said) so I won't hash it out. I went outside the interface, and now I have to deal with it. I think this came about because I really never

Re: Proposal: Revised form rendering

On Tue, Jul 13, 2010 at 3:03 AM, Gabriel Hurley wrote: > Hi all, > > I'm certainly excited to see improvements in the form rendering arena, > so thanks Russ for putting in the work here! > > I work with Django plenty as a programmer, but in truth I work more as > a designer. And

Re: Proposal: Revised form rendering

On Tue, Jul 13, 2010 at 12:28 AM, Preston Timmons wrote: > Hey Russ, > > I think this is a great proposal so far! > > Is there a way with the proposed solution for the template designer to > add custom attributes to a form field? If so, do you envision that > happening

Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...

Let's take the admin changelist as an example again. I have a changelist just like this. Let me give a sequence of steps: 1. User1 and User2 both have the changelist displayed on their screen, and both are displaying objects A and B. Let's say the objects have a 'name' field, and objectA's

Re: Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 11:29 PM, André Eriksson wrote: > It appears my reply got eaten so I'm trying again. > > On Jul 12, 3:43 pm, Russell Keith-Magee > wrote: >> I'm having difficulty reconciling these two positions. My template tag >> is too complex

Re: Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 11:01 PM, Tim Chase wrote: > On 07/12/2010 07:03 AM, Russell Keith-Magee wrote: >> > Yeah, I'll give you the point that your > solution looks more elegant for individual field rendering, while one of my > envisioned use cases was "I want

Re: Proposal: Revised form rendering

Your proposal really needs to cater to two different audiences: 1. People who will use the new {% form myform %} where they just want all the fields rendered without any fuss, much like {{ form }} now. 2. The tweakers that need to control every aspect of the each field being rendered. I'd say

Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...

On Tue, Jul 13, 2010 at 5:10 PM, Margie wrote: > Hi developers, > > I would suggest considering making this new model validation code path > optional.  IE, give users a way to stay with the old form validation. > Or better yet, keep the idea of model validation, but make

Re: Accessible Command Output using self.stdout & self.stderr

On Tue, Jul 13, 2010 at 2:23 PM, maxweld wrote: > I would like to propose that all commands in core.management be > modified to enable command output to be directed to self.stdout and > self.stderr so that the command output can be captured and made > accessible to an

Re: django 1.2 ModelForm save during post_clean has caused me quite a headache ...

On Jul 13, 9:10 pm, Margie wrote: > Yes, I know from tickets I have posted that modifying exclude > dynamically is "not allowed". Why wouldn't you just modify self.fields? -- You received this message because you are subscribed to the Google Groups "Django

Re: Proposal: Revised form rendering

On Jul 12, 11:43 pm, Russell Keith-Magee wrote: > > > On Jul 12, 12:31 pm, André Eriksson wrote: > >> Good proposal overall. One thought I have in order to try and combat > >> the massive parameter list of {% form %} is to optionally add an > >>

Accessible Command Output using self.stdout & self.stderr

I would like to propose that all commands in core.management be modified to enable command output to be directed to self.stdout and self.stderr so that the command output can be captured and made accessible to an application. I use a virtual web hosting environment where no shell access is

django 1.2 ModelForm save during post_clean has caused me quite a headache ...

Hi developers, Having just ported to 1.2.1, I'd like to make a comment about a change that was made to the code from 1.1. I understand that you wanted to add a more generic form of model validation into the code base. But I'd just like to let folks know that changing the code such that the

Re: Regression problem on admin date format

Am 13.07.2010 um 01:35 schrieb Russell Keith-Magee: >> On Sun, Jul 11, 2010 at 10:36 AM, Antoni Aloy wrote: >>> Hi, >>> >>> I have confirmed the bug with other non speaking people and I have >>> sent an e-mail to django-i18n group to point out the problem. >>> >>> I

Re: Proposal: Revised form rendering

I really like the idea of using Django templates instead of generating markup in Python, which should enable designers (who don't know and don't want to know Python) to customise markup in almost any way they like. We just need to add a few hooks that will make it easier to override specific