how can i use different template in different application.in a project i have two app 1)Site 2)Ad .I want to use default template in Ad but different in Site..How to ?OR in the template is there is a way to use 'if condition' as i have to change only two lines in the templates.
First of all, you are never bound to use same template in different application. Different apps can use different templates, as common practice these days are to place template directories in respective app folder.
Moreover, for change of two lines, you can alwayz use `
{% if condition %}
something
{% else %}
some other thing
{% endif %}
or
{% ifequal var 'var' %}
something
{% else %}
some other thing
{% endifequal %}
All in same template.
Edit
If you say you want to use same templates in diff applications, you can apply path of template considering the facts that,
firstly django template loader will look for a template in same app directory,
then in projects's root directory, and if not found, it will look for it django's own template source.
So if you want to use template anywhere, you can place them in a folder called templates, placed in the same path where your apps directories are. (i.e. root of the project).
projectroot/app1/templates/app1.html
projectroot/app2/templates/app2.html
projectroot/app3/
projectroot/templates/common.html
likewise common.html can be available to all apps.
Use template inheritance http://www.djangobook.com/en/1.0/chapter04/ Define a base template and change only the desired block.
Pl. check the links to the question I had raised for which the answer is provided by Yuji T
How to use 2 different change_list.html for 2 applications in the same django project
Related
I have only started with Django recently, and assume there must be a good solution for this issue!
After installing django-allauth through pip, it tried to extend base.html from my project/templates folder rather than from its own subdirectory. This user had the same issue and was told to rename one of the base.html files and then update all references to it in the related app templates. For a complex app (already bad), this is error-prone; it's even worse if multiple third party apps are each defining their own base.html and referring to it simply as {% extends 'base.html' %}. Also, I think this only applies to third party apps, since I can easily name base.html something different for each of my own apps, but I don't want to mess around with 3rd party apps that work.
My question is: is there a safe/easy way to allow multiple third-party apps to use {% extends 'base.html' %} without clashing?
I have read the docs on template inheritance in Django and understand that:
By default, templates are loaded from the filesystem first, and then from app subdirectories. Therefore my projects/templates directory, which is defined in my TEMPLATE_DIRS setting, will be called first; hence the django-allauth problem.
I can reverse this order for the app subdirectory to be called first, by changing the order of TEMPLATE_LOADERS. However, this just means that my website will now extend the wrong base.html.
Although I can fix the current clash by renaming allauth's base.html as allauthbase.html and changing child template references to it as {% extends 'allauthbase.html' %}, this seems bulky.
Most wierdly, this person is complaining that each app extends its own base.html by default, but that seems impossible...
It seems there is an open issue related to the problem:
https://github.com/pennersr/django-allauth/issues/370
For my application I want to serve a different base.html (and other templates and static files) for visitors and for admins: visitors will see a customized themed frontend, admins will see the editor interface (not related to the django admin interface). Some templates / resources will be shared between the two frontends.
I know I can do this by having separate settings.py configurations and include different template paths in each of them through a django app, but that would also mean I have to run two instances of the app. I'd rather serve both frontends from a single instance (or pool of workers).
Is there a way to dynamically add extra folders to the Django search path? That should suit my needs: if the user comes through the visitor domain, search the added path first and then the defaults, else just use the default template search path.
This is exactly why I've created django_layers
It's inspired by the Plone skinning/layer system where you can switch skins and have the framework search different layers for templates, staticfiles, and so on. I was missing something similar in Django where, like you, the only option I could find was inheritance or distinct INSTALLED_APPS configurations.
It turns out it's also very suitable for other use-cases such as A/B testing.
The packages is relatively new, let me know if it works for you or if you have issues if you decide to use it.
You can leverage template inheritance for this purpose, especially the {% extends %} template tag, which can accept variables instead of literal strings.
Example:
In your child templates make them extend unknown base template like this:
{% extends BASE_SITE_TEMPLATE %}
{% block page_head %}
<!-- Custom per-page static files may be defined here -->
{% endblock %}
{% block page_content %}
...
{% endblock %}
And then write a template context processor that will pass the BASE_SITE_TEMPLATE variable based on your custom conditions to rendered templates:
def base_site_template(request):
# Here goes your conditions to select proper base template, for example
# by checking request.user permissions or some other logic.
...
return {'BASE_SITE_TEMPLATE': ...}
Of course You will need to define various base templates, like base_site_user.html, base_site_editor.html, base_site_admin.html.
This method doesn't require you to change any of your views, just child templates, so I think it's one of the simplest methods to do what You want.
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'm using Django to create a site that provides a separate web UI for sorts of producers and consumers. Both UIs (or "subsites") have different layouts, menus and graphics. However they access the same database and models, just from different aspects (producer vs. consumer...).It's all hosted under a single domain, the UI differentiation is done with URLs.
The problem comes when I want to integrate a CMS to this system, to take care of the menu structures and textual content. How should I go about handling the two different menus for the different UIs? I took a look at django-cms and django-page-cms, and they seem to maintain only a single menu hierarchy.
Any ideas?
One dirtyish solution would be to add e.g. a different prefix for each UI's menu items in the CMS, and hack the CMS code so that it only inserts the menu items for the correct UI (given as a parameter to the show_menu template tag).
A nicer way would be if it was possible to have multiple instances of the CMS app, so that each of them had their own database tables as well. But is this possible with django and e.g. django-cms or django-page-cms?
Some further restrictions:
the CMS must support localization
I'd prefer running a single Django instance, to keep the configuration and testing simple
I have not used django-cms so this is just off the top of my head.
There's a section of the docs called Extending the menu that looked promising. It may be unfortunate that so much of their configuration is in settings.py because it looks like you could manipulate their CMS_TEMPLATES to use different base templates (etc.) for different users. One way of getting around this (assuming that there is not a more direct route) is to add something to the UserProfile that identifies a user as consumer/producer. Then in your base.html you do:
{% if user.get_profile.consumer %}
...
{% else %}
...
{% endif %}
This effectively gives you two entirely different look/feel options based on user type. I'll also note that {% extends %} can take either a string constant or a string variable, so you could use a context_processor to set the name of template you are extending.
What you need is show_menu_below_id tag of django-cms. Create the pages consumers and producers with their respective id (advanced fieldset, on bottom of the page form) and then start building the page hierarchy for each one.
Then in the templates uses the tags:
<ul>
{% if user.get_profile.consumer %}
{% show_menu_below_id "consumer" %}
{% else %}
{% show_menu_below_id "provider" %}
{% endif %}
</ul>