> Do you know Colander? I do now. Thanks, that's very similar, and looks well done.
> I personally think that Forms are already the place that should handle (de)serialisation. They already serialise to HTML: why should they not be able to serialise to other stream types? Conceptually I agree. As it happens django-serializers is perfectly capable of rendering into HTML forms, I just haven't yet gotten around to writing a form renderer, since it was out-of-scope of the fixture serialization functionality. Pragmatically, I'm not convinced it'd work very well. The existing Forms implementation is tightly coupled to form-data input and HTML output, and I think trying to address that without breaking backwards compatibility would be rather difficult. It's maybe easy enough to do for flat representations, and pk relationships, but extending it to deal with nested representations, being able to use a Form as a field on another Form, and representing custom relationships would all take some serious hacking. My personal opinion is that whatever benefits you'd gain in DRYness, you'd lose in code complexity. Having said that, if someone was able to hack together a Forms-based fixture serialization/deserialization implementation that passes the Django test suite, and didn't look too kludgy, I'd be perfectly willing to revise my opinion. There's also some subtle differences between serializer fields, and Django's existing form fields. Because form fields only handle form input, incoming fields can never be null, only blank or not blank. With other representations such as JSON, that's not the case, so for serializer fields, the blank=True/False null=True/False style is appropriate, whereas for form fields the required=True/False style is appropriate. I'm also wary of getting bogged down in high level 'wouldn't it be nice if...' conversations. With just a little bit of work, the django-serializers implementation could be turned into a pull request that'd replace the existing fixture serialization with something much more useful and flexible. What I'm really looking for is some feedback on if it'd be worth my time. Regards, Tom On Wednesday, 29 August 2012 06:27:35 UTC+1, schinckel wrote: > > Hi Tom, > > I've knocked around ideas of my own (internally, and on #django) related > to serialisation: it's something I've had lots to think about, since until > recently, most of my django work was in JSON apis. > > I personally think that Forms are already the place that should handle > (de)serialisation. They already serialise to HTML: why should they not be > able to serialise to other stream types? > > This is the approach I've started to use for my API generation code. They > already have a declarative nature, and then you get all of the form > validation on incoming data: a big improvement over how I've done it in the > past. > > (I've done some work on a form-based API generation framework: > https://bitbucket.org/schinckel/django-repose. Whilst this is in use, > it's still not really feature complete). > > Matt. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/Lc0fSSAdz4IJ. 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/django-developers?hl=en.
