Commits
-------
f2a1c2b Refactor and add additional default filter tests
e760483 Make `a.b is defined` not throw an exception if a is not defined (in strict mode)
Discussion
----------
Make `a.b is defined` not throw an exception if a is not defined (in strict mode)
This commit does two things: Firstly (that's the main part) it makes `a.b is defined` not throw an error in strict mode if `a` is undefined (applies for `a.b.c` aso too) [fixes#337]. Additionally it allows `a.b|default` just like it is allowed to do `a|default`.
---------------------------------------------------------------------------
by fabpot at 2011/06/09 22:21:11 -0700
This is quite a big change. Can you add some tests?
---------------------------------------------------------------------------
by nikic at 2011/06/10 08:19:49 -0700
I added some more tests for the default filter in the fixtures. But I wasn't sure how I should test the default test's behavior in strict mode. If you could point me in the right direction here I would add those tests, too ;)
Commits
-------
5ec1955 added {% line \d+ %} directive
Discussion
----------
added {% line \d+ %} directive
This directive allows to change the current line number in the tokenizer.
This allows to generate Twig code from some other Twig or partially-Twig script, and still get relevant line numbers in error messages, when the line numbers of the generated Twig script do not match those of the original script.
For example in the following script:
foo
{% line 10 %}
bar
{{ baz }}
`"foo"` is on line 1, `"bar"` is considered to be on line 10 and `{{ baz }}` is considered to be on line 11.
This is similar to `# line ...` directives in C.
---------------------------------------------------------------------------
by nikic at 2011/06/05 08:51:20 -0700
I don't quite yet understand it's use cases.
---------------------------------------------------------------------------
by arnaud-lb at 2011/06/05 09:17:57 -0700
The `{% line ... %}` directive is not meant to be used by humans, but rather by generators.
The use case is the same as [#line directives in C](http://gcc.gnu.org/onlinedocs/cpp/Line-Control.html): when you generate a C file from a template, you would prefer that the compiler refers to the line number of the template, instead of the line number of the generated file.
In my case, I built a [HAML compiler for php](https://github.com/arnaud-lb/MtHaml) which can target Twig as an output language. I use it as a Twig pre-processor so that it translates HAML scripts to Twig scripts on the fly in a custom Twig_Loader.
So I have scripts like that:
%p
test
%div = foo.bar
which is compiled like that:
<p>
test
</p>
<div>
{{ foo.bar }}
</div>
If an error occurs in the execution of {{ foo.bar }}, Twig will throw an error refering to line 5 in the original script, which is wrong. A simple solution to this is the {% line %} directive:
<p>
test
</p>
<div>
{% line 3 %}
{{ foo.bar }}
</div>
Now if an error occures in {{ foo.bar }}, the error will refer to line 3.
---------------------------------------------------------------------------
by nikic at 2011/06/05 09:33:26 -0700
Ah, okay, seems reasonable. Though I'm not sure whether it is appropriate to use the comment syntax to accomplish that.
---------------------------------------------------------------------------
by arnaud-lb at 2011/06/05 10:41:03 -0700
You are right, I changed the request to use the block syntax instead.
Traits are "special" templates that define blocks that you can "include" in
other templates.
Let's take an example:
{# 'foo' template defines the 'foo' block #}
{% block 'foo' %}
FOO
{% endblock %}
{# 'main' template defines the 'bar' block and include the 'foo' block from the 'foo' template #}
{% extends 'base' %}
{% use 'foo' %}
{% block 'bar' %}
BAR
{% endblock %}
In the previous example, the 'main' template use the 'foo' one. It means that
the 'foo' block defined in the 'foo' template is available as if it were
defined in the 'main' template.
You can use as many 'use' statements as you want in a template:
{% extends 'base' %}
{% use 'foo' %}
{% use 'bar' %}
{% use 'foobar' %}
If two templates define the same block, the latest one wins. The template can
also overrides any block.
The 'use' tag also supports "dynamic" names:
{% set foo = 'foo' %}
{% use foo %}
The 'use' tag only imports a template if it does not extend another template,
if it does not define macros, and if the body is empty. But it can 'use' other
templates:
{# 'foo' template #}
{% block 'foo' %}
FOO
{% endblock %}
{# 'bar' template #}
{% use 'foo' %}
{% block 'bar' %}
BAR
{% endblock %}
{# 'main' template #}
{% extends 'base' %}
{% use 'bar' %}
In this example, the 'main' template has access to both 'foo' and 'bar'.
Traits are mainly useful when you consider blocks as reusable "functions";
like we do in Symfony2 forms or if you use Twig for code generation.
* markstory/whitespace:
Updating documentation for whitespace trim tags.
Making trim tags consume all whitespace, both horizontal and vertical.
Adding additional test suggested by nikic.
Making a capturing group non capturing, as the group isn't used.
Moving newline trimming into the regexp used to match end of tags.
Applying changes suggested by nikic to simplify how end of comments are processed.
Fixing some whitespace.
Fixing typo.
Adding a bit of documentation for whitespace trimming.
Adding whitespace trimming support to other tag types (comments, variables) Refactoring how whitespace trimming is done, and moving it into a separate option that is combined with other tag types. Adding more tests. Refs #284
Fixing use of non-existent method name.
Adding a test case for mixing {%- and %} tags together.
Adding a test that uses tabs. Added a test for trailing tabs and -%} Refs #284
Implementing {%- which trims non-newline whitespace preceding it. Refs
Josh Turmel
Fabien Potencier
nikic
Arnaud Le Blanc
Jeremy Mikola
Tobias Naumann
Joseph Bielawski
lenar
Mark Story