On 12/12/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> On 12/11/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Mon, 2007-12-10 at 20:56 -0600, Joseph Kocherhans wrote:
> > > On 12/9/07, James Bennett <[EMAIL PROTECTED]> wrote:
> > > >
> > > > OK, so after chatting a bit with
On 12/11/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 2007-12-10 at 20:56 -0600, Joseph Kocherhans wrote:
> > On 12/9/07, James Bennett <[EMAIL PROTECTED]> wrote:
> > >
> > > OK, so after chatting a bit with Joseph on IRC I'm working on revising
> > > my original patch. The chan
On Dec 11, 2:10 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Hello Guys,
>
> I am following this post about ModelForm and I am still puzzled on how
> this new class can address the dynamic generation of a form. I would
> like to see how it is possible to do it with this new API.
>
> Let
On Mon, 2007-12-10 at 20:56 -0600, Joseph Kocherhans wrote:
> On 12/9/07, James Bennett <[EMAIL PROTECTED]> wrote:
> >
> > OK, so after chatting a bit with Joseph on IRC I'm working on revising
> > my original patch. The changes it makes still need some discussion, so
> > I'll outline them here.
Hello Guys,
I am following this post about ModelForm and I am still puzzled on how
this new class can address the dynamic generation of a form. I would
like to see how it is possible to do it with this new API.
Let us imagine that for an Online Survey application :
http://yml.alwaysdata.net/
I
Joseph Kocherhans said the following:
> I'm close to checking this in and adding a note to
> BackwardsIncompatibleChanges, but I'm still a little uneasy about
> generating the form fields at form instantiation time. It just feels
> weird to me, but I can't really come up with any actual reasons wh
On 12/9/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> OK, so after chatting a bit with Joseph on IRC I'm working on revising
> my original patch. The changes it makes still need some discussion, so
> I'll outline them here.
>
> 1. The "instance" argument to ModelForm.__init__() essentially beco
I've just attached a new patch which (hopefully) makes everything work
in an acceptable way:
1. The argument ordering is still fixed, and you'll still want to pass
"instance" as a kwarg in most cases.
2. A ModelForm with neither model nor instance is an error.
3. A ModelForm which works on any of
OK, so after chatting a bit with Joseph on IRC I'm working on revising
my original patch. The changes it makes still need some discussion, so
I'll outline them here.
1. The "instance" argument to ModelForm.__init__() essentially becomes
a keyword argument defaulting to None, and moves out of the
On Dec 8, 2007 11:51 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> That's exactly what I'd imagined. Your example can be solved right now
> by the following:
>
> class LatLongForm(ModelForm):
> class Meta:
> fields = ('latitude', 'longitude')
>
> model_class = figure_out_latlong_model
On Dec 8, 2007 11:29 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> So, I'm going to pretend you didn't say anything about rearranging
> positional arguments because a) it doesn't work, and b) your patch
> doesn't do that.
It does, it just makes 'instance' the last positional argument.
Whethe
So, I'm going to pretend you didn't say anything about rearranging
positional arguments because a) it doesn't work, and b) your patch
doesn't do that. So, my response will assume that you are suggesting
that instance become a keyword argument rather than the first
positional argument, and that if
Since code speaks louder than words, I've opened ticket 6162[1] and
attached a patch which:
1. Makes "instance" the *last* argument to ModelForm.__init__().
2. Has ModelForm fall back to creating an instance of _meta.model if
the "instance" argument isn't supplied.
Updated tests and docs are als
On Sat, 2007-12-08 at 19:12 -0600, James Bennett wrote:
[...]
> In the first case, switching the positional order of the arguments
> would suffice; having 'instance' move after the 'data' and 'files'
> arguments would bring ModelForm back into line with "standard"
> newforms forms.
>
> In the se
I'd like to propose some refactoring of ModelForm to bring it into
line with the standard conventions of other newforms forms. Right now
there are two main issues:
1. A standard django.newforms.Form accepts POST data as its first
positional argument, while a ModelForm expects an instance of the
m
15 matches
Mail list logo
