Fix extension crash when calling unknown method inside a macro

merged branch nomack84/fixed_typo (PR #891)

This PR was merged into the master branch.

Commits
-------

cc65c88 [template_from_string]Fixed typo

Discussion
----------

[template_from_string]Fixed typo in docs

Fix a typo in the template_from_string function docs

[template_from_string]Fixed typo

bumped version to 1.11.0-DEV

prepared the 1.11.0 release

merged branch char101/fix-build-warning (PR #886)

This PR was merged into the master branch.

Commits
-------

3164ee3 Fix build warning for const pointer

Discussion
----------

Fix build warning for const pointer

 Issue #883

Fix build warning for const pointer

added a .gitignore to ignore files created when building the C extension

merged branch char101/nativeext-exception-info (PR #885)

This PR was merged into the master branch.

Commits
-------

db13b66 Pass lineno and filename to Twig_Error constructor
feee667 Merge branch 'nativeext-exception-info' of https://github.com/fabpot/Twig into nativeext-exception-info
adb31d4 Call Twig_Error constructor
d4a8c8b added tests for exceptions thrown in Twig_Template::getAttribute()
1b82bf7 Add template filename for the rest of the exception
5675140 Handle NULL filename
71f64bc Add template name to error message

Discussion
----------

Add template name to error message

Issue #884

---------------------------------------------------------------------------

by fabpot at 2012-11-06T07:43:16Z

For some unknown reasons, I don't see your branch when I try to submit a PR. Can you cherry-pick my unit tests from my `nativeext-exception-info` branch?

---------------------------------------------------------------------------

by Tobion at 2012-11-06T08:29:19Z

@char101 Maybe you could also integrate the fixes of #878?

---------------------------------------------------------------------------

by fabpot at 2012-11-06T08:30:55Z

@Tobion Let's do one thing at a time.

---------------------------------------------------------------------------

by char101 at 2012-11-06T08:59:30Z

@Tobion AFAIK, unlike the PHP implementation, the C implementation does not automatically convert array key type.

---------------------------------------------------------------------------

by char101 at 2012-11-06T09:27:54Z

@fabpot How about the lineno variable? Should I just set it to 0 or is there any function that can be called to obtain it?

```php
if (-1 === $this->lineno || null === $this->filename) {
    $this->guessTemplateInfo();
}
```

---------------------------------------------------------------------------

by fabpot at 2012-11-06T09:32:09Z

You need to keep `-1` for the line.

---------------------------------------------------------------------------

by char101 at 2012-11-06T09:36:56Z

If `$lineno` is `-1`, wouldn't `$this->guessTemplateInfo()` still be called?

---------------------------------------------------------------------------

by fabpot at 2012-11-06T09:45:34Z

Yes, but the template name will not be guessed. So, there is a performance overhead for the line guessing, but not for the template name guessing.

Pass lineno and filename to Twig_Error constructor

Merge branch 'nativeext-exception-info' of https://github.com/fabpot/Twig into nativeext-exception-info

Call Twig_Error constructor

added tests for exceptions thrown in Twig_Template::getAttribute()

Add template filename for the rest of the exception

Handle NULL filename

Add template name to error message

fixed macro compilation when a variable name is a PHP reserved keyword (closes #881)

fixed CS

merged branch fabpot/timezones (PR #876)

This PR was merged into the master branch.

Commits
-------

f99504a changed the date filter behavior to always apply the default timezone, except if false is passed as the timezone
d3b0cbd merged branch jmikola/patch-1 (PR #845)
a6a1ef0 Avoid setting timezones on DateIntervals

Discussion
----------

changed the date filter behavior to always apply the default timezone, except if false is passed as the timezone

This PR is based on #845, and addresses issue #778.

Right now, the timezone management when using the date filter is counter-intuitive. When you pass a DateTime object, the default timezone is not applied, but in all other cases, it is.

This PR makes the behavior more consistent by always applying the default timezone (which is probably what users want most of the time), and this can be disabled by explicitly passing ``false`` as the timezone value.

This is a BC break but I think that not many consciously rely on the current behavior.

---------------------------------------------------------------------------

by fabpot at 2012-10-30T15:49:13Z

@jmikola Can you have a look at this PR and tell me your opinion about this change?

---------------------------------------------------------------------------

by jmikola at 2012-11-02T20:17:30Z

@fabpot: Will take a look at this tonight. I missed the notifications as I was offline for a few days.

---------------------------------------------------------------------------

by jmikola at 2012-11-03T04:09:54Z

I read through all of the issues and PR's and this looks reasonable. Are we missing a test case for passing in a DateTime object with `false` for the timezone? I do see one example where we render the current date using the `'e'` format string and provide `false` for the timezone, but that's it.

---------------------------------------------------------------------------

by fabpot at 2012-11-03T07:09:08Z

ok, I've added an additional test just to be sure.

changed the date filter behavior to always apply the default timezone, except if false is passed as the timezone

added a paragraph in the docs about how the Twig blocks work (based on an explanation from nikic, closes #704, refs #351)

fixed a stupid test

fixed broken test

fixed bitwise operator precedences (closes #866)

merged branch fabpot/template_from_string (PR #874)

This PR was merged into the master branch.

Commits
-------

4599188 added the template_from_string function

Discussion
----------

added the template_from_string function

One of the most often asked question is how someone can evaluate a template string from a template.

The template_from_string function solves this problem (more in the included docs).

I have two questions before merging this:

 * What about the name? I find it quite long but also readable (`{% include template_from_string(template) %}`).

 * Does it belongs to Twig core?

---------------------------------------------------------------------------

by boutell at 2012-10-28T16:45:08Z

Interesting. What are the use cases? Would it cache in some way, the md5 of the string maybe, to avoid having this be a major performance hit on every use?

---------------------------------------------------------------------------

by gcoguiec at 2012-10-28T16:46:04Z

And what about include_from_string ?

---------------------------------------------------------------------------

by lsmith77 at 2012-10-28T16:46:35Z

Heh, was just going to ask the same thing, would a use case be loading a twig snippet from a database? something like https://github.com/symfony-cmf/ContentBundle/issues/8 ..

---------------------------------------------------------------------------

by stof at 2012-10-28T16:48:09Z

@gcoguiec It is not including anything but creating a Twig_Template instance. ``{% extends include_from_string(foo) %}`` would be very ugly.

---------------------------------------------------------------------------

by gruzilla at 2012-10-28T16:48:37Z

i'd say yes.
im not like the core must can do everything. but besides that, what are the reasons against it?
i can already think of some usecases: user defined dynamic templates, ...

---------------------------------------------------------------------------

by alexandresalome at 2012-10-28T16:49:34Z

IMHO it's a mistake to put it in Twig. People won't get how to use it. My reasons are also regarding cache: will the template be regenerated on each call?

Looks magic

---------------------------------------------------------------------------

by stof at 2012-10-28T16:50:06Z

@fabpot I'm not really sure this should be in the core.
But FYI, there is a [PR on your Twig-extensions repository](https://github.com/fabpot/Twig-extensions/pull/68) adding an ``eval`` function with the same goal (but an incomplete implementation)

---------------------------------------------------------------------------

by fabpot at 2012-10-28T16:51:00Z

The template is loaded like any other ones, so it is using the cache if you have configured it. No magic included!

---------------------------------------------------------------------------

by fabpot at 2012-10-28T16:52:44Z

@lsmith77 yes, that's the main use case.

You can also have a look at this thread on the mailing-list: https://groups.google.com/group/twig-devs/browse_thread/thread/a8b7bbae31cade18

---------------------------------------------------------------------------

by fabpot at 2012-10-28T16:54:28Z

I forgot to say that we can also move this function into its own extension, so that enabling it would have to come from a conscious choice from the developer (like the debug function in the debug extension).

---------------------------------------------------------------------------

by lsmith77 at 2012-10-28T16:55:32Z

OK great. Looks like something the CMF will need then. But it would also work for us if its part of the twig extension repo. we could of course also just drop the code into https://github.com/symfony-cmf/CoreBundle/blob/master/Twig/TwigExtension.php

---------------------------------------------------------------------------

by fabpot at 2012-10-28T16:56:59Z

I have proposed it for inclusion in Twig core (but not necessarily in the core extension) as it seems to be something many developers want to do in their code (mainly people writing a CMS in top of Twig).

---------------------------------------------------------------------------

by dlsniper at 2012-10-28T17:05:45Z

Hi

- why not name it `template_string` or `string_template`? Then it would read like: ` {% include template_string(template) %} ` or ` {% include string_template(template) %} `

- imo this shouldn't be in the core but rather in the extensions part of Twig as you just extend existing Twig functionality :)

Cheers.

---------------------------------------------------------------------------

by fabpot at 2012-10-28T17:37:12Z

I've moved the function to a new extension that should be enabled explicitely.

---------------------------------------------------------------------------

by EvanK at 2012-10-28T18:05:57Z

I would love to see this as a built-in feature to Twig, as my coworkers & I have had to implement a workaround for something similar.

(Our workaround involved writing said string to a file named after an md5 of the string's content, and then calling render() on said file, all within the php userspace. It was less than elegant, but functional.)

---------------------------------------------------------------------------

by Crell at 2012-10-28T19:11:34Z

This would lend itself to some of the wacky stuff Drupal has been discussing, too.  +1 on the feature.  No opinion on the name.

---------------------------------------------------------------------------

by jorgelbg at 2012-10-28T20:45:37Z

+1 for built-in support i think this is something Twig should do out of the box, regarding the name I guess that I'll vote for this name ```{% include from_string(template) %}``` The only thing that you can include is a template righ? So why put this explicitly in the function's name?

---------------------------------------------------------------------------

by pylebecq at 2012-10-29T09:53:05Z

+1 for me. And for the name, it seems I'm the only one but I would have vote for `eval` :smiling_imp:

---------------------------------------------------------------------------

by sstok at 2012-10-29T10:14:25Z

eval is bad name as can be confused with eval() in PHP, aka that what is passed is treated as PHP (similar to embeded PHP in Smarty). Please don't..

+1 for as it is now.

---------------------------------------------------------------------------

by drak at 2012-10-29T17:25:24Z

Love it +1

---------------------------------------------------------------------------

by acasademont at 2012-10-30T12:02:40Z

Very useful feature! +1

---------------------------------------------------------------------------

by acasademont at 2012-10-30T12:20:46Z

For clarification, now if you wanted to make dynamic include or dynamic inheritance like this ```{% extends some_var %}``` you had to supply a valid Twig_Template object. Now with this function you can supply a simple string that will be evaluated and transformed into a Twig_Template object. So this PR is not inventing dynamic inheritance but providing a helper to make it easier. Am I right?

---------------------------------------------------------------------------

by stof at 2012-10-30T12:45:08Z

@acasademont no. It is provinding a way to evaluate a string stored somewhere (in a database for instance) as a template. It is not about making dynamic inheritance easier.
If your template can be loaded by your loader (for instance a file when using the Twig_Loader_Filesystem), you can use the template name in your variable for the dynamic inheritance. You are not required to build the Twig_Template instance yourself

---------------------------------------------------------------------------

by fabpot at 2012-10-30T12:53:02Z

When you have `{% extends some_var %}`, `some_var` must be the template name. Using `{% extends template_from_string(some_var) %}` means that `some_var` contains the parent template code.

---------------------------------------------------------------------------

by acasademont at 2012-10-30T13:15:37Z

Perfectly understood, thanks!

added a note about double-escaping when using a variable for the strategy (closes #868)

merged branch jmikola/patch-1 (PR #845)

This PR was merged into the master branch.

Commits
-------

a6a1ef0 Avoid setting timezones on DateIntervals

Discussion
----------

Avoid setting timezones on DateIntervals

Edit: originally, I opened this to ensure the default Twig timezone was always set on incoming DateTime objects, but I came to realize why that behavior would be undesirable. The idea was prompted by this line from: http://twig.sensiolabs.org/doc/filters/date.html

> The default timezone can also be set globally by calling `setTimezone()`.

Anyway, I did notice an edge case where the code might call `DateInterval::setTimezone()`, so this PR attempts to correct that. Additionally, I added some tests for passing a DateTimeZone object to the `date` filter.

---------------------------------------------------------------------------

by jmikola at 2012-09-22T17:18:56Z

@fabpot: One question came up as I was looking through this a second time: if `twig_date_converter()` receives a DateTime argument, it will override its timezone regardless of the logic path within (either from the `$timezone` argument, Twig default, or the system default).

At first, I thought that it was redundant for `twig_date_format_filter()` not to utilize `twig_date_converter()`, but it looks like that was a careful decision; otherwise, there'd be no way to display DateTimes with their internal timezone. This PR would remove that functionality, so I need to reconsider.

Having said that, there does appear to be a bug in `twig_date_format_filter()` in that it could end up calling a nonexistent `setTimezone()` method on a DateInterval object. Would it be preferable to throw an exception or simply ignore the `$timezone` argument if the `$date` argument is a DateInterval?

---------------------------------------------------------------------------

by fabpot at 2012-10-30T08:56:31Z

I don't know if not changing the timezone on DateTime object was a conscious/careful decision or not. The documentation is not so clear about that, and there is even a bug report about this behavior: #778.

For consistency, I think we can always set the timezone and allow disabling that by passing `false` for the timezone.

Does it sounds good?

fixed default timezone usage for the date function (refactor of the previous merge)

merged branch vitman/patch-1 (PR #871)

This PR was squashed before being merged into the master branch (closes #871).

Commits
-------

b89163d Update lib/Twig/Extension/Core.php

Discussion
----------

Update lib/Twig/Extension/Core.php

Added support for setted default timezone for twig date functions.

---------------------------------------------------------------------------

by henrikbjorn at 2012-10-26T07:19:02Z

This have the same problem as the other PR you created. See php.net/datetime for reference.

Update lib/Twig/Extension/Core.php

added the template_from_string function

added two new recipes

added missing documentation about Twig_Loader_Chain

fixed phpdoc

merged branch jeremymarc/master (PR #873)

This PR was merged into the master branch.

Commits
-------

c5d351d cast $name to string ($name can be an object implementing __toString function)

Discussion
----------

Cast $name to string in Loader/Chain.php and Loader/FileSystem.php

related to #603

cast $name to string ($name can be an object implementing __toString function)

merged branch fabpot/faster-exceptions (PR #864)

This PR was merged into the master branch.

Commits
-------

2506be1 optimized the way Twig exceptions are managed

Discussion
----------

Optimized the way Twig exceptions are managed

As guessing the template name and the line number of where an error occurred is quite expensive, this is now avoided as much as possible.

~~As a side-effect, it also fixes 822 (@hason can you confirm?).~~

optimized the way Twig exceptions are managed

As guessing the template name and the line number of where an error
occurred is quite expensive, this is now avoided as much as possible.

updated the docs for the new Twig_ExistsLoaderInterface interface

renamed Twig_ExtendedLoaderInterface to Twig_ExistsLoaderInterface

merged branch dlsniper/loader-exception-improvement (PR #841)

This PR was squashed before being merged into the master branch (closes #841).

Commits
-------

08ecb0e Improvements for loader speeds

Discussion
----------

Improvements for loader speeds

This is something started from #822 .

It attempts to improve the speed of the chain loader and rest of the standard loaders by adding a cache level and a ```hasSource()``` method for them in order gain speed.

---------------------------------------------------------------------------

by dlsniper at 2012-09-27T14:56:24Z

Thanks for the feedback, I'll do the changes tonight or during the coming weekend.

As for the utility of the ```::setExtendedErrorHandling()``` function, this saves me about 25% to 40% on the benchkmark Fabien presented in the original ticket.

Thanks!

---------------------------------------------------------------------------

by dlsniper at 2012-09-29T11:34:59Z

I've added some caching for the Chain Loader but it's still a WIP. I'll work more on this in the coming hours.

---------------------------------------------------------------------------

by dlsniper at 2012-09-29T23:10:10Z

I'm getting better values right now that I had before, standing on:
```
0.09
0.07 ... x 1
0.07 ... x 1
```
I've also noticed that if I run the tests from the browser then I'll have an overall slowdown of about 0.10 which I'm not sure from where it comes from. Any pointers before me digging a bit more into Twigs internals.

---------------------------------------------------------------------------

by dlsniper at 2012-10-03T21:31:15Z

@fabpot what's your opinion about this PR?

---------------------------------------------------------------------------

by dlsniper at 2012-10-14T18:26:13Z

@Tobion and @fabpot done and done :)

I'm not sure why the tests are failing on PHP 5.4 as I don't have it installed anywhere.

Improvements for loader speeds

bumped version to 1.11.0-DEV

prepared the 1.10.3 release

changed Node instances line numbers from 0 to 1 in unit tests to better reflect what really happens when using Twig

updated CHANGELOG

reverted BC break

moved some logic from the sandbox node visitor to the sandbox node

fixed wrong exception class in the filesystem loader

fixed wrong template location in error messages (closes #803)

added missing version info in the docs for the split filter

fixed previous merge

merged branch innsand/split-filter_fix (PR #811)

This PR was merged into the master branch.

Commits
-------

d5df200 * bug fixes. * str_split on empty delimeter. * tests and documentation updated.
e3c201a Added "split" filter aka explode.

Discussion
----------

Split filter fix

Modification of request #621:
str_split, bug fixes

---------------------------------------------------------------------------

by senz at 2012-08-21T05:56:51Z

@fabpot this is squashed and fixed (hopefully) #621

fixed import doc

bumped version to 1.10.3-DEV

prepared the 1.10.2 release

fixed macro calls on PHP 5.4

bumped version to 1.10.2-DEV

prepared the 1.10.1 release

updated macro documentation to warn about a hack that won't work anymore in Twig 2.x

merged branch Adel-E/update-api-docs (PR #858)

This PR was merged into the master branch.

Commits
-------

bee4cd1 Update doc to correspond to the following: http://twig.sensiolabs.org/documentation http://twig.sensiolabs.org/doc/filters/escape.html

Discussion
----------

Update api docs

Update doc to correspond to the following:
http://twig.sensiolabs.org/documentation
http://twig.sensiolabs.org/doc/filters/escape.html

Update doc to correspond to the following:
http://twig.sensiolabs.org/documentation
http://twig.sensiolabs.org/doc/filters/escape.html

fixed tests where macros were not used properly

refactored previous commit to avoid collission between symbols of different types

optimized macros when imported via the "import" tag

This commit unifies the way macros are called independently of how they
were included (via the from or import tag -- see e81c932).

merged branch pierrejoye/master (PR #855)

This PR was merged into the master branch.

Commits
-------

d398e55 - drop tsrm fetch, not necessary as it is passed as argument already

Discussion
----------

drop unnecessary tsrmls_fetch

- drop tsrm fetch, not necessary as it is passed as argument already

refactored some unit tests

updated CHANGELOG

fixed unit tests when XDebug is enabled

merged branch weltling/master (PR #854)

This PR was merged into the master branch.

Commits
-------

b013ede fix windows build

Discussion
----------

Trivial fix for windows build

fix windows build

merged branch greg0ire/patch-1 (PR #851)

This PR was merged into the master branch.

Commits
-------

d52e15b remove tautology

Discussion
----------

remove tautology

We already know the example is "for example".

fixed blanks in the doc

remove tautology

fixed a doc anchor

updated CHANGELOG

fixed CS

merged branch char101/master (PR #844)

This PR was merged into the master branch.

Commits
-------

c23ef25 Add assertEquals to NativeExtensionTest.php
9126dc6 Twig extension: fix case when accessing property of an array casted into object
34cf8e1 Fix double free
4980903 Enhancements for twig extension
db3cb80 Fix NativeExtensionTest
3485ee7 Native extension: handle dynamic properties defined in the get_properties handler in a per instance fashion.

Discussion
----------

Native extension: call get_properties in per instance manner instead of caching it.

Since dynamic properties of an object can be defined by its get_properties handler, we need to call it for each instance.

---------------------------------------------------------------------------

by char101 at 2012-09-21T10:30:37Z

PHPUnit test result

```
PHPUnit 3.7.1 by Sebastian Bergmann.

.S...........................................................   61 / 1253 (  4%)
.............................................................  122 / 1253 (  9%)
.............................................................  183 / 1253 ( 14%)
.............................................................  244 / 1253 ( 19%)
.............................................................  305 / 1253 ( 24%)
.............................................................  366 / 1253 ( 29%)
.............................................................  427 / 1253 ( 34%)
.............................................................  488 / 1253 ( 38%)
.............................................................  549 / 1253 ( 43%)
.............................................................  610 / 1253 ( 48%)
.............................................................  671 / 1253 ( 53%)
.............................................................  732 / 1253 ( 58%)
.............................................................  793 / 1253 ( 63%)
.............................................................  854 / 1253 ( 68%)
.............................................................  915 / 1253 ( 73%)
.............................................................  976 / 1253 ( 77%)
............................................................. 1037 / 1253 ( 82%)
............................................................. 1098 / 1253 ( 87%)
............................................................. 1159 / 1253 ( 92%)
............................................................. 1220 / 1253 ( 97%)
.................................

Time: 4 seconds, Memory: 13.25Mb

OK, but incomplete or skipped tests!
Tests: 1253, Assertions: 2969, Skipped: 1.
```

---------------------------------------------------------------------------

by stof at 2012-09-21T11:58:51Z

@char101 My previous comment about the way the test should be implemented is still valid. Please rewrite it to use the same way to all other integration tests in Twig

---------------------------------------------------------------------------

by char101 at 2012-09-23T04:51:36Z

@stof I don't see the reason of using a fixture. The test case works, it accomplishes its goal. It's simple. It doesn't test for a feature, it tests for a specific case where PHP crashes.

---------------------------------------------------------------------------

by stof at 2012-09-23T13:53:41Z

@char101 I see one: you are building a Twig instance and rendering a template here, which is exactely what the integration tests are doing.
Btw, your test would fail when running phpunit in strict mode as it does not assert anything

---------------------------------------------------------------------------

by char101 at 2012-09-24T02:05:58Z

@stof I don't have the desire to change what isn't broken, but you are free to change it as you see fit. As for the assert, I have added it to the test.

bumped version to 1.10.1-DEV

prepared the 1.10.0 release

merged branch hason/php52 (PR #849)

Commits
-------

adb5d4f Fixed PHP 5.2 incompatibilty

Discussion
----------

Fixed PHP 5.2 incompatibilty

Fixed PHP 5.2 incompatibilty

Add assertEquals to NativeExtensionTest.php

Avoid setting timezones on DateIntervals

Twig extension: fix case when accessing property of an array casted into object

Fix double free

Enhancements for twig extension

- Fix extension memory leak
- Fix gcc compile warning (cast to const char *)
- Add TWIG_HAS_DYNAMIC_PROPERTY
- Remove the previous translation of 'array_key_exists($item, $object)'
  into TWIG_ARRAY_KEY_EXISTS when checking object property because what
  it really means is property_exists which has already been handled by
  TWIG_HAS_PROPERTY and TWIG_HAS_DYNAMIC_PROPERTY
- Fix native extension spacing

Fix NativeExtensionTest

Native extension: handle dynamic properties defined in the get_properties handler in a per instance fashion.

updated CHANGELOG

tweaked docs

merged branch drak/reusable_fixtures (PR #805)

Commits
-------

36372c6 Made node tests reusable

Discussion
----------

Reusable tests and fixtures

This PR makes Twig integration testing reusable for 3rd party extensions.

I have implemented resuable functional tests.

The [test runner](https://github.com/zikula/core/blob/master/src/Zikula/Bundle/CoreBundle/Tests/Twig/IntegrationTest.php) and the [fixtures](https://github.com/zikula/core/tree/master/src/Zikula/Bundle/CoreBundle/Tests/Twig/Fixtures) are the only part that an extension needs to implement itself.

I've included documentation in the PR.

---------------------------------------------------------------------------

by jusuff at 2012-08-11T20:41:55Z

This PR would make things little easier. Right now tests are organized in confusing way and are hard to implement for Twig extensions

---------------------------------------------------------------------------

by drak at 2012-08-14T09:09:45Z

@fabpot - This is ready for merging now. When it's merged I'll update the documentation as this PR significantly eases our ability to test extensions.

---------------------------------------------------------------------------

by fabpot at 2012-09-16T14:28:16Z

@drak Do you plan to update this PR with the code you have in Zikula?

---------------------------------------------------------------------------

by drak at 2012-09-16T14:37:30Z

@fabpot - Yes, I just need a couple of days (or less).

---------------------------------------------------------------------------

by drak at 2012-09-17T12:00:34Z

@fabpot - I have ported over the code.

---------------------------------------------------------------------------

by drak at 2012-09-18T08:23:18Z

@fabpot - I updated Zikula to us this particular branch so there is a practical test. I've updated the links in the top description part of this PR with the relevant links. The PR also refactors Twig's core tests to use the re-usable test base classes.

---------------------------------------------------------------------------

by fabpot at 2012-09-18T09:01:10Z

@drak Can you squash your commits before I merge? Thanks.

---------------------------------------------------------------------------

by drak at 2012-09-18T09:14:08Z

@fabpot - I've squashed them now. Thanks!

Made node tests reusable

merged branch hason/loader (PR #838)

Commits
-------

c503287 Fixed typo in Filesystem loader

Discussion
----------

Fixed typo in Filesystem loader

Fixed typo in Filesystem loader

added missing information in the doc

merged branch fabpot/named-paths (PR #772)

Commits
-------

7e5acd1 fixed some possible warnings
f0d0d6d fixed typo
b7076fe added Twig_Loader_Filesystem::getNamespaces()
8f7ccd1 moved an exception
9426072 tweaked documentation
b9afa84 renamed the default filesystem namespace to __main__
c34541d changed notation of namespaced templates to @namespace/template_path
0eb4d01 added namespaced templates support in Twig_Loader_Filesystem
c24ea1b added Twig_Loader_Filesystem::prependPath()

Discussion
----------

added namespaced templates support in Twig_Loader_Filesystem

Everything is explained in the updated documentation.

Basically, it gives more flexibility when it comes to manage many templates that are not necessarily related (think frontent vs backend for instance, or templates from different Symfony bundles, ...). It is useful if, for each namespace, you need to look for templates in different directories. This implementation would probably be enough to replace the current Symfony bundle template paths, with more flexibility and less restrictions.

Feedback is more than welcome. One thing I'm not sure about is the `#` separator between the namespace and the template path. Is it the best choice? We need a character that is not used in filesystem paths, so good candidates are: `@`, `!`, `%`, `$`, `*`, `;`, `?`.

Some immediate benefits: give the same template flexibility that we have in Symfony to other frameworks using Twig like Silex. Another benefit would be the ability to share template between Symfony and other frameworks like Twig (more on a proof of concept later).

---------------------------------------------------------------------------

by alessandro1997 at 2012-07-14T16:25:42Z

This is very nice, and I think # is a great choice for the separator character. We could also use @.

---------------------------------------------------------------------------

by jjbohn at 2012-07-14T16:25:59Z

:+1: for #

---------------------------------------------------------------------------

by Symfomany at 2012-07-14T16:27:45Z

Pipe character isn't candidate?

---------------------------------------------------------------------------

by inspiran at 2012-07-14T16:32:52Z

I remember from the wetter.com talk at sf live that they actually implemented a similar functionality: allow twig templates to be defined different from the default path.   So they had something like:

{% extends "cms://Home/weather/..."  ... %}
If we could make the "cms" part a configurable setting then one could use it to point to a custom folder or even to a content provider (symfony cmf?)

Maybe that would be another approach?

---------------------------------------------------------------------------

by fabpot at 2012-07-14T16:33:21Z

The other syntax possibility is something more like we have in Symfony: `@namespace/template_path`.

---------------------------------------------------------------------------

by fabpot at 2012-07-14T16:34:37Z

@inspiran: that's another possibility: use the PHP stream notation.

---------------------------------------------------------------------------

by mvrhov at 2012-07-14T16:36:18Z

I'd also prefer uri/php streams syntax...

---------------------------------------------------------------------------

by Tobion at 2012-07-14T16:41:16Z

On Windows I can create a file with `#` in it. How does it distinguish that? I don't think we will find a single seperation character that works on all file systems, do we? And `@` (e.g. namespace@file) would be semantically strange (unless you read it from right-to-left).
So I'd also prefer uri/php stream syntax.

---------------------------------------------------------------------------

by Symfomany at 2012-07-14T16:43:17Z

@fabpot  Pointer Syntax? or greater than character?

---------------------------------------------------------------------------

by markstory at 2012-07-14T16:43:48Z

I'm in favour of the `foo://` style syntax.  It is similar to other parts of PHP, and avoids overlap with filesystem characters, and doesn't introduce new unique syntax.

---------------------------------------------------------------------------

by stof at 2012-07-14T16:44:25Z

@fabpot ``@namespace/template_path`` would make it confusing in Symfony. Because locating a resource with the kernel would use ``@AcmeDemoBundle/Resources/views/layout.html.twig`` whereas Twig would find the same file as ```@AcmeDemoBundle/layout.html.twig``.

And none of ``#``, ``@``, ``!``, ``%``, ``$`` or ``;`` is forbidden in filenames on Windows.

So I think the URI/stream notation is fine

---------------------------------------------------------------------------

by maryo at 2012-07-14T16:46:44Z

On Windows @!%$; are valid. Invalid characters are \/:*?"<>|

---------------------------------------------------------------------------

by maryo at 2012-07-14T16:47:55Z

Is > allowed on Linux?

---------------------------------------------------------------------------

by jschreuder at 2012-07-14T16:49:17Z

Some thoughts from a non-Symfony user:

* Not sure about the `#`, on the one hand it is used as the comment character on the other hand I'm also familiar with it as a membership operator (which supports its usage)
* The streams/PHP syntax: I don't really like this, the syntax signifies some type of protocol to be used. Even stretched to the limits of its definition you wouldn't be able to define different namespaces as different protocols (same protocol, different location).
* `@namespace/file/path` - kind of like this one, the `@` signifies that it is followed by a special symbol (being the namespace name) and other than that a normal path.
* Another option we've used in Fuel is the double colon `::` as in `namespace::file/path` (like the `#` it signifies membership, but doesn't have another significance in Twig)

---------------------------------------------------------------------------

by gunnarlium at 2012-07-14T17:10:15Z

Does it matter what symbols are valid in filenames? Won't the separator just be used for exploding the string into namespace and path, and thus never be used to directly access a file?

---------------------------------------------------------------------------

by alessandro1997 at 2012-07-14T17:15:27Z

As @gunnarlium said, what's the problem with filenames?

```php
$path = 'namespace#new#page.html';
$parts = explode('#', $path, 2);
list($namespace, $filename) = $parts;

// "namespace and "new#page.html"
var_dump($namespace, $filename);
```

---------------------------------------------------------------------------

by stof at 2012-07-14T17:16:19Z

@gunnarlium the issue is that if you use this symbols in the filename of your template without namespace, Twig will consider it as a namespaced template for another file name

---------------------------------------------------------------------------

by stof at 2012-07-14T17:16:45Z

@alessandro1997 the issue is that namespaces are optional

---------------------------------------------------------------------------

by alessandro1997 at 2012-07-14T17:17:07Z

@stof Oh, right. I didn't get that :-)

---------------------------------------------------------------------------

by gunnarlium at 2012-07-14T17:20:32Z

@stof Ok, I see. So what we want is a symbol which is not allowed as a filename? Or (suboptimally) just add a requirement that template filenames can't contain certain reserved symbols?

---------------------------------------------------------------------------

by fabpot at 2012-07-14T17:23:37Z

But then, who is using `#` in a filename?

Anyway, I'm going to implement a version based on PHP streams to stick to the PHP way. Using a PHP stream might also allow us to get rid of the array loader.

---------------------------------------------------------------------------

by alessandro1997 at 2012-07-14T17:24:01Z

@gunnarlium But how would we check if the user is using reserved symbols in template names? Twig isn't aware of the available templates' names until the user requests them. And when he/she does it's too late because Twig doesn't know if the separator is used as namespace or if it's part of the filename.

---------------------------------------------------------------------------

by stof at 2012-07-14T17:33:38Z

@fabpot even if no sane guy would probably use ``#`` in a filename, it would mean that Twig assumes that all its userbase is sane :)

---------------------------------------------------------------------------

by lolautruche at 2012-07-14T18:51:53Z

-1 for #
+1 for php stream, though I agree with @jschreuder's arguments against it
+2 for @ syntax like in Symfony. I find it more consistent.

---------------------------------------------------------------------------

by fabpot at 2012-07-14T19:50:31Z

One problem with PHP streams is that it makes using template names quite ugly and verbose:

    {% include 'twig://namespace/index.html' %}

And for non-namespaced templates:

    {% include 'twig:///index.html' %}

for which we can provide a shortcut:

    {% include 'index.html' %}

---------------------------------------------------------------------------

by fabpot at 2012-07-14T19:54:35Z

If we are using `@` like in Symfony, it will be:

    {% include '@namespace/index.html' %}

And for non-namespaced templates:

    {% include 'index.html' %}

And for Symfony users, the notation would be the same as for resources. If we register each bundle path as a namespace, the path would even be exactly the same:

    {% include '@AcmeDemoBundle/Resources/views/layout.html.twig' %}

EDIT: that's not so simple because of the templates stored under `app/`.

---------------------------------------------------------------------------

by mahono at 2012-07-14T19:56:54Z

might not be the best idea, but what about using Backslash as namespace char?

---------------------------------------------------------------------------

by fabpot at 2012-07-14T19:57:50Z

@mahono: I have not dared to propose this alternative ;)

---------------------------------------------------------------------------

by fabpot at 2012-07-14T20:06:17Z

I've just made an additional commit that implements the `@namespace/template_path` notation.

---------------------------------------------------------------------------

by Baachi at 2012-07-14T20:32:41Z

The `@` syntax is the most consistent solution.
But the integration in symfony2 is really hard and a BC break.

The stream syntax is not a good solution.
`twig` might already be already registered as a stream.

I would suggest the `::` syntax.

fixed some possible warnings

fixed typo