Re: Error reporting info in compiled templates

> This seems like an interesting idea to me. Of course, it all depends on
> how it actually works out in the implementation but on the face of it,
> I can see its uses. I would expect that these operations would be
> optional, perhaps controlled via a class-member switch to minimize
> impact on production environments.

Definitely. All this debugging feature can be configured and optional
between dev and prod environments even though you can have scenarios where
this should be active in prod environments too. There are solutions for this
case too though (next paragraph).

> Realistically, I'm not convinced that hooks like this are the best way
> to build debug symbol tables, but given the current options, it does
> seem like a reasonable approach especially since no one seems to have a
> better solution available atm.

Well there actually is an elegant solution to this problem. First of all you
create a common Smarty API for retrieving debug info from compiled
templates. A set of standard methods that plugins can use in any context to
find out where the "execution pointer" is. Behind the scenes, this API can
use several methods for storing and retrieving this info, depending on
several imperatives.

The method I described earlier adds some PHP code to compiled templates but
guarantees the same conformance to PHP 4.0.6 as the rest of Smarty.

There could be another method starting with PHP 4.3.0 by which you could use
debug_backtrace to find the current execution line inside the compiled
template, and then parse that line for specially formatted PHP comments
containing the debug info. Instead of inserting PHP code that updates
private variables, you'd have comments like /* %%L23 %%Tarticle.tpl
%%Pget_resources */. The API then finds out the execution line and parses
that line for this info. This method doesn't generate any overhead and can
be used automatically in environments based on the proper PHP version, dev
as well as prod.

> Aside: Something that may be worth considering is that this idea using
> hooks could possibly be generalized into an event model where Smarty
> defines certain events (compile_start, compile_end, etc) and users can
> register appropriate callbacks to handle these events much like the
> plugin system.

Good point. We should find some real world use-cases for this extension but
I'm sure it'll find its utility as the applications that use Smarty mature.

> FWIW, I'm tentatively +1 on this one

I'll put together a first version of the code as soon as I can.

Daniel

-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php