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. :) On Monday, 6 June 2016 19:59:02 UTC+10, Xavier Ordoquy wrote: > > Hi Daniel > > > Le 5 juin 2016 à 10:30, Daniel Haggard <[email protected] > <javascript:>> a écrit : > > > > 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 :) > > > 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. > > -- You received this message because you are subscribed to the Google Groups "Django REST framework" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
