IMHO, this can be easily solved with nunjucks.js and jinja which are both
interchangeable, but in my experience it's better to had 2 template languages.
Using only one tpl gives you the need to implement the same in the django views
than in the js controller wich is "harsh" coupled and a PITA.
Also the need to reimplement django.shortcuts.render is unneded. Add in the
base tpl a {% if request.is_ajax %} then wrap the result in a entire html tpl
for regular http calls and the new content only in the other case.
Another option is to use django_braces and AjaxResponseView to respond back
ajax with only json data but again you'll be force to sync django views and the
controller for js.
Just my two cents, I'm used to build JS intense sites backed with django
without any problem.
For me the work should be documenting how to use django with a client MV# and
list the options and the apis for that.
Cheers!
E.
On Sat, May 30, 2015 at 6:52 PM, Emil Stenström <[email protected]> wrote:
> Hi,
> This is the second feature proposal as part of my general drive for
> getting Django to work better for javascript heavy sites.
> Support a javascript template language on the server
> ----------------------------------------------------
> The multiple template engine work has made it possible to switch out
> Django Templates with another engine. One of the most powerful things
> this enables is to use a template language that is executable both on
> the server and client.
> A typical use-case for this could be that you have a list of tweets on
> your site. When the user first loads the page you send the full HTML for
> all the rendered tweets over. When there's a new tweet you would like to
> just add that one tweet to the list, without re-rendering the whole
> page. Now you have a couple of options:
> 1. Reimplement the Django template code from your site in javascript.
> This is harder the more complex the template your have. Also risks bugs
> when you change the server-side template but forget the client-side one.
> 2. Use Pjax, render everything on the server and send the result to the
> page. This sends unnecessary data over the wire, and requires that you
> figure out how to append the data in the correct location.
> 3. Send the server-side templates to the browser, and then re-render on
> the client when new data arrives. This uses the least data over the
> wire, and does not require that you keep track of mappings, just update
> the data and re-render everything (React.js's virtual DOM can make this
> really fast if you need it to be).
> Option 3 opens up lots of interesting use-cases for Django, that
> previously was only possible for javascript-based frameworks.
> ---
> To be clear, I'm not saying that Django should include any front-end
> code at all. That's something that the individual developer should have
> full control over. 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.
> 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...
> ---
> This would open up great possibilities for Django, with sites that would
> feel much more responsive than today. It would be possible to build
> something like Meteor.js on top of Django, that propagates changes in
> the database all the way to the correct DOM node in the browser.
> Would anyone we willing to work with me on this? I think the changes to
> django.shortcuts.render() is something that would have to happen in
> Django, but the new template engine is something that could be done as a
> separate project I guess.
> Thoughts? Ideas?
> (And yes, for people seeing the connections between this feature and
> template components, you are right: they would be awesome together)
> Regards,
> Emil Stenström
> Twitter: @EmilStenstrom
> --
> 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/5569EAC9.4040503%40kth.se.
> For more options, visit https://groups.google.com/d/optout.
--
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/1433090936307.21995b85%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.
