So far I've refactored a bunch of the methods to store less in the
session, and generate more on demand (otherwise you could change the
method and then session data represents inaccurate information). I've
completedly redesigned the pages storage so it's just storing valid
and verified in the session. I'm a little curious as to what valid is
(vs verified), but I'll leave it for now. I've fixed an issue with URL
base, it seemed to only allow URLs which didn't end with a / (mine
do).

(r'^verify-number/(:?(?P<page_key>\w*)/)?$', 'verification.index'),

This is my sample URL.

I've changed the done() method to pass form_classes just as it would
originally. I've also changed _validate_all_forms to support this
change in the new _handle_post_request (renamed from POST) method. GET
is renamed to _handle_get_request. get_URL_base is renamed to
get_url_base.

When the done() method is called, the session is also cleared unless
done(). Maybe this should only happen if say a ValidationError isn't
raised? Maybe a setting that makes this not happen? In all of my
situations it makes sense to erase it when it's complete, and not have
to call methods manual. Let's decide which is more common.

On Dec 3, 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.
>
> 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):
>
> - A few more hooks such as get_page_title
> - 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).
>
> 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).
>
> 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..
>
> 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.
>
> The API (even private) also needs cleaned IMO to be a bit closer to
> PEP 8.
>
> Anyways, I'm going to work up some changes, and I'll submit another
> patch. If anyone has any recommendations on API for this please let me
> know as I can commit the time nescesary (since we need this) to finish
> the code.
>
> Also, is this feature still slated for 1.1?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to