mirror of
https://github.com/django/django.git
synced 2025-07-21 18:19:12 +00:00
Replaced '' with * for consistent emphasis styling in docs/howto/custom-template-tags.txt.
This commit is contained in:
parent
be402891cd
commit
5020a9d43a
@ -837,12 +837,12 @@ The template system works in a two-step process: compiling and rendering. To
|
|||||||
define a custom template tag, you specify how the compilation works and how
|
define a custom template tag, you specify how the compilation works and how
|
||||||
the rendering works.
|
the rendering works.
|
||||||
|
|
||||||
When Django compiles a template, it splits the raw template text into
|
When Django compiles a template, it splits the raw template text into *nodes*.
|
||||||
''nodes''. Each node is an instance of ``django.template.Node`` and has
|
Each node is an instance of ``django.template.Node`` and has a ``render()``
|
||||||
a ``render()`` method. A compiled template is a list of ``Node`` objects. When
|
method. A compiled template is a list of ``Node`` objects. When you call
|
||||||
you call ``render()`` on a compiled template object, the template calls
|
``render()`` on a compiled template object, the template calls ``render()`` on
|
||||||
``render()`` on each ``Node`` in its node list, with the given context. The
|
each ``Node`` in its node list, with the given context. The results are all
|
||||||
results are all concatenated together to form the output of the template.
|
concatenated together to form the output of the template.
|
||||||
|
|
||||||
Thus, to define a custom template tag, you specify how the raw template tag is
|
Thus, to define a custom template tag, you specify how the raw template tag is
|
||||||
converted into a ``Node`` (the compilation function), and what the node's
|
converted into a ``Node`` (the compilation function), and what the node's
|
||||||
@ -906,8 +906,7 @@ Notes:
|
|||||||
* The ``TemplateSyntaxError`` exceptions use the ``tag_name`` variable.
|
* The ``TemplateSyntaxError`` exceptions use the ``tag_name`` variable.
|
||||||
Don't hardcode the tag's name in your error messages, because that
|
Don't hardcode the tag's name in your error messages, because that
|
||||||
couples the tag's name to your function. ``token.contents.split()[0]``
|
couples the tag's name to your function. ``token.contents.split()[0]``
|
||||||
will ''always'' be the name of your tag -- even when the tag has no
|
will *always* be the name of your tag -- even when the tag has no arguments.
|
||||||
arguments.
|
|
||||||
|
|
||||||
* The function returns a ``CurrentTimeNode`` with everything the node needs
|
* The function returns a ``CurrentTimeNode`` with everything the node needs
|
||||||
to know about this tag. In this case, it passes the argument --
|
to know about this tag. In this case, it passes the argument --
|
||||||
@ -1305,9 +1304,9 @@ Here's how a simplified ``{% comment %}`` tag might be implemented::
|
|||||||
followed by ``parser.delete_first_token()``, thus avoiding the generation of a
|
followed by ``parser.delete_first_token()``, thus avoiding the generation of a
|
||||||
node list.
|
node list.
|
||||||
|
|
||||||
``parser.parse()`` takes a tuple of names of block tags ''to parse until''. It
|
``parser.parse()`` takes a tuple of names of block tags *to parse until*. It
|
||||||
returns an instance of ``django.template.NodeList``, which is a list of
|
returns an instance of ``django.template.NodeList``, which is a list of
|
||||||
all ``Node`` objects that the parser encountered ''before'' it encountered
|
all ``Node`` objects that the parser encountered *before* it encountered
|
||||||
any of the tags named in the tuple.
|
any of the tags named in the tuple.
|
||||||
|
|
||||||
In ``"nodelist = parser.parse(('endcomment',))"`` in the above example,
|
In ``"nodelist = parser.parse(('endcomment',))"`` in the above example,
|
||||||
|
Loading…
x
Reference in New Issue
Block a user