Perhaps my question will seem somewhat simple and understandable, but even so.
In my project, I use standard pagination and sorting.
The problem is that they replace each other in the get request, for example I sort them and if I go to the second page then the set is not sorted. I understand the reason and it seems the answer lies on the top, but even so I could not find it.
Sorting:
Counter
Pagination example:
<a class="page-link" href="?page={{ history_application.previous_page_number }}">«</a>
The question is how to save the parameters that were transmitted earlier.
Try using a Django templatetag that updates the current request.GET parameters and adds new parameters using urllib.urlencode.
Create a templatetag:
# templatetags.app_tags
import urllib
#register.simple_tag(takes_context=True)
def url_add_query(context, **kwargs):
""" Updates the current path from existing GET parameters. """
request = context.get('request')
get = request.GET.copy()
get.update(kwargs)
return u'{path}?{params}'.format(path=request.path,
params=urllib.urlencode(get, 'utf-8'))
On your HTML template:
{% load app_tags %}
«
Related
So since i've been trying to learn django there is one thing that confuses me more than anything else, and that is getting something that works in the django shell into a format that works in models.py of views.py. So here is an example from the Documentation:
>>> Entry.objects.all().filter(pub_date__year=2006)
So I can work with the shell, there are loads of examples everywhere, what never seems to be covered is how you then put this in your code if you want to filter for other years for example. Can someone explain this or point me at documentation that explains this, as I've not found it in the django docs.
There are several ways to do that, but for the beginning and learning purposes your view should accept a year argument:
def my_view(request, year):
entries = Entry.objects.filter(pub_date__year=year)
context = {
"entries": entries
}
return TemplateResponse(request, 'my_template.html', context)
The line you are talking about is used to query the database and then filter things. This line is mostly used in views or serializers since you want the entries to be passed on to either template or as JSON to API response.
Using it in views:
def view(request):
entries = Entry.objects.filter(pub_date__year=year)
return render(request, 'index.html', {'entries': entries})
Here the object {'entries': entries} in above code is context object.
And then after that, you can use the same thing in Django Templates for example here in index.html
{% for entry in entries %}
<li> {{ entry.id }} </li>
{% endfor %}
I am new to Django, and I would like to try a FBV for an activity that doesn't require a Model. This will eventually implement a search with user-defined parameters and show the results in the template, but for now my template and views are essentially empty to show this problem.
I'm using python 3.6 and Django 2.1.3.
The tutorials go straight to CBV and I'm having a hard time getting good info on the FBV way.
File: 'positivepets/picture_search.html':
-------
{% extends 'positivepets/base.html' %}
{% block body %}
<p> You have reached the picture search page </p>
{% endblock %}
File: urls.py
--------
app_name = 'positivepets'
urlpatterns = [...
url(r'^picture_search/$', views.misc_views.picture_search, name='picture_search'),
...]
File: misc_views.py
--------
def picture_search(request):
return render(request, 'positivepets/picture_search.html')
Problem
This all works fine and renders the template picture_search.html.
My problem is that I want to avoid hardcoding the template name. I thought this would work:
def picture_search(request):
return HttpResponseRedirect(reverse('positivepets:picture_search'))
This takes the user to http://127.0.0.1:8000/positivepets/picture_search/
but produces a "too many redirects" error in chrome. I think I am just telling it to redirect to itself over and over.
Question
Where do I specify that picture_search.html is the template that I want to render without hardcoding it in the view?
It seems that the answer should lie in reverse, but I can only find CBV examples of reverse(), and I think it works with CBV because there is a template_name attribute set in the class definition. FBV doesn't have that, of course.
I'm hoping this is an easy one for someone with some FBV experience.
I don't think there is any benefit in doing what you're trying to do. You have to tell django what template you want by name somewhere. If you don't do it in your return, but somewhere else in your code you've only added a layer of abstraction with no net benefit.
i.e
def picture_search(request):
return render(request, reverse('some_pointer'))
some_pointer = 'picture_search' - you still have to hard code it
= No benefit
the reverse function is for getting the url from the view, or the label.
At the end of that url is some function to render a template, with the template name.
My Django app currently has URLs which are protected by 'permission_required()' functions.
This function is called in three different ways.
As a decorator in views.py, with hardcoded parameters.
As a plain function, with autogenerated parameter, in custom Class Based Generic Views.
As a function invoking views in urls.py, with hardcoded parameters.
I'm now adding a menu system to the app, and I need to make menu entries reflect whether the user has permission to request the URL of each menu entry. (Either by greying-out or hiding said entries.)
Is there a way of query the permissions required to a URL without requesting the URL?
The only solution I've thought of so far is to replace the decorator with a parameterless 'menu_permssion_required()' decorator and hardcode all of the permissions into a Python structure. This seems like a step backwards, as my custom Class Based Generic Views already autogenerate their required permissions.
Any suggestions on how to make a menu system which reflects URL permissions for the current user?
Here is an example of how to solve your problem:
First, Create a decorator wrapper to use instead of permission_required:
from django.contrib.auth.decorators import login_required, permission_required, user_passes_test
from django.core.exceptions import PermissionDenied
from functools import wraps
from django.utils.decorators import available_attrs
def require_perms(*perms):
def decorator(view_func):
view_func.permissions = perms
#wraps(view_func, assigned=available_attrs(view_func))
def _wrapped_view(request, *args, **kwargs):
for perm in perms:
return view_func(request, *args, **kwargs)
raise PermissionDenied()
return _wrapped_view
return decorator
Then, use it to decorate your views:
#require_perms('my_perm',)
def home(request):
.....
Then, add a tag to use for your menu items:
from django.core.urlresolvers import resolve
def check_menu_permissions(menu_path, user):
view = resolve(menu_path)
if hasattr(view.func, "permissions"):
permissions = view.func.permissions
for perm in permissions:
if user.has_perm(perm):
return True # Yep, the user can access this url
else:
return False # Nope, the user cannot access this url
return True # or False - depending on what is the default behavior
And finally, in your templates, when building the menu tree:
<button href="{{ some_path }} {% if not check_menu_permissions some_path request.user %}disabled="disabled"{% endif %} />
N.B. I've not tested the last part with the tag, but I hope you got the idea. The magic thing here is to add the permissions to the view_func in the decorator, and then you can access this using resolve(path). I'm not sure how this will behave in terms of performance, but after all that's just an idea.
EDIT: Just fixed a bug in the example..
Is there a way of query the permissions required to a URL without requesting the URL?
User.has_perm() and User.has_module_perms()
Any suggestions on how to make a menu system which reflects URL permissions for the current user?
I really like this question, because it concerns anyone that makes a website with django, so I find it really relevant. I've been through that myself and even coded a menu "system" in my first django project back in 2008. But since then I tried Pinax, and one of the (so many) things I learnt from their example projects is that it is completely unnecessary bloat.
So, I have no suggestion which I would support on how to make a menu "system" which respects the request user permissions.
I do have a suggestion on how to make a simple menu which respects the request user permissions, so that might not be completely unrelated.
Just make your menu in plain HTML, it's not like it's going to change so often that it has to be generated. That will also keep your Python code simpler.
Add to settings.TEMPLATE_CONTEXT_PROCESSORS: 'django.core.context_processors.PermWrapper'
Use the {{ perms }} proxy to User.has_perms.
Example:
{% if perms.auth %}
<li class="divider"></li>
{% if perms.auth.change_user %}
<li>
{% trans 'Users' %}
</li>
{% endif %}
{% if perms.auth.change_group %}
<li>
{% trans 'User groups' %}
</li>
{% endif %}
{% endif %}
{# etc, etc #}
That's how I keep navigation simple, stupid, and out of the way. But also I always include an autocomplete not far from the menus to allows the user to navigate to any detail page easily. So, that's all I know about navigation in django projects, I'm eager to read other answers !
I had a similar issue, but it went a little deeper. Instead of just permissions, I also wanted other tests based on the lidded in user (ie, is_staff, or user.units.count() > 1). Duplicating these in the view and the template seems prone to errors.
You can introspect a view object, and see all of the decorators wrapping it, and work out if they are checks (in my case: the first argument I'd u or user). If they all pass, then allow rendering the link.
Get all decorators wrapping a function describes the technique in a little more detail. You can find the app that wraps this up into a handy replacement for {% url %} at Django-menus.
I want to create dynamic menus according to user permissions. As was already discussed here and by the the documentation itself, I know that I can achieve this in the templates using the following snippet:
{% if perms.polls.can_vote %}
<li>
Vote
</li>
{% endif %}
But the problem is that for security reasons I want to limit the access to the views too. The snippet that I found in the documentation is the following:
from django.contrib.auth.decorators import permission_required
def my_view(request):
# ...
my_view = permission_required('polls.can_vote', login_url='/loginpage/')(my_view)
Isn't this against DRY principle? Isn't there a way to define only in one place what is the permission needed for each url? Perhaps in urls.py?
EDIT: (See end of post for the original text of the answer with the initial, simple idea.)
After being kindly stricken with a cluebat (see the OP's comment below), I find I can see more to the problem than before. Sorry it took so long. Anyway:
Would this kind of template be alright for you?
{% for mi in dyn_menu_items %}
{% if mi.authorised %}
<a href={{ mi.url }}>{{ mi.title }}</a>
{% endif %}
{% endfor %}
To make this work on the Python side, you could use RequestContext in your views with a custom context processor setting the dyn_menu_items variable appropriately. In case some background information is required, the Advanced Templates chapter of the Django Book introduces RequestContext, shows how to use it with render_to_response (kinda important :-)) etc.
Also, I guess at this point it could be useful to put the view functions responsible for the locked-up sections of your site in a list somewhere:
_dyn_menu_items = [(url1, view1, title1, perm1), ...]
Then you could map a couple of functions, say prepare_pattern and prepare_menu_item across that list, having it work roughly like so:
def prepare_pattern(menu_item):
url1, view, title, perm = menu_item
pattern = PREPARE_URLCONF_ENTRY_SOMEHOW(...) # fill in as appropriate
return pattern
def prepare_menu_item(menu_item):
url, view, title, perm = menu_item
mi = PREPARE_THE_BIT_FOR_REQUESTCONTEXT(...) # as above
return mi
These could be combined into a single function, of course, but not everybody would find the result more readable... Anyway, the output of map(prepare_menu_item, _dyn_menu_items) would need to be a dictionary to be passed to your views by a helpful context processor (the figuring out of which, it being the slightly tedious bit here, I'll leave to you ;-)), whereas the output of map(prepare_pattern, _dyn_menu_items), let's call it dyn_menu_patterns, would be used in patterns('', *dyn_menu_patterns), to be used in your URLconf.
I hope this makes sense and is of some help...
THE PRE-EDIT ANSWER:
Based on your short description, I'm not sure what solution would be best for you... But if the permission_required snippet does what you want, just not DRY-ly enough, how about rolling your own wrapper:
def ask_to_login(perm, view):
return permission_required(perm, login_url='/loginpage/', view)
You could put this anywhere, including in URLconf. Then you could replace all mentions of '/loginpage/' with reference to a variable defined towards the top of your URLs file and you'd have yourself a solution with a single mention of the actual login URL, for one-place-only update of said URL should you have to move it around. :-)
Of course the views would still need to be wrapped explicitly; if that bothers you, you could try to make ask_to_login into a decorator for easy wrapping at the definition site. (But perhaps it's really best not to do it, lest you force yourself to dig your views from under the decorator in case you need them undecorated at some point in the future.)
I'm aware this question was asked a couple of weeks ago now, but you mentioned http://code.google.com/p/greatlemers-django-tools/ in one of your comments so I thought I'd chip in.
The project is still active (although it's slightly on the backburner at the moment) but I'm not sure if it is as DRY as you're after. You would still have to specify permissions twice, once in the model object for the menu item and once on the view. This isn't necessarily a bad thing however as the permissions that you define on the menu item may be slightly different from those on the view.
If you wanted to do everything in one place I'd probably suggest a combination of a utility function for use in urls.py that can add restrictions to a view whilst also storing said restriction somewhere for use with a special template tag. I'd imagine it may look something like this.
# Stored in a file named access_check_utils.py say.
from django.conf.urls.defaults import url
from django.core.urlresolvers import get_callable
from django.contrib.auth.decorators import permission_required
access_checked_urls = {}
def access_checked_url(regex, view, kwargs=None, name=None, prefix='', perms=None, login_url=None):
if perms is None:
perms = []
callback = None
if callable(view):
callback = view
elif isinstance(view, basestring):
if prefix:
view_path = "%s.%s" % (prefix, view)
else:
view_path = view
try:
callback = get_callable(view_path)
except:
callback = None
if callback is not None:
# Add all the permissions
for perm in perms:
callback = permission_required(perm, login_url=login_url)(callback)
if name is not None:
access_checked_urls[name] = perms
else:
callback = view
return url(regex, callback, kwargs=kwargs, name=name, prefix=prefix)
That should work for the pit needed in urls.py called the same way as you would with a normal url but with the added perms and login_url parameters (perms should be a list of all the relevant ones).
# In a templatetag folder somewhere
from django import template
from django.core.urlresolvers import
# This needs to point to the right place.
from access_check_utils import access_checked_urls
register = template.Library()
#register.inclusion_tag("access_checked_link.html", takes_context=True)
def access_checked_link(context, title, url, *args, **kwargs):
perms = access_checked_urls.get(url, [])
if not perms:
allowed = True
else:
allowed = context.request.user.has_perms(perms)
return { 'allowed': allowed,
'url': reverse(url, *args, **kwargs),
'title': title }
This would have an associated template file like:
{% if allowed %}{{ title }}{% endif %}
I've not tested this fully, but it should work (or at least be a good basis for something that should work). I'll probably even look to adding something like this into gdt_nav allowing it to check for these base permissions if they exist, and then checking for any extras added.
Hope this is of some help.
--
G
I want to highlight the current page in the navigation menu. Obviously I need to give the menu links a class like 'active' when you are on their page. This is a classic problem and I've seen many solutions proposed. My problem is I hate all of them and consider none of them to be very DRY. For example:
#register.simple_tag
def active(request, pattern):
import re
if re.search(pattern, request.path):
return 'active'
return ''
----
{% load tags %}
<div id="navigation">
<a class="{% active request "^/about/" %}" href="/about/">About</a>
<a class="{% active request "^/contact/" %}" href="/contact/">Contact</a>
<a class="{% active request "^/services/" %}" href="/services/">Services</a>
</div>
The tag takes your current request and a url expression and returns 'active' if you're currently on this page. Alternatively this can be done with named views rather than urls but the principle is the same.
My main issue with this is that my navigation will be called on 99% of my views and yet, in order to get the current request variable I still have parse a RequestContext to the template with something like this:
def contact(request):
# snip ...
return render_to_response(
'contact.html',
{ 'myvar' : myvar },
context_instance=RequestContext(request))
Why do I need to add this context_instance line to every single one of my views when probably all but one of them needs the request variable in order to get the current url/view to highlight the active link? This seems awfully wet, especially for a feature that must be in the great majority of django sites. I want the request to be included by default and be able to optionally suppress it. I can't find a way to do this in middleware as I can't intercept the template before its rendered after the view has returned it.
Any suggestions?
Your intention makes sense, you'll need RequestContext most of the time and only rarely it can be safely omitted for performance reasons. The solution is simple, instead of render_to_response use direct_to_template shortcut:
from django.views.generic.simple import direct_to_template
def contact(request):
# snip ...
return direct_to_template(request, 'contact.html', { 'myvar' : myvar })
... or render_to decorator from django-annoying:
from annoying.decorators import render_to
#render_to('template.html')
def foo(request):
bar = Bar.object.all()
return {'bar': bar}
You don't necessarily have to do anything to the markup of your navigation to give the current one a different style - there are declarative ways to do that using CSS.
See my answer here: Django: Is there a better way to bold the current page link for an example.
For future reference, one can use django-tabs for doing what OP wanted.