Thanks Chris! I was just struggling with this same issue -- in the past five minutes in fact. This workaround is perfect for me, and perfectly timed.
I'll just add one additional hitch that I found regarding multipart forms while trying to solve this on my own: Django actually seems to set request.raw_post_data to an empty string if the request's content-type is multipart, so if the form's enctype is not changed before submission there is no way to reconstruct the original ordered request body in Django views. There's a Django ticket about this here: https://code.djangoproject.com/ticket/9054 Thanks again! -Ethan On Fri, Aug 19, 2011 at 7:00 PM, Chris Pyper <[email protected]> wrote: > Thanks for the input buddy! > > I found a work around. For anyone else with the same issue here it > is: > > Deform for sequences use special hidden ordered fields for delimiting > where groupings begin and end. If you look at the raw POST data you > can see them everywhere named “__start__” and “__end__”. However, > Django mangles this in the QueryDict it uses to represent POST data. > This dictionary data type cannot have duplicate keys, and does not > guarantee order, so you have missing delimiters and everything is out > of order. Deform can’t work with this mess. To fix this you need to > parse the raw POST data yourself and make sure it stays in order. > Python actually has a function to parse raw POST data already and > return it as the same structure that deform needs. Just use the > parse_qsl() function from the urlparse module. > > from urlparse import parse_qsl > controls = parse_qsl(request.raw_post_data, keep_blank_values=True) > appstruct = form.validate(controls) > > Just remember to change the form enctype under the template 'templates/ > form.pt’(directly or via js) from 'multipart/form-data' to > 'application/x-www-form-urlencoded’, as the parse_qsl() function > cannot handle multipart data. That said, you won’t be able to use > file upload functionality in your forms. As for finding a solution in > Python to parse multipart data, there were none that were simple. > They were all very complex and strongly tied to their respective > frameworks and librairies. > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
