Here's a different approach:
You could serialize an incomplete form instance to another table
(could just be serialized to the user's session too.) Then, when the
user requests to continue filling out an incomplete form, just
deserialize the form instance and you have the form exactly as the
user
On Oct 30, 12:27 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> Basically, you'd write pend() to take care of storing an in-progress
> form, and save() for processing a completed form. Then you have a
> couple options on deciding when to call which one. Also, I'll leave
> pulling up a pended
On 10/30/07, Milan Andric ([EMAIL PROTECTED]) wrote:
>I'm writing an application form (allow people to apply for a workshop)
>and we allow the applicant to submit unfinished applications because
>they can return to complete them at a later date. So most of the
>model fields are blank=True. Mos
On 10/30/07, Milan Andric <[EMAIL PROTECTED]> wrote:
> I'm writing an application form (allow people to apply for a workshop)
> and we allow the applicant to submit unfinished applications because
> they can return to complete them at a later date. So most of the
> model fields are blank=True.
Hi,
I'm writing an application form (allow people to apply for a workshop)
and we allow the applicant to submit unfinished applications because
they can return to complete them at a later date. So most of the
model fields are blank=True. Most of the fields are not required for
a save() but i'd
5 matches
Mail list logo