eulcommon.djangoextras
– Extensions and additions to django¶
auth
- Customized permission decorators¶
Customized decorators that enhance the default behavior of
django.contrib.auth.decorators.permission_required()
.
The default behavior of django.contrib.auth.decorators.permission_required()
for any user does not meet the required permission level is to redirect them to
the login page– even if that user is already logged in. For more discussion of
this behavior and current status in Django, see:
http://code.djangoproject.com/ticket/4617
These decorators work the same way as the Django equivalents, with the added feature that if the user is already logged in and does not have the required permission, they will see 403 page instead of the login page.
The decorators should be used exactly the same as their django equivalents.
The code is based on the django snippet code at http://djangosnippets.org/snippets/254/
-
auth.
user_passes_test_with_403
(test_func, login_url=None)¶ View decorator that checks to see if the user passes the specified test. See
django.contrib.auth.decorators.user_passes_test()
.Anonymous users will be redirected to login_url, while logged in users that fail the test will be given a 403 error. In the case of a 403, the function will render the 403.html template.
-
auth.
permission_required_with_403
(perm, login_url=None)¶ Decorator for views that checks whether a user has a particular permission enabled, redirecting to the login page or rendering a 403 as necessary.
See
django.contrib.auth.decorators.permission_required()
.
-
auth.
user_passes_test_with_ajax
(test_func, login_url=None, redirect_field_name='next')¶ Decorator for views that checks that the user passes the given test, redirecting to the log-in page if necessary. The test should be a callable that takes the user object and returns True if the user passes.
Returns special response to ajax calls instead of blindly redirecting.
To use with class methods instead of functions, use
django.utils.decorators.method_decorator()
. See http://docs.djangoproject.com/en/dev/releases/1.2/#user-passes-test-login-required-and-permission-requiredUsage is the same as
django.contrib.auth.decorators.user_passes_test()
:@user_passes_test_with_ajax(lambda u: u.has_perm('polls.can_vote'), login_url='/loginpage/') def my_view(request): ...
-
auth.
login_required_with_ajax
(function=None, redirect_field_name='next')¶ Decorator for views that checks that the user is logged in, redirecting to the log-in page if necessary, but returns a special response for ajax requests. See
eulcommon.djangoextras.auth.decorators.user_passes_test_with_ajax()
.Example usage:
@login_required_with_ajax() def my_view(request): ...
-
auth.
permission_required_with_ajax
(perm, login_url=None)¶ Decorator for views that checks whether a user has a particular permission enabled, redirecting to the log-in page if necessary, but returns a special response for ajax requests. See
eulcore.django.auth.decorators.user_passes_test_with_ajax()
.Usage is the same as
django.contrib.auth.decorators.permission_required()
@permission_required_with_ajax('polls.can_vote', login_url='/loginpage/') def my_view(request): ...
formfields
- Custom form fields & widgets¶
Custom generic form fields for use with Django forms.
-
class
eulcommon.djangoextras.formfields.
W3CDateField
(max_length=None, min_length=None, strip=True, *args, **kwargs)¶ W3C date field that uses a
W3CDateWidget
for presentation and uses a simple regular expression to do basic validation on the input (but does not actually test that it is a valid date).-
widget
¶ alias of
W3CDateWidget
-
-
class
eulcommon.djangoextras.formfields.
W3CDateWidget
(attrs=None)¶ Multi-part date widget that generates three text input boxes for year, month, and day. Expects and generates dates in any of these W3C formats, depending on which fields are filled in: YYYY-MM-DD, YYYY-MM, or YYYY.
-
create_textinput
(name, field, value, **extra_attrs)¶ Generate and render a
django.forms.widgets.TextInput
for a single year, month, or day input.If size is specified in the extra attributes, it will also be used to set the maximum length of the field.
Parameters: - name – base name of the input field
- field – pattern for this field (used with name to generate input name)
- value – initial value for the field
- extra_attrs – any extra widget attributes
Returns: rendered HTML output for the text input
-
render
(name, value, attrs=None)¶ Render the widget as HTML inputs for display on a form.
Parameters: - name – form field base name
- value – date value
- attrs –
- unused
Returns: HTML text with three inputs for year/month/day
-
value_from_datadict
(data, files, name)¶ Generate a single value from multi-part form data. Constructs a W3C date based on values that are set, leaving out day and month if they are not present.
Parameters: - data – dictionary of data submitted by the form
- files –
- unused
- name – base name of the form field
Returns: string value
-
-
class
eulcommon.djangoextras.formfields.
DynamicChoiceField
(choices=None, widget=None, *args, **kwargs)¶ A
django.forms.ChoiceField
whose choices are not static, but instead generated dynamically when referenced.Parameters: choices – callable; this will be called to generate choices each time they are referenced -
widget
¶ alias of
DynamicSelect
-
-
class
eulcommon.djangoextras.formfields.
DynamicSelect
(attrs=None, choices=None)¶ A
Select
widget whose choices are not static, but instead generated dynamically when referenced.Parameters: choices – callable; this will be called to generate choices each time they are referenced.
http
- Content Negotiation for Django views¶
-
http.
content_negotiation
(formats, default_type='text/html')¶ Provides basic content negotiation and returns a view method based on the best match of content types as indicated in formats.
Parameters: - formats – dictionary of content types and corresponding methods
- default_type – string the decorated method is the return type for.
Example usage:
def rdf_view(request, arg): return RDF_RESPONSE @content_negotiation({'application/rdf+xml': rdf_view}) def html_view(request, arg): return HTML_RESPONSE
The above example would return the rdf_view on a request type of
application/rdf+xml
and the normal view for anything else.Any
django.http.HttpResponse
returned by the view method chosen by content negotiation will have a ‘Vary: Accept’ HTTP header added.NOTE: Some web browsers do content negotiation poorly, requesting
application/xml
when what they really want isapplication/xhtml+xml
ortext/html
. When this type of Accept request is detected, the default type will be returned rather than the best match that would be determined by parsing the Accept string properly (since in some cases the best match isapplication/xml
, which could return non-html content inappropriate for display in a web browser).