[Doc] Minor fixes and removed belittling words

This commit is contained in:
Javier Eguiluz
2019-06-20 13:32:09 +02:00
parent 5c9ec4d4a3
commit 270d4a57a2
10 changed files with 20 additions and 25 deletions
+1 -1
View File
@@ -851,7 +851,7 @@ This is very convenient but not recommended as it makes template compilation
depend on runtime dependencies even if they are not needed (think for instance
as a dependency that connects to a database engine).
As of Twig 1.26, you can easily decouple the extension definitions from their
As of Twig 1.26, you can decouple the extension definitions from their
runtime implementations by registering a ``\Twig\RuntimeLoader\RuntimeLoaderInterface``
instance on the environment that knows how to instantiate such runtime classes
(runtime classes must be autoload-able)::
+8 -9
View File
@@ -13,7 +13,7 @@ itself with node visitors.
.. note::
The first section of this chapter describes how to extend Twig easily. If
The first section of this chapter describes how to extend Twig. If
you want to reuse your changes in different projects or if you want to
share them with others, you should then create an extension as described
in the following section.
@@ -140,7 +140,7 @@ callable. For instance, let's say you have the following code in a template:
When compiling this template to PHP, Twig looks for the PHP callable
associated with the ``lower`` filter. The ``lower`` filter is a built-in Twig
filter, and it is simply mapped to the PHP ``strtolower()`` function. After
filter, and it is mapped directly to the PHP ``strtolower()`` function. After
compilation, the generated PHP code is roughly equivalent to:
.. code-block:: html+php
@@ -303,7 +303,7 @@ templates.
When compiling this template to PHP, Twig looks for the PHP callable
associated with the ``constant`` function. The ``constant`` function is a built-in Twig
function, and it is simply mapped to the PHP ``constant()`` function. After
function, and it is mapped directly to the PHP ``constant()`` function. After
compilation, the generated PHP code is roughly equivalent to:
.. code-block:: html+php
@@ -617,8 +617,7 @@ possible::
.. note::
Of course, this extension does nothing for now. We will customize it in
the next sections.
This extension does nothing for now. We will customize it in the next sections.
Twig does not care where you save your extension on the filesystem, as all
extensions must be registered explicitly to be available in your templates.
@@ -629,8 +628,8 @@ main ``Environment`` object::
$twig = new \Twig\Environment($loader);
$twig->addExtension(new Project_Twig_Extension());
Of course, you need to first load the extension file by either using
``require_once()`` or by using an autoloader (see `spl_autoload_register()`_).
Don't forget to load first the extension file by either using ``require_once()``
or by using an autoloader (see `spl_autoload_register()`_).
.. tip::
@@ -731,7 +730,7 @@ at the cost of a small overhead.
Overriding default Filters
..........................
If some default core filters do not suit your needs, you can easily override
If some default core filters do not suit your needs, you can override
them by creating your own extension. Just use the same names as the one you
want to override::
@@ -834,7 +833,7 @@ Testing an Extension
Functional Tests
~~~~~~~~~~~~~~~~
You can create functional tests for extensions simply by creating the
You can create functional tests for extensions by creating the
following file structure in your test directory::
Fixtures/
+1 -1
View File
@@ -47,7 +47,7 @@ date, use a ternary operator:
{{ post.published_at is empty ? "" : post.published_at|date("m/d/Y") }}
If no format is provided, Twig will use the default one: ``F j, Y H:i``. This
default can be easily changed by calling the ``setDateFormat()`` method on the
default can be changed by calling the ``setDateFormat()`` method on the
``core`` extension instance. The first argument is the default format for
dates and the second one is the default format for date intervals:
+1 -1
View File
@@ -11,7 +11,7 @@ The ``date_modify`` filter modifies a date with a given modifier string:
{{ post.published_at|date_modify("+1 day")|date("m/d/Y") }}
The ``date_modify`` filter accepts strings (it must be in a format supported
by the `strtotime`_ function) or `DateTime`_ instances. You can easily combine
by the `strtotime`_ function) or `DateTime`_ instances. You can combine
it with the :doc:`date<date>` filter for formatting.
Arguments
+1 -1
View File
@@ -33,7 +33,7 @@ options of:
* ``.`` as the decimal point.
* ``,`` as the thousands separator.
These defaults can be easily changed through the core extension:
These defaults can be changed through the core extension:
.. code-block:: php
+1 -1
View File
@@ -1,7 +1,7 @@
Twig Internals
==============
Twig is very extensible and you can easily hack it. Keep in mind that you
Twig is very extensible and you can hack it. Keep in mind that you
should probably try to create an extension before hacking the core, as most
features and enhancements can be handled with extensions. This chapter is also
useful for people who want to understand how Twig works under the hood.
+3 -3
View File
@@ -131,7 +131,7 @@ might be tempted to write the following:
{# page.twig in .../templates/mysite #}
{% extends "page.twig" %} {# from .../templates/default #}
Of course, this will not work as Twig will always load the template from
However, this will not work as Twig will always load the template from
``.../templates/mysite``.
It turns out it is possible to get this to work, by adding a directory right
@@ -376,7 +376,7 @@ When attaching a visitor to a ``\Twig\Environment`` instance, Twig uses it to
visit *all* templates it compiles. If you need to keep some state information
around, you probably want to reset it when visiting a new template.
This can be easily achieved with the following code::
This can be achieved with the following code::
protected $someTemplateState = [];
@@ -511,7 +511,7 @@ remove it from the database, and everything else will still work as before.
Loading a Template from a String
--------------------------------
From a template, you can easily load a template stored in a string via the
From a template, you can load a template stored in a string via the
``template_from_string`` function (available as of Twig 1.11 via the
``\Twig\Extension\StringLoaderExtension`` extension):
+1 -3
View File
@@ -104,7 +104,7 @@ Named Block End-Tags
--------------------
Twig allows you to put the name of the block after the end tag for better
readability:
readability (the name after the ``endblock`` word must match the block name):
.. code-block:: twig
@@ -114,8 +114,6 @@ readability:
{% endblock inner_sidebar %}
{% endblock sidebar %}
Of course, the name after the ``endblock`` word must match the block name.
Block Nesting and Scope
-----------------------
+1 -1
View File
@@ -20,7 +20,7 @@ of that file:
template outputs its rendered contents in the current scope; a tag should
not display anything);
* The rendered template can be more easily stored in a variable when using
* It's easier to store the rendered template in a variable when using
the ``include`` function:
.. code-block:: twig
+2 -4
View File
@@ -109,7 +109,7 @@ via the ``from`` tag:
Importing macros using ``import`` or ``from`` is **local** to the current
file. The imported macros are not available in included templates or child
templates; you need to explicitely re-import macros in each file.
templates; you need to explicitly re-import macros in each file.
.. tip::
@@ -130,12 +130,10 @@ Named Macro End-Tags
--------------------
Twig allows you to put the name of the macro after the end tag for better
readability:
readability (the name after the ``endmacro`` word must match the macro name):
.. code-block:: twig
{% macro input() %}
...
{% endmacro input %}
Of course, the name after the ``endmacro`` word must match the macro name.