In the original PhpTal it was not possible to automatically parse
arbitrary strings, I don't know if this feature has been introduced in
later releases.
The common approach is to execute the string as a template, introducing
the result in the actual template context. If this is a pattern that
Hi,
I've never been a big fan of metal macros so I might be a bit biased here.
What I would do is instead of creating a slot for the header, populate
it in your general.tpl file directly.
Since you're already including a file in your pages to calculate the
header contents, you could put there
On 9/16/09 4:56 PM, Kornel Lesiński wrote:
On 16-09-2009 at 14:45:39 Iván -DrSlump- Montes
wrote:
// Get the standard instance of the loader
$loader = $tpl->getFilterLoader();
// and add a new location for filters
$loader->addPrefixPath('My_Filter', '/path/to/my/filter');
I'm afraid it does
On 9/16/09 6:03 PM, Kornel Lesiński wrote:
On 16-09-2009 at 16:30:35 Iván Montes wrote:
I'm not too fond in how the caching works so I might be completely
wrong here. Why are prefilters needed to compute the caching logic?
As I understand it, the filters are run at compile time not at
Hi,
I vote for not changing the behavior but I would like, for next major
version of PHPTAL, to break BC for escaping and remove the escaping of
the dollar symbol:
${variable} -> variable
$${variable} -> $variable
Since TAL is heavily based on HTML/XML semantics I guess it makes more
sense
Check PHP's ob_* functions, they allow to capture what is being send to
the browser allowing to either get back the result, echoing it all
together or discarding it.
/imv
On 10/28/09 11:53 PM, Nestor A. Diaz wrote:
Hello, i want to know if there is any possibility to disable the
output of the
I would advocate to don't make Tales syntax more complex. There is
however one point which I would think as a good compromise, the use of
inline PHP. For example:
foo
This would work nicely with syntax highlighting and other editor/IDE
features, is common enough for PHP developers and allows
After looking at the wiki page examples, couldn't we solve this with
specialized tales modifiers?
It's a bit more verbose but they are quite declarative and should be
easy to implement in the current PHPTAL infrastructure.
/imv
On 11/17/09 2:05 PM, Kornel Lesiński wrote:
On 17-11-2009
Hi,
Yes, "paths" can resolve to method calls, in fact methods take
precedence over properties. The logic can be seen in PHPTAL_Context::path().
However it's not allowed to use arguments in path expressions. The php
modifier is needed in those cases. ie:
tal:content="username">Username
reg
I fail to see why checking for closures makes variable access much
slower. As far as I remember, interpolated variable paths are "compiled"
to use the $ctx->path() method, and it already does quite a few type
checking logic already.
Checking for a closure basically would mean adding "instanceo
he object, the property_exists() condition would only make
sense to retrieve private/protected properties, which I don't think it's
a desired outcome.
regards,
/imv
On 12/23/09 8:17 PM, Kornel Lesinski wrote:
On 23 Dec 2009, at 18:27, Iván Montes wrote:
I fail to see why checking for c
On 12/24/09 11:50 AM, Kornel Lesiński wrote:
Yes, it probably would be negligible most of the time, but
unfortunately lots of users are (unreasonably) afraid of template
engine overhead and use synthetic benchmarks to compare template engines.
I think TAL attractive to users is its elegance, wit
Hi,
I've put together a very simple chunk iterator [1] which works with
arrays, traversables and iterators. There is also an example tales
modifier.
Perhaps it could even be added to the standard PHPTAL code base?
[1] http://gist.github.com/266759
regards,
/imv
On 12/31/09 11:02 AM, Kornel
nough to just modify the code and use a SplFixedArray
object to ensure constant memory usage, without relying on PHP's garbage
collector to do the job.
[1] http://php.net/limititerator
/imv
On 1/4/10 3:19 PM, Kornel Lesiński wrote:
On 31-12-2009 at 15:23:20 Iván Montes wrote:
I'
14 matches
Mail list logo
