Right, after a bit of black magic, a few false starts and a fair bit of
reworking, djmultipartform is actually working as its meant to more
than just an abstract concept which i posted last time.
* www.halfapenguin.com/djmultipartform-0.1.tar.gz
* www.halfapenguin.com/djmultipartform-0.1.zip
Right, after a bit of black magic, a few false starts and a fair bit of
reworking, djmultipartform is actually working as its meant to more
than just an abstract concept which i posted last time.
www.halfapenguin.com/djmultipartform-0.1.tar.gz
www.halfapenguin.com/djmultipartform-0.1.zip
(in ca
I created the ticket containing the wizard proposal, it includes new
cleaned up version that offers a lot more flexibility...
http://code.djangoproject.com/ticket/3218
On 12/27/06, Honza Kr l <[EMAIL PROTECTED]> wrote:
So,
a little example with dynamic forms, I hope you don't mind
pseudo-code,
So,
a little example with dynamic forms, I hope you don't mind
pseudo-code, I don't feel like writing a working standalone example
and I cannot publish my application (its in Czech anyway ;) )
urls.py:
urlpatterns = patterns('some.app.views',
(r'wizard/$', 'my_wizard' ),
)
some/app/views.py:
f
Hello all,
I got bored during the holiday, so I put together a simple
implementation of django.contrib.formtools.wizard...
Features:
all data are kept in POST, nothing is stored on the server (this is
simply not very good for file uploads, but should be OK for the
majority)
security_hash from
One slight modification, there was debugging code left in, which I've
now fixed.
--~--~-~--~~~---~--~~
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@goo
Hi,
I'm Ben's (Afternoon) collegue Tom,
As much as I was asked to be interesting, I don't do interesting, or at
least when I do, people fall asleep
http://www.halfapenguin.com/djmultipartform.tar.gz
I've posted the code sample on my server, its not complete, but it is a
snapshot of where w
On Mon, Dec 11, 2006 at 11:52:19AM -0800, Kevin wrote:
> I'm mainly concerned with the scenario where credit cards are used as
> part of the form. I haven't found too many supported cryptography
> libraries for python though.
>
As far as crypto libraries go, I've used the Python Cryptography Too
On 12/11/06, Kevin <[EMAIL PROTECTED]> wrote:
>
>
> I like the idea of storing an encoded-pickled version of the form data
> in a hidden field. I'm concerned about privacy implications with
> sharing that data with the client. What about encrypting the contents
> too? The server could have a pri
Isn't the session a natural place to store these kinds of things? Is
there a reason for the avoidance of sessions? Are they buggy? Do they
require some sort of over-head people are trying to avoid?
Just curious,
Rob
On 20061211.1152, Kevin said ...
>
> I like the idea of storing an encoded-p
I like the idea of storing an encoded-pickled version of the form data
in a hidden field. I'm concerned about privacy implications with
sharing that data with the client. What about encrypting the contents
too? The server could have a private key that it encrypts the
serialized form data and de
We are definitely interested in sharing, that was our initial
intention.
The code is by no means finished, but my colleague Tom will post an
interim version and some notes on our design soon. Hopefully it will be
interesting.
--~--~-~--~~~---~--~~
You received t
Hi,
nice work. I have been trying to come up with a solution of my own,
but I ran into some problems/questions:
1) I think it would be better to allow (but not force) users to add
actions after every step and a final done() - I have NO idea how to do
this, at least no working idea...
2) I don't k
Here's an example template:
{% extends "base.html" %}
{% block content %}
{% if form.errors %}Please correct the following errors{% else
%}{{ form_step_name }}{% endif %}
{{ form }}
{% if not first %}
{% endif %}
{% if not last %}
{% endif %}
{% if last %}
{% endif %}
{% endb
Here's a first attempt. As such, this code does per-page validation
only.
import cPickle as pickle
import base64
from django.core.exceptions import ImproperlyConfigured
from django.http import HttpResponse,HttpResponseRedirect
from django.shortcuts import render_to_response
from django.newforms
On 8 Dec 2006, at 19:10, JP wrote:
> What I've always done in these cases is carry a MAC along with the
> hidden data and just validate that the hidden data hasn't changed by
> re-hashing it after each form submit. You don't really need to
> re-validate the already-validated data, you just need to
> > You could probably have a partial validation, per-page, and a complete
> > one on the final page, essentially re-validating all the fields.
> > HTML-escaping of these hidden fields values would be mandatory in all
> > cases anyway.
>
> Yes, my thoughts exactly. Per-page validation, plus a fina
On 12/5/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> It's an abstraction of the workflow "Display an HTML form, force a
> preview, then do something with the submission."
Very slick.
> What other sorts of things can we make abstractions for,
> given a Form?
I wanted to come up with a standa
Isn't it useful to allow two-step validation in general: one by the
form and one by the model when saving (both optional of course). This
would allow to add constraints to a form that are not needed by the
model in general (interesting when using different forms on the same
model eg for different
Adrian Holovaty wrote:
> On 12/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Yes, something along the lines of the wizard control in ASP.NET.
> > Ideally, nothing is committed to the db unless all the pages in the
> > wizard are validated. Whether this is done by capturing the
> > inter
Waylan Limberg wrote:
> Presumably each page would do validation on submit (we don't want to
> send the user back to page one after completing 10 pages). If the
> validated data is now in hidden fields, couldn't someone alter that
> data (with evil intent) requiring re-validation?
Why would it be
I'm interested.
--~--~-~--~~~---~--~~
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 [EMAI
Adrian Holovaty wrote:
> Also, this is only the beginning of django.contrib.formtools, which I
> intend to be a collection of common high-level form operations such as
> this one. What other sorts of things can we make abstractions for,
> given a Form?
I do have an idea, almost an obsession: I
On 12/7/06, Antonio Cavedoni <[EMAIL PROTECTED]> wrote:
> On 12/7/06, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> > Presumably each page would do validation on submit (we don't want to
> > send the user back to page one after completing 10 pages). If the
> > validated data is now in hidden fields,
On 12/7/06, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> Presumably each page would do validation on submit (we don't want to
> send the user back to page one after completing 10 pages). If the
> validated data is now in hidden fields, couldn't someone alter that
> data (with evil intent) requiring
On 12/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> This would be a great addition. Rather than requiring sessions, what
> do you think of passing intermediate form data in hidden fields? It's
> simpler, it wouldn't require cookies and I can't immediately think of
> any downsides to the appro
On 20061207.0851, Adrian Holovaty said ...
> This would be a great addition. Rather than requiring sessions, what
> do you think of passing intermediate form data in hidden fields? It's
> simpler, it wouldn't require cookies and I can't immediately think of
> any downsides to the approach.
One do
On 12/7/06, Antonio Cavedoni <[EMAIL PROTECTED]> wrote:
> > This would be a great addition. Rather than requiring sessions, what
> > do you think of passing intermediate form data in hidden fields?
>
> Isn't that the way the dreaded ASP.NET "view state" works? Saving
> marshaled temporary data in
On 12/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> This would be a great addition. Rather than requiring sessions, what
> do you think of passing intermediate form data in hidden fields?
Isn't that the way the dreaded ASP.NET "view state" works? Saving
marshaled temporary data in a hidden f
On 12/7/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> Adrian Holovaty wrote:
> > This would be a great addition. Rather than requiring sessions, what
> > do you think of passing intermediate form data in hidden fields?
>
> +1
>
> It's cleaner anyway since all data accumulated in one place.
>
+1
Adrian Holovaty wrote:
> This would be a great addition. Rather than requiring sessions, what
> do you think of passing intermediate form data in hidden fields?
+1
It's cleaner anyway since all data accumulated in one place.
--~--~-~--~~~---~--~~
You received th
Adrian Holovaty wrote:
> On 12/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Yes, something along the lines of the wizard control in ASP.NET.
>> Ideally, nothing is committed to the db unless all the pages in the
>> wizard are validated. Whether this is done by capturing the
>> intermedi
On 12/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Yes, something along the lines of the wizard control in ASP.NET.
> Ideally, nothing is committed to the db unless all the pages in the
> wizard are validated. Whether this is done by capturing the
> intermediate form data in the session o
Yes, something along the lines of the wizard control in ASP.NET.
Ideally, nothing is committed to the db unless all the pages in the
wizard are validated. Whether this is done by capturing the
intermediate form data in the session or by rolling back a db
transaction, I'm not sure. DB transaction
Adrian Holovaty wrote:
> What other sorts of things can we make abstractions for,
> given a Form?
Wizards, maybe? Given a series of forms, run through them all appending data
from previous forms to next ones, or processing each in turn. Maybe an option
to
have it do either, so you can process
On 12/6/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> Next on the list should be a Login form.
What would you envision for that?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you are subsc
Next on the list should be a Login form.
Should be very simple.
On 12/5/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> > Adrian Holovaty wrote:
> > > What other sorts of things can we make abstractions for,
> > > given a Form?
> >
> > Fi
This looks pretty cool. I'm excited by the new forms development and
hope to play with some of it soon.
It seems a little out of place to me to instantiate an object in
urls.py:
(r'^post/$', MyFormPreview(MyForm)),
(There was some thread talking about urls.py becoming more of a
"controller
Adrian Holovaty wrote:
> Yes, *definitely*...That one is next on the list.
I just wanted to make sure :-). I'm about to create a forum for my site
and am waiting for this bit to use it and test it :-)
--~--~-~--~~~---~--~~
You received this message because you a
On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Adrian Holovaty wrote:
> > What other sorts of things can we make abstractions for,
> > given a Form?
>
> First thing that comes to mind is the same thing you describe but
> without preview. In other words it's what update_object generic view
Adrian Holovaty wrote:
> What other sorts of things can we make abstractions for,
> given a Form?
First thing that comes to mind is the same thing you describe but
without preview. In other words it's what update_object generic view
does now but it works only on models and often it is desired t
I've just checked in a new bit of Django functionality I've been
developing for the past couple of days (extracted from some production
code).
It's an abstraction of the workflow "Display an HTML form, force a
preview, then do something with the submission." If you're familiar
with the forced-pre
42 matches
Mail list logo
