This table tag helps with render tables, which can be fairly complex.
I updated the previous table tag (296).
I added support for oddrow,evenrow,lastcellinrow,oddcol,evencol. And made a few minor adjustments to syntax formatting, and some non needed if conditionals
These are all of the supported variables available in the context
{{table.counter0}}
{{table.counter}}
{{table.rowcounter0}}
{{table.rowcounter}}
{{table.startrow}}
{{table.endrow}}
{{table.oddrow}}
{{table.evenrow}}
{{table.firstrow}}
{{table.lastrow}}
{{table.firstcell}}
{{table.lastcell}}
{{table.lastcellinrow}}
{{table.evencol}}
{{table.oddcol}}
{{table.parenttable}}
This is a conditional templatetag decorator that makes it *very* easy to write template tags that can be used as conditions. This can help avoid template boilerplate code (e.g. setting a variable in your template to be used in a condition).
All you have to do is define a function with expected parameters that returns True or False. Examples are in the code.
Create a list containing an arithmetic progression that can be iterated through in templates.
Emulate the [range](http://docs.python.org/library/functions.html#range) syntax.
You can use either numbers or variables.
Syntax:
{% num_range [start] stop [step] as some_range %}
{% for i in some_range %}
... do something
{% endfor %}
**About the author**:
Take a look at [my website](http://www.marcofucci.com)
This tag gives you an iterable Python [Calendar object](http://docs.python.org/library/calendar.html) in your template namespace. It is used in the [django-calendar](http://github.com/dokterbob/django-agenda) project.
Use it as follows in your template:
{% get_calendar for <month_number_or_variable> <year_or_variable> as calendar %}
<table>
<tr>
<th>Mon</th>
<th>Tue</th>
<th>Wed</th>
<th>Thu</th>
<th>Fri</th>
<th>Sat</th>
<th>Sun</th>
</tr>
{% for week in calendar %}
<tr>
{% for day in week %}
<td>{{ day.day }}</td>
{% endfor %}
</tr>
{% endfor %}
</table>
Does exactly what it says on the tin!
This template tag, when implemented, converts a duration (in seconds) to a more meaningful format. It has a short and long setting, which is easy to manipulate for your needs. Apologies if something already exists like this, however I felt that writing this would be quicker than trying to find it online.
As an example, given the duration 84658:
Short (default): 23 hrs 30 mins 58 secs
Long: 23 hours, 30 minutes and 58 seconds
All the best,
[Dan Ward](http://d-w.me).
This is a [Paginator Tag](http://www.djangosnippets.org/snippets/73/) for 1.x. Since the context is less overfull, the template, paginator.html, needs more logic.
Put the tag in your templatetags and the template at the root of a template-directory.
The tag will work out of the box in a generic view, other views must provide `is_paginated` set to True, `page_obj`, and `paginator`. You can get the `object_list` from the `page_obj`: `page_obj.object_list`. See [the pagination documentation](http://docs.djangoproject.com/en/1.0/topics/pagination/).
This is a template tag that works like `{% include %}`, but instead of loading a template from a file, it uses some text from the current context, and renders that as though it were itself a template. This means, amongst other things, that you can use template tags and filters in database fields.
For example, instead of:
`{{ flatpage.content }}`
you could use:
`{% render_as_template flatpage.content %}`
Then you can use template tags (such as `{% url showprofile user.id %}`) in flat pages, stored in the database.
The template is rendered with the current context.
Warning - only allow trusted users to edit content that gets rendered with this tag.
** DEPRECATED**, use [django-reversetag @ github](http://github.com/ulope/django-reversetag/tree/master) instead.
If you want to be able to use context variables as argument for the "url" template tag this is for you.
Just put this code somwhere where it will be run early (like your app's _ _init_ _.py) and of you go.
Usage:
{% url name_of_view_or_variable arg1 arg2 %}
**NOTE:** This may possibly break your site!
Every view name that is passed to url will be tried to be resolved as a context variable first!
So if there is a variable coincidentally named like one of your views THEN IT WILL BREAK.
So far it works great for me, but keep an eye out for name clashes.
Sometimes you need to write a tag that renders other template, but the template name depends on template tag arguments. Usually you use simple_tag or write your own Node class. Here is a simple aproach that uses inclusion_tag. This way you can use context objects when used with takes_context=True
This snippet adds simple partial support to your templates. You can pass data to the partial, and use it as you would in a regular template. It is different from Django's `{% include %}`, because it allows you to pass a custom variable (context), instead of reusing the same context for the included template. This decouples the templates from each other and allows for their greater reuse.
The attached code needs to go into `templatetags` folder underneath your project. The usage is pretty simple - `{% load ... %}` the tag library, and use `{% partial_template template-name data %}` in your template. This will result in template passed as **template-name** to be loaded from **partials** folder. The **.html** extension will be appended to the file name. The file has to be in one of template paths accessible to the loader) and rendered with **data** as its context. The data is available in the template as an `item` context variable.
You can find more information in the [relevant Django documentation](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#howto-custom-template-tags)
returns a list of (argname, value) tuples
(NB: keeps ordering and is easily turned into a dict).
Params:
* tagname : the name of calling tag (for error messages)
* bits : sequence of tokens to parse as kw args
* args_spec : (optional) dict of argname=>validator for kwargs, cf below
* restrict : if True, only argnames in args_specs will be accepted
If restrict=False and args_spec is None (default), this will just try
to parse a sequence of key=val strings.
About args_spec validators :
* A validator can be either a callable, a regular expression or None.
* If it's a callable, the callable must take the value as argument and
return a (possibly different) value, which will become the final value
for the argument. Any exception raised by the validator will be
considered a rejection.
* If it's a regexp, the value will be matched against it. A failure
will be considered as a rejection.
* Using None as validator only makes sense with the restrict flag set
to True. This is useful when the only validation is on the argument
name being expected.
Simply returns a created gravatar url based on input. Creates the url utilizing the full gravatar url inputs as defined at http://en.gravatar.com/site/implement/url.