A related problem is that I'd like to use the test client to verify
that when there's an error in the field the input field in the
response is populated with the original input.
So I'd like to do something like:
iteration = 'bad data'
response = self.client.post('/metrics/add/', {
'iteration' : iteration,
... )
self.failUnlessEqual(response.context[0]['form'].fields
['iteration'].value), 'bad data')
Would be great to know where I can fish this from (the last line in
the above snippet is just for illustration of how I would hope to
access the value)
Cheers,
Sagi
On Dec 17, 3:40 pm, sagi s <sag...@yahoo.com> wrote:
> On Dec 16, 4:49 pm, "James Bennett" <ubernost...@gmail.com> wrote:
>
> > On Tue, Dec 16, 2008 at 7:19 AM, sagi s <sag...@yahoo.com> wrote:
> > > So I'm looking at the data available in the template to try to get my
> > > hands dirty and restore all this manually but can't find how all this
> > > magic works. I'm in the debugger looking at the form passed to the
> > > template via the context and this looks like a mountain I'd rather not
> > > climb (I'll spare you the details of the data structure here).
>
> > There is no "magic" involved in the form; a ModelForm simply
> > introspects the model to get the model class' Field objects and, for
> > each field to be included in the form, calls that Field object's
> > 'formfield()' method to get a form field.
>
> I guess "magic" is a relative term. I am looking at the forms module
> and as far as I can see it is anything but trivial.
>
>
>
> > Of course, the moment you put a custom form field definition in the
> > form class, it ignores whatever comes from the model in favor of your
> > definition. So, either:
>
> > 1. Stop overriding the field definition, and instead poke at the
> > attributes you want to change inside your form's __init__ method, or
>
> I can override the __init__ method but I'm back to the problem of
> figuring out what to "poke" at.
> In the debugger I see this monstruous and deeply-nested data structure
> with a bazillion _meta's all over the place. Not sure where I can
> plant the attributes. Looking at the code with all that
> __meta__programming___ doesn't get me anymore enlightened.
>
> > 2. Use the same method the ModelForm uses to get the form field, and
> > then change the attributes you want to change before using the
> > resulting form field object to define your form.
>
> No joy in this direction either.
>
>
>
> > It's really not that difficult once you take a look at the code
> > involved; probably no more than a half-dozen lines of code if you're
> > just tweaking a couple of fields.
>
> I'm not a novice with Python so half-dozen lines of codes sounds like
> something I can deal with. I just need to know what those lines should
> say :)
>
> Seems like what I'm trying to accomplish should be bread-and-butter
> stuff for Django (tweak a bit the appearance of a ModelForm). Would be
> good to have an easy way to do it.
>
> If I ever learn I'm willing to take it upon myself to create a recipe
> somewhere.
>
> Thanks for the help here Jim. If you have more hints I'll appreciate
> much.
>
> > Also, when trying to work out what's happening, a debugger is probably
> > the worst possible choice; the underlying code is quite clear and
> > readable, and is far superior for getting an understanding of how the
> > system works.
>
> > --
> > "Bureaucrat Conrad, you are technically correct -- the best kind of
> > correct."
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
