Creates a filter for displaying calendars.
Passed value is a dict of dicts of arrays: that is, indexed by year, then by month. The list of month days is used to generate links in the format specified by the argument. If a particular day is *not* in the list, then no link will be generated and it will just display a number for that day.
**EXAMPLE**
`{{ calendar|calendar_table:"/schedules/calendar/[Y]-[m]-[d]/" }}`
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)
Displays an input with an add button. Clicking the add button creates a simple form - input with a submit button. Clicking the submit button will send the output to the server and return a value which is displayed.
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.
We had some fun today on the #django IRC channel searching and counting through past logs for people saying "thanks" to [a known very helpful person](http://djangopeople.net/magus/).
Here's a unix shell script for checking your own score if you're using Pidgin and have logging turned on.
Replace ".purple" with ".gaim" in the script if you're using Gaim (an older version of Pidgin).
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.