On Thu, Oct 22, 2009 at 1:23 AM, Simon Wilcox <[email protected]> wrote:
> So, it's not a bug in TT per se, i.e. it's not a regression, it's always
> been this way but it is a change in behaviour caused by a change
> *elsewhere*. The subsequent question is whether TT should change to
> suppress the warnings.
>
>
It seems like it already does. In the Template::Document module, where the
generated code gets evalled, a local $SIG{__WARN__} hook is installed which
suppresses all warnings.
Is it possible that some other module does something that makes assignment
to $SIG{__WARN__} ineffective? Maybe by tying the %SIG hash, but that seems
awfully intrusive.
The perl warning seems reasonable to me. It's a code smell to be trying
> a numeric comparison on something that's not numeric.
>
> The Right Thing To Do[tm] is to fix your code so that empty strings are
> turned into zeros or something else that makes sense in your application
> BEFORE you hand it off to the template for display.
>
Another useful thing might be to introduce a configuration option or two
that provide more control over which warnings can be generated by evaluated
template code, and how such warnings are disposed of. Something like:
$t = Template->new({
WARNINGS => [ '+numeric', '-uninitialized' ],
WARNSUB => \&aggregate_warnings,
....
});
...where aggregate_warnings() might collect all of the warnings and spit out
just a single warning like "123 numeric warnings issued."
--Sean
_______________________________________________
templates mailing list
[email protected]
http://mail.template-toolkit.org/mailman/listinfo/templates
