Yes, they are called `Template tags and filters` in Django parlance. A tag
has the form {% <tag name> %} and is replace in the final render with its
output. a Filter has the form {{ |<filter name>: <filter parameters> }}
and works like a piped command in Linux, receiving the input from a
variable and modifying it.
Documentation link:
https://docs.djangoproject.com/en/1.11/howto/custom-template-tags/
Custom tags need to be placed in the templatetags folders of an app. You
can also make your own almost empty app to add your own custom tags if you
don't to directly change committed code.
Example of custom tag in Mayan:
https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/documents/templatetags/printing_tags.py
https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/appearance/templatetags/appearance_tags.py
To enable a set of tags in a template you need to load then using {% load
appearance_tags %} for example will enable all tags and filters in the file
appearance_tags.py
You can have many tag libraries for each app templatetags directory but a
common suggestion is to have just one per app with the app name as the
prefix (appearance_tags.py, folders_tags.py, etc).
You can create a complex tag subclassing the Node class (example: when you
need an opening and closing tag like {% for %} {% endfor %}), but the
easiest way it to use a decorated function that can read the template
context and return a value. Less common and not recommended, but tags and
filters can also modify the context to insert variables or change values of
other variables.
On Thursday, April 20, 2017 at 9:05:46 AM UTC-4, MacRobb Simpson wrote:
>
> Is there any way to define a simple class somewhere and call it using the
> template language to do this?
> Something like how validators are made?
>
> On Thursday, April 20, 2017 at 12:27:29 AM UTC-7, Roberto Rosario wrote:
>>
>> Allowing interpreted Python code was later considered a security risk.
>> These fields now use the template language of Django (
>> https://docs.djangoproject.com/en/1.10/ref/templates/language/
>> <https://www.google.com/url?q=https%3A%2F%2Fdocs.djangoproject.com%2Fen%2F1.10%2Fref%2Ftemplates%2Flanguage%2F&sa=D&sntz=1&usg=AFQjCNGH5bfzqqQg_T5-xttrWYt1G7EIhg>)
>>
>> and expect a comma delimited output. So the years example would now be:
>>
>> '1990', '1991', '1992', '1993', '1994', '1995', '1996', '1997', '1998',
>> '1999', '2000'
>>
>> without the brackets.
>>
>> The second example cannot be done as the template language doesn't
>> support range generators. This is some of the reasons switching to the
>> Jinja2 template language is being considered. It is more secure than Python
>> code, is a superset of Django's template language but add many Pythonistic
>> tags line range().
>>
>>
--
---
You received this message because you are subscribed to the Google Groups
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
