Rails-style form value deserializer?

[Todd Blanchard]

One thing I'm keenly missing from rails is the form input naming convention that causes the form values to be converted into a hierarchy. For instance,

<input name="foo[bar]" value"one">
<input name="foo[baz]" value="two">

will result in the request values being stored as { 'foo' : {'bar' : 'one', 'baz' : 'two' }}

this is very handy when updating multiple related objects in a single form submit.

Is there a similar facility for django/python or will I need to write it?

-Todd Blanchard

[Jani Tiainen]

<input name="foo" value="one">

<input name="foo" value="two">

Result is stored in request.POST (or you can do same with get params, ?foo=one&foo=two). 

for example request.POST.getlist('foo'). Default getitem implementation returns only last occurence from list.

See: http://docs.djangoproject.com/en/1.1/ref/request-response/#querydict-objects for more info.

--

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

[Todd Blanchard]

How does this solve the problem of having two related objects that have the same attribute name (like "name") on the same html form?  As I see it, it doesn't.  There will be a conflict and it will be impossible to keep them separate.

IOW,

<form ... >

{{ account_form }}

{{ contact_form }}

<input type="submit">

</form>

def update_account_and_contact

if(request.POST)

account_form = AccountForm(request.POST, instance=get_object_or_404(Account, id=request.POST['id'])

contact_form = ContactForm(request.POST, instance=get_object_or_404(Contact, id=request.POST['id'])

if(account_form.is_valid() && contact_form.is_valid())

account_form.save()

contact_form.save()

.....

The rails solution is much superior.

[Antoni Aloy]

2009/12/19 Todd Blanchard <tblan...@mac.com>:

> How does this solve the problem of having two related objects that have the
> same attribute name (like "name") on the same html form?  As I see it, it
> doesn't.  There will be a conflict and it will be impossible to keep them
> separate.
> IOW,
> <form ... >
> {{ account_form }}
> {{ contact_form }}
> <input type="submit">
> </form>
> def update_account_and_contact
> if(request.POST)
> account_form = AccountForm(request.POST, instance=get_object_or_404(Account,
> id=request.POST['id'])
> contact_form = ContactForm(request.POST, instance=get_object_or_404(Contact,
> id=request.POST['id'])
> if(account_form.is_valid() && contact_form.is_valid())
> account_form.save()
> contact_form.save()
> .....
>
> The rails solution is much superior.
>

Thi is clearly explained in the Django documentation about forms
http://docs.djangoproject.com/en/dev/ref/forms/api/#ref-forms-api

Django documentation us much superior :-P

--
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

[Karen Tracey]

I think you might be looking for the form prefix argument:

http://docs.djangoproject.com/en/dev/ref/forms/api/#prefixes-for-forms

Karen

[Todd Blanchard]

Clear as mud. Where does it show how I update two objects in one form?

[Todd Blanchard]

I think what i actually want is a form set, but I don't find that all that well done either.

What I'm finding lacking is the ability to put a master/detail relationship in a single form.  For instance, Author/Books.  Furthermore, I don't see a nice way to work with dynamically expanding forms - IOW, allow the user to keep adding books to an Author using DHTML.

So far my impression of forms is - ick - lame.

-Todd Blanchard

[Matt Schinckel]

On Dec 20, 2:22 pm, Todd Blanchard <tblanch...@mac.com> wrote:
> I think what i actually want is a form set, but I don't find that all that well done either.
>
> What I'm finding lacking is the ability to put a master/detail relationship in a single form.  For instance, Author/Books.

You can achieve this with an inline formset.

> Furthermore, I don't see a nice way to work with dynamically expanding forms - IOW, allow the user to keep adding books to an Author using DHTML.

This, however, is harder. I have been thinking about the best way to
do this, and with a formset, you need to make sure that the POSTed
values match up with what the form management tags say.

More recently, I have been using jQuery, and the RESTful interface I
provided for my apps, to add an object. I haven't combined this with a
formset as yet, but one way might be to have a formset with a large
number of extra forms, that are hidden until a new one is added. This
feels a little hacky, however.

> So far my impression of forms is - ick - lame.

I think of forms as simply the method of sanitising the input from the
user. I have had to subclass the forms quite heavily, but it can
generally do what I want.

[Russell Keith-Magee]

On Sun, Dec 20, 2009 at 12:22 PM, Todd Blanchard <tblan...@mac.com> wrote:
> I think what i actually want is a form set, but I don't find that all that
> well done either.

I would like to point out that so far, you haven't actually told us
what your problem *is*. You've asked how Django does something that
Rails can apparently do, but you haven't told us what problem Rails is
trying to solve when it does what you describe.

> What I'm finding lacking is the ability to put a master/detail relationship
> in a single form.  For instance, Author/Books.  Furthermore, I don't see a
> nice way to work with dynamically expanding forms - IOW, allow the user to
> keep adding books to an Author using DHTML.

That's because Django doesn't handle this problem as a single form.
Instead, Django treats each database object as a separate form, and
then you put multiple forms into your view. When you have multiple
related objects (e.g., multiple books related to a single author), you
have a form for the author, then a FormSet [1] for the collection of
books. The formset is itself a collection of forms, one form for each
book.

[1] http://docs.djangoproject.com/en/dev/topics/forms/formsets/

As for dynamically expanding forms - Django treats that as a client
side problem. Django doesn't ship with any javascript dependencies in
it's form library, so it doesn't provide dynamically expanding forms
out of the box.

It's not that difficult to do, though. You just have to dynamically
create form elements, and tweak the formset management fields [2] in
the submitted form.

[2] http://docs.djangoproject.com/en/dev/topics/forms/formsets/#formset-validation

> So far my impression of forms is - ick - lame.

You've been told this before, but it bears repeating: if you'd like to
continue to receive the assistance of those in the Django community,
you might want to consider toning down the epithets. If you don't, you
might find your calls for assistance being ignored by the people that
are best able to assist you.

Yours,
Russ Magee %-)

[Todd Blanchard]

Yeah - I'm going to shelve django and see what is up with TG2 and its Geo extensions for awhile.

It has become very clear that it is "not a fit" for the kind of dynamic web application development I'm looking for. I need effective and well integrated ajax out of the box and the ability to compose forms dynamically and quickly.

Thanks for the help. I may pick it up again - but probably not for this project.

-Todd Blanchard