On Wed, Dec 3, 2008 at 7:50 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > So I needed the ability to specify initial data for a wizard, and I > also liked the idea of storing it in the session (vs the POST). I was > pointed to the SessionWizard patch, and I believe this was a 1.1 > possibility as well, so I figured I'd bring up the numerous issues.
Thanks for taking the time to look at it. > First and foremost, the latest patch doesn't even work. There's > several naming conflicts, and mismatches in the docs. There's a few > things I like about this, that I think would work well in the base > wizard class (which needs to be created): If you want you can message me offlist about this. I'd be interested to work with you to resolve any issues. I wrote all the code and am quite familiar with it, though I'm not a django or python guru. I know that my most recent patch passes all the tests I wrote, but I have not spent too much time with the code recently because the project I was using this for changed direction. > - The possibility to interact with the GET request to get form data (I > want to sometimes skip a step if they come from a location which > provides that information). There's a hook that can be used to interact with GETs, it's called _show_form. This is also called on validation failure. My thinking was that POSTs will be where people need to make workflow decisions, so most of the hooks are in the POST processing. > And a few of the obvious issues: > > - The API is *completely* different. > - Much of the code is specifically written for sessions (which is good > and bad). Yes it is. This is why I didn't see a clear route to a base class. I actually started with a base wizard class, but removed it when there was no common functionality. > I've got it working locally myself, but I've already begun making > tweaks (to make it work in our environment, and fix the bugs). I'm > going to refactor a BaseWizard class, and try to keep all the original > FormWizard methods, such as render_template, done, etc.. I think if you decide to use render_template for both hidden field form wizards and session-based form wizards you're going to be doing conditional "is this is a session wizard or a hidden fields wizard" type of checking. But I haven't seen your work so can't say for sure. > Most of the original base methods are still possible without tweaking > the design, but one of the very obvious differences is the done > method. This may be up for debate, but I believe the done method > should be what it says, done. This means that the session data should > automatically wipe once the done method has been called. There is also > the issue that the forms are not passed via the done method, and this > needs changed so that it is the same API. Sounds good to me. Thanks. -Dave --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
