I have a simple (I hope so) question about the structure of a typical Django website. I have to restructure my site using some "Django-powered" pages mixed to other typical static pages.
I'd like to have a few templates and a lot of pages using these templates.
My question is:
What is the best way to provide different content for each page?
What I'm thinking right now is having different pages in my URL conf using the same templates and modifying the content within the View. But it's so unnatural to "hard-code" my content within the View, I suppose.
Is there a way to define content areas in my template and, for example, edit them within the Admin panel?
There must be better ways, I think.
Thank you!
Edit
Maybe Flatpages could help in my task. But does exist a way to add "content areas" tied to specific parts of the templates? I can fine only the main content area.
How are your "content areas" different than django's template blocks? You can define something like this in your layout file:
base.html
{% block overridable %}Default content{% endblock overridable %}
And in your templates, you extend it like this:
view.html
{% extends "base.html" %}
{% block overridable %} Overrided by view {% endblock overridable %}
You can use generic views, and I would heartily encourage you to. They're great. Check out the django docs for generic views. But as for different pages requiring a different template, yeah, that's how websites work.
Django is not "file-light" - it works by combining lots of small files. You're quite right to be averse to hard-coding HTML in your view controller - that's generally bad practice. You're going to have a template for each view, but really, how many views do you have? Even in a large application, the number of views that can't be handled by either a built-in or custom-made generic view is going to be pretty low.
Related
I’m planning to use the Django templating system in a slightly uncommon way. I need an app that will let me easily create simple “fill in the gap”-style forms and I decided to use Django templates with custom tags to design the forms.
Here is a sketch of what I mean:
<p>
This is the <i>form</i>. Two plus two is {% gap four 4 vier %}.<br>
The best programming language is {% case_gap Python Haskell %}.
</p>
{% if all_correct %}
You are smart.
{% else %}
<input type="submit">
{% endif %}
The idea is that the *gap tags render a text input control, look into the context to see if the answer for them was sent, and if the answer is correct, mark the text inputs green.
The question is how to implement the all_correct logic. The simple solution is to add this variable to the context and then make each *gap tag update it based on its correct answer, and, I believe, this should work with my example. But what if I want to move the {% if all_correct %} code to the top of the template, where none of the gaps were rendered, and thus none of them have validated their answers yet?
Looks like I need some way to iterate over all the *gap tags before starting to render the template and [ask them to] validate the answers, but I don’t know the internals of the templating system well enough to implement this. Or there might be a completely different and better way.
I believe I figured how to do this after reading Chapter 9 of The Django Book.
Creating of a custom template tag involves defining of two things: how to compile the tag and how to render it. The compile-function should parse the tag data and return a Node—basically a thing that has a .render(self, context) method and some other data derived from the tag text.
The solution is to create FormNode—a subclass of Node that will also have a .validate(self, context) method. Then our custom tag will be compiled to a subclass of FormNode that implements validation logic.
The next thing to do is to create FormTemplate—a subclass of Template with a super-power: before starting to render individual nodes it will validate all the nodes by iterating over them and calling validate(context) on all the subclasses of FormNode and it will set the all_valid variable in the context.
Here is my proof-of-concept implementation: https://github.com/kirelagin/django-template-forms. I believe it works pretty well.
I used the ability to instantiate a custom template engine, which was added in Django 1.8. Overall, I had to dig a little deeper than one might expect and I always had this feeling that splitting of the templating API and the django engine (which is now just one of the available backends) wasn’t complete yet. I hope that Django 2.0 will bring us new cool stuff and all the hacks I had to add will vanish.
I'm working on my first Django project and have my templates setup with a base that all the others extend. In that base I want to have some user-specific navigation which means loading some values from the database to build the contents of a drop down menu. However I don't want to have to do this inside each view. Coming from Symfony2/Twig I would normally do this using a sub-request where I tell the template to render a view and that will use it's own template. Using syntax like:
{% render 'Bundle:Controller:action' with {} %}
How would I accomplish this same thing with Django? I've read over the docs a couple of times but can't find any way to do this.
You have two approaches:
(better)
- add the code to base.html (the one you're always extending) and only override it when you need to.
or
(worse)
- in every template use {% include %} to include your menus.html template.
Update: re-reading your question: you could modify the request in context-processor so your base.html would then have this information.
Custom template tags are what you want.
A friend and developer I respect recently advised that I avoid using 'Includes' in django templates. The sum of their argument was that includes are 'evil'.
I am having trouble understanding the logic; My novice opinion is that they are a great way to organise chunks of reusable html, and instead of having to edit html in multiple locations I can simply edit it in one when changes must be made.
What do all you geniuses think? Please provide some Pro's and Con's of using includes in Django templates
It seems a slightly odd opinion. Includes are a perfectly valid part of the template language, have been so since day 1 and have never AFAIK been recommended against or deprecated.
Your friend might be trying to say that you should rely more on template inheritance (which is kind of an opposite include). That's true as far as it goes - most of the time it's better to compose your templates of blocks that override or extend ones defined in parent templates. But there's definitely a use-case for includes.
The only other reason he might say that would be because of the added filesystem hit of loading include templates from disk. In which case, he's definitely off the mark - again, the template inheritance model which definitely is recommended would have exactly the same hit; and both can be avoided by using the optional caching filesystem loader.
As mentioned by Daniel, includes are perfectly valid for the reasons he mentioned. As such it is difficult to give Pro's and Con's because it really depends on what you're trying to accomplish.
Generally it is best to define common elements of a website inside block tags in a base template and use template inheritance to change out the parts you need on each page. However, if you simply need to reuse a snippet of text in many places, an 'includes' would be perfect.
An important point to note is that includes cannot contain block tags as they are rendered by themselves without any knowledge of the parent page. To better understand this see the note from the template docs on includes or this (non-bug) bug report. If you find yourself needing this functionality, it may be worth considering if you should instead move the included file into a base template inside a block tag.
He might be saying you'd be better off writing custom tags. So instead of having:
{% for post in blog %}
{% include "blog.tmpl" %}
{% endfor %}
you should do:
{% for post in blog %}
{% formatPost post %}
{% endfor %}
The include method relies on the blog posting being in an object called 'post', whereas the custom tag method lets you format anything. For example if you had a page that compared two blog posts, you would send them as as 'post1' and 'post2' in the context and do:
<h1>John Said</h1>
{% formatPost post1 %}
<h1>And Fred Said</h1>
{% formatPost post2 %}
Much more reusable. With includes you'd have to rename each of post1 and post2 as 'post' and then include the template...
I store my sites navigation menu in database. I want to load all objects in the list once I launch my server, but I haven’t got idea how to do it. I really need to do it, because it will be problem in future to load data from database in views to display menu.
I tried to put loading code in settings.py, but there was an error, and in views after imports, but there was no effect.
I think you need Template context processors.
Here is a nice tutorial by James Bennett on that:
http://www.b-list.org/weblog/2006/jun/14/django-tips-template-context-processors/
Well, I'm very new to django, and maybe I'm wrong, but I think you are looking for something like caching. Read the docs, and decide whether is it fits you or not.
You can cache just a part of your view:
https://docs.djangoproject.com/en/1.3/topics/cache/#template-fragment-caching
surround your navigation bar like this:
{% cache 500 navbar %}
... put your navbar code
{% endcache %}
and ensure to have
{% load cache %}
at the top of your template or the base template.
I've got an existing Django site, with a largish variety of templates in use. We've agreed to offer a custom-skinned version of our site for use by one of our partners, who want the visual design to harmonize with their own website. This will be on a separate URL (which we can determine), using a subset of the functionality and data from our main site.
So my question is: what's the best way to add reskin functionality to my site, without duplicating a lot of code or templates?
As I see it, there are several components which need to work together:
URL: need to have a different set of URLs which points to the partner-branded version of the site, but which can contain all the standard path info the site needs to build pages.
Template 'extends': need to have the templates extend a different base, like {% extends 'partner.html' %} instead of {% extends 'base.html' %}
View logic: need to let the views know when this is the partner-branded version, so they can change the business logic appropriately
My idea so far is to put the partner site on a subdomain, then use a middleware to parse the domain name and add 'partner' and 'partner_template' variables to the request object. Thus, I can access request.partner inside my views, to handle business logic. Then, I have to edit all my templates to look like this:
{% extends request.partner_template|default:'base.html' %}
(According to this answer, 'extends' takes a variable just like any other template tag.)
Will this work properly? Is there a better way?
If you are using different settings.py for the different sites you can
specifiy different template loading directories. (Which may default to your unskinned pages.)
Personally I'm not convinced by having different business logic in the same view code, that smells like a hack to me - the same as extensive conditional compilation does in C.
So to sum up.
Use django.contrib.sites and different settings.py
Get a clear idea, how much this is a new app/website using the same data, or just different css/templates.