Re: [Templates] Of segfaults, lists and hashes
Simon Wilcox wrote:
This causes a segfault on my 5.6.1 tt v 2.10 setup:
[% PERL %]
$foo = 'hello';
[% END %]
It doesn't on 5.8.0 which makes me think it's a Perl bug,not TT.
[% PERL %]
my $sub = sub { ( ref( $_[0] ) eq $_[1] ) };
$Template::Stash::LIST_OPS-{ is_a } = $sub;
$Template::Stash::HASH_OPS-{ is_a } = $sub;
$Template::Stash::SCALAR_OPS-{ is_a } = $sub;
[% END %]
And again, it's OK on 5.8.0.
BTW, you can write it like this:
[% PERL %]
my $sub = sub { UNIVERSAL::isa($_[0], $_[1]) ? 1 : 0 };
$stash-define_vmethod( list = isa = $sub);
[% END %]
Or rather, that's how I would write it, using UNIVERSAL::isa and
the new define_vmethod() method. You can also call define_vmethod()
on the context, btw and it delegates it off to the stash.
$context-define_vmethod( list = isa = $sub );
.list vmethod automagically converts the single scalar into an arrayref
but when they're hashref's, .list doesn't DWIM, instead it returns a list
of hashrefs containing each key, value pair from the original hashref.
I'll cover this in a separate message...
A
___
templates mailing list
[EMAIL PROTECTED]
http://lists.template-toolkit.org/mailman/listinfo/templates
[Templates] Fixing the hash.list virtual method
A short time ago in a nearby thread, Simon Wilcox wrote:
I have a routine that returns a hashref
or an arrayref containing multiple hashrefs. If they're scalars then the
.list vmethod automagically converts the single scalar into an arrayref
but when they're hashref's, .list doesn't DWIM, instead it returns a list
of hashrefs containing each key, value pair from the original hashref. I
had to resort to the vmethod above and this code:
I think it's time to admit that this behaviour is wrong and change it.
Currently hash.list accepts an argument which is one of 'keys', 'values',
or 'each'. But these are just duplicates for the hash.keys, hash.values
and hash.each vmethods so are effectively redundant.
hash.list('keys')# hash.keys
hash.list('values') # hash.values
hash.list('each')# hash.each
Currently, if you call hash.list without an argument then you get a
list of hashrefs containing a 'key' and 'value'. I can't think why I
did this because I'm sure it's as good as useless if you're not prepared
for the data you're getting back.
However, that's not to say that the functionality isn't useful for when
you do know what's going on. For example, you can use it to sort a hash
by value:
[% FOREACH person IN people.list.sort('value') %]
So it's worth having this functionality, but I think it should be
implemented as a separate vmethod. Perhaps called 'kv' (for key/value),
'kvlist' or 'pairs', which is my current favourite (opinions and other
suggestions welcome).
[% FOREACH person IN people.pairs.sort('value') %]
hash.pairs would return what hash.list currently returns, a list of key/value
pairs, each implemented as a hash array with a 'key' and 'value' item.
hash = {
a = 'foo',
b = 'bar',
c = 'baz'
}
hash.pairs # [ { key = 'a', value = 'foo' }
{ key = 'b', value = 'bar' }
{ key = 'c', value = 'baz' } ]
Of course you would get them in a non-deterministic order, but you
get the idea.
Alternately, it could return a list of lists.
hash.pairs # [ [ a = 'foo' ]
[ b = 'bar' ]
[ c = 'baz' ] ]
Or we go the whole hog and have 2 different vmethods, hash.pairs to
return a list of lists, and hash.kvlist to return a list of key/value
hashes.
Then it just remains to decide what hash.list should return. Does it
return a list containing the single hash reference? (i.e. it behaves
like scalar.list automatically promoting a single item to a list)
hash.list =[ { a = 'foo', ... } ]
Or does it behave like hash.each and return a list of the hash contents?
hash.list =[ a = 'foo', ... ]
Although it could be argued that the second is slightly more intuitive,
it's identical to hash.each. So I think it should be the first - hash.list
returns a list containing the hash reference, as you have used it.
Either way, I think we should wait for TT3 before making this change
because it is likely to break templates that currently rely on that
behaviour. We can go ahead and add the new vmethods now but leave
hash.list working as it currently does. Additionally, we document the
fact that hash.list will change at some point in the future and encourage
people relying on the existing behaviour to change their templates to
use hash.keys, hash.values, hash.each, or hash.pairs (or hash.kvlist, etc).
To solve your immediate problem, we can add another option to the current
hash.list vmethod, say 'list', which does what you want:
hash.list('list')# [ { a = 'foo', ... } ]
It's ugly, but it'll work for now until we can properly fix hash.list to
Do What It Should Have Done All Along (DWISHDAA).
How does that sound?
A
___
templates mailing list
[EMAIL PROTECTED]
http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] tt annoyances
Mark D. Anderson wrote: Keep in mind this is with the best of intentions; Understood. For what it's worth, your critiscism is both constructive and fair, and I'm glad that you took the time to do it. 2. There is no typeof or instanceof operator (or similar). Perl has ref and isa; practically all real programming languages Yep, in TT3 there will be both 'ref' and 'type' vmethods for all types. The .ref vmethod returns what Perl's ref() returns so for cgi_obj.ref it will return 'CGI' but for text.ref it will return nothing. The .type vmethod will be slightly different, returning 'TEXT' for text.type and 'OBJECT' for cgi_obj.type, for example. 3. There is (effectively) no defined operator. Nope. That was intentional. But it should (in theory, if not currently in practice) to be able to set your own variable called 'undef' which has the Perl undefined value and then use it. The current stash doesn't handle undefined values very well. This is definately something that I plan to improve... I refuse to run without undefined variable warnings (in TT, that means DEBUG=undef). ...this too. 4. Common string functions are available in counter-intuitive ways. This is all sorted in the new TT3 virtual methods. Vmethods, filters and things like the String.* functions will all become one. 5. The iterator objects/methods are not generic. Yep, this also needs to be fixed. 6. You can't call methods directly on literals, for example [% 'asdf'.length %] or [% [1,3,2].sort %]. Yes, this is already implemented in the new TT3 parser. Certain common operators such as [% count++ %] and [% count += 1 %] Ditto. All these and others are of course a concomitant penalty for going with the mini-language school of template systems (We're hurting you because we love you...). Still, it hurts. I'm here to take the pain away :-) 7. There is no way to comment out a whole block of template lines which includes other directives. That is, you can't nest things like [%# [% %] %]. True, but that's a limitation of the scanner/parser and it's very hard to work around that. The scanner has no way of knowing which '%]' terminates the directive. Nevertheless, it is something that I think I've managed to work around in TT3. Well, to a fashion. You may have to use a different tag style, e.g. [# [% ... %] #] Or it may be possible to do something like this: [%# [% ... %] #%] Or [% COMMENT %] [% ... %] [% END %] Maybe. Whatever. 8. A bug: [% SET str = 'a'; str.repeat(0) %] prints 'a', not '' Now fixed. 9. The diagnostics stink. (This was a topic of an earlier email post.) Yep. Again, I'm working on that. 10. Boolean interpolation is non-obvious. [%1==2%] interpolates as '', and [%2==2%] interpolates as '1'. Blame Perl for that one. There are also no builtin constant values true and false. But it's not hard to write: [% true = 1 false = 0 %] I prefer that to adding more reserved words. A ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
[Templates] Assigning filter output
I'm trying to do some rounding and I'm wondering if there's an easy way
to assign the output of a FILTER to a variable. This throws some
errors:
[% floor = FILTER('%.0f'); num; END %]
Brian Hann
___
templates mailing list
[EMAIL PROTECTED]
http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] Assigning filter output
* Hann, Brian Brian.Hann at umb.com [2003-10-10 12:07]:
I'm trying to do some rounding and I'm wondering if there's an easy way
to assign the output of a FILTER to a variable. This throws some
errors:
[% floor = FILTER('%.0f'); num; END %]
[% floor = num | format('%.0f') %]
(darren)
--
The death of democracy is not likely to be an assassination from
ambush. It will be a slow extinction from apathy, indifference,
and undernourishment.
-- Robert Maynard Hutchins
pgp0.pgp
Description: PGP signature
[Templates] Developer version 2.10a released
The latest developer version 2.10a is now available from the TT web site: http://www.template-toolkit.org/download.html#devel Changes below are as I posted a few days. The only things that has changed is a minor fix to the Makefile.PL where I overlooked some version numbers. Thanks to Axel for catching that. Enjoy A # # Version 2.10a - 9th October 2003## DEVELOPER RELEASE ## # * Applied two patches from Axel Gerstmair to fix bugs in Makefile.PL and t/date.t. See. http://tt2.org/pipermail/templates/2003-April/004553.html http://tt2.org/pipermail/templates/2003-May/004572.html * Applied patch from Jim Cromie to t/autoform.t to skip tests on all versions of Perl from 5.8.0 onwards. * Changed $OUTPUT in Template::Directive to be a package variable, allowing it to be re-defined to permit a flushed output hack. http://tt2.org/pipermail/templates/2003-October/005136.html * Applied a patch from Darren to the 'item' hash vmethod to protect against accessing private variables (prefixed '.' or '_') http://tt2.org/pipermail/templates/2003-June/004761.html * Applied a patch from Ivan Adzhubey to template/splash/frame. http://tt2.org/pipermail/templates/2003-August/004953.html * Applied a patch from Bryce Harrington to add the absolute and relative options to ttree. Also applied a patch from Mark Anderson to add the 'template_debug'. Removed the old debug option which was as good as useless. http://tt2.org/pipermail/templates/2003-October/005110.html http://tt2.org/pipermail/templates/2003-October/005126.html * Applied another patch from Mark to push files named on the command line through the process_file() sub to ensure that various options like accept checking, pemission preserving and copy processing (but not modification time) are applied. http://tt2.org/pipermail/templates/2003-October/005132.html * Applied a variation of yet another ttree patch from Mark to add the 'suffix' option for changing the suffix of output files created. http://tt2.org/pipermail/templates/2003-October/005121.html * Applied a variation of a patch from Dylan William Hardison which adds the 'depend' and 'depend_file' options to ttree. http://tt2.org/pipermail/templates/2003-July/004783.html http://tt2.org/pipermail/templates/2003-October/005147.html ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
[Templates] Apache::Template version 0.08
I finally got around to uploaded Apache::Template 0.08 to CPAN. It should be propagating around within the next few days. It's been available from here for some time: http://andywardley.com/perl/Apache-Template-0.08.tar.gz Apologies for having it in my blind spot for so long, and thanks to those who sent the gentle reminders so I couldn't forget. A ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] ttree questions
Andy Wardley [EMAIL PROTECTED] writes: 'Twas asked: Is there any way to get ttree to generate files with a different suffix than the template? Mark Anderson responded: Ok, here is a patch that does it. Thanks Mark, I've applied a slight variation of this. In my version the suffix option can be used multiple times to define different extensions to be mapped from src to dest. I thought this gave a little more flexibility. e.g. $ ttree --suffix tt2=html --suffix htm=html This will change all '.tt2' and '.htm' extensions to '.html', leaving all others as they are. I really appreciate that one, thanks. -- David Dyer-Bennet, [EMAIL PROTECTED], www.dd-b.net/dd-b/ RKBA: noguns-nomoney.com www.dd-b.net/carry/ Photos: dd-b.lighthunters.net Snapshots: www.dd-b.net/dd-b/SnapshotAlbum/ Dragaera mailing lists: dragaera.info/ ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] tt annoyances
[EMAIL PROTECTED] (Randal L. Schwartz) writes: Mark == Mark D Anderson [EMAIL PROTECTED] writes: Mark Keep in mind this is with the best of intentions; I'm sure TT is the most Mark mature of the mini-language school of perl templating solutions. But don't misunderstand what TT is about. I think perhaps you are. You deliberately don't *want* TT to be a full programming language. It has *just enough* to do most tasks. Yeah, when I was looking at TT before starting to use it fro the current project, I was struck by the amount of programming language already being added. What struck *me* was that I'd rather have perl than some new special programming language, actually. Or PHP, if I have to. :-) -- David Dyer-Bennet, [EMAIL PROTECTED], www.dd-b.net/dd-b/ RKBA: noguns-nomoney.com www.dd-b.net/carry/ Photos: dd-b.lighthunters.net Snapshots: www.dd-b.net/dd-b/SnapshotAlbum/ Dragaera mailing lists: dragaera.info/ ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
RE: [Templates] tt annoyances
Yeah, when I was looking at TT before starting to use it fro the current project, I was struck by the amount of programming language already being added. What struck *me* was that I'd rather have perl than some new special programming language, actually. Or PHP, if I have to. :-) The problem with in-line perl or PHP is that you often wind up wanting to seperate the display level code from the data generation code and you are right back to wanting a template system. If you think I'm kidding look at how many PHP projects there are that implement templates... http://smarty.php.net/ is the biggest that I know of but there are plenty more. Large PHP projects always run into the same CGI WALL that perl CGI projects and ColdFusion projects slam into. At some point, interleaving the code and the view into a single file ties your hands and feet. And falling flat on your face hurts. :) I've taken to looking for ugly constructs in the templates (like CASE style IFs that set styles or nested FOREACHes) and moving some of that work back to mod_perl or the CGI that generates the data. And I've finally broken myself of having a single script that tries to return two entirely different web pages based on input... those sites always wind up being entirely broken when you try and book-mark sub-pages. I hunt and destroy complexity at the Template level, to keep process level features from leaking into my display code. --mark mills Xodiax Engineering ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] CGI/TT vs SSI
On 10 Oct 2003, David Dyer-Bennet wrote: Tosh Cooey [EMAIL PROTECTED] writes: After reading some of the things that Randall has suggested I was thinking about making the menu static, but then I have to rebuild after every change, and also lose a bit of dynamism. I'm running a mod_perl environment. Is this just a case of; six of one, one-half dozen of the other or is forcing a Template-process call on hapless static HTML, just to put in a menu, a bit of overkill? To a first approximation, CPU spent at build time is free. You build so few times, compared to the number of times the page is viewed. So unless you *need* minute-by-minute dynamic generation of your site, you win by using a build-time process to produce pages which are then served statically. I've used this on the last couple of sites I've designed, and am liking it *very* much. In both of them I do have a couple of live CGIs for things that really *do* change minute by minute. I also have an automated every-day rebuild, so that scheduled events can be listed only for the current and future days, not letting the past events linger around. I'd ditto these remarks. The OSDL website is not huge - takes less than a minute to rebuild - but we occasionally get high traffic spikes (such as when we hired Linus). The troubles we've had with using a build system are more process related than efficiency related, but they've been workable. By the way, we've been experimenting with various versions of the Linux kernel for the web server, as we're wont to do, and found some pretty major performance benefits from upgrading from 2.4 to 2.6. For example, we'd typically seen load spikes in the 5-10 range on the webserver under 2.4 kernels, but with 2.6 we rarely see above 1, even including during the traffic spikes mentioned above. Obviously this is very anecdotal, but it suggests that if you're strongly interested in maximizing performance you may get more bang-for-the-buck to focus on getting a good kernel. (Btw, we've also encountered a few stability issues with the kernel on our webserver, so if you're in a high availability situation you may want to hold off a bit for 2.6 to mature.) Bryce ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
[Templates] Announce: Cvs-Brancher 1.00
Static websites have a number of advantages over dynamically built sites, but one of the disadvantages is being able to schedule deployment of new content at arbitrary times. Cvs-Brancher is designed to address this issue by making it straightforward to branch a CVS tree and schedule a merge and rebuild using 'at'. http://freshmeat.net/projects/cvsbrancher/ An example for use of this is for posting press releases and other assorted website changes at 5am west coast time, to co-incide with start of business east coast time. This was the primary motivation for writing it. The advantage of doing a branch/merge is that regular maintenance can go on while the scheduled release is assembled and tested. Cvs-Brancher provides options to control what actions it should take in case of merge errors. While intended for CVS-based websites that use a build tool such as ttree, it is implemented generically and may have non-web uses, such as deploying cfengine-based system config changes, etc. Bryce ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
RE: [Templates] tt annoyances
4. Common string functions are available in counter-intuitive ways.
The builtin scalar string supports: length, repeat, replace, match, search,
split, chunk. Now, suppose I want the equivalent of the perl functions substr,
uc, and index. Where do I find them? Well, substr is available by using the
String plugin, which has no relation to a builtin scalar string:
One thing I do around any template perl wrapper code is add a few stash
methods for my own sanity. Eg:
$Template::Stash::SCALAR_OPS-{ lc } = sub { lc shift };
$Template::Stash::SCALAR_OPS-{ uc } = sub { uc shift };
$Template::Stash::SCALAR_OPS-{ lcfirst } = sub { lcfirst shift };
$Template::Stash::SCALAR_OPS-{ ucfirst } = sub { ucfirst shift };
This allows me to use [% str.uc %] rather than
[% str FILTER upper %]
I also used this as a replacement for substr. It looks odd, but I seemed to
have problems when writing it any other way...
$Template::Stash::SCALAR_OPS-{ substr } = sub {
if (exists $_[3]) {
return substr($_[0], $_[1], $_[2], $_[3]);
} elsif (exists $_[2]) {
return substr($_[0], $_[1], $_[2]);
} elsif (exists $_[1]) {
return substr($_[0], $_[1]);
} else {
return $_[0];
};
};
-Japheth J.C. Cleaver
___
templates mailing list
[EMAIL PROTECTED]
http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] CGI/TT vs SSI
On Fri, 2003-10-10 at 13:15, David Dyer-Bennet wrote: So unless you *need* minute-by-minute dynamic generation of your site, you win by using a build-time process to produce pages which are then served statically. I think you could make an actual formula for calculating this. Basically, static generation is a win until the amount of time it takes to generate the whole site becomes larger than the amount of time in which the data changes. Then you have to look for alternatives. We had this situation at eToys, when it started taking hours to generate the hundreds of thousands of pages on the site and we needed them to update within an hour or so. We were already pushing our luck by using SSI (thorugh mod_perl of course) in the generated pages for up-to-the-minute stock level data, so finally we changed our approach to generating pages on demand and then caching them. This worked great for us, since only a small percentage of our pages were actually viewed in any given hour. So, the other factor is knowing what percentage of pages get viewed. - Perrin ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] CGI/TT vs SSI
Perrin Harkins [EMAIL PROTECTED] writes: On Fri, 2003-10-10 at 13:15, David Dyer-Bennet wrote: So unless you *need* minute-by-minute dynamic generation of your site, you win by using a build-time process to produce pages which are then served statically. I think you could make an actual formula for calculating this. Basically, static generation is a win until the amount of time it takes to generate the whole site becomes larger than the amount of time in which the data changes. Then you have to look for alternatives. We had this situation at eToys, when it started taking hours to generate the hundreds of thousands of pages on the site and we needed them to update within an hour or so. We were already pushing our luck by using SSI (thorugh mod_perl of course) in the generated pages for up-to-the-minute stock level data, so finally we changed our approach to generating pages on demand and then caching them. This worked great for us, since only a small percentage of our pages were actually viewed in any given hour. So, the other factor is knowing what percentage of pages get viewed. Yes, percentage of possible pages viewed is a factor that doesn't get thought about often enough; especially for large dynamic sites. I'd imagine Advanced Book Exchange, for example, actually shows a very small proportion of their pages any given day. Probably the same for Ebay. I must have had that idea in the back of my head (even though I didn't articulate it) since it would never have occurred to me to make an Ebay-type site out of static pages generated from templates. I probably wouldn't have tried it for eToys, either, but it sounds like it served you well for quite a while. -- David Dyer-Bennet, [EMAIL PROTECTED], www.dd-b.net/dd-b/ RKBA: noguns-nomoney.com www.dd-b.net/carry/ Photos: dd-b.lighthunters.net Snapshots: www.dd-b.net/dd-b/SnapshotAlbum/ Dragaera mailing lists: dragaera.info/ ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] tt annoyances
Mark Mills [EMAIL PROTECTED] writes: Yeah, when I was looking at TT before starting to use it fro the current project, I was struck by the amount of programming language already being added. What struck *me* was that I'd rather have perl than some new special programming language, actually. Or PHP, if I have to. :-) The problem with in-line perl or PHP is that you often wind up wanting to seperate the display level code from the data generation code and you are right back to wanting a template system. If you think I'm kidding look at how many PHP projects there are that implement templates... http://smarty.php.net/ is the biggest that I know of but there are plenty more. Yes, that's really true. But I think I actually want *the same* programming environment for each, really; I think what I really want is for the distinction between form and content to be a completely human-decided distinction. Actually, for niceness of environment, what I really like is HTML::Mason, but I hear it takes some, um, care, to make busy sites not beat the CPU to death, and it's not really very friendly to a virtual-server environment. -- David Dyer-Bennet, [EMAIL PROTECTED], www.dd-b.net/dd-b/ RKBA: noguns-nomoney.com www.dd-b.net/carry/ Photos: dd-b.lighthunters.net Snapshots: www.dd-b.net/dd-b/SnapshotAlbum/ Dragaera mailing lists: dragaera.info/ ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] CGI/TT vs SSI
On Fri, 2003-10-10 at 14:45, David Dyer-Bennet wrote: I probably wouldn't have tried it for eToys, either, but it sounds like it served you well for quite a while. Yes, what happened was that the number of products (and thus the number of pages) more than doubled in a short period of time, and crushed the existing system which had worked really well when the database was small. That's when we changed it to generate-on-demand. - Perrin ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] tt annoyances
On Fri, Oct 10, 2003 at 01:49:00PM -0500, David Dyer-Bennet wrote: [...] I think I actually want *the same* programming environment for each, really; I think what I really want is for the distinction between form and content to be a completely human-decided distinction. I have to disagree here. If I wanted that, I'd write pages in straight Perl -- factored to separate business logic from presentation, of course, but both halves done in the same language. What brought me to TT in the first place was the customer's requirement: no programming in the templates! We've snuck a little in -- simple foreachs for presenting lists, and an if or two -- and the customer has adapted well. But if I'd tried to tell them to deal with Perl's $, @, % prefixes, and the difference between hash members and object methods, and all that programming stuff, it would have been a complete non-starter. That TT abstracts all of that away, letting me deal with it so that the template writer doesn't have to, is for me the whole point. Sure, I could make great use of a richer templating environment -- but then I'm a computer geek. If the cost of that richness is making TT useless to non-programmers, I'd *much* rather live without it. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] tt annoyances
Andy Wardley wrote:
Keep in mind this is with the best of intentions;
Understood. For what it's worth, your critiscism is both constructive
and fair, and I'm glad that you took the time to do it.
And I'm glad to see that Buddha is not a Buddhist, as it were.
One of the detractors from some mini-language template systems
is the mailing list vitriol that ensues when someone
suggests features.
For example, in one well-known such java-based system,
if you want to add integers, that is fine, but if
you want to add floating point numbers, then you are a benighted
fool who doesn't understand presentation abstraction and the MVC
paradigm.
btw, I just discovered that while this works:
[% people.exists('noone')%]
for simple hashes when 'noone' is not a member and DEBUG=undef,
it does not work with tied hashes in the same circumstance.
For tied hashes, you get the usual fatal undef error.
At least, for the DBI plugin. There are too many layers involved
for me to quickly surmise why this might be.
-mda
___
templates mailing list
[EMAIL PROTECTED]
http://lists.template-toolkit.org/mailman/listinfo/templates
[Templates] patches for some better diagnostics
ok, it isn't pretty, but i've beaten TT into spitting out context
information for undef errors, as well as spitting out trace information
to the console.
First off, an unrelated patch to ttree to give better startup
failure handling:
my $template = Template-new($ttopts);
+ use Data::Dumper;
+ print STDERR Template-new returned false value with options: , Dumper($ttopts)
unless $template;
+ die Template::ERROR is: $Template::ERROR unless $template;
We add debug_format support to ttree:
'template_debug|debug=s',
+ 'template_debug_format|debug_format=s',
At the top of Template/Context.pm, we introduce a new global $LAST_LINE
and we trap die:
!use vars qw( $VERSION $DEBUG $AUTOLOAD $DEBUG_FORMAT);
+use vars qw( $VERSION $DEBUG $AUTOLOAD $DEBUG_FORMAT $LAST_LINE);
use base qw( Template::Base );
use Template::Base;
use Template::Config;
use Template::Constants;
use Template::Exception;
$VERSION = sprintf(%d.%02d, q$Revision: 2.81 $ =~ /(\d+)\.(\d+)/);
$DEBUG_FORMAT = \n## \$file line \$line : [% \$text %] ##\n;
+$LAST_LINE = undef;
+
+$SIG{__DIE__} = sub {
+die @_ if !$LAST_LINE || $_[0] =~ m/At /;
+die 'At ', $LAST_LINE-{file}, ':', $LAST_LINE-{line}, ' token |',
$LAST_LINE-{text}, '|: ', @_;
+};
Then later in Template/Context.pm in the function debugging we:
- always set $LAST_LINE
- make sure that there isn't a two-character \n in the format string
- support for a stdout: prefix found in the value of DEBUG_FORMAT,
to print immediately instead of returning the value (and fouling up the template).
(You'll need to diff yourself; sorry)
sub debugging {
my $self = shift;
my $hash = ref $_[-1] eq 'HASH' ? pop : { };
$LAST_LINE = $hash;
my @args = @_;
# print *** debug(@args)\n;
if (@args) {
if ($args[0] =~ /^on|1$/i) {
$self-{ DEBUG_DIRS } = 1;
shift(@args);
}
elsif ($args[0] =~ /^off|0$/i) {
$self-{ DEBUG_DIRS } = 0;
shift(@args);
}
}
if (@args) {
if ($args[0] =~ /^msg$/i) {
return unless $self-{ DEBUG_DIRS };
my $format = $self-{ DEBUG_FORMAT };
# interpolate EOL in format
$format =~ s/\\n/\n/g;
$format = $DEBUG_FORMAT unless defined $format;
$format =~ s/\$(\w+)/$hash-{ $1 }/ge;
if ($format =~ m/stdout:(.*)/s) {
print STDOUT $1;
return '';
}
return $format;
}
elsif ($args[0] =~ /^format$/i) {
$self-{ DEBUG_FORMAT } = $args[1];
}
# else ignore
}
return '';
}
Ok, now the coup de grace...
If my ttree rc file has:
template_debug = undef,dirs
template_debug_format = stdout:DEBUG: $file:$line : |$text|\n
Then it will spit out lines to the console as it executes, like:
...
DEBUG: header.inc:100 : IF (level == 1)
DEBUG: header.inc:101 : IF (item.relurl)
DEBUG: header.inc:101 : downdir
...
And when/if there is an undef error you'll get a line like:
! undef error - At header.inc:17 token |foobar|: foobar is undefined
If you want just the context tracking in undef errors without the debug output,
then set:
template_debug = undef,dirs
template_debug_format = stdout:
-mda
___
templates mailing list
[EMAIL PROTECTED]
http://lists.template-toolkit.org/mailman/listinfo/templates
Re: [Templates] patches for some better diagnostics
# interpolate EOL in format $format =~ s/\\n/\n/g; $format = $DEBUG_FORMAT unless defined $format; Should be this order to avoid undef warning (ironically enough): $format = $DEBUG_FORMAT unless defined $format; # interpolate EOL in format $format =~ s/\\n/\n/g; -mda ___ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
