On 25-06-2010 at 11:57:12 Per Bernhardt wrote:
For me it is exactly the other way around :)
When I return true in
PHPTAL_Php_Attribute_METAL_FillSlot::shouldUseCallback(), my actual
template works fine!
Returning false (and so disabling the optimisation) breaks the result.
It is the same
For me it is exactly the other way around :)
When I return true in PHPTAL_Php_Attribute_METAL_FillSlot::shouldUseCallback(),
my actual template works fine!
Returning false (and so disabling the optimisation) breaks the result.
It is the same with beta and the latest svn.
So maybe you should alw
We already thought of this solution. Our team agreed that this is not really
the "PHPTAL"-way and we should use slots.
But now, with your explanation of the technical issue regarding variable scope
and the added explanation in the manual, it's fine :)
Thank you!
-Ursprüngliche Nachricht--
On 25-06-2010 at 09:57:12 Per Bernhardt wrote:
Thanks. That's a great example. I've turned it into a test case - and it
passes in the SVN version, but it may be just because the test is short.
There's optimisation that turns "large" slot fills into callbacks to save
memory and improve "str
On 24-06-2010 at 18:55:31 Per Bernhardt wrote:
taken the following macro and macro-usage:
metal:use-macro="ul">
${item}
I would expect the template to be rendered like this:
Hi,
I have a problem related to macros / slots again:
Imagine this macro, used to render a fieldset:
Use it nestedly:
First Level
Second
Leve
