Re: Proposal: Replace django.contrib.formtools.wizard

[shacker]

On Sep 8, 1:27 pm, Anssi Kaariainen  wrote:

> > This is a real special case. ATM the formwizard isn't able to store invalid
> > forms. But if you are at the sprints in Portland, I would be happy to talk
> > to you about possible solutions.
>
> > Do you have any idea how this could be solved? (maybe you already patched
> > the formwizard to support this?)

I haven't  attempted patching formwizard - I'm not at that level :)
Was just letting you know the need is out there, since you're working
on this part of the system.

I'll probably end up doing as Anssi suggests and pickle the temporary
form data, only saving it to a db record once all fields are valid.

Thanks,
Scot

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Anssi Kaariainen]

On Sep 8, 7:47 pm, Stephan Jäkel  wrote:
> Hi Scot,
>
> shacker wrote:
> > Not all forms are completed in a single sitting. We have a form with
> > more than 100 fields, which takes at least two hours for the user to
> > complete. Therefore it's essential that the (authenticated) user be
> > able to save it and return later to edit or complete it. IOTW there is
> > a need for resumable forms. The problem arises when you have required
> > fields - if these aren't filled out yet, form.is_valid() will never
> > pass, so you can't elegantly save it to be resumed later.
>
> This is a real special case. ATM the formwizard isn't able to store invalid
> forms. But if you are at the sprints in Portland, I would be happy to talk
> to you about possible solutions.
>
> Do you have any idea how this could be solved? (maybe you already patched
> the formwizard to support this?)
>
> Cheers,
>
> steph

I might be missing something obvious here, but couldn't the
request.POST be serialized upon temporary save, and then when
continuing work the form will use the saved POST data as its initial
value?

By the way, I am working on creating easy-to-display forms. The idea
is that BoundFields will have .display_value property, which will
return the entered data in human readable format. I think it could be
useful for "preview changes" step. If something like this is needed,
take a look at: http://github.com/akaariai/django/tree/ticket10427.
Basically any form (barring forms with FileFields, which I really
don't know how to handle at the moment) can be shown by using code
like this:

{% for field in form.visible_fields %}
{{ field.label }}: {{field.display_value}}
{% endfor %}

The code should be able to handle MultipleSelectFields and so on.
Unfortunately I haven't had enough time to work on it lately, so there
is still some work to do.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi Scot,

shacker wrote:

Not all forms are completed in a single sitting. We have a form with
more than 100 fields, which takes at least two hours for the user to
complete. Therefore it's essential that the (authenticated) user be
able to save it and return later to edit or complete it. IOTW there is
a need for resumable forms. The problem arises when you have required
fields - if these aren't filled out yet, form.is_valid() will never
pass, so you can't elegantly save it to be resumed later.


This is a real special case. ATM the formwizard isn't able to store invalid 
forms. But if you are at the sprints in Portland, I would be happy to talk 
to you about possible solutions.


Do you have any idea how this could be solved? (maybe you already patched 
the formwizard to support this?)


Cheers,

steph

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[shacker]

On Sep 7, 6:00 pm, Stephan Jäkel  wrote:
> Hi,
>
> about 4 months ago, I started this thread. I want to give some news on
> django-formwizard to keep you all up2date.

Great to hear this is being worked on. At the djangocon forms session
today, I raised the following question and didn't get any concrete
suggestions. Hoping the new FormWizard will address this use case:

Not all forms are completed in a single sitting. We have a form with
more than 100 fields, which takes at least two hours for the user to
complete. Therefore it's essential that the (authenticated) user be
able to save it and return later to edit or complete it. IOTW there is
a need for resumable forms. The problem arises when you have required
fields - if these aren't filled out yet, form.is_valid() will never
pass, so you can't elegantly save it to be resumed later.

I would love to see FormWizard (or Forms in general) provide some
mechanism to deal with this.

Thanks,
Scot

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

about 4 months ago, I started this thread. I want to give some news on 
django-formwizard to keep you all up2date.


Stephan Jäkel wrote:

The last not solved problem is handling file uploads.


This problem is solved. The formwizard supports file uploads in any step. I 
solved the problem by providing or at least requiring the user to provide a 
file storage for storing temp data. The storage backend is responsible for 
removing old data/files. The formwizard only removes the temp. data when the 
wizard gets finished by the uploading user.


I'm currently working on a example storage which can clean its data itself.

I also did some work on getting the app thread-safe.

Another new feature is conditions for form-steps. Using these conditions you 
can skip/show steps depending on - for example - other steps' data. (see 
testapp2 in the test_project)


The docs got some updates too but need to be extended.. The docs are hosted 
on RTD, http://django-formwizard.readthedocs.org/


See the develop branch for the latest changes, 
http://github.com/stephrdev/django-formwizard/tree/develop


Cheers,

steph

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

Alex Gaynor wrote:

My one comment (and we discussed this on IRC) is that this really
should inherit from GenericView IMO, so it'd be nice if that landed
before this.


Agreed, many stuff in formwizard/classbased-views is duplicated. (I actually 
got the thread-safety bit from there).


Cheers,

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

Harro wrote:

+1 on the storage backend. Can the current filestorage backend be
reused for this?


I think yes, but will need some extensions for invalidation of files. But 
can be subclassed (already wrote a experimental backend for doing this)


Cheers,

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

TiNo wrote:

On Sat, May 29, 2010 at 22:07, Stephan Jäkel > wrote:

I already discussed this ticket with Jannis during the sprints and
hope to start a discussion here to find the right way to allow file
uploads and see if my approach takes the right direction.


Couldn't you just use python's /tempfile.NamedTemporaryFile/[1]? That
way the file will get cleaned by the filesystem itself, unless you move
it somewhere else in your ``done`` method. If you pass delete=False, you
will be able to open the file again in the last step, as long as you
properly closed it before.


Could work but going this way, we cannot control how long the file will 
exist (I most ways it has to be there until the session is expired).


Cheers,

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

Harro wrote:

We had a site where we needed a wizard with the ability to go back and
forward and store files.
Only allowing files in the last step really isn't an option imho, that
just avoiding the problem ;-)


I totally agree. But it is _one_ option to get around the problem.


What we did was simply store the files in a temporary folder and have
a management command to clean them up when needed. (The files where
stores with a timestamp in the name so we knew when they where old).


Basicly I like this idea. But this is a design decision - how to get rid of 
old files. Going this way, there is also a risk to get dos'ed by bot which 
upload tons of files. If the bots are fast enough, your disk get out of 
space quickly.


I also thought about extending the cleanup-management command, which - atm - 
only removes old/expired sessions. Maybe this could get extended to also 
remove files which a prefix of the session id or something like that.


Cheers,

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Hi,

Jacob Kaplan-Moss wrote:

I couldn't tell from my quick play, though, if there were any
backwards-incompatible changes. There's a fair bit of code churn (in a
good way :), so before we could merge this I'd like a sense of what
any backwards-compatibily concerns would be.


There are some backwards-compatibility issues. I'm currently preparing a 
guide to migrate from the old formtools.wizard to django-formwizard. This 
example will hopefully make the changes clear and migration simple.


Cheers,

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Harro]

+1 on the storage backend. Can the current filestorage backend be
reused for this?


On May 31, 10:44 am, Gert Van Gool  wrote:
> MEDIA_ROOT isn't a good solution. It should use a StorageBackend.
> For instance, when you use a load-balancer there is no guarantee that
> your session hits the same server twice.
>
> -- Gert
>
> Mobile: +32 498725202
> Web:http://gert.selentic.net
>
>
>
> On Mon, May 31, 2010 at 10:36, Gregor Müllegger  wrote:
> > Storing the file in a temporary directory is elegant but brings up
> > some new problems.
>
> > IMO it's critical - if you want to support file uploads - to put these
> > files into MEDIA_ROOT. Otherwise you wouldn't be able to show previews
> > of uploaded images etc.
>
> > 2010/5/30 TiNo :
> >> On Sat, May 29, 2010 at 22:07, Stephan Jäkel  wrote:
>
> >>> I already discussed this ticket with Jannis during the sprints and hope to
> >>> start a discussion here to find the right way to allow file uploads and 
> >>> see
> >>> if my approach takes the right direction.
>
> >> Couldn't you just use python's tempfile.NamedTemporaryFile[1]? That way the
> >> file will get cleaned by the filesystem itself, unless you move it 
> >> somewhere
> >> else in your ``done`` method. If you pass delete=False, you will be able to
> >> open the file again in the last step, as long as you properly closed it
> >> before.
> >> TiNo
> >> [1] http://docs.python.org/library/tempfile.html#tempfile.NamedTemporaryFile
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Django developers" group.
> >> To post to this group, send email to django-develop...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> django-developers+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >>http://groups.google.com/group/django-developers?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Gert Van Gool]

MEDIA_ROOT isn't a good solution. It should use a StorageBackend.
For instance, when you use a load-balancer there is no guarantee that
your session hits the same server twice.

-- Gert

Mobile: +32 498725202
Web: http://gert.selentic.net



On Mon, May 31, 2010 at 10:36, Gregor Müllegger  wrote:
> Storing the file in a temporary directory is elegant but brings up
> some new problems.
>
> IMO it's critical - if you want to support file uploads - to put these
> files into MEDIA_ROOT. Otherwise you wouldn't be able to show previews
> of uploaded images etc.
>
> 2010/5/30 TiNo :
>> On Sat, May 29, 2010 at 22:07, Stephan Jäkel  wrote:
>>>
>>> I already discussed this ticket with Jannis during the sprints and hope to
>>> start a discussion here to find the right way to allow file uploads and see
>>> if my approach takes the right direction.
>>
>> Couldn't you just use python's tempfile.NamedTemporaryFile[1]? That way the
>> file will get cleaned by the filesystem itself, unless you move it somewhere
>> else in your ``done`` method. If you pass delete=False, you will be able to
>> open the file again in the last step, as long as you properly closed it
>> before.
>> TiNo
>> [1] http://docs.python.org/library/tempfile.html#tempfile.NamedTemporaryFile
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Gregor Müllegger]

Storing the file in a temporary directory is elegant but brings up
some new problems.

IMO it's critical - if you want to support file uploads - to put these
files into MEDIA_ROOT. Otherwise you wouldn't be able to show previews
of uploaded images etc.

2010/5/30 TiNo :
> On Sat, May 29, 2010 at 22:07, Stephan Jäkel  wrote:
>>
>> I already discussed this ticket with Jannis during the sprints and hope to
>> start a discussion here to find the right way to allow file uploads and see
>> if my approach takes the right direction.
>
> Couldn't you just use python's tempfile.NamedTemporaryFile[1]? That way the
> file will get cleaned by the filesystem itself, unless you move it somewhere
> else in your ``done`` method. If you pass delete=False, you will be able to
> open the file again in the last step, as long as you properly closed it
> before.
> TiNo
> [1] http://docs.python.org/library/tempfile.html#tempfile.NamedTemporaryFile
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[TiNo]

On Sat, May 29, 2010 at 22:07, Stephan Jäkel  wrote:

> I already discussed this ticket with Jannis during the sprints and hope to
> start a discussion here to find the right way to allow file uploads and see
> if my approach takes the right direction.
>

Couldn't you just use python's *tempfile.NamedTemporaryFile*[1]? That way
the file will get cleaned by the filesystem itself, unless you move it
somewhere else in your ``done`` method. If you pass delete=False, you will
be able to open the file again in the last step, as long as you properly
closed it before.

TiNo

[1] http://docs.python.org/library/tempfile.html#tempfile.NamedTemporaryFile

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Alex Gaynor]

On Sun, May 30, 2010 at 12:33 PM, Harro  wrote:
> We had a site where we needed a wizard with the ability to go back and
> forward and store files.
> Only allowing files in the last step really isn't an option imho, that
> just avoiding the problem ;-)
>
> What we did was simply store the files in a temporary folder and have
> a management command to clean them up when needed. (The files where
> stores with a timestamp in the name so we knew when they where old).
>
> I'm for having a better form wizard in django. +1
>
>
>
> On May 30, 11:15 am, Jacob Kaplan-Moss  wrote:
>> Hey Steph --
>>
>> I've had a chance to play with your code, and I'm impressed and
>> generally +1 on replacing formwizard with yours.
>>
>> I couldn't tell from my quick play, though, if there were any
>> backwards-incompatible changes. There's a fair bit of code churn (in a
>> good way :), so before we could merge this I'd like a sense of what
>> any backwards-compatibily concerns would be.
>>
>> Thanks!
>>
>> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

My one comment (and we discussed this on IRC) is that this really
should inherit from GenericView IMO, so it'd be nice if that landed
before this.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Harro]

We had a site where we needed a wizard with the ability to go back and
forward and store files.
Only allowing files in the last step really isn't an option imho, that
just avoiding the problem ;-)

What we did was simply store the files in a temporary folder and have
a management command to clean them up when needed. (The files where
stores with a timestamp in the name so we knew when they where old).

I'm for having a better form wizard in django. +1



On May 30, 11:15 am, Jacob Kaplan-Moss  wrote:
> Hey Steph --
>
> I've had a chance to play with your code, and I'm impressed and
> generally +1 on replacing formwizard with yours.
>
> I couldn't tell from my quick play, though, if there were any
> backwards-incompatible changes. There's a fair bit of code churn (in a
> good way :), so before we could merge this I'd like a sense of what
> any backwards-compatibily concerns would be.
>
> Thanks!
>
> Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: Replace django.contrib.formtools.wizard

[Jacob Kaplan-Moss]

Hey Steph --

I've had a chance to play with your code, and I'm impressed and
generally +1 on replacing formwizard with yours.

I couldn't tell from my quick play, though, if there were any
backwards-incompatible changes. There's a fair bit of code churn (in a
good way :), so before we could merge this I'd like a sense of what
any backwards-compatibily concerns would be.

Thanks!

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Proposal: Replace django.contrib.formtools.wizard

[Stephan Jäkel]

Proposal: Replace django.contrib.formtools.wizard

This proposal is about replacing the current form wizard, because it is not 
usable in many ways. According to ticket #9200, the new form wizard module 
should

a) have multiple storage backends to save the form data for the single steps. 
(The ticket calls for a session based backend)

b) support all kinds of form classes, which include
1) Form
2) ModelForm
3) FormSet

c) support all kinds of form fields, including ModelChoiceFields, 
ManyToManyFields and FileFields

The ticket already has some patches, but no patch solves all problems or hasn't 
decent tests and documentation. Because of this, I started to write a complete 
new external app, which solves nearly all problems, has full test coverage and 
is documented well.

The last not solved problem is handling file uploads. In my opinion, there are 
two ways to solve the file uploading issue.

Before I describe my ideas of solving the problem, I'll try to explain the 
problem itself. When uploading files, the uploaded data needs to be stored at 
some place. The problem is, removing the files at the right time. But what is 
the right time? The right time is the expiration date of the other form data 
stored in a session, cookie or somewhere else.

To easiest way to prevent having this problem, is not allowing file uploads, or 
at least only allow file uploads in the last step (because the next request 
would do the processing form data stuff like saving data to database...).

Another way to allow file uploads would need changes in the file storage 
backends to add a method to invalidate/remove data after a certain amount of 
time. But I think this would be a much harder way to solve the file uploading 
stuff and maybe it gets to complicated to end developers.

I already discussed this ticket with Jannis during the sprints and hope to 
start a discussion here to find the right way to allow file uploads and see if 
my approach takes the right direction.

Coming to the pragmatic stuff, the API of django-formwizard is in some ways 
different to the current formwizard API, but a convertion shouldn't be that 
hard (won't need more changes than for example the new-comments migration).

The current documentation is available on GitHub 
(http://stephrdev.github.com/django-formwizard/). I will add a migration guide 
when I think that new API is stable.

The current code is available on GitHub too 
(http://github.com/stephrdev/django-formwizard/) 

steph

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.