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? (ma
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 t
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 ther
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 con
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
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).
Cheer
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
Hi,
TiNo wrote:
On Sat, May 29, 2010 at 22:07, Stephan Jäkel mailto:m...@sjaekel.com>> 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 directi
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
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 back
+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 se
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
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.Na
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
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 t
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
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
18 matches
Mail list logo
