I was just looking at the ratings element and wondering why it has so much data in it.
For me, it looks like this (using Python, the u means its unicode):
(u’rating’, {u’positive’: True, u’negative’: False, u’value’: 4, u’neutral’: False, u’unknown’: False, u’type’: {u’simple’: True, u’star_rating’: False}})
Instead of getting a string for the rating, we get all four simple ratings as booleans. Additionally, we get the star rating and both types as another dictionary.
I think this would probably be a better option, just due to neatness:
(u’rating’, {u’type’: u’simple’, u’rating’: u’positive’})
or
(u’rating’, {u’type’: u’stars’, u’rating’: u’5’})
Participez à la discussion - ajoutez un commentaire ci-dessous:
Thanks for the feedback. I had left the “rating” field out of the Library Entry model documentation for exactly this reason. It will indeed be changed to {type: (“simple” | “advanced”), rating: (0.5 | 1 | 1.5 | … | 5 | null)} shortly.
Will we have to do the conversion between simple and advanced rating modes on the client side or will it happen via server-side methods (or at least some documentation)?
Format has been updated – the rating field now returns
{"type":"advanced","value":"4.0"}
.Conversion between rating types needs to be done client-side. The rules for conversion are:
[0, 2.4] -> negative
(2.4, 3.6) -> neutral
[3.6, 5] -> positive
I will be documenting this soon.