Handling of nested form data with a writable nested serializer

[Daniel Haggard]

Hi folks,

I had this issue recently where I had a writeable serializer nesting User info under the key 'owner', that was passing validation (because it contained the owner related data) but then removing the entire owner field from the validated data.  This would get passed up to my update method which would hang because it was expecting to find owner data to play with.  This was happening when I was using FormData objects on the client side, and it was perplexing because it wasn't happening if I used json instead.

Turns out it was caused by get_value() method on the nested serializer which would call the utils.html.parse_html_dict function when it gets a QueryDict objects (as it does when it handles FormData).  This is turn does a regex match between the submitted keys in the FormData and the field names.  If it finds no match between a key and a field it returns empty.  The regex specifies that to match,  the key which is used to represent nested data must include a full_stop character.  So in my case the keys of nested data should look something like:  'owner.email'.  But because all I had included was a key: 'owner'.  The regex never found a match.

No big deal - as I now know what I should be doing.  But I'm just wondering if this convention for nested data in FormData objects is documented in the api docs?  I've spent quite a lot of time looking for it - but couldn't find anything.  But apologies if I missed it.  Or is this just a standard convention for getting around the limits of form nesting in html5?  My googling on that topic is that lots of folk do lots of very different things.

Also - I'm wondering if it's ideal that the serializer should be able to pass validation in this instance?

Thanks for your time :)

[Xavier Ordoquy]

Hi Daniel

At the moment, nested writable nested forms are not supposed to work. There is possibly an exception for a direct foreign key relation.
I’m currently working on making writable nested forms working in all the cases.
I’ll give some thought about adding documentation on that part.

I’m not sure I correctly understood your issue.
Browsable API should have the correct names right out of the box. It’ll also display a comment about nested forms not working if it doesn’t.

Regards,
Xavier,
Linovia.

[Daniel Haggard]

Thanks for the response :)

We are currently building our forms using React on the front end - not using DRF to generate the forms - but we are using DRF's views and serializers.  So there are no problems with DRF's forms or the browsable api.

I opted to use a writable nested serializer to try and save on a few calls to the server.  I had been using json to send the data and that was fine, but since DRF has a form parser - it happens to be convenient for various reasons to use it instead.  I've had to write custom update methods - but that was no problem and nicely documented.  It was just a matter of figuring out what the client should be sending so that it was properly included in the validated data.  I can understand though if our use case is not common enough to warrant including that information in the docs. 

You can ignore what I said about it managing to pass validation when it shouldn't have (that was my silly mistake).  So really there are no problems with DRF code at all - just a doc suggestion.  :)

[Daniel Haggard]

Oh, my apologies.  I think I understand you better now.  it was a direct foreign key that I managed to get it to work with..  Just tried it with a many-to-many field and as you point out it doesn't like it.  I'll go back to using json.  I suppose i would change my doc request to a warning - perhaps in the api guide in the section on writeable nested serializers - that they aren't compatible currently with formdata objects. 

Cheers,

Dan

On Monday, 6 June 2016 19:59:02 UTC+10, Xavier Ordoquy wrote: