Simple e-mail template tag
Usage: {% mailto email [linktext] %} `email' parameter is required; linktext is optional, defaulting to the email address.
- template
- tag
- templatetag
Usage: {% mailto email [linktext] %} `email' parameter is required; linktext is optional, defaulting to the email address.
Usage: Literal value, use default timeout {% geturl "http://example.com/path/to/content/" %} Variable value, literal timeout {% geturl object.urlfield 5 %}
If you want to modify the length of a column of a contrib application, you can either modify django (cumbersome) or you can run a post_syncdb signal hook. Related: [Ticket 4748](http://code.djangoproject.com/ticket/4748)
This filter converts a XHTML-compatible shorttag `<input ... />` to a HTML4-compatible tag `<input ...>`. Example: `{% for field in form %} <dt>{{ field.label_tag }}</dt> <dd> {{ field.errors }} {{ field|remove_shorttag }} </dd> {% endfor %}` This will produce html4-compatible output, opposed to newform's normal XHTML output.
This allows you to define a 'prefilter' function in your view modules which will be invoked before any view in that same. This provides an easy place to decorate the request or modify arguments. For simplicity it doesn't allow configuration of the name of the prefilter function. I also skipped recursing into parent modules since that's somewhat edgecase.
This is a little snippet that you can use to make your Django newforms dynamic at runtime. You can define an arbitrary number of fields of the form without loosing newforms capibilites. You can render the form dynamically be "misusing" the "help_text" attribute of the form fields (Every form field allows the definition of this attribute). This way you can search for changes in the help_text of every field and render the form accordingly. The form itself is dynamically defined in the view. The form state can be saved in a Django Session Variable (specifically for Linux users with a process-based Apache Server), so that you can rebuild and verify a submitted form.
When you need to include a specific javascript file/code snippet in your page, it's always better to do it at the bottom of your page to avoid to block the rendering too soon. This tag provide you a nice way to include and launch only what is needed: Example in an included template that need to display google maps: {% dict js_file google_api %} <script src="http://www.google.com/jsapi?key={{ MAPS_API_KEY }}" type="text/javascript" charset="utf-8"></script> <script src="{{MEDIA_URL}}js/map.display.js" type="text/javascript">...</script> {% enddict %} {% dict js_code link_map %} $('.show-map').click(function() { ... }); $('.hide-map').click(function() { ... }); {% enddict %} Finaly you just have to add this to the very bottom of your base.html file: .... </body> {% for k,v in js_file.items %} {{v}} {% endfor %} <script type="text/javascript"> /* <![CDATA[ */ {% for k,v in js_code.items %} {{v}} {% endfor %} /* ]]> */ </script> </html>
This server-side middleware implements some of the functionality in the Yahoo User Interface Loader component. YUI JavaScript and CSS modules requirements can be declared anywhere in the base, inherited or included templates, and the resulting, optimized `<script>` and `<link rel="stylesheet">` tags are inserted at the specified position of the resulting page. Requirements may be specified in multiple locations. This is useful when zero or more components are included in the HTML head section, and inherited and/or included templates require possibly overlapping sets of YUI components in the body across inherited and included templates. All tags are collected in the head section, and duplicate tags are automatically eliminated. The middleware understands component dependencies and ensures that resources are loaded in the right order. It knows about built-in rollup files that ship with YUI. By automatically using rolled-up files, the number of HTTP requests is reduced. The default syntax looks like HTML comments. Markup for the insertion point is replaced with `<script>` and `<link>` tags: <!-- YUI_init --> Component requirements are indicated, possibly in multiple locations, with the `YUI_include` markup. It is removed from the resulting page by the middleware. Example: <!-- YUI_include fonts grids event dragdrop --> Non-minified and compressed versions are requested, respectively, by: <!-- YUI_version raw --> <!-- YUI_version debug --> Example: <html><head> <!-- YUI_init --> <!-- YUI_include dom event --> </head><body> <!-- YUI_include element selector reset fonts base --> </body></html> Renders: <html><head> <link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.5.1/build/reset-fonts/reset-fonts.css" /> <link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.5.1/build/base/base-min.css" /> <script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/yahoo-dom-event/yahoo-dom-event.js"></script> <script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/element/element-beta-min.js"></script> <script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/selector/selector-beta-min.js"></script> </head><body> </body></html> The markup format can be customized with global Django settings. Example: YUI_INCLUDE_PREFIX_RE = r'{!' YUI_INCLUDE_SUFFIX_RE = r'!}' would change markup to e.g. `{! init !}` and `{! include dom event !}`. The base URL is customized with the `YUI_INCLUDE_BASE` setting, e.g.: YUI_INCLUDE_BASE = 'http://localhost:8000/yui/build/' To remove the XHTML trailing slash from the `<link>` tag, use: YUI_INCLUDE_CSS_TAG = '<link rel="stylesheet" type="text/css" href="%s">' See also the [home page for this module](http://trac.ambitone.com/ambidjangolib/wiki/YUI_include).
Automatically sets date to today if only time part was entered. If today is 01/01/2008, then both DateTimeField and TodayDateTimeField clean '2008-01-01 15:05' to datetime(2008,01,01,15,5,0), while '15:05' is cleaned as datetime(1900,01,01,15,5,0) for DateTimeField but datetime(2008,01,01,15,5,0) for TodayDateTimeField.
Serving KML from your Django webapp to feed Google-earth isn't that hard, it's just some fun with templates, plus some headers. But serving a compressed version of your KML needs a trick. KMZ isn't just zipped KML. A good KMZ file is a zipped file that decompress to a file called 'doc.kml', which is a KML file. So, I suppose 'http://yourdomain.com/kml/' points to a view generating a well-formed KML. I even suppose that 'http://yourdomain.com/kmz/' points to the same view, but it will serve KMZ instead that KML: no change needed in your code! If your webapps serves more than one KML file you just need to append the new KMZ urls to your urls.py, pointing to the very same view serving the KML version. Then add that urls to the list in this middleware. As an example I included a 'http://yourdomain.com/kml/restricted/' to 'http://yourdomain.com/kmz/restricted/' conversion.
A middleware that parses the HTTP_ACCEPT header of a request. The request gets a new method called "accepts" that takes a string and returns True if it was in the list of accepted mime-types. It makes it possible to write views like: def exampleview(request): if request.accepts('application/json'): # return a json representation if request.accepts('text/html'): # return html Please note that with this middleware the view defines the priority of the mime-types, not the order in which they where provided in the HTTP-Header.
Standarization of image fields (for being used when saving models). Automatically creates thumbnail. Change image name to /path/to/images/<my_field>-<id>.<ext>. Resize image and thumbnail to specified size (optionally can crop image to force size).
This view will provide a link for AuthSub proxy authentication to the Google Contacts API and then grab the user's Google contacts and compare against User.email for possible user relationships. A couple of things to note: * Dependency on the GData Python client library: http://code.google.com/p/gdata-python-client/ * The domain hosting the view must be verified by Google's domain manager (otherwise API calls will result in a 403): https://www.google.com/accounts/ManageDomains Thanks to Simon for get_url_host and get_full_url.
A replacement test runner which outputs a coverage report after the tests. Simply change your ``TEST_RUNNER`` setting to point to ``run_tests_with_coverage`` and you're good to go. Note that 'as-is' this snippet reports the coverage of all modules underneath the app, by walking the directory tree and loading all of the .py modules (this may be a naive approach). If you change it to use `get_coverage_modules()` instead, it will only display the coverage of modules that have been imported by the test suite, using the Python `inspect` lib, which may be more reliable. Uses [coverage.py](http://nedbatchelder.com/code/modules/coverage.html). Based on ideas from: [1](http://www.thoughtspark.org/node/6), [2](http://blogs.23.nu/c0re/stories/15428/) and [3](http://siddhi.blogspot.com/2007/04/code-coverage-for-your-django-code.html)
This simple middleware replaces all 'a href' links to the current page to the 'span' elements. This very usefule from the usability point of view. For example, user open in bowser page http://svetlyak.ru/blog/, and this middleware will replace all 'a' elements on this page, which refer to the '/blog/'. Because of this, link 'Blog' in the main menu, become a simple 'span'. Next, when user goes to the next page, a post with full comments list ('/blog/123/'), for example, the item 'Blog' in the main menu become a link again! To use this middleware, just add it to the list of middleware classes: MIDDLEWARE_CLASSES = ('utils.middleware.RemoveSelfLinks',)
2956 snippets posted so far.