This module is comes from the original staticview.py from django. But when you using it, it can looks for static files in your app's subdirectory. So that you can put static files which concerned with your app in a subdirectory of the app. I should say it method only suit for developing, so if you want to deploy your application to apache, you should copy static folder to the real media folder. And if you keep the same structure of the directory, then it'll be very easy. And you can write a little script to automatically do that. But for now, I didn't have written one yet :P
How to use it in urls.py
--------------------------
Here's an example:
(r'^site_media/(.*)$', 'utils.staticview.serve', {'document_root': settings.SITE_MEDIA, 'app_media_folder':'media'}),
It seems just like the original one in django. But there is a new parameter "app_media_folder", it's used for subdirectory name of app. So your django project folder structure maybe seem like this:
/yourproject
/apps
/appone
/media
/css
/img
/js
/media
/css
/img
/js
Ever want to call stored procedures from Django easily? How about PostgreSQL functions? That's that this manager attempts to help you with. To use, just stick this in some module and in a model do:
class Article(models.Model):
objects = ProcedureManager()
Now you can call procedures (MySQL or PostgreSQL only) to filter for models like:
Article.objects.filter_by_procedure('ProcName', request.user)
This will attempt to construct a queryset of objects. To just get random values, do:
Article.objects.values_from_procedure('ProcName', request.user)
Which will give you a list of dictionaries.
Keeps database table names out of custom SQL code, but still allows for correct parameter passing in the execute function. (psycopg doesn't substitute table or field names, only data, in the execute function)
This isn't really any trick, its just that I didn't find any documentation of this or any references in searching. There are a few changes proposed for css classes which might make this redundant, but for now this works!
If you want to add attributes for any fields, just include them in the widget constructor. They get written out in key value pairs when the input field is being created. e.g. in the example above, this will come out like:
`
'<input type="text" name="start_date" id="id_start_date" class="vDateField required" size="10"/>'
`
This template inclusion tag provide a way to have multiple pagination blocks in the same page. Aditionnal parameters in "request.GET" are also automaticaly keeped in pagination links.
Usage :
**{% show_pagination users_paginator request "page_members" %}**
The expected result :
**[1] 2 3 … 14**
Or :
**1 … 5 6 [7] 8 9 … 14**
A little tiny middleware that, when used in multilingual sites, will make Django I18N ignore any `Accept-Language` headers in the request, thus ensuring that every first-time visitor (with no explicit language preference set via session or cookie) will see the site in the language specified by `settings.LANGUAGE_CODE`.
(Please note that I think that overriding user preferences is generally a bad practice, but I had my reasons to use it :) )
This a small but very handy view that gives you a convenient direct access to your templates.
Now suppose you saved the snippet under `misc.py`, it's critical to add this snippet (or a similar one, once you get the idea) to your `urls.py`:
if settings.DEBUG:
# Direct Templates
urlpatterns += patterns('misc',
(r'^template/(?P<path>.*)$', 'direct_to_template', {'template': '%(path)s'}),
)
Now you are able to access any of your templates, in different directories by specifying their path after `template/`. e.g., http://example.com/template/news/index.html
Of course you can change it as you want, you can also add other values to the dict argument, the only required key is `'template'`. The whole dict is made available in the template as a context.
All GET parameters are made available in the template too. So `http://example.com/template/news/index.html?title=Testing Title` will make the `{{ title }}` var available in your template. So you can substitute basic variables quickly.
This is was inspired by [django.views.generic.simple.direct_to_template](http://www.djangoproject.com/documentation/generic_views/#django-views-generic-simple-direct-to-template)
Changes **all slugify calls** to support translat automatically, behind the scenes. Using this one doesn't have to change any models or code to make it work everywhere.
Create new project, I call it myself *autoslugifytranslat*, and add the following to project's `__init__.py` file. It will automatically add translat slugify support for all default slugify calls.
This script is depending on the fact that slugify function in Django is always in *django.template.defaultfilters.slugify*.
**Note:** The snippet is supposed to have "ä","Ä" and "ö","Ö" in the `char_translat` list, but djangosnippets does not let me put ä's and ö's to the code part!
**The code is a bit messy and may include bugs ;-) Anyway, I want to clean it up and add features (see below).**
The `process_latex()` function will read the given template, render it with a custom context and convert it into the desired output format by running it through pdflatex.
Depending on the `outfile` parameter, the output will either be returned (for a response object) or written to the path specified in `outfile` (useful for `save()` in models which generate static, unique files).
**TODO**
* Error handling in case pdflatex breaks (non-zero return value)
* Optionally returning a HttpResponse with the correct mimetype and Content-Disposition set to attachement and an appropriate filename
* RequestContext instead of Context (passing the Context object instead of a dict)
**CREDITS**
Credits also go to ronny for the names dict :-P
You're looking at the most-bookmarked snippets on the site; if you'd like to help useful snippets show up here, sign up for an account and you'll get your own bookmarks list.