Re: [SMARTY-DEV] Error reporting info in compiled templates

> I'll start off by agreeing that this could be a useful idea, and there
> is nothing stopping you from extending the existing Smarty class and
> declaring your own trigger_error method.

I agree but embedding debug info inside the compiled templates using this
technique is not that simple since the compiled output is calculated inside
compiler methods that don't provide easy means for customizing this output
in derived classes.

> Using debug_backtrace() in the main distribution, aside from being
> inaccurate, like you said, would also raise the requirements to
> PHP4.3.0 or higher, which is an unreasonable requirement considering
> that we support as far back as 4.0.6.

debug_backtrace would have been useful for retrieving error line numbers as
this is among the only accurate data this function is guaranteed to return
but it can be done without it completely.

> Compiled templates are designed so the output of the template EXACTLY
> matches how it looked in the template. This has been discussed many
> many times on the mailing lists, and so far (to my knowledge anyway)
> we've yet to find a solution that lets us align compiled templates
> correctly, especially given how complex the compiled foreach/section
> constructs are and that its possible for them to take up to 12 lines
> to open the construct.

I was aware of some of the work to keep the two aligned but I didn't know
this aspect was so important. The way I personally see things (read:
disclaimer) working on this strict requirement is to some extent counter
productive. Imagine that binary executables wouldn't include debug data like
the Stabs format but instead try to mimic the source files, regardless of
their quality.

Trying to respect this requirement heavily narrows the techniques that can
be employed inside the compiled output and like you've said, it can't always
be fully respected anyway.

What I propose is to simply embed this kind of information in the compiled
templates which would literally break the previous requirement and would
additionally provide a clean and global API for debug data retrieval at any
processing stage.

> The name of the template being processed, however, can be found with
> $smarty->_current_file inside of functions etc, as the smarty object
> is also passed amoungst the arguments, it's slightly more difficult
> with modifiers, but not impossible.

That variable and the one for the line number are compiler variables and are
only available while compiling the template. Once the template is compiled,
they are no longer present and that's the whole problem actually. They
should find their way into the compiled templates.

> That being said, it's possible to implement something to pull out line
> numbers in plugins etc using debug_backtrace() in
> smarty::trigger_error(), but because of the 4.3 requirement, I can't
> see this being implemented in the main distribution.

We've already done it using either debug_backtrace or the aforementioned
compiler variables but the second solution which is the cleanest, requires
modifications to the core Smarty source files. We can then perpetually merge
this set of modifications on every Smarty release or we can work towards
having it included in the main Smarty tree.

Just to clear things up some more, all this is actually about recording the
compiler variables for the template and the line number, in the compiled
templates, at compile time. It would also use to have the plug-in name
recorded the same way but that can then be easily added afterwards.

What I'd like to know is if the Smarty development coordinators are
interested by this feature or not so that I can start preparing a diff but
the preparation takes time and I can't currently afford to work on things
that won't be taken into consideration.

Daniel