W dniu niedziela, 2 kwietnia 2017 14:52:03 UTC+2 użytkownik Xavier Ordoquy napisał: > > > > Are you saying date translation should only be done on the client ? > > I’m saying that’s an option and possibly a better solution. > If one goes in another timezone, one is more likely to change its computer > timezone than go through every website and change the settings there. >
I don't fully understand your reasoning, but a few people experienced people have told me this is a good approach, so I I'll stick with it. > > > Unlike in Django, which is happy to translate the date for you ? > > That’s inexact as Django doesn’t translate the date for you out of the > box. Extract from the Django documentation: > > So you're saying Django is performing a bit of magic to get those nice month names, and I came to rely on that. Fine, a js function to translate just month names won't be difficult. > > More code duplication. > > Can you elaborate ? > > I didn't want to bother you with this at first, it may be just my problem because I'm using Django for something it's not meant to do. Pagination via asynchronous requests. I came to appreciate Django's objects like querysets and model methods when I couldn't access them in Javascript (json data from REST API). Template filters are also nice, like date formatting. For a while I could use the workaround of just serializing method calls. Now it seems I have to get more serious with Javascript, a language I'm not comfortable with. There is a bit of code duplication between templates and javascript data massaging. i can cut it down a bit by putting more weight on views and models instead of templates, which is arguably a good idea anyway (because templates are slow and by design not very expressive). I could go all in with the REST api, by switching from ListView to TemplateHTMLRenderer. Operate on the same type of data - json instead of querysets etc - in both cases, which should reduce duplication. Maybe even make the actual Django logic part blank and handle everything with Javascript, even if it's a synchronous (traditional) request. But I need a fallback for when client doesn't have Javascript enabled, so maximizing js part is probably not a good idea. Look at this intiuitive paginator behavior. https://docs.djangoproject.com/en/1.10/topics/pagination/#using-paginator-in-a-view Javascript doesn't provide something like this out of the box. My pagination also supports 'ordering' query param, and those little details keep piling up. In django view, I can conveniently use {{ page.number }} to display what page it is, in the asynchronous part I need to make the javascript part react to which page the serializer actually provided, or put the logic in javascript to make it decide which should be provided. A side note, when is it a good idea to use TemplateHTMLRenderer ? I tried to use it initially, then I got into trouble with context, and read that the same view shouldn't provide both user HTML and api data. > Is there anything conceptually wrong with an API providing a translated > date according to request language ? > > Which ones of PT, MT, CT or ET are you going to choose for en-US ? > > As far as English goes I only distinguish GB and US :-). Ignorance is bliss ? Cheers, Marek -- 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.
