This function takes a string (most likely from a template), searches it for `<code>[...]</code>`, highlights it with Pygments, and returns the entire thing back, as a string. (Note: the `<code>[...]</code>` must have a class corresponding to the language inside. If it lacks the class, then it's silently ignored.)
This is like [snippet 36](/snippets/36/). And it'll return css also. And it's not a filter.If the code parameter is skip, it'll test the code first, and if there is not a suiable lexer for the code, then use default python lexer to render the code. The code lanauage parameter is comes from pygments lexer alias. How to use it ---------------- html = to_html(rest_text) And there is a level parameter in to_html function, default is `2`, it's the sections level. And the html will be `css style + body` How to write ReST --------------------- Below is a example. This is a test. .. code:: def code(name, arguments, options, content, lineno, content_offset, block_text, state, state_machine): opt = {'display':'on'} opt.update(options) docnodes.Node(content, ''.join(arguments), **opt) if opt['display'].lower() == 'on': return [nodes.literal_block('', '\n'.join(content))] else: return [] .. code:: html+django <h1 id="title">通讯录</h1> <hr> <div> <table border="0" width="500"> <tr align="right"> <td>{% if has_previous %} <a href="/address?page={{ previous }}">上一页</a> {% endif %} {% if has_next %} <a href="/address?page={{ next }}">下一页</a> {% endif %}</td></tr> </table>
The loremipsum tag generates random content for use in mockups. It takes this content from Cicero's De finibus bonorum et malorum. By default you get a random number of paragraphs up to 6, but you can affect this behaviour by passing in parameters for quantity and units. Units can be "paragraphs" or "words"; the default is paragraphs. Quantity dictates the number of units returned. If your django.conf.settings.TEMPLATE_DEBUG is True, then no output is returned, so you should be OK in the event you leave the tag in a production template. Syntax: {% loremipsum %} {% loremipsum quantity="3" units="paragraphs" %} By leaving the behaviour as random, you can see how your layout handles varying amounts of content. Handy, especially for multi-column pages. [Here's a stoopid site](http://lakes.knoxzilla.com/) where I'm playing with random text, pictures, business listings, etc. I do plan to add a "corpus" parameter to allow you to put your own corpus between lorumipsum and endloremipsum tags and a template parameter to specify the corpus should come from a template, but this has suited me well thus far.
In your site’s settings.py module (in your site root), TEMPLATE_DIRS takes absolute paths. Here is a way to dynamically determine the absolute path to the application directory so you only have to specify relative paths within settings.py. Obviously, replace “application_directory” with the name of your application’s directory.
Most of the time when you want a dropdown selector based on a ForeignKey, you'll want to use [snippet #26](http://www.djangosnippets.org/snippets/26/) Here's an alternative approach, perhaps useful when you want to define choices once and reuse it in different views without overriding Form `__init__`.
This bash script clears the session variables prior to running the development server.
`foo = dynamic_import ( 'rawr.i.am.a.lion' )` Will import `lion` from `rawr.i.am.a` and return it. (This isn't really Django specific) Props to Crast for the original.
A way to implement models with translatable content. The translatable field of the default language has no extension, like "title" and the translations have extensions postfixes "_<two-letter language code>", like "title_la" or "title_mn". Method get_title() in this case returns the translation of the currently chosen language or the title of the default language, if the translation is not set. The class XFieldList overrides the default list class and is used for modifying ordering and list_display settings according the chosen language. For example, when the German language is chosen, the list of translatable content objects will be ordered by German titles (not English). *At the time when the list of field names is assigned to ordering or list_display (at the import of the model), the currently chosen language is still not known. But the language is known when ordering and list_display lists are used in contributed administration or elsewhere.* The XFieldList returns the modified values of the passed-in list, when its methods/properties are triggered. XFieldList transforms field names ending "_" (except the ones beginning with "__", like "__str__") to appropriate translations according the currently chosen language. For example ['title_', 'content_', 'is_published'] will be changed to ['title', 'content', 'is_published'] for the English language and to ['title_lt', 'content_lt', 'is_published'] for the Lithuanian language. *The best practice is to put XFieldList into a separate file and import it from different apps whenever needed.* It's worth mentioning that one implementing this should also know about [Django internationalization](http://www.djangoproject.com/documentation/i18n/).
Returns a sharpened copy of an image. Resizing down or thumbnailing your images with PIL.Image tends to make them blurry. I apply this snippet to such images in order to regain some sharpness.
I use this script to keep track of the cache usage for various sites. It presently only supports memcached because that's all that I use, but leave a comment with patches for other systems and I'll add them.
Using newforms you can create forms from existing models easily and automatically with either `form_for_model(class)` or `form_for_instance(instance)`. Usually the automagically generated form fields are sufficient; however, sometimes you need to restrict selections in a choice field. You can also set the default selection when instantiating the form. In this example, if `acct` is not contained in the 'account' field choices, the selection defaults to the first entry. This example is probably not good practice when using `form_for_instance` because the existing value 'selection' of the choice field is lost and must be reset manually (see above).
A patch (against django svn trunk [4649](http://code.djangoproject.com/browser/django/trunk/?rev=4649)) that allows users to log in with Basic HTTP Authentication i.s.o. login forms using some simple middleware (entire patch is ~50 lines). I was unaware of http://code.djangoproject.com/wiki/GenericAuthorization so I'm not sure about its usefulness in the long run. You can enable it by including 'django.contrib.auth.middleware.BasicAuthenticationMiddleware' in your MIDDLEWARE_CLASSES and then adding the following lines in your settings.py: BASIC_WWW_AUTHENTICATION = True WWW_AUTHENTICATION_REALM = "djangolures.com" Updated: See also http://code.djangoproject.com/ticket/3609 (patch now availble here as well).
[Snippet #2](http://www.djangosnippets.org/snippets/2/) demonstrated some cool tricks possible with manager methods. This example shows how to assign and use a custom manager method. In this snippet the `belongs_to_user` method returns an Account queryset containing only those accounts associated with the specified user. The method is useful because it hides the implementation of User in the Account model. Line 17 associates the custom manager with the Account model.
Allows you to override form fields created by form_for_model or form_for_instance, without having to redefine whole fields for example in form.base_fields.
This middleware will add a log of the SQL queries executed at the bottom of every page. You can (should) use BeautifulSoup to place this in a specific location. Note: If you serve non-html content, it would be wise to do a mimetype check.