This code example shows how to loop over a subset of values in order to implement one common use-case of "break" in PHP. I decided to use the "full" notation of slice rather than the sugared version (that example would just be "for user in users[:10]")
This PR was merged into the master branch.
Commits
-------
f8d4db4 added the first and last filters (closes#951)
Discussion
----------
added the first and last filters (closes#951)
---------------------------------------------------------------------------
by acasademont at 2013-01-26T20:45:23Z
👍 great! Using twig_slice is a nice thing, we can have string and traversable objects work also with the new filters
---------------------------------------------------------------------------
by jankramer at 2013-01-30T17:39:31Z
👍 Was actually just looking for this :) When do you think you'll merge this feature into master?
This PR was merged into the master branch.
Commits
-------
8bb953c Fix doc block for twig_constant.
c7dafb7 Update documentation for constant()
cb921ce Implement getting constants from objects.
998b367 Add tests for getting constants from instances.
Discussion
----------
Object constants
Implement the changes discussed in #954.
This PR was merged into the master branch.
Commits
-------
f4f88a5 added an include function
Discussion
----------
added an include function
---------------------------------------------------------------------------
by stof at 2012-12-09T14:12:25Z
I see an issue with this naming: it will confuse Symfony users because of the ``render`` tag doing something different than the ``render`` function. And it will force to break BC for Silex users where the subrequest logic is using a ``render`` function right now
---------------------------------------------------------------------------
by fabpot at 2012-12-10T12:49:57Z
@stof: I know about the possible confusion. For Silex, as it is not stable yet, we don't need to keep BC. And I don't have any other better name. What I want to introduce next is a `render_request` function in both Silex and Symfony (which will do the same as the current render tag in Symfony and the render function in Silex).
---------------------------------------------------------------------------
by Taluu at 2012-12-10T14:13:31Z
Hi,
I may be absent-minded, but I don't really understand the difference between `render` function and the `include` tag... ?
---------------------------------------------------------------------------
by fabpot at 2012-12-10T14:16:09Z
@Taluu Using a function allows you to do whatever you want with the output (which is not possible with a tag), like a simple:
```jinja
{{ set content = render('some_template') }}
```
Also, semantically, using a tag to output some content is less correct.
---------------------------------------------------------------------------
by vicb at 2012-12-10T14:18:17Z
could it be named `include` ?
---------------------------------------------------------------------------
by tcz at 2012-12-10T14:18:40Z
I agree that it's confusing for Symfony users. It is the same as raw filter and raw tag. I would prefer execute as name or something like that
---------------------------------------------------------------------------
by Taluu at 2012-12-10T14:19:29Z
@fabpot so, does it means that it could replace the include tag ? Then, we could could name it `include` as @vicb suggested... ?
---------------------------------------------------------------------------
by titomiguelcosta at 2012-12-10T14:21:51Z
I agree with @stof, naming it render will be confusing, parse or execute or compile are other names that come to my mind for this purpose.
---------------------------------------------------------------------------
by silentworks at 2012-12-10T14:24:36Z
How about calling it `partial`? even though you are rendering a full template, it is being included in another so this could be seeing as a partial of that template.
---------------------------------------------------------------------------
by stof at 2012-12-10T14:26:05Z
@titomiguelcosta parse is totally wrong. The function is not parsing the string you give it. you don't pass the content of the template but its name. and ``compile`` is also wrong. It is not compiling a template but rendering it.
---------------------------------------------------------------------------
by jmather at 2012-12-10T14:30:53Z
I think `render` is probably the most appropriate name, but also may cause confusion, however I don't have another suggestion that is nearly as clear as to context and meaning.
---------------------------------------------------------------------------
by emgiezet at 2012-12-10T14:31:26Z
Can you pass the array of params as an argument to the `render` function?
---------------------------------------------------------------------------
by titomiguelcosta at 2012-12-10T14:31:59Z
@stof true that we pass the filename as argument, but we end up parsing the file.
---------------------------------------------------------------------------
by stof at 2012-12-10T14:32:48Z
@emgiezet you mean passing some variables available in the included template ? Sure you can. See the doc. the argument is named ``variables``
---------------------------------------------------------------------------
by stof at 2012-12-10T14:34:36Z
@titomiguelcosta But the goal of the function is not to parse the file (btw, it may not parse it if the template was already compiled in the cache). The goal is to render the template.
Btw, I agree with @jmather. As far as Twig is concerned, ``render`` is the best name. The only issue comes from the fact that Symfony already use a ``{% render %}`` tag with a different meaning
---------------------------------------------------------------------------
by emgiezet at 2012-12-10T14:39:02Z
@stof thx a lot didn't noticed the doc link. Maybe `render_partial` will be good in this case?
---------------------------------------------------------------------------
by tcz at 2012-12-10T14:44:13Z
In an ideal world the Symfony2 `render` tag would be renamed to `subrequest` or something like that and the new function in Twig would get the `render` name. The question is how many people use Twig because of Symfony2 and how many of them use it in itself (in my company we use standalone Twig for example).
I think it's important to avoid `raw`-style confusions for the former group.
---------------------------------------------------------------------------
by stof at 2012-12-10T15:16:28Z
@tcz The issue with renaming the tag in Symfony is that it would be a BC break. So we cannot simply drop the tag (we can provide a new name and deprecate the current one, but we would still keep it).
---------------------------------------------------------------------------
by Taluu at 2012-12-10T15:18:56Z
I think `partial` would be a good idea... But still, does it mean that the `include` tag would be deprecated in favor of `render` (or whatever the name will be) function ?
---------------------------------------------------------------------------
by tcz at 2012-12-10T15:19:49Z
@stof Yes :( hence my remark "in an ideal world"
---------------------------------------------------------------------------
by stof at 2012-12-10T15:27:52Z
@Taluu It depends if @fabpot wants to keep the compatibility with Jinja where possible (as it is where the ``include`` tag comes from)
---------------------------------------------------------------------------
by WouterJ at 2012-12-10T15:48:26Z
I like the function, but I don't like the name. I like the name `partial`.
I am a front-end developer from origin and all files you include in the base CSS stylesheet are called 'partials' in SASS or other preprosessors. Twig is used to make live easier for front-end developers and I think a function called `partial` is more familiair for them than `render`.
---------------------------------------------------------------------------
by silentworks at 2012-12-10T16:17:24Z
@stof I guess based on @fabpot wanting to keep Twig compatibility with Jinja, calling the tag `partial` rather than `render` shouldn't be a problem since Jinja doesn't have any of these.
---------------------------------------------------------------------------
by Taluu at 2012-12-10T16:19:25Z
@silentworks @stof was talking about my question, about why keep the `include` tag if the `render` (or whatever the name will be) is indeed inserted into Twig. :)
---------------------------------------------------------------------------
by stof at 2012-12-10T16:19:38Z
@silentworks I was not talking about the name of the function, but about the removal of the ``include`` tag
---------------------------------------------------------------------------
by silentworks at 2012-12-10T16:22:37Z
Thanks for clarity from both.
On the basis of keeping to conformity to Jinja, should this function not be a part of twig extensions rather than in the core?
---------------------------------------------------------------------------
by mvrhov at 2012-12-10T17:20:03Z
Well search and replace for symfony users when upgrading shouldn't be that hard so I'd say that we rename the symfony block into subrequest or sth similar.
---------------------------------------------------------------------------
by Taluu at 2012-12-10T17:26:22Z
If we were to follow your recommandations, we could say the same for all and every changes inducing a BC break huh...
---------------------------------------------------------------------------
by markstory at 2012-12-10T17:49:36Z
What about naming the function `include`? It would share a name with the tag, but it also does the same type of thing as the tag. The function has the advantage of having its return captured. I think `{{ include(template) }}` semantically does what it looks like it does when operating on the template object as well.
Other names that I think could fit well are `partial` and `display`. Render works well, but I understand people not wanting to overlap with existing symfony features that do very different things.
---------------------------------------------------------------------------
by Baachi at 2012-12-10T18:13:25Z
I think "partial" is a better name for this function and it would keep BC.
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.
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` 😈
---------------------------------------------------------------------------
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!
Kevin Boyd
carlwitt
Tobias Schultze
Fabien Potencier
Grégoire Pineau
Javier Eguiluz
Jacek Jędrzejewski
iamdto
Bilal Amarni
Mark Story
Vincent Terraillon
Gunnar Lium
Mario A. Alvarez Garcia