Is there another way to get the request.user by not passing it from the views? I think passing request.user from all functions in views to the template is quite wrong. Is there any method or way that the template will get the user or any object in the database?
By default (I am talking about Django version 1.3) you do not need change TEMPLATE_CONTEXT_PROCESSORS. Because default value already contains *django.contrib.auth.context_processors.auth*.
So to your question: By default, you should be able to use user, messages and perms variables in your template. For example:
User: {{user.username}}
{% if perms.appname.permname %}
... do something usefull ...
{% endif %}
Context processors.
Related
i cant quite find it so i hope someone can help me out.
I found the option of using the
TEMPLATE_CONTEXT_PROCESSORS = ("django.contrib.auth.context_processors.auth" )
In django (1.5). But now its not clear for me how i should use it. Should i still put the request in my views, or can i with this enabled use the user_object in my template without sending an extra variably with the Requestcontect
For example:
My view at the moment:
def user_characters(request, user_id):
characters = Character.objects.filter(user=user_id)
user = User.objects.get(id=user_id)
return render_to_response('characters.html',
{'characters': characters, "user": user},
context_instance=RequestContext(request))
My template:
{% extends "base.html" %}
{% block mainframe %}
{% if characters|length < 3 %}
<p>New Character(WN)</p>
{% endif %}
And then the rest of my view.
I notice in almost every view i make i want the user_object send with it.
Can someone please give me an example of how this works?
With kind regards
Hans
django.contrib.auth.context_processors.auth context processor is enabled by default, you don't have to add anything. When you use RequestContext(), a context variable user is available in all templates that you can use. To get id {{userd.id}}.
To check user is authenticated or not, do
{% if user.is_authenticated %}
{# handle authenticated user #}
{%else%}
{# handle anonymous non-authenticated users #}
{%endif%}
You should not expose the user id in the url, you wont need it anyway, if you use django sessions- and the authentication framework. You can always check the logged in user via request.user in your serverside view. With the context processor your should be able to access the user with user.desiredattribute, but you should not need it for the url you try to create.
The docs on this seem pretty clear to me:
https://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.RequestContext
If you want context processors to function, you must ensure that you're using a RequestContext instance. You can do that by explicitly creating it in your views, as you show, or (more conveniently, in my opinion) by using the render shortcut rather than render_to_response as documented here:
https://docs.djangoproject.com/en/dev/topics/http/shortcuts/#render
With the django.contrib.auth.context_processors.auth context processor in place, the user will always be available in the context variable user. At least, assuming your template is being rendered with a RequestContext instance.
You absolutely should not trust a variable obtained from the URL to determine the user if you have any kind of controlled information. With the system you have shown, anyone can view anyone's data simply by editing the URL. That might be OK for a totally insecure application, but it's much more normal to look at request.user.
I am trying to put a login form in every page in my web that uses django.contrib.auth.views.login. I created a templatetag in templatetags/mytags.py, where I define a function called get_login wich looks like this:
#register.inclusion_tag('registration/login.html', takes_context=True)
def get_login(context):
...
return {'formLogin': mark_safe(AuthenticationForm())}
...and in base.html:
{% load mytags %}{% get_login %}
The problem now is that the template (registration/login.html) doesnt recognize {{ formLogin.username }},{{ formLogin.password }}... and so on.
What am I missing?
mark_safe returns an instance of django.utils.safestring.SafeString, not a form, so those lookups will fail. I don't think there's anything wrong with directly returning the form (that's what all the generic views in django.contrib.auth do when populating templates, for instance). Just change your return statement to
return {'formLogin': AuthenticationForm()}
and it should work.
I am using django-threadedcomments. Everything works fine except 2 things: csrf token and user template tag.
Problem is, when user submits a comment, there is no csrf token for the form, so the form could not be validated server-side. Tried adding csrf token to the dictionaries that threaded-comments passes internal with no result; kept receiving errors (most of them telling that this-method takes only 2 arguments with 3 given). Tried to fix those methods to accept 3 arguments and just pass third one further; no success.
Did someone stumble upon the same problem in past and solved it? because this is not an acceptable solution for me:
MIDDLEWARE_CLASSES = (
#'django.middleware.csrf.CsrfViewMiddleware',
)
Second one - there is a HTML helper to get the user_id for the user who posted a comment. Is there an out of the box html helper to get the name of the user by id or would i have to write it myself?
http://code.google.com/p/django-threadedcomments/
Here is the code for the project, I cant really tell exactly which chunks of it should be posted here so I just give link to the entire project.
I am really stuck in here and any help would be welcomed.
Thanks in advance.
Tried adding csrf token to the
dictionaries that threaded-comments
passes internal with no result;
csrf_token is a template tag -- it shouldn't be passed as an argument somewhere.
I took a look at threadedcomments and it's based on contrib.comments with no html rendering, so it's up to you to insert the csrf_token in your template.
What does your TEMPLATE code look like that is displaying your form code?
If you have CsrfViewMiddleware enabled and you are using RequestContext in your view, you simply need to add {% csrf_token %} inside of your <form></form> tags.
As for getting the user name:
ThreadedComment is a subclasses of Comment which has a name property, or you could just access the User directly...
{% for comment in comments %
{{ comment.user.first_name }}
{{ comment.name }}
{% endfor %}
You should use {% csrf_token %} tag or #csrf_protect in a views
You can put your form in its own template and {% include %} it into your page template. As of Django 1.3, {% include %} can pass context variables to the included template. Here's what I'm using with django.contrib.comments instead of a templatetag:
...
{% include "comments/comment-form.html" with content_object=article user=request.user %}
...
{%csrf_token %} works in this included template because it's using your main view context.
I am writing small social application. One of the features is to write user name in the header of the site. So for example if I am logged in and my name is Oleg (username), then I should see:
Hello, Oleg | Click to edit profile
Otherwise I should see something like:
Hello Please sign-up or join
What I want is to show this on every page of my site. The obvious solution is to pass request.user object into every view of my site. But here http://www.willmer.com/kb/category/django/
I read that I can simply access request object from any template, just by enabling:
TEMPLATE_CONTEXT_PROCESSORS = (
'django.core.context_processors.request',
)
Not sure why but it actually didn't work :(
Maybe someone can help me and suggest a solution?
Thanks a lot,
Oleg
Also note that you should use django.core.context_processors.auth instead of django.core.context_processors.request if you don't need the whole request context. Then you can simply type:
Hello {{ user.get_full_name }}
in your template.
Don't forget to pass context_instance=RequestContext(request) when you call render_to_response (or use direct_to_template).
There are probably two issues here.
Firstly, if you redefine TEMPLATE_CONTEXT_PROCESSORS as you have done you will override the default, which is probably not a good idea. By default, the setting already includes the auth processor, which gives you a user variable anyway. If you definitely need the request as well you should do this (notice the +=):
TEMPLATE_CONTEXT_PROCESSORS += (
'django.core.context_processors.request',
)
Secondly, as described in the documentation here when using context processors you need to ensure that you are using a RequestContext in your template. If you're using render_to_response you should do it like this:
return render_to_response('my_template.html',
my_data_dictionary,
context_instance=RequestContext(request))
Use
from django.template import RequestContext
instead of
from django.template import Context
So now just call RequestContext(request, context)
More here.
Once you have set up the context process, the request is passed to the template as a variable named request. To access the user object within the variable you need to drill into it:
{{ request.user }}
Here is a list of attributes stored in the Django Request object. More specifically, here is the user attribute.
{% if user.is_authenticated %}
<p>Welcome, {{ user.username }}. Thanks for logging in.</p>
{% else %}
<p>Welcome, new user. Please log in.</p>
{% endif %}
Would be enough if you have TEMPLATE_CONTEXT_PROCESSORS already set.
I think just by adding locals() can solve the problem.
return render_to_response('my_template.html',
my_data_dictionary,locals())
Short version:
Is there a simple, built-in way to identify the calling view in a Django template, without passing extra context variables?
Long (original) version:
One of my Django apps has several different views, each with its own named URL pattern, that all render the same template. There's a very small amount of template code that needs to change depending on the called view, too small to be worth the overhead of setting up separate templates for each view, so ideally I need to find a way to identify the calling view in the template.
I've tried setting up the views to pass in extra context variables (e.g. "view_name") to identify the calling view, and I've also tried using {% ifequal request.path "/some/path/" %} comparisons, but neither of these solutions seems particularly elegant. Is there a better way to identify the calling view from the template? Is there a way to access to the view's name, or the name of the URL pattern?
Update 1: Regarding the comment that this is simply a case of me misunderstanding MVC, I understand MVC, but Django's not really an MVC framework. I believe the way my app is set up is consistent with Django's take on MVC: the views describe which data is presented, and the templates describe how the data is presented. It just happens that I have a number of views that prepare different data, but that all use the same template because the data is presented the same way for all the views. I'm just looking for a simple way to identify the calling view from the template, if this exists.
Update 2: Thanks for all the answers. I think the question is being overthought -- as mentioned in my original question, I've already considered and tried all of the suggested solutions -- so I've distilled it down to a "short version" now at the top of the question. And right now it seems that if someone were to simply post "No", it'd be the most correct answer :)
Update 3: Carl Meyer posted "No" :) Thanks again, everyone.
Since Django 1.5, the url_name is accessible using:
request.resolver_match.url_name
Before that, you can use a Middleware for that :
from django.core.urlresolvers import resolve
class ViewNameMiddleware(object):
def process_view(self, request, view_func, view_args, view_kwargs):
url_name = resolve(request.path).url_name
request.url_name = url_name
Then adding this in MIDDLEWARE_CLASSES, and in templates I have this:
{% if request.url_name == "url_name" %} ... {% endif %}
considering a RequestContext(request) is always passed to the render function. I prefer using url_name for urls, but one can use resolve().app_name and resolve().func.name, but this doesn't work with decorators - the decorator function name is returned instead.
No, and it would be a bad idea. To directly refer to a view function name from the template introduces overly tight coupling between the view layer and the template layer.
A much better solution here is Django's template inheritance system. Define a common parent template, with a block for the (small) area that needs to change in each view's version. Then define each view's template to extend from the parent and define that block appropriately.
If your naming is consistent in your urls.py and views.py, which it should be, then this will return the view name:
{{ request.resolver_match.url_name }}
Be sure to apply some context to it when you call it in the template. For example, I use it here to remove the delete button from my detail view, but in my update view the delete button will still appear!
{% if request.resolver_match.url_name != 'employee_detail' %}
Since Django 1.5 you can access an instance of ResolverMatch through request.resolver_match.
The ResolverMatch gives you the resolved url name, namespace, etc.
one simple solution is :
def view1(req):
viewname = "view1"
and pass this viewname to the template context
def view2(req):
viewname = "view2"
and pass this viewname to the template context
in template access the viewname as
{{viewname}}
and also you can use this in comparisons.
I'm working on this for a help-page system where I wanted each view to correspond to a help-page in my cms with a default page shown if no help page was defined for that view. I stumbled upon this blog where they use a template context processor and some python inspect magic to deduce the view name and populate the context with it.
This sounds like the perfect example of a generic view that you can set up.
See the following resources:
Django Book - Chapter 11: Generic Views
Django Docs -Tutorial: Chapter 4
Django Docs - Generic Views
These links should help you simplify your views and your templates accordingly.
If you're using Class Based Views, you most likely have a view variable you can access.
You can use several methods from that to determine which view has been called or which template is being rendered.
e.g.
{% if view.template_name == 'foo.html' %}
# do something
{% else %}
# other thing
{% endif %}
Another option is to take out the piece of the template where you need something to change and make it into a snippet and then use {% include 'my_snippet.html' with button_type = 'bold' %} in your templates, sending arbitrary values to the snippet so it can determine what to show / how to style itself.
Most generic views — if not all — inherits the ContextMixin which adds a view context variable that points to the View instance.
In your template, you can access the current view instance like this:
{{ view }}
Define class_name method in your view
class ExampleView(FormView):
...
def class_name(self):
return self.__class__.__name__
You can get the class name of the current view in a template like this:
{{ view.class_name }}
{% if view.class_name == "ExampleView" %} ... {% endif %}
Why not trying setting up a session cookie, then read the cookie from your template.
on your views set cookies
def view1(request):
...
#set cookie
request.session["param"]="view1"
def view2(request):
request.session["param"]="view2"
then in your ONE template check something like..
{% ifequal request.session.param "view1" %}
... do stuff related to view1
{% endifequal %}
{% ifequal request.session.param "view2" %}
... do stuff related to "view2"
{% endifequal %}
Gath