Commits
-------
351910b added twig comments
2b7e8d9 added phpDocs for TokenParsers, filters and tests
Discussion
----------
PHPDocs updated
fixed copy/paste errors and added docs to Sandbox and Use tags
Commits
-------
e4b8371 Improve performance of is defined in non strict mode
Discussion
----------
Improve performance of is defined in non strict mode
Addresses issue #380: This gives a good performance improvement on defined tests in non-strict code. About 2x.
Reasoning: It doesn't make sense to propagate the `is_defined_test` flag into deeper levels in non-strict mode, because all getAttr functions and name accesses will just return `null` if it doesn't exist and `null` is just as good as `false`.
---------------------------------------------------------------------------
by nikic at 2011/07/02 03:22:53 -0700
Though, do not merge yet please. Changes behavior concerning methods.
---------------------------------------------------------------------------
by nikic at 2011/07/02 13:34:32 -0700
Hm, I really don't know what I was thinking when I wrote my last comment. There shouldn't be any behavior changes introduced by that change (and tests pass).
Commits
-------
5b91f12 Update tests
a5ef326 Use Template->getContext in non-strict mode too
Discussion
----------
Use Template->getContext() when in non-strict mode, too
As described in #380 using the current `isset($context['test']) ? $context['test'] : null` approach can cause problems in some cases: The ternary operator always returns by value and thus PHP's copy-on-write concept does not apply. So `$context['test']` needs to be copied in any case, even though a write never happens to it. Basically Twig is copying the values of all variables ever used inside Twig if it operates in non-strict mode. This is problematic when `$context['test']` contains big arrays as the whole array is copied.
In this patch I change Twig to use `Template->getContext` when in non-strict mode too and add an `isStrictVariables` check in there.
Commits
-------
75748a5 revert accidental mode change
681d2b8 fix nested buffers issue #374
Discussion
----------
fix nested buffers issue #374
see #374 for details
---------------------------------------------------------------------------
by fabpot at 2011/07/09 01:02:50 -0700
You have inadvertently changed the mode to 0755. Should stay at 0644.
---------------------------------------------------------------------------
by macolu at 2011/07/09 03:07:42 -0700
Mode change reverted.
About this Windows bug... Are you talking about the zlib issue? When zlib compression is activated, it adds a buffer level that ob_end_clean() can't close. So ob_get_level() never go below 1.
http://cksource.com/forums/viewtopic.php?t=21653http://www.php.net/manual/fr/function.ob-get-level.php#52945
In that case, the first ob_get_level() call will always return something greater than 0. So $level var will be > 0. This should avoid infinite loops.
Commits
-------
c178c28 Making docs more explict as to what kind of object can be used with Twig_Function_Method. Fixes#308
Discussion
----------
Fix for #308
Making docs more explict as to what kind of object can be used with Twig_Function_Method.
Fixes#308
Commits
-------
6593761 Allow setting of timezone on twig_date_format_filter method
Discussion
----------
Allow setting of timezone on twig_date_format_filter method
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.
Fabien Potencier
Robert Gruendler
Matthieu Robin
nikic
Mark Story
Josh Turmel
nikic
Arnaud Le Blanc