I saw your message on GitHub and I thought I had answered that I'll work on
the formwizard within the next weeks. But maybe I missed to press the "send"
button :-)
Regarding your points, I had the same thoughts in 02/2010 and started to
write django-formwizard. There were also some discussions with Jannis Leidel
and Russell Keith-Magee about replacing the current formwizard with
django-formwizard.
Currently, the first changes in Django, which are needed for the upload
stuff, were done and my next plan is to update the cbv refactor branch to
use the class based views coming with Django 1.3. The next big thing will be
extending the docs.
After moving to class based views, your points should be solved, I think.
Within the next days the 27c3
(http://events.ccc.de/congress/2010/wiki/Main_Page) occurs in Berlin. I will
be there and will work on django-formwizard and I hope to come back with
some news.
Cheers,
steph
Miguel Araujo wrote:
> Hi everyone,
>
> I think FormWizard solves a common problem when you need forms to be split
> into steps, many frameworks have solutions to this pattern. I started using
> it and soon realized there is much left to be done and it looks like it's
> been postponed too long.
>
> In brief it's missing support for:
> - Formsets http://code.djangoproject.com/ticket/11112
> - Session backend http://code.djangoproject.com/ticket/9200
> - Multipart forms http://code.djangoproject.com/ticket/7439
> - Others
>
> One that I actually think needs to be discussed is ticket
> http://code.djangoproject.com/ticket/8808 Problem is that it looks like
> FormWizard is treated as a singleton and it also appears to me that
> Singleton objetcs within Django have per interpreter process instance scope,
> which I would have supposed to be per request scope. So setting variables
> using self is a time bomb. Sure you can use request.session to pass
> variables within methods, but no where in the docs this is stated. So many
> people end up using it and having obscure bugs they don't understand.
>
> I first thought about improving this code to see If I could solve some of
> this issues, But I came across django-formwizard
> <https://github.com/stephrdev/django-formwizard> which the author defines as
> a rewrite of django's formwizard with pluggable storages. I tried to reach
> the author Stepahn Jaekel without luck. I read the code of this application
> and it solves at list the first 3 issues listed before. It's missing big
> chunks of documentation and some methods share names with the contrib app
> but have different uses. But I think the approach is more DRY and more
> Django like.
>
> So I would like to propose to replace contrib.formwizard with
> django-formwizard app in Django 1.4. I could document the parts missing and
> work on integrating it, if there is interest in it. I solved the only issue
> I could find in django-formwizard 's code in my own fork
> <https://github.com/maraujop/django-formwizard> of the project.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
I just updated the cbv_refactor branch to use the generic class based views
from Django trunk. I hope everything works as supposed.
I would appreciate any help on writing documentation - even if its just a
draft but its a beginning ;-)
Looking forward to feedback!
Cheers,
steph
Miguel Araujo wrote:
> Hi Stephan,
>
> I'm sorry but I didn't get any answer on Github :)
>
> In that case, if you already discussed it with Jannie Leidel and Russell
> Keith-Magee, then I guess they liked the idea of replacing it with you app
> when it has some more work done. In that case if you are planning on working
> on it, I can offer you my humble help with anything you need. I can do my
> best documenting it in English, though I make mistakes often. I read the
> code thoroughly and all I did to it is in my fork. Hopefully the back
> browser's button will be fixed with class based views.
>
> If you want me I can work on a how-to draft with some basics on how to setup
> your app and get some basic wizards running.
>
> Only thing that disturbs my sleeping is the singleton issue. I would like
> someone can clarify why the singleton has a per interpreter scope instead of
> request scope.
>
> Kind regards,
>
> ----
> Miguel Araujo
> @maraujop
>
>
>
> 2010/12/26 Stephan J�kel <ma...@sjaekel.com <mailto:ma...@sjaekel.com>>
> <mailto:django-d...@googlegroups.com>.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com
> <mailto:django-developers%2Bunsu...@googlegroups.com>.
2010/12/26 Stephan Jäkel <ma...@sjaekel.com <mailto:ma...@sjaekel.com>>
https://github.com/stephrdev/django-formwizard/blob/master/formwizard/forms.py
I think this implementation misses the core point I was trying to
address with #9200, that you should not have to POST in order to
navigate to a step/form in the wizard. My implementation of course
was not as robust as the current one, but I think the point about
successful POST of a step/form should redirect to GET the next step is
valid. This is I think what leads to correct back/forward browser
navigation, and it also enables you to easily display links to
different steps in the wizard.
Please correct (or ignore) me, if I am mistaken.
Thanks,
Dave
you should take a look at the NamedUrlFormWizard. In this second approach,
after successful posting a form, a redirect is done to get the user to the
next step. Is this the point you meant?
Using the NamedUrlFormWizard, it's also possible to display links to
different steps.
Cheers,
Stephan
>> 2010/12/31 Stephan J�kel<ma...@sjaekel.com>
>>>> 2010/12/26 Stephan J�kel<ma...@sjaekel.com<mailto:ma...@sjaekel.com>>
Ah, yes. I see it right there in NamedUrlFormWizard.render_next_step.
I approve. Good work.
-Dave
--