On Sunday, 31 May 2015 18:49:07 UTC+2, Enrique Paredes wrote:
>
> 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.
>
I'm not sure what your argument is here.
Are you saying you prefer implementing all templates in two languages,
since implementing views twice is too much work? The time you save being
able to reuse the same templates in the client side is huge, and avoids the
maintenance burden of keeping two identical things in sync.
I'm also not saying you should implement views twice. Each time you click a
link that request can go to the exact same server side view, get the
correct data back (only the data), and re-render only the parts that
changed.
> 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.
>
I'm not sure I follow here. Are you saying I should just go through all my
templates and split them in two? What do you mean by "new content" here? My
suggestion is that you would send only the new DATA, and that the client
would use that data, and the templates, to re-render the page.
The good thing about changing render is that render gets both the template
and the template_context as input (the two things we need on the client
side to re-render the page), all you need is a way to get them out of
there. Maybe this is possible to get from a HTTPResponse, if it is, no
changes would have to be made to render().
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.
>
I'm not advocating client side MVC here, I think most sites would be better
of just letting Django handle all the routing. That's why the idea of just
modifying your existing views to return the template_context is so
convenient. All you need on the client side is to turn link clicks to ajax
calls (or fallback to normal clicks if the client doesn't support
javascript), and render templates with the returned data.
>From your different suggestions throughout your e-mail it sounds to me you
have had to duplicate lots of your code between the server and the client.
This proposal would avoid much of that.
--
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/e74237d5-18ad-45a9-99d3-d12f1ea6902b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
