IP Authorisation Decorator
Simple decorator definition to authorize particular IPs access to a view function.
- decorator
- auth
- IP
- authorisation
- ip-authorisation
Simple decorator definition to authorize particular IPs access to a view function.
This creates an RSS feed that has "content:encoded" elements for each item in the feed. The "description" is best used for a brief summary of the entry, while the extra ["content:encoded"](http://purl.org/rss/1.0/modules/content#syntax2) element is designed for the entire contents of something. This is the code I'm using for a weblog app. The main features you'd need to copy to add "content:encoded" elements to your own feed are: * **ExtendedRSSFeed()** -- this is used to create a new kind of feed generator class that will know about these extra elements. * **feed_type = ExtendedRSSFeed** -- we tell the feed class which feed generator class to use. * **item_extra_kwargs()** -- we add the "content:encoded" element to each item. This populates the element by calling... * **item_content_encoded()** -- this prepares the actual content. The name doesn't have to be in this format, but it seemed sensible to follow convention. The body of my weblog Entries are split into two parts and here it makes sure we add both parts, both of which contain HTML (which the syndication classes will encode appropriately.
This authenticate together django.contrib.auth.models.User like django normal login does.
This code is taken from a [Stack Overflow answer by Will Hardy](http://stackoverflow.com/questions/3715550/creating-a-list-on-the-fly-in-a-django-template/3715794#3715794). Usage: `{% collect var1 var2 'foo' 'bar' 5 as some_list %}`. Sometimes one wishes to create a list on the fly within a template. Perhaps a collection needs to be passed to a template filter, but the collection cannot be created in the view since the values of one or more of its items are set in the template. A contrived example: {% with 5 as max %}{% with posts|length as len %} {% for post in posts %} {% if forloop.counter <= max %} {% include 'excerpt.dhtml' %} {% endif %} {% endfor %} {% collect len max as limits %} <p>Displaying {{ limits|minimum }} of {{ len }} post{{ posts|pluralize }}.</p> {% endwith %}{% endwith %} The final line will state how many posts are displayed: something like "5 of 24" or "2 of 2". This particular problem can be solved in a number of other ways, some of which are more appropriate. Having a template tag that can create lists on the fly is potentially useful in quite a few situations, though. I don't know whether this need is common enough to warrant being in the core. If something like this is to be included one day, it'd be much nicer to overload the `with` tag than to introduce a new tag. `{% with var1 var2 var3 as some_list %}` reads well.
I'll throw my implementation into the mix - shortcut for render_to_response as a decorator.
Unfortunately, it is not possible currently to use foreign keys in list filter of the admin website. list_filter=['city__country'] doesn't work. This filter spec tries to workaround this problem. It is also possible to have 2 filters for a foreign-key field but it requires to add a dummy field to the model. Set the fk_filterspec dictionnary on this dummy field and add 'fk':'real-field' to the dict.
if_installed checks to see if the app is in installed apps. If it is not then it excludes it from being resolved in the url structure. In this example, myapp.urls will not be imported if myapp is not installed
I have many heavy views which run slowly when accessed at same time in multiple threads. I make this decorator to allow run only one view at the time and cache returned result. Other threads will wait to complete first thread and use response from the cache if executed thread put it to cache. Also I take idea of MintCache to refresh staled cache and return cached (stale) response while response refreshed in the cache. Usage: @single_cacheable(cache_timeout=60, stale_timeout=30, key_template='my_heavy_view-{arg1}-{arg2}') def heavy_view(request, arg1, arg2): response = HttpResponse() ... your code here # cache timeout may be set from inside of view response._cache_timeout = cache_time return responce The "key_template" is a template for cache key. Some my views have additinal parameter "cache_time" which set from parent page and request.path is different for these pages but they need to be cached not depending of this parameter. Variable "key_template" in the example used named agrument, if you have no named paramaters you need to use 'my_heavy_view-{1}-{2}-{...}' where {1},{2}, {...} arguments of view. The line with setting "key" variable may be changed to: key = "sc_"+request.get_full_path() if you need to take full URL path as cache key.
Sometimes you want more rendering control than common widgets give you. We wrote this, for example, to allow rendering the checkboxes of a multi select field with checkbox widget, as multiple columns. Place this in the templatetags subdirectory of an app you are loading (be sure it has a __init__.py file), and load it something like this (you may want to shorten the name): {% load checkboxiterator_filter %} Then you can say something like: {% for checkbox in form.categories|checkboxiterator %} {# other code #}{{ checkbox }}{# other code #} {% endfor %} where form.categories is a multiple select field (no doubt this technique could be applied to radio buttons and a single select field). The filter does use some internal interfaces, but may well still work on newer Django version.
Forces admin site to use your custom login. Very useful when using RemoteUserBackend. See [here](http://djangosnippets.org/snippets/2128/) for a use case.
The `internal_view` decorator makes a view accessible only from `INTERNAL_IPS`. Handy for exposing internal APIs.
This is custom tag I wrote for myself for solving situations when you have filter form and page numbers in the same page. You want to change ?page=.. or add it if it doesn't exist to save filter form data while moving through pages. Usage: place this code in your application_dir/templatetags/add_url_parameter.py In template: {% load add_get_parameter %} <a href="{% add_get_paramater param1='const_value',param2=variable_in_context %}"> Link with modified params </a> It's required that you have 'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS URL: [http://django.mar.lt/2010/07/add-get-parameter-tag.html](http://django.mar.lt/2010/07/add-get-parameter-tag.html)
Automatically register models for the Django-admin. This snippet aids in the process of keeping your admin.py up-to-date with the models in your apps, have all models automatically added to the admin and reflect any future changes without updating the file. [zweckdev.com](http://zweckdev.com/)
This is in the spirit of php's include_once or a C preprocessor #ifndef. Kind of. As you might've guessed, the output of {% renderonce %}foo{% endrenderonce %} {% renderonce %}foo{% endrenderonce %} in a template will be a single 'foo'. I use it for js script tags personally, to prevent duplicate inclusions. If you ended up here, chances are you've already explored the "use inheritance" or "use django-(app X)" solutions, so feel free to omit such comments.
This is a minimal template loader for Django 1.2 or higher that loads [Jinja2](http://jinja.pocoo.org/2/) templates. It is better integrated with Django than using Jinja2 directly: * Your view code is the same * Unmodified generic views use it * RequestContext and context processors still work To use it, add the following to you `settings.py` file: TEMPLATE_LOADERS = ( 'jinja2_for_django.Loader', ) It searches for templates in the same places as `django.template.loaders.app_directories.Loader` − that is in the `templates` directory of each installed app. Django custom and default template tags and filters are not available. Some are the same in Jinja2, but you need to replace the others yourself. You can add global filters and variables (such as functions) in the `Loader.env.filters` and `Loader.env.globals` dicts. You can not add tags. See the [Jinja2 documentation](http://jinja.pocoo.org/2/documentation/) for more details.
3110 snippets posted so far.