On 06/02/2015 05:54 AM, Aymeric Augustin wrote: > 2015-05-30 17:52 GMT+01:00 Emil Stenström <[email protected] <mailto:[email protected]>>: [snip] > 2. A template language that has a solid javascript implementation. > To be able to render the templates the server side and client side > must use the same language. I see two options here, either make sure > the Jinja flavor we are supporting works with JS templatations > (maybe https://mozilla.github.io/nunjucks/ ?), or get a handlebars > implementation working with Django (https://github.com/wbond/pybars3 > ?). Or maybe there's some third option I didn't think of... > > > To achieve this goal, I think Andrew Ingram's second suggestion is the > easiest solution since Django 1.8: implement a template engine that > hands over data to a Node.js process, lets it render the template, gets > the HTML back, and returns it. > > That's a good candidate for a pluggable application. It will probably > have some specific deployment instructions ("run this Node.js next to > your Django...)
I'm sure this Node-daemon technique is workable (I know of at least one project already using it), but I'm not sure it's the easiest option. Using Jinja2 on the server and nunjucks on the client with shared templates works very well, is quite easy, and doesn't require Node.js on the server. I've been using this combination for a year and a half on several different projects and am quite happy with it. The primary discipline involved is ensuring that you only pass JSON-serializable objects to your templates (this is required for any template-sharing technique). In practice, this just means you need a full set of serializers and to use them consistently. The same serializers should be used in your server-side views and in your API, so the objects passed to your templates on the server and client side are the same. (I think using serializers and avoiding passing model instances/querysets directly into template contexts is a good practice anyway.) The main problem is that if you want to extend the template language with custom tags/filters, you have to write these extensions twice. We tend to accommodate this by just writing many fewer template language extensions, doing more display-preparation work in serializers instead, and relying on Jinja's built-in expressive power (e.g. macros) instead of template language extensions. Carl -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/556DE287.7050808%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
