[patch] django.contrib.formtools.wizard proposal

Very nice Honza, I'm already using it in a registration form.

What do you think about a method to navigate through the formlist with html inputs like [< Back] [ Next Step >]? Or is it possible with current wizard.py (01/02/07)?

yes it is, you just press the back button, it will work, or you revert the step to a lower number... but these are all hacks, there is no currently supported way...

I have new version that allows the form to be pre-filled from the previous steps... I will attach it...

updated version

thanks for the initial data function..
unfortunately I don't understand how to use it. could you give a small example like you did on the maillinglist?

regarding the navigational functionality with "back"- and "next"-form submit inputs:

I try to lower self.step within a subclass method "parse_params" by finding out if request.POST.get("navigation") is set (submit input html tag with the name "navigation") and decreasing self.step by 1. strangely it will just work if I decrease by 2 which then breaks the parsing of the template when I want to jump back to form 0 because it wants template wizard-1.html and not wizard0.html. I'm sure this is just an misunderstanding on my side. could you explain a little more?

5cb16d1ade0a My homepage vvv_5_1 vvv_5_1 vvv_5_2 vvv_5_2 vvv_5_3 vvv_5_3 vvv_5_4 vvv_5_4 vvv_5_5 vvv_5_5

There is an interesting snippet about that: http://www.djangosnippets.org/snippets/222/

matching current trunk (6158)

This is a cool idea. Before we can check it in, though, it needs docs and tests.

working on docs and tests

matching django's coding style

My test code so far

validating all forms before invoking done()

Test so far, anyone else want to give it a go, i'm suffering from test blindness

added current_step and step_count

Updated to Honza's latest code

Test of hashes done

Added some extra tests

Updated documentation, final.

Documentation finished, reassigning to Honza, so he can double-check before moving to check-in

Complete patch for newforms-admin branch

Since the previous step's data is kept as POST parameters, there isn't a nice way to go back to a previous step (other than the back button). I think something like this is an important usability feature (think of a checkout process where you can click previous steps if you made a mistake).

Example:

| 1 | 2 | 3 | 4 |

I am on step 4. I click the 2, loading the 2nd step with the data I originally entered.

Replying to jstritar@gmail.com:

Since the previous step's data is kept as POST parameters, there isn't a nice way to go back to a previous step (other than the back button). I think something like this is an important usability feature (think of a checkout process where you can click previous steps if you made a mistake). Example: | 1 | 2 | 3 | 4 | I am on step 4. I click the 2, loading the 2nd step with the data I originally entered.

I thought that wouldn't be the common usage, but you can achieve that via overriding the parse_params method, you can derive self.step from URL, GET or any other means you feel like...

You'd be able to pass the step via a URL or GET parameter, but the Forms up to and including that step wouldn't have any data (since there wasn't a POST).

Replying to Jon Stritar <jstritar@gmail.com>:

You'd be able to pass the step via a URL or GET parameter, but the Forms up to and including that step wouldn't have any data (since there wasn't a POST).

true, haven't actually thought it through this far... I guess the only option is to have the form post the data with the appropriate step value - you won't avoid a form or some javascript...

I a generally opposed to the idea of storing the data on server-side it doesn't make much sense, adds a lot of additional complexity and dependency on sessions and/or some other form of storing the data...

Replying to Honza_Kral:

I a generally opposed to the idea of storing the data on server-side it doesn't make much sense, adds a lot of additional complexity and dependency on sessions and/or some other form of storing the data...

I think what we are talking about here is state, and isn't maintaining state exactly what sessions are for in an otherwise stateless protocol? I know that it is more elegant to minimize dependancies, but depending on the sessions framework is justified here imho.

oops didn't want to show as an anonymous coward :)

what is the status of this bug?

I tested the diffs with 0.97-pre-SVN-6971 and it didn't work for me. :(

I have an immediate need for this for a project, so I'll take the lead on reviewing and checking it in.

(In [7236]) Fixed #3218 -- Implemented django.contrib.formtools.wizard. Thanks, Honza and Oyvind. Note that there are no docs yet

I know a lot of people have cc'd this, so i'll ask this here before making a ticket out of it in the hopes that someone can answer.

When calculating the hash, why dose it use unclean data? I've found a bug that causes Booleanfields that are set to false to erroneously cause the hash tst

(On the first pass, the value for the field is calculated to be (empty string), but the next time you try to submit something it's somehow False now, so the data is different than it was previously so the test fails and you have to start over.)

I would gladly write a patch that has it pull the data to be hashed from form.cleaned data, but before I do is there a reason why it doesn't already do that?

Replying to anonymous:

I know a lot of people have cc'd this, so i'll ask this here before making a ticket out of it in the hopes that someone can answer. When calculating the hash, why dose it use unclean data?

because than we can make tests without doing the clean(), which may be an expensive operation... so we don't have to validate every data on every pass...