New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serialization and rendering #15
Comments
Could the serializer accept the renderer / encoder as an option? Or have a default? For an API representation: class APIUserSerializer(Serializer):
renderer_class = JSONRenderer
... For a template form: class FormUserSerializer(Serializer):
renderer_class = HTMLFormRenderer
... Then doing something like: s = APIUserSerializer(data=data)
s.serialize()
>>> # Output is in the format defined by the renderer This would allow for some neater grouping and also give some customisation, such as providing your own renderer. This allows renderers to handle specific datatypes like We're almost definitely doing a rehash of some components of DRF, but for me this whole idea started as I saw benefit of some parts of DRF being useful in Core Django :) |
It's an interesting question where the limits of what the core object is responsible for is. My ideas are currently more around the Serializer class knowing the "rules" about itself, but delegating everything it does to other pluggable layers - validation, data extraction, rendering etc. I think the main thing I'd like to try and do if we can is to make it possible that you can do the above easily if you want - it's about a framework. DRF is a good framework in itself, but in reality validation and data extraction/de-extraction are still quite entangled. In Django.forms, rendering and parsing are also entangled in the same layers. |
The need to serialize rich objects will definitely arise but I don't think that should be the job of a serializer (i.e. a thing that converts a simple, almost dict-like structure with simple value types (str, int, etc.) to something else like JSON or an HTML form). |
The issue with that is that the "rich"er data types supported depends on the transport encoding. In particular, www-form-encoded ONLY supports strings and arrays, no booleans, nested dicts etc. |
The reducer in this case could be a simple type of renderer? Encoding the data from an external data type to an internal version (like your unreducer) could also be encompassed within this. |
Yes, I guess the reducer would actually be a simple renderer itself. So you would then have something like:
On second thought I'm not sure if that should be the case. Because if you start chaining renderers this violates the idea of "every renderer gets the same kind of predefined input data". |
I do not know where to post this, but this project reminded me vaguely that other project https://github.com/WiserTogether/django-remote-forms |
In core Django, I think the job of converting simple data to/from rich internal data is done by the |
|
@luzfcb Thanks a lot for that! I didn't know about that project (or the 2012 talk). That's definitely one of the problems we hope to tackle - only with an underlying data structure which is more abstract, rather than tied to the implementation of @MoritzS @Ian-Foote Yes, and that |
We're not sticking to HTML forms at all, in fact we thought about it to be exactly as you described it: Just another rendering options besides JSON or other formats. |
💃 |
A few different form libraries have been mentioned on #17 which I think are actually more in scope for this issue: |
Serialization is strictly the process of getting from a rich object to a bytestring (encoded in some format). Forms in particular make that bytestring rather complicated, and the deserialization step is funky. I'm not sure of the "right" terminology but I think we should think about two separate steps.
Firstly, we want to deconstruct and normalise our data set to a small subset of types. Some of these types are obvious -
list
,dict
,str
,int
,float
,bool
,NoneType
etc. Some are less clear whether they should be supported at this level - for exampledecimal.Decimal
,collections.OrderedDict
,datetime.datetime
,set
, or even more domain specific types likeprices.Price
. It's hard to know where to draw the line here - there's no perfect common set of data types which are supported by all possible encodings (renderers). Given that theHTMLForm/x-www-form-encoded
renderer will need to do some custom transformations even for simple types as it depends on how things are being rendered by the widget (e.g.['on', ''] -> [True, False]
for checkboxes), I think it's clear we need to consider this as two steps. Perhaps we have a "core" set of data types which are valid return types from a serialization object and all renderers "must" support those types, but we allow renderers to become aware of other data types so they can support them.Pseudocode:
This obviously has some overlap with DjangoJSONEncoder which knows how to handle various data types such as UUID, datetime, lazy strings etc.
Whilst it would be possible, it should be strongly advised that you do not have type encoders for high level types such as instances of models.
Note that it's entirely possible here I'm just rehashing renderers/parsers from DRF, perhaps with some other extensibility ideas and we can pretty much use those for rendering. I think my main change is that perhaps I'd like to see
.render(structure, data)
or something so that the form renderer is aware of the underlying configuration of the form for example. I probably need to do more research into how DRF handles these layers, and the content negotiation for them.The text was updated successfully, but these errors were encountered: