Re: using newforms, an uncommon case.

2007-10-30 Thread RajeshD
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

Re: using newforms, an uncommon case.

2007-10-30 Thread Milan Andric
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

Re: using newforms, an uncommon case.

2007-10-30 Thread Scott SA
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

Re: using newforms, an uncommon case.

2007-10-30 Thread Marty Alchin
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.

using newforms, an uncommon case.

2007-10-30 Thread Milan Andric
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