On Tuesday, 2 June 2015 13:54:44 UTC+2, Aymeric Augustin wrote: > > 2015-05-30 17:52 GMT+01:00 Emil Stenström <e...@kth.se <javascript:>>: > >> But what needs to happen is that the same templates that Django uses >> needs to be accessible to, and executable in, javascript. >> >> For this to work, two things needs to be built: >> >> 1. A way to access the template and the template context for a view >> separately, so that it can be delivered to the client. Maybe the easiest >> would be to modify django.shortcuts.render so it returns both the input and >> the result. The client could then get access to this via a <script> tag >> when the page renders. >> > > I'm not sure I understand why changes to render() are necessary. > > If you intend to use the system you've described in your own views, you > can use your own variant of render that returns an appropriate HttpResponse > subclass. >
Yes, I could. I was thinking in terms of what the README for my third party template backend should be. Either it's just "pip install <package>" and add this to your TEMPLATES setting", or having to tell people to also replace all calls to "render" with my custom version. > It's unclear to me that you can reasonably plug such a system on views > provided by third-party apps, since context data generated by these views > will often not be JSON-serializable. > That's a problem that I hadn't thought about. I was hoping that querysets where always serializable, but I didn't think of datetime and decimal (and others), which people might send to their views. Are there other pitfalls here? Maybe this could just be else that people would have to change to use the new template backend. > Could you clarify the reasons for this feature request? > > >> 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...) > Yep, that's probably the one that's easiest to use right now. I replied to that post separately. Would be great if this could work without having to maintain a separate node.js process though... -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/15b4dbd2-6666-48b7-809f-cb9a022d5b62%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
