Using template language in Django in a DRY way - django

I've troubles using Django template language in a DRY way.
I defined base-section.html, which is a base for all sections of my website.
Each section must override some pieces of code in this basic template to provide proper title, icon, description, body of the section, etc - always in same way.
Now, I want to write some code in each section, but I don't like the idea of overriding about 10 blocks in each section, because it would be writing same things again and again.
Whereas keyword for specified section is X:
title of the section is X, too
title of the website in a browser is X, too
name of icon is X+"_icon.png"
and so on
I'll appreciate a solution where I can assign only 1 or 2 variables per section and have my templates working.
Is it possible?

A lot of this data could simply be passed along with the view. However, I often find that writing a custom template tag might be preferable.
You could take a look at custom tags in the Django documentation: https://docs.djangoproject.com/en/dev/howto/custom-template-tags/
Using either a simple tag or an inclusion tag, you can quite easily reuse template code.

Related

Dynamic templates with Django and Ajax

My question is a bit generic in that my problem is a broad one. I have been working with django for some time, and I really want to move more into doing very dynamic web pages where actual page reloads aren't common.
I have read about the different popular javascript frameworks available, and I always feel like I am missing part of the puzzle, particularly in templating.
What are some of the best practices for keeping my templating code as non redundant as possible. I get the impression that a lot of templating logic will make it's way into the JS in addition to my django templates. I want to avoid situations where I am writing templating code in two different places.
For a very basic example, let's say I am writing some template code inside Django for an input field that has a set number of attributes. I have then also written in JS that when I click on a button, another input field of the same type is generated with all the appropriate attributes. In practice this could be a form that takes an arbitrary amount of e-mail addresses. The problem I see is that when I want to change something about that input field, I need to do it in two places.
Is there a particular development paradigm or work flow that I am unaware of? How are issues like this generally avoided?
Recommendations on frameworks would be amazing too!
as you mentioned above:
Use Django Template language. Pass the data from view to template dynamically.
Read Django Template Language documentation.
For JS :
its better to write your js in home.html.... use {% include %} tag for other html

Determining parent page of template

Inside a Grails GSP template (e.g., _form.gsp), how can I determine what page is calling the template (e.g., create.gsp or edit.gsp) so that different fields can be displayed?
There is no general way, no. If you just know that in your application that the foo action always renders the foo view and there aren't exceptions to that, then of course you can just look at the action name. You could also do something simple like put something in the model when rendering the template, like <g:render template="foo" model="[parentPage:'edit']"/>, or set a variable in pageScope or similar. There are ways to accomplish what you want, but no general way in a template to answer the question "What GSP rendered this template?". I hope that helps.
So I googled it without any mention of templates (gsp determine current page) and found the answer on this Nabble thread. I will use params.action to determine what action I'm currently doing (e.g., create or edit), and use that to display different fields.
Cheers!

Django: Built-in include tag vs custom inclusion tag

What is the difference between Django's built-in include tag and custom inclusion tags?
I have read the documentation, and both seem to to achieve the same goal: render a template passing it a context or variable.
They serve different purposes. The include tag simply includes the content from an existing template in its entirety and unmodified. A custom inclusion tag passes the context to a function which can contain logic to manipulate the context before passing it to a template.
For example, perhaps I have a panel that will be shown on multiple pages. The panel's template requires a few specific queries to be passed to it through the context. The pages that contain the panel don't require those context variables for anything else. If I include the panel template with the include tag, I would have to write those queries in every view that contains the panel and pass them as context variables.
Alternatively, I could write a custom inclusion tag that contains the queries and passes them to the panel's template. By using the custom inclusion tag I wouldn't need to repeat the code to produce its context in every view that contains the panel. My views would contain less code and would be less cluttered with context variables only used by the panel.
Although you are correct in the sense that a custom inclusion tag that simply passes on the context unmanipulated would be the same as the include tag.
Need to separate templates to smaller files? Use include tag (for readability and maintainability and DRY)
Need to include more code before rendering the template? Use inclusion tags (fetch more data, add some business logic.. it is really like another small url-less view. it is like a template function).
In principle, the point made by dgel's and YardenST's answers is correct. Additionally, a look into django's code gives a good insight on how these two options are compared in performance.
When using the default template loaders, there is absolutely no difference between the two. Both eventually make a call to the InclusionTag render() function, which in turn makes a call to template Loader get_contents() that opens the template file from filesystem. render() only caches the file in case it is used in a template for loop.
As a side note, a difference in performance would be possible by using the django.template.loaders.cached.Loader.
Last, regarding dgel's suggestion to use the inclusion tag for common context across different views: it is very much possible to avoid the small extra overhead of rendering an inclusion template, when the html markup is in a single base template that spans across many views, by using a ContextMixin. This is a quite common scenario for rendering eg. a main menu in a base template.
Just recently faced this question as I was trying to find which route is best to take - include vs inclusion tag - when there's no real extra logic that might go into an inclusion tag.
And I choose the inclusion tag for the following reasons:
more compact and readable markup in templates
<!-- include -->
{% include "path/to/funky.html" with arg1=arg1 arg2=arg2 %}
vs
<!-- inclusion tag -->
{% funky arg1 arg2 %}
easier to maintain code, if you ever had to add custom logic to the tag then it's easy to add
it enforces you to use template variables that are scoped properly, so the inclusion tag cannot inherit a variable from the parent view, makes it more resilient against weird bugs

Combining multiple Django Views/Templates

I am working on a website. On the Homepage, I want to show the posts in the center and show famous tags on the right side of the page. Now, posts and tags are two different apps and their views/tempaltes are calculated/generated in two separate functions.
How can I show what I want on my Homepage keeping my mind that its two different views being called. As far as I understand, I can only call a single view to show my homepage.
This must be possible but I am unable to understand this. Any help will be much appreciated.
I think you need to create a custom template tag that in this case called: Inclusion tags
You can look into writing a custom template tag for the tags. That way the tag logic can stay in the right application.
It depends how these different apps render the templates. If they just render the template without extending from a base template you could simply use AJAX to load all the content into your homepage.
If not, then there is no other way than writing a custom solution for this. This could be an extension to your views, a custom template tag as already mentioned or something else according to what exactly you need.

How can I pass a standard, static variable from all views in Django?

I'm working on a blog application, and I want to have a sidebar that includes a list of all the months the blog has been in existence, to provide links to archives pages. Moreover, I'd like to make this automatically update when the month changes, rather than hardcoding it in the template. Of course, as far as I can tell, this means that I'll have to calculate the list of months in every view, and pass it into every template from every view.
I'd like to avoid this, if possible. Is there a way to calculate the list once and automatically apply it to every template, without having to explicitly pass it into the template from every view?
There are a few possible solutions to your problem.
If you really want to have this on every page on your site a context processor is probably your best choice. Context processors are basic way to inject data into all template contexts. Be aware however that the context processor will be called on every request.
An alternative solution would be to create a custom template tag and use it on a shared base template for all of the pages you wish to have your sidebar. Template tags are a bit more complex to create but they are more flexible.
With either solution you should also look at Django's cache framework. The cache framework makes it pretty easy to temporarily store your calculated values for a while to save some work on each request.
You want a template context processor
Django - having middleware communicate with views/templates
http://docs.djangoproject.com/en/dev/ref/templates/api/?from=olddocs#id1
Django's template inheritance should cover this. You could create a base template that handles your sidebar functionality. Your other views extend this template.
Template Inheritance:
http://www.djangobook.com/en/1.0/chapter04/#s-template-inheritance
A combination of custom template tags as mentioned previously and template fragment caching should do the trick.