Thread: [htmltmpl] H::T dies with utf8 templates in perl-5.8.0-88
Brought to you by:
samtregar
From: Brandon B. <br...@oj...> - 2003-09-22 16:47:54
|
HTML::Template 2.6 dies with templates stored by Perl as UTF-8 under perl-5.8.0-88 packaged by RedHat. Again, H::T is victim of buggy Unicode. The script below causes HTML::Template to die complaining of invalid template syntax. This occurs on RedHat 8.0 (linux 2.4.18-...) and RedHat 9.0 (linux 2.4.20-...). We've worked around it on both RH8.0 and RH9.0 by downgrading to perl-5.8.0-55. This is similar but not a duplicate of the bug discussed here late in 2002: http://www.mail-archive.com/htm...@li.../msg00330.html So I've already got that patch in place: $which = $1; $which = uc($which); ####### reproduce the bug ####### #!/usr/local/bin/perl -w use strict; use HTML::Template; my $template = q(<html>).chr(560).q(<TMPL_VAR NAME=foo></html>); my $ht = HTML::Template->new(scalarRef=>\$template); print "ok 1\n"; ##Another way to get it to die by making sure it's in memory as utf8. #use Encode; #my $template2 = q(<html><TMPL_VAR NAME=foo></html>); #my $decoded2 = Encode::decode('iso-8859-1', $template2); #my $ht2 = HTML::Template->new(scalarRef=>\$decoded2); #print "ok 2\n"; ####### /reproduce the bug ####### Where else can I report this bug? Not to bugzilla.redhat.com because RedHat does not package HTML::Template, right? What about the perl-porters? The script to reproduce the bug causes this die: HTML::Template->new() : Syntax error in <TMPL_*> tag at /fake/path/for/non/file/template : 1. at /usr/lib/perl5/site_perl/5.8.0/HTML/Template.pm line 2243. It's not just H::T that has trouble with RedHat perl-5.8.0-88: http://www.livejournal.com/users/jwz/257602.html http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102106 Thanks in advance for any help, Bryan Cribbs and Brandon Bowersox (br...@oj...) |
From: Sam T. <sa...@tr...> - 2003-09-22 19:39:11
|
On Mon, 22 Sep 2003, Brandon Bowersox wrote: > HTML::Template 2.6 dies with templates stored by Perl as UTF-8 under > perl-5.8.0-88 packaged by RedHat. Again, H::T is victim of buggy Unicode. Don't bother trying to fix HTML::Template, Perl 5.8 is broken by Redhat 8 and 9's default locale settings. Here's the Redhat bug for it: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87682 One workaround is noted "export LANG=en_US" and I happen to know editing /etc/sysconfig/i18n works just as well. -sam |
From: Puneet K. <pk...@ei...> - 2003-09-28 00:15:04
|
So I am working with frames (I have to). Different scripts populate different templates in different frames -- at different times. Now I want to press one button in one frame, and update two (or more) frames with respectively different templates. I have -- frame1.cgi --> frame1.tmpl --> frame1 frame2.cgi --> frame2.tmpl --> frame2 frame3.cgi --> frame3.tmpl --> frame3 frame4.cgi --> frame4.tmpl --> frame4 I want to do -- frame1 frame2 frame3 --> frame3.cgi --> frame3.tmpl --> frame3 | frame4 |-> frame4.tmpl --> frame4 Needless to say... there is stuff in frame3.cgi that is powering stuff in frame3.tmpl as well as in frame4.tmpl. ( I am clicking on a map in one frame which is causing features to be selected and the map to be redrawn with the selection visible. At the same time, I want to query the underlying database for the selected features and display them in another frame. ) How do I do this? |
From: Karen J. C. <si...@ph...> - 2003-09-28 01:41:13
|
On Sat, 27 Sep 2003, Puneet Kishor wrote: PK>So I am working with frames (I have to). Different scripts populate PK>different templates in different frames -- at different times. Now I PK>want to press one button in one frame, and update two (or more) frames PK>with respectively different templates. Only way I know of to do that is with Javascript and putting an onclick either in the FORM or in the A link (depending on whether your "button" is a submit button or just a link button). Here's one explanation: http://www.experts-exchange.com/Web/Web_Languages/HTML/Q_20737567.html (The problem is, of course, those of us who use non-Javascript browsers will only get one frame updated. Of course, my non-JS browser is also a non-framed browser, so I suppose it's a moot point...) -- Karen J. Cravens si...@ph... |
From: Puneet K. <pk...@ei...> - 2003-09-28 02:16:18
|
On Saturday, September 27, 2003, at 08:03 PM, Karen J. Cravens wrote: > On Sat, 27 Sep 2003, Puneet Kishor wrote: > > PK>So I am working with frames (I have to). Different scripts populate > PK>different templates in different frames -- at different times. Now I > PK>want to press one button in one frame, and update two (or more) > frames > PK>with respectively different templates. > > Only way I know of to do that is with Javascript and putting an onclick > either in the FORM or in the A link (depending on whether your "button" > is a submit button or just a link button). > ya but... see, the problem is not really being able to fire two frames (yes, js is the solution)... the problem is firing them from one perl script calculating/creating values that have to be displayed in two frames... as I understand... one script usually has one template associated with it (although it could have more templates... there is nothing in the docs that says it can't). What I cannot to is fire two scripts... because all the relevant calculations are in one script... I just want to take the results and divvy them up into two frames. this may well prove my undoing. |
From: Karen J. C. <si...@ph...> - 2003-09-28 14:06:40
|
On Sat, 27 Sep 2003, Puneet Kishor wrote: PK>see, the problem is not really being able to fire two frames (yes, js PK>is the solution)... the problem is firing them from one perl script PK>calculating/creating values that have to be displayed in two frames... PK>as I understand... one script usually has one template associated with PK>it (although it could have more templates... there is nothing in the PK>docs that says it can't). What I cannot to is fire two scripts... PK>because all the relevant calculations are in one script... I just want PK>to take the results and divvy them up into two frames. Ah. It's still sort of do-able, depending on your reason for frames. If they're just there to, say, provide scrollbars and you don't mind refreshing the whole page, you can do something like this: Button launches script into _top. Script builds all the frames, writes them out (either as complete HTML files or as parms to be stuffed in H::T later) to something persistent, then returns the top-level HTML to the browser. That top-level HTML either refers to files that were just written, or to a subsidiary script that just populates templates. (In the former case, you have to worry about expiring old files and handling 404's; in the latter you just have to worry about expiring old data, and the subsidiary script can gracefully handle references to data it can't find.) It's not quite as pretty as just refreshing two frames, but I can't think of any other way to do it. Depending on the structure of your page, you might be able to make the frames that need refreshed a nested framed page, though. -- Karen J. Cravens si...@ph... |
From: Puneet K. <pk...@ei...> - 2003-09-29 00:35:17
|
On Sunday, September 28, 2003, at 08:49 AM, Karen J. Cravens wrote: > .. > > It's still sort of do-able, depending on your reason for frames. If > they're just there to, say, provide scrollbars and you don't mind > refreshing the whole page, you can do something like this: > .. On Sunday, September 28, 2003, at 02:49 PM, Erik wrote: > .. > > This is a little off-HTML::Template topic but I might propose another > solution. > .. Thanks for the replies folks. Really appreciate it. However, I _need_ to use frames because... well, I need to. I am not a big fan of frames, and know most all the ways to avoid them (or fake them... overflow:auto is great). However, I also believe that frames can be immensely useful in certain situations, and this is one of 'em. POST requests usually cache-out, and db queries are expensive. In this application, frames not only simplify navigation, they also minimize user-webserver as well as webserver-dbserver traffic. As I described earlier, I have four frames like so (we can forget about the header frame) -- header.cgi --> header.tmpl --> frame: header map.cgi --> map.tmpl --> frame: map table.cgi --> table.tmpl --> frame: table tabledetail.cgi --> tabledetail.tmpl --> frame: tabledetail clicking on the map (in the map frame, obviously), causes map.cgi to select certain features in the map and redraw the map with those features selected. Those features are also connected to a dbf file (and later on, to a real table in MySQL). Hence, the dbf rows are also selected. However, the map gets redrawn via the map.tmpl in the map frame, while the dbf rows need to be shown in the table frame. The way I am doing it right now is that I show the map in the map frame, and then a form button with a lame message such as "12 features selected -- press button to view them". Pressing the button calls table.cgi with target="table", and the dbf rows are displayed in the table frame. Then clicking on any single row shows its details in the tabledetail frame. Ideally, I would like map.cgi to select the features in the map, redraw the map, and send the map to the map frame, and the dbf rows to the table frame. In case the table frame or the tabledetail frame have query results from a previous call, I would also like to send a blank.html to them, etc. Drawing the map and querying the dbf file (or the MySQL table, later on) is a fairly expensive proposition (esp drawing the map), so frames allow me to have the user navigate only parts of the application desktop without refreshing things unnecessarily. Would be nice if I could somehow tell a template to go to a specific frame, of course, filling a frame is a pulling action, so there is no way to send a template to a specific frame. I am coming to the conclusion that I cannot do what I want, and will have to devise some other approach to this app. Puneet. |
From: Erik <er...@ne...> - 2003-09-29 05:12:58
|
Puneet Kishor has written: > header.cgi --> header.tmpl --> frame: header > map.cgi --> map.tmpl --> frame: map > table.cgi --> table.tmpl --> frame: table > tabledetail.cgi --> tabledetail.tmpl --> frame: tabledetail > > clicking on the map (in the map frame, obviously), causes map.cgi to > select certain features in the map and redraw the map with those > features selected. Those features are also connected to a dbf file (and > later on, to a real table in MySQL). Hence, the dbf rows are also > selected. However, the map gets redrawn via the map.tmpl in the map > frame, while the dbf rows need to be shown in the table frame. The way > I am doing it right now is that I show the map in the map frame, and > then a form button with a lame message such as "12 features selected -- > press button to view them". Pressing the button calls table.cgi with > target="table", and the dbf rows are displayed in the table frame. Then > clicking on any single row shows its details in the tabledetail frame. If I understand this right ... I click a link in "map", it changes both "map" and "table" and blanks out "tabledetail". If that's right, the following solution will work for you. 1.) In your map frame, create your links like this: <a href="table.cgi" onClick="window.self.location='map.cgi'" target="table"> My Map Link </a> Note the the HREF fills the "table" frame and the onClick fills the current frame. 2.) In the SRC of the table.tmpl file, include a lil bit of javascript magic. Something like this (the actual syntax here may be incorrect) top.tabledetail.document = "blank.html"; Put that right after yer script tag, with no subroutine around it so it will fire as soon as the browser reads it. And you're done. - Erik |