Thanks. I will recheck my code and see if I can fix it. If I'm not
successful in fixing it, I'll be back on tomorrow asking some more
questions. Thanks again for the help and suggestions.
On Mar 31, 9:12 pm, Sam Walters wrote:
> Yes, Id really need to see some code to work
Yes, Id really need to see some code to work it out.
A bit hard to work out wether you're returning the request.POST.copy()
and wether this is instantiated in a new form instance and returned.
Eg: if form validation fails.
Or wether you are having trouble redisplaying the original
request.POST
Sorry the last example I gave maybe wrong. I think I'm actually
getting the data back out using the cleaned_data. I'm trying to do
this from memory, since this is a work problem and I've been
struggling with it since the middle of this afternoon and it's been
very frustrating.
On Mar 31, 8:24
Currently I have logic in place that makes a copy of request.POST so
it can put data from a record using a key, gotten from the previous
bunch of POSTed data, on the screen for display purposes. This all
works fine. But when I go in and alter some of the data being
displayed then the next time I
Hi hank23
request.POST would be immutable.
"QueryDict instances are immutable, unless you create a copy() of
them. That means you can't change attributes of request.POST and
request.GET directly."
http://docs.djangoproject.com/en/dev/ref/request-response/
So I'm
> wondering if there is
I need to know when I can or should use request.POST.copy() when
processing screens, as opposed to when not to use it. I've used it
some, on one screen in particular, which seems to work fine for
displaying the data that I want to display, when I put the data on the
screen programatically from
6 matches
Mail list logo