|
Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon. |
|
View previous topic :: View next topic |
Author |
Message |
Frosty Smarty n00b
Joined: 10 Oct 2012 Posts: 3
|
Posted: Wed Oct 10, 2012 4:46 pm Post subject: Smarty 3.1.12 - endless loop encountered |
|
|
Hi,
Recently for a project, I had to migrate from Smarty 3.0.7 to 3.1.12. That fixed a bunch of weird "HTTP error 500" when the project was run on a IIS 7 server.
After that, I noticed a bug with some "treeviews". Those used "recursively included" smarty templates, with a "custom" template inclusion mechanism.
Basically:
Code: | $smarty = new Smarty();
....
$smarty->registerPlugin('helpers/IncludeHelper.php', 'includeTemplate'); |
Code: | class IncludeHelper
{
/*
* Calling example:
* {includeTemplate module="common" name="thumb"}
* will load and process template templates/common/thumb.tpl
*/
static function includeTemplate($params, $smarty)
{
foreach($params as $key => $param)
$smarty->assign($key, $param);
return $smarty->fetch('templates/'.$params['module'].'/'.$params['name'].'.tpl');
}
} |
And for example, having a template items.tpl, where we can find something like:
Code: | {foreach key=currentKey item=currentItem from=$childs}
{includeTemplate module="something" name="items" childs=$currentItem.childs level=$level+1}
{/foreach} |
After migrating to Smarty 3.1.12, that kind of recursive template inclusion triggered "Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 35 bytes) in ....\smarty\libs\sysplugins\smarty_internal_templatebase.php on line 60"
To solve that problem, I had to do the following changes in libs\sysplugins\smarty_internal_templatebase.php:
Line 42
Code: | - $parent = $this;
+ $parent = clone $this; |
Towards lines 340-350, comment out the two Code: | if ($merge_tpl_vars) {...} | blocks (otherwise, I got nearly no variable assigned to my included templates)
Could someone please look at that issue? In fact, this post is nearly a pull request, so that I would not face again this problem after a future Smarty migration.
Thanks for your attention |
|
Back to top |
|
U.Tews Administrator
Joined: 22 Nov 2006 Posts: 5068 Location: Hamburg / Germany
|
Posted: Wed Oct 10, 2012 6:11 pm Post subject: |
|
|
Indeed the recursion implemented by the plugin does create a problem.
I must take a closer look at this.
But why do you use the plugin to do this and do not do it in the template like this
Code: | {foreach key=currentKey item=currentItem from=$childs}
{include file='items.tpl' childs=$currentItem.childs level=$level+1}
{/foreach} |
You can get even better performance if you use template functions for recursive calls.
See http://www.smarty.net/docs/en/language.function.function.tpl |
|
Back to top |
|
Frosty Smarty n00b
Joined: 10 Oct 2012 Posts: 3
|
Posted: Thu Oct 11, 2012 8:20 am Post subject: |
|
|
Thanks for your interest.
I made my own {includeTemplate} plugin in order to compute automatically the template directory path given some parameters, in order to have a Symfony 1.x - like directory structure + simple "include template" calls.
Basically I would like to do, for example:
Code: | {foreach key=currentKey item=currentItem from=$childs}
{include module="common" name="items" childs=$currentItem.childs level=$level+1}
{/foreach} |
Where {include} would fetch template apps/myapp/modules/common/templates/items.tpl
If there is a better / more efficient way to do that, than with my {includeTemplate} plugin, I would be interested. |
|
Back to top |
|
U.Tews Administrator
Joined: 22 Nov 2006 Posts: 5068 Location: Hamburg / Germany
|
Posted: Fri Oct 12, 2012 12:14 am Post subject: |
|
|
Your include file name can be dynamic
Code: | {foreach key=currentKey item=currentItem from=$childs}
{include file="templates/$module/$name.tpl" module="common" name="items" childs=$currentItem.childs level=$level+1}
{/foreach} |
|
|
Back to top |
|
Frosty Smarty n00b
Joined: 10 Oct 2012 Posts: 3
|
Posted: Fri Oct 12, 2012 9:11 am Post subject: |
|
|
Obviously that could work, however I would have to repeat the template path structure at each {include} call.
Even if that path is unlikely to change, IMO Code: | {include name=<template name> module=<module name (optional ; default being current module)> param1=<value1> param2=<value2> ...} | , computing automatically the path, is slightly more readable/maintainable ; hence the plugin method.
BTW, even if there was a small performance loss with that plugin, that has never been an issue. |
|
Back to top |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|