What I've always done in these cases is carry a MAC along with the
hidden data and just validate that the hidden data hasn't changed by
re-hashing it after each form submit. You don't really need to
re-validate the already-validated data, you just need to ensure that it
hasn't changed since you validated it.

JP

On 8 Dec 2006, at 19:10, JP wrote:

MAC? An MD5/SHA1 hash, probably?
--
Antonio

Here's a first attempt.  As such, this code does per-page validation
only.

import cPickle as pickle
import base64

from django.core.exceptions import ImproperlyConfigured
from django.http import HttpResponse,HttpResponseRedirect
from django.shortcuts import render_to_response
from django.newforms.forms import SortedDictFromList
from django.newforms import *

class FormWizard(object):
    '''
    Formtools Wizard application

    Given a list of django.newforms.Form objects, and a corresponding
list of step names,
    it provides the following:

    * Displays each form on a separate page in turn
    * Marshals data between between pages in a hidden field
    * Validates each form as it is submitted
    * After the final form is validated, calls the done() hook that you
define

    ToDo:
    * Checksum marshalled data that's already been validated?
    * Look at other ways to save state
    * What's the most useful format for final data?
    * Get feedback from people smarter than me
    * Make this simpler

    Usage:

    Define your forms somwhere:

        class PageOne(Form):
            first_name = CharField()

        class PageTwo(Form):
            middle_name = CharField()

        class PageThree(Form):
            last_name = CharField()

    Subclass FormWizard and define a done() method, overriding
form_template if you like:

        class MyFormWizard(FormWizard):
            form_template = MyApp/formwizard.html"

        def done(self, request):
            for clean_form_data in self.data:
                ...

    In your urls.py:

        (r"^mywizard/$",
MyFormWizard([PageOne,PageTwo,PageThree],["First","Middle","Last"])),

    '''

    form_template = "formtools/formwizard.html"

    def __init__(self, form_steps, form_step_names):
        '''
        Store the wizard steps in a SortedDict
        '''
        form_steps = [(form_step_names[x], form_steps[x]) for x in
range(len(form_steps))]
        self.form_steps = SortedDictFromList(form_steps)
        self.data = [{} for x in range(len(form_steps))]

    def serialize_data(self):
        '''
        Serialize our previously captured form data in a base64 encoded
pickle
        '''
        serialized_data =
base64.encodestring(pickle.dumps(self.data)).strip()
        return serialized_data

    def deserialize_data(self, serialized_data):
        '''
        Restore our previously captured data
        '''
        deserialized_data =
pickle.loads(base64.decodestring(serialized_data))
        self.data = deserialized_data

    def render_step(self, form, form_step_name, first=False,
last=False):
        return render_to_response(self.form_template, {
            "form": form,
            "form_step_name": form_step_name,
            "form_prev_state": self.serialize_data(),
            "first": first,
            "last": last,
        })

    def __call__(self, request, *args, **kwargs):
        '''
        Handle a request
        '''
        if request.method == "POST":
            step_name = request.POST.get("form_step_name", "")
            if step_name in self.form_steps.keys():
                self.current_step_name = step_name
                if request.POST.get("form_prev_state", None):

self.deserialize_data(request.POST.get("form_prev_state"))
                submit_type = request.POST.get("submit_type", None)
                if submit_type == "Prev":
                    return self.handle_prev(request)
                elif submit_type == "Next":
                    return self.handle_next(request)
                elif submit_type == "Finish":
                    return self.handle_last(request)

        ## initial request, display first step with no data ##
        name,form = self.form_steps.items()[0]
        return self.render_step(form(), name, first=True)

    def get_prev_step_offset(self):
        '''
        Determine the previous step
        '''
        prev_offset = 0
        try:
            prev_offset =
self.form_steps.keys().index(self.current_step_name)-1
        except:
            pass
        first = False
        if prev_offset < 1:
            prev_offset = 0
            first = True
        return first,prev_offset

    def handle_prev(self, request):
        '''
        Go back to the previous step
        '''
        ## add the current step's data, but we don't yet care if its
valid ##
        form = self.form_steps[self.current_step_name](request.POST)
        form.is_valid()
        self.data[self.form_steps.keys().index(self.current_step_name)]
= form.clean()

        first,offset = self.get_prev_step_offset()
        data = self.data[offset]
        name,form = self.form_steps.items()[offset]
        return self.render_step(form(data), name, first=first)

    def get_next_step_offset(self):
        '''
        Determine the next step
        '''
        offset = 0
        try:
            offset =
self.form_steps.keys().index(self.current_step_name)+1
        except:
            pass
        last = False
        if offset >= len(self.form_steps)-1:
            offset = len(self.form_steps)-1
            last = True
        return last,offset

    def handle_next(self, request):
        '''
        Process this step and if valid, go to the next
        '''
        form = self.form_steps[self.current_step_name](request.POST)
        if form.is_valid():
            ## add this step's data ##

self.data[self.form_steps.keys().index(self.current_step_name)] =
form.clean()

            last,next_offset = self.get_next_step_offset()
            name,form = self.form_steps.items()[next_offset]
            if self.data[next_offset]:
                form_instance = form(self.data[next_offset])
            else:
                form_instance = form()
            return self.render_step(form_instance, name, last=last)
        else:
            return self.render_step(form_instance,
self.current_step_name, first=(self.current_step_name ==
self.form_steps.keys()[0]))

    def handle_last(self, request):
        '''
        Handle the final POST
        '''
        form = self.form_steps[self.current_step_name](request.POST)
        if form.is_valid():
            ## add this step's data ##

self.data[self.form_steps.keys().index(self.current_step_name)] =
form.clean()

            ## finished ##
            self.done(request)
        else:
            return render_step(form, self.current_step_name,
first=(self.current_step_name == self.form_steps.keys()[0]))

    def done(self, request):
        #for form_data in self.data:
        #    print form_data
        "Does something with the clean_data and returns an
HttpResponseRedirect."
        raise NotImplementedError('You must define a done() method on
your %s subclass.' % self.__class__.__name__)

Here's an example template:

{% extends "base.html" %}

{% block content %}

{% if form.errors %}<h1>Please correct the following errors</h1>{% else
%}<h1>{{ form_step_name }}</h1>{% endif %}

<form action="" method="post">
<table>
{{ form }}
</table>
<input type="hidden" name="form_prev_state" value="{{ form_prev_state }}" />
<input type="hidden" name="form_step_name" value="{{ form_step_name }}" />

{% if not first %}
  <p><input type="submit" name="submit_type" value="Prev" /></p>
{% endif %}

{% if not last %}
  <p><input type="submit" name="submit_type" value="Next" /></p>
{% endif %}

{% if last %}
  <p><input type="submit" name="submit_type" value="Finish" /></p>
{% endif %}
</form>

{% endblock %}

Hi,
nice work. I have been trying to come up with a solution of my own,
but I ran into some problems/questions:

1) I think it would be better to allow (but not force) users to add
actions after every step and a final done() - I have NO idea how to do
this, at least no working idea...

2) I don't know what would be the best way to store data from previous steps
  individual fields sound the best, but for that they would need to
have some prefix to make them unique accross forms (perhaps modify the
form.fields names in __init__() ?? )
  or whole pickled steps

  with security hash (as in preview.py) for every step. failing the
hash check would revert the wizard to the step that failed to validate

3) templates - I think some users will want to specify different
templates for each step (if you supply a template_name as a string -
use it throughout the form, if list - use templates[step] for each
step --- but this seems too magical to my liking.. :-/

if all this is done (and I still hope I will find the way to do it, if
only as an excersize), the Preview could be rewritten as a fairly
simple (just override the method responsible for selecting a form to
always return the supplied form, and some other minor tweaks) wrapper
around the Wizard (DRY)

What do you think?

On 12/8/06, chad.ma...@gmail.com <chad.ma...@gmail.com> wrote:

--
Honza Král
E-Mail: Honza.K...@gmail.com
ICQ#:   107471613
Phone:  +420 606 678585

One downside to storing accumulated data in hidden fields is when file
uploads are allowed as part of the wizard. Re-uploading each time would
be far less than ideal.

We've built a wizard abstraction that stores data in a bin in the
session, keyed by an ID which is passed through in the request, either
in the query string or in a hidden field. This avoids the file upload
and re-validation problems and also allows multiple submissions to be
active in one browser. The data store is available to each step along
the way.

Our abstraction is based on manipulators currently, a list of
manipulators describes the entire wizard. A default view is provided
for displaying a step. These can be overridden with custom templates,
custom form views or custom submit views. That is, as each step is
submitted we can specify that something different is done, e.g.
displaying a preview page, or computing some result based on data
collected so far. No data is inserted into the DB by the abstraction,
that is left entirely the programmer to do, in a custom submit view for
the last step for example.

On 12/10/06, Afternoon <aftern...@uk2.net> wrote:

That sounds like useful code. Is this proprietary, or would you be
willing to contribute it back to the project? No pressure either way
-- I just figured it's worth asking about.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

We are definitely interested in sharing, that was our initial
intention.

The code is by no means finished, but my colleague Tom will post an
interim version and some notes on our design soon. Hopefully it will be
interesting.

I like the idea of storing an encoded-pickled version of the form data
in a hidden field.  I'm concerned about privacy implications with
sharing that data with the client.  What about encrypting the contents
too?  The server could have a private key that it encrypts the
serialized form data and decrypts on submission.

I'm mainly concerned with the scenario where credit cards are used as
part of the form.  I haven't found too many supported cryptography
libraries for python though.

I'd envision:
base64.encodestring( crypto.encrypt(key, pickle.dumps(self.data)))

and
base64.loads( crypto.decrypt(key, base64.decodestring( form_data )))

*(I made up the crypto library for demonstration)

Isn't the session a natural place to store these kinds of things?  Is
there a reason for the avoidance of sessions?  Are they buggy?  Do they
require some sort of over-head people are trying to avoid?

Just curious,
Rob

On 20061211.1152, Kevin said ...

On 12/11/06, Kevin <kevinast...@gmail.com> wrote:

I'm mainly concerned with the scenario where credit cards are used as

I can't see a good reason for passing CC info in its entirety back and forth
at all, no matter how encrypted.  That said, there might be good reasons why
you may want to encrypt form data, but I would leave that up to the
individual programmer.  Perhaps I could provide hooks into the serialization
methods to allow for that.

I'd envision:

*(I made up the crypto library for demonstration)

As far as crypto libraries go, I've used the Python Cryptography Toolkit
(http://www.amk.ca/python/code/crypto) a number of times, and have been
pretty pleased with it.

Thought you might like to know.

--
Scott Paul Robertson
http://spr.mahonri5.net
GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601

application_pgp-signature_part < 1K Download

Hi,

I'm Ben's (Afternoon) collegue Tom,

As much as I was asked to be interesting, I don't do interesting, or at
least when I do, people fall asleep....

http://www.halfapenguin.com/djmultipartform.tar.gz

I've posted the code sample on my server, its not complete, but it is a
snapshot of where we are going.

Currently it stores both fields and files.

The form should be constructed using a query dict fed into the url in
as in the following snippet

from myforms import FormWithSections

urlpatterns+= patterns('',
(r'^testmultipartform/((?P<slug>\w*)/)?$',
'djmultipartform.views.index',{'manipulator_constructor':
FormWithSections}),
)

(with tabs in the right places of course).

I'll put up a further post with more details about what will be done in
the future to finish it.

Enjoy
From
Tom

One slight modification, there was debugging code left in, which I've
now fixed.

Hello all,

I got bored during the holiday, so I put together a simple
implementation of django.contrib.formtools.wizard...

Features:
 all data are kept in POST, nothing is stored on the server (this is
simply not very good for file uploads, but should be OK for the
majority)

  security_hash from preview.py (by adrian) is used to ensure that
previously submitted data didn't change (if they have, returns to the
step in question), successful validation is only done once

  old data are stored as individual fields not pickled by step

  process_step() is called after successful validation of every step
or after verifying the step's hash.. it is not meant to change
something in the DB, it is meant as a hook to change the wizard's
state (for example after processing step 1, generate form for step 2).
That's also why it is called every time a form is submitted for all
submitted steps (except the current one if its invalid)

  done() is THE method to override, it receives list of form instances
with valid data corresponding to the form_list, and the request
object, its output is returned directly...

Bugs:
  there is no (or very little) way of introducing your own logic or
overriding some defaults (for example there is no way to supply the
step number vie URL), this will change (see TODO)

  no documentation so far - I first want to make sure people are OK
with the state of things before I start doing some. However if someone
needs to know more than is written here to give it a try, let me
know...

Usage:
  1) subclass it and supply a done() method, that will taje request
and a list of form instances with valid data
  2) into urls enter:
   ( r'SOMETHING', MyWizard( [MyForm1, MyForm2, ...] ) ),
  3) supply a template (default is test.html so far, or override it in
get_template() ) taht looks like this:
 <form action="." method="POST">
 FORM( {{ step }}): {{ form }}

 previous_fields: {{ previous_fields }}

 <input type="submit">
 </form>

  4) report bugs and enhancement requests here or to me personally

I am looking forward for any feedback
Thanks
Honza

On 12/20/06, rassilon <rassilon2...@gmail.com> wrote:

--
Honza Král
E-Mail: Honza.K...@gmail.com
ICQ#:   107471613
Phone:  +420 606 678585

wizard.py 7K Download

So,
a little example with dynamic forms, I hope you don't mind
pseudo-code, I don't feel like writing a working standalone example
and I cannot publish my application (its in Czech anyway ;) )

urls.py:

urlpatterns = patterns('some.app.views',
  (r'wizard/$', 'my_wizard' ),
)

some/app/views.py:
from django import newforms as forms
from django.contrib.formtools import wizard

# we always have to supply at least one form
class FirstForm( forms.Form ):
   item_list = forms.MultipleChoiceField( choices=[ (1,'ONE'), ( 2, 'TWO) ] )

# function that will generate a second form for us dynamically:
def get_second_form( items ):
  # second form contains only labels for items selected in FirstForm
  class SecondForm( forms.Form ):
    def __init__( self, **kwargs ):
      super( SecondForm, self ).__init__( **kwargs )
      for i in items:
         self.fields['label_%s' % i ] = forms.CharField( max_length=100 )
  return SecondForm

# our wizard
class LabelManyWizard( wizard.Wizard ):
  # after submitting the first form, create the second and append it
to form_list
  def process_step( self, request, form, step ):
    if step == 0:
      form.full_clean()
      self.form_list.append( get_second_form( form.clean_data['item_list'] ) )
    super(LabelManyWizard, self ).process_step( request, form, step )

  # when both forms are validly filled, do what you always wanted to do
  def done( self, request, form_list ):
    first, second = form_list
    first.full_clean()
    second.full_clean()
    for i in first.clean_data['item_list']:
       print "Label for item %s is %s" % ( i, second.clean_data[
'label_%s' % i ])
    return HttpresponseRedirect( '/' )

# a little wrapper function - we could put the LabelManyWizard(
[FirstForm] ) into urls as a callable,
# but since it modifies its form_list it wouldn't work, hence this
little work around
# (this is only neccessary for dynamic wizards)

def my_wizard( request ):
  wiz = LabelManyWizard( [FirstForm] )
  return wiz( request )

-------------  DONE -------------------

in order for this to work, you will need patch from ticket #3193 -
that is needed to pass the values from FirstForm.item_list because
normal as_hidden() wouldn't work for MultipleChoiceField...

looking forward to any comments
Honza

On 12/26/06, Honza Král <honza.k...@gmail.com> wrote:

--
Honza Král
E-Mail: Honza.K...@gmail.com
ICQ#:   107471613
Phone:  +420 606 678585

I created the ticket containing the wizard proposal, it includes new
cleaned up version that offers a lot more flexibility...

http://code.djangoproject.com/ticket/3218

On 12/27/06, Honza Král <honza.k...@gmail.com> wrote:

--
Honza Král
E-Mail: Honza.K...@gmail.com
ICQ#:   107471613
Phone:  +420 606 678585

Right, after a bit of black magic, a few false starts and a fair bit of

reworking, djmultipartform is actually working as its meant to more
than just an abstract concept which i posted last time.

* www.halfapenguin.com/djmultipartform-0.1.tar.gz

* www.halfapenguin.com/djmultipartform-0.1.zip
(in case someone doesn't have the tools to unzip tar.gz).

There have been a few changes in the way the system works.
1.there is now a complete method which is accessed through the
/complete (overidable when implementing a multipartform), this should
be implemented as complete_action.

2. Each page descriptor can have assigned a method to generate a view,
which has passed in the the slug, the_form request, and the filter
variable. This updates the info_dict passed to the template, by default

the method passes an empty dict

3. Stored files can be deleted by a post request to the page with a
fieldname and the post variable 'delete' (which should be the
fieldname).

4.When a file is uploaded into the store where there is a file
already for that field, the old file is deleted and the new file is
saved

5.Clear_store now exists and will clear out all the data in the
datastore, this should be run as part of the complete method.

6. It is now possible to go backwards without completing form data,
however should there be errors in validation of the data on the current

page, to avoid confusion the new data for the page will be junked --see

below

Future work
* adding in behaviour options for the multipartform with respect to
moving backwards and junking data

* Modularise the view code so that components of the view can be
overridden.

* updating the code to use newforms instead of manipulators