Thread: [htmltmpl] error : attempt to set parameter 'todayissues' with an array ref - parameter is not a TM
Brought to you by:
samtregar
From: paul P. <pau...@fr...> - 2003-06-25 15:04:05
|
I have the following error that I don't understand : attempt to set parameter 'todayissues' with an array ref - parameter is=20 not a TMPL_LOOP! at=20 /home/httpd/html/koha.dev/cgi-bin/koha/circ/circulation.pl line 291 2 things are strange : * it works fine with DB A, it shows an error with DB B * the @realtodayissues is EMPTY on both tests. my @realtodayissues; ... (something not related to realtodayissues $template->param( findborrower =3D> $findborrower, borrower =3D> $borrower, borrowernumber =3D> $borrowernumber, branch =3D> $branch, printer =3D> $printer, branchname =3D> $branches->{$branch}->{'branchname'}, printername =3D> $printers->{$printer}->{'printername'}, todayissues =3D> \@realtodayissues, previssues =3D> \@realprevissues, && the template : <TMPL_IF name=3D"todayissues"> <table border=3D1 cellpadding=3D5 cellspacing=3D0 width=3D80%> <tr> <th colspan=3D5 background=3D"<TMPL_VAR=20 name=3D"themelang">/images/background-mem.gif"> <font color=3Dblack> <b>Todays Issues</b></font> </th> </tr> <tr> <th>Due Date</th><th>Bar=20 Code</th><th>Title</th><th>Author</th><th>Class</th> </tr> <TMPL_LOOP name=3D"todayissues"> <tr><td bgcolor=3D<TMPL_VAR NAME=3D"tcolor"> align=3Dcenter><TMPL= _VAR=20 NAME=3D"dd"></td> <td bgcolor=3D<TMPL_VAR NAME=3D"tcolor"> align=3Dcenter> <a href=3D"/cgi-bin/koha/detail.pl?bib=3D<TMPL_VAR=20 NAME=3D"biblionumber">&type=3Dintra" onClick=3D"openWindow(this, 'Item', = 480,=20 640)"><TMPL_VAR NAME=3D"barcode"></a></td> <td bgcolor=3D<TMPL_VAR NAME=3D"tcolor">><TMPL_VAR NAME=3D"title"= ></td> <td bgcolor=3D<TMPL_VAR NAME=3D"tcolor">><TMPL_VAR NAME=3D"author= "></td> <td bgcolor=3D<TMPL_VAR NAME=3D"tcolor"> align=3Dcenter><TMPL_VAR= =20 NAME=3D"dewey"> <TMPL_VAR NAME=3D"subclass"></td></tr> </TMPL_LOOP> </table> </TMPL_IF> Any idea welcomed. --=20 Paul POULAIN Consultant ind=E9pendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org) |
From: <pk...@ei...> - 2003-06-25 15:28:03
|
vexing issue, pl bear with me. I am using a module that allows me to create images (think gd). Typically I write the image to a temp directory, and then include that image in my html template (see example below)... .. in the script .. saveImage($tmpimgname, $tmpimgdir, etc. etc.); $template->param(myimg => $tmpimgname); .. .. and then in the template .. <img src="tmpimgdir/<tmpl_var myimg>"> .. everything works fine. Now here is the problem. In the saveImage method above, if I use undef instead of the $tmpimgname, perl writes the image directly to the web server. This is a great facility because not only do I not have to worry about writing a cronjob to take out the trash in the $tmgimgdir, it is also significantly faster because there is no extra write, read to the disk involved for the image. Except, while using h::t I can't do this. Or, at least I think I can't do this because I can't figure out how to have the template see the stdout. I am shooting in the dark here, and will be posting on the list for the above mentioned module also. I am posting to this list also... if only to find out that what I am wanting can't be done... that would be great to know as well. Many thanks. -- Puneet Kishor |
From: Ron M. <rma...@in...> - 2003-06-25 16:59:25
|
On Wed, Jun 25, 2003 at 08:27:54AM -0700, pk...@ei... wrote: > vexing issue, pl bear with me. > > I am using a module that allows me to create images (think gd). > Typically I write the image to a temp directory, and then include that > image in my html template (see example below)... [snip] Well, the way you would accomplish this is break up the creation of the image and the creation of the HTML that includes the image into two separate scripts. Script one uses the H::T template to produce html and sends that to the client with an image tag: <img src="/cgi-bin/script2.cgi">. Script2.cgi uses GD to create an image, sets the Content-type header to image/gif (or whatever is appropriate) and writes the image to stdout (sending the data to the users browser). No temp files to clean up! -- Ron Mahoney Ra Security Systems, Inc. rma...@ra... |
From: Bob H. <bob...@ad...> - 2003-06-27 00:15:09
|
Is the INCLUDE option supposed to retain formatting? Or does it just "dump" the contents? |
From: Vince V. <vi...@ly...> - 2003-06-27 08:07:18
|
Hello all, this is not an exclusive html-template question but html-template uses carp::croak() too... A module similar to H::T croaks and therefore the script using this module ist stopped to immediately. A Message goes to stdoud and the script stops. I am unable to start my own error routines what I'd really like to do. Is there a way to catch the "die" that carp::croak calls? Best regards, Vince mailto:vi...@ly... |
From: Chris R. <ct...@dy...> - 2003-06-27 08:52:40
|
On Fri, 27 Jun 2003, Vince Veggus wrote: [snip] > Is there a way to catch the "die" that carp::croak calls? eval { ...code that dies... }; if ($@) { # There was an error in the eval {} } -- Chris Reinhardt ct...@dy... Systems Architect Dynamic DNS Network Services http://www.dyndns.org/ |
From: Vince V. <vi...@ly...> - 2003-06-27 08:58:57
|
Hello Chris, thanks - works fine! Best regards, Vince mailto:vi...@ly... ----- Friday, June 27, 2003, 10:52:23 AM, you wrote: CR> [snip] >> Is there a way to catch the "die" that carp::croak calls? CR> eval { ...code that dies... }; CR> if ($@) { CR> # There was an error in the eval {} CR> } |
From: Chisel W. <ch...@he...> - 2003-06-27 10:05:23
|
On Fri, Jun 27, 2003 at 04:52:23AM -0400, Chris Reinhardt wrote: > eval { ...code that dies... }; > if ($@) { > # There was an error in the eval {} > } I've always been uncomfortable using eval(). I know /how/ to use it, but it just feels dirty. What are the negative effects (if any) of using eval()? I'm curious why the call to H::T->new() has to die, and not just return undef.. I'd love to be able to do something along the lines of: my $ht = HTML::Template->new(...) or my_error_handling_routine(...); instead of: eval ( $ht = HTML::Template->new(...); ); Chisel -- e: ch...@he... | They asked how many employees we had, w: www.herlpacker.co.uk | broken down by sex. Told them drugs gpg: D167E7FE | and alcohol was more of a problem. |
From: Cory T. <ct...@on...> - 2003-06-27 12:02:56
|
Hello, a suggestion: Wrap your calls in 'load_tmpl( )' and then do my $ht = $self->load_tmpl(...) or my_error_handling_routine(...); Use the eval call in load_tmpl( ) to determine if you return false or true. Just the way I would do it ... Sincerely, Cory Trese Lead Web Application Developer O'NEIL & ASSOCIATES, INC. 495 Byers Rd. Miamisburg, Ohio 45342-3662 Phone: (937) 865-0846 ext. 3038 Fax: (937) 865-5858 E-mail: [ct...@on...] -----Original Message----- From: htm...@li... [mailto:htm...@li...] On Behalf Of Chisel Wright Sent: Friday, June 27, 2003 5:51 AM To: HTML::Template List Subject: Re: [htmltmpl] catch the carp::croak() death... On Fri, Jun 27, 2003 at 04:52:23AM -0400, Chris Reinhardt wrote: > eval { ...code that dies... }; > if ($@) { > # There was an error in the eval {} > } I've always been uncomfortable using eval(). I know /how/ to use it, but it just feels dirty. What are the negative effects (if any) of using eval()? I'm curious why the call to H::T->new() has to die, and not just return undef.. I'd love to be able to do something along the lines of: my $ht = HTML::Template->new(...) or my_error_handling_routine(...); instead of: eval ( $ht = HTML::Template->new(...); ); Chisel -- e: ch...@he... | They asked how many employees we had, w: www.herlpacker.co.uk | broken down by sex. Told them drugs gpg: D167E7FE | and alcohol was more of a problem. ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Html-template-users mailing list Htm...@li... https://lists.sourceforge.net/lists/listinfo/html-template-users |
From: Chris D. <Chris.Davies@ManheimEurope.com> - 2003-06-27 12:58:26
|
Chisel Wright [ch...@he...] wrote: > I've always been uncomfortable using eval(). > I know /how/ to use it, but it just feels dirty. > What are the negative effects (if any) of using eval()? Fundamentally here are two different ways of using eval (plus, of course, the option of not using it all - which is preferable in *many* situations): 1. eval "some string expression here" This forces the perl interpreter to evaluate the string expression at run time, each time it occurs, with the fairly obvious penalties for the compilation phase prior to executing the code. You really, really, really, want to avoid this construct if at all possible because of its run time inefficiencies. You would use it whenever you have a perl expression or code block that is created dynamically during the program execution. 2. eval { some code block here } The perl interpreter can evaluate and compile the block of code at program startup time - exactly as it would for any other block of code. This means that the eval doesn't present any significant overhead at run time. Although you should try and avoid using eval when realistically possible, this construct won't present dynamic compilation overhead, so it's actually very efficient. You would use it whenever you have a perl expression or code block that is known and constant. For example, my $template = HTML::Template->new (filename => 'thing.tmpl'); ... my $string = eval { $template->output }; if ($@) { # eval failed... } Regards, Chris |
From: Philip S T. <phi...@gm...> - 2003-06-27 10:02:59
|
On Fri, 27 Jun 2003, Vince Veggus wrote: > Is there a way to catch the "die" that carp::croak calls? perldoc -f eval perldoc -f die -- "I think trash is the most important manifestation of culture we have in my lifetime." - Johnny Legend |