RE: templating system opinions (axkit?)
On Wed, 23 Jul 2003, Hauck, William B. wrote: What i've done is just use completely external html files with html-compliant comments indicating the data field. (example !-- APPNAME_USER_FIRST_NAME --). My application just reads in the html on startup and does a series of substition statements over the file as necessary to replace the comments with the actual data. Thus, each type of page has one base html (or html file pieces) that are merged with each other and data as necessary allowing all logic to be kept in the program. Change that to: !-- TMPL_VAR APPNAME_USER_FIRST_NAME -- and you can use HTML::Template! You'll also get loops, includes, and simple conditionals should you ever need them. -sam
Re: templating system opinions
On Sun, 20 Jul 2003, Dave Rolsky wrote: OTOH, if you were to try to replicate some of Mason's more powerful features with H::T, like autohandlers, inheritance, etc., then I'm sure that'd bring H::T's speed down to Mason's level ;) I wouldn't be too sure. I implemented a lot of that stuff to add HTML::Template support to Bricolage and it's still much faster than Mason. In other words, you generally get what you pay for. The most powerful and flexible systems are generally slower and more RAM-hungry. One exception to this might be Embperl, which has large chunks written in C. In that case, the cost is paid for in development time. HTML::Template::JIT also trades development time (mine) for run-time speed. Right now it doesn't support all of HTML::Template's functionality, but it comes pretty close. The upside is that it's between four and eight times faster than HTML::Template, which makes it the fastest templating system by a large margin. -sam
Re: templating system opinions
On Mon, 21 Jul 2003, Dave Rolsky wrote: On Mon, 21 Jul 2003, Sam Tregar wrote: I wouldn't be too sure. I implemented a lot of that stuff to add HTML::Template support to Bricolage and it's still much faster than Mason. A lot as in _all_ of it, or a lot as in autohandlers and dhandlers? A lot as in everything that was needed to get HTML::Template to fill the role of Mason in Bricolage's publish process. I'd certainly be a fool to claim I'd implemented all of Mason! I doubt I could even list all the stuff that Mason does. In other words, I don't think one could do all of the same stuff, or even most, and achieve a huge speed increase. There would have to be something sacrificed. My impression is that Mason doesn't get much advantage from clients that only use part of the Mason system. I imagine that one of the reasons that the Mason workalike I built for Bricolage is faster than Mason is that it only implements the functionality actually needed by Bricolage. Following this line of thinking it might be possible to modify Mason to only use/load the slower/bigger pieces when they are actually needed. Of course, I'm no authority on why Mason is slow or how it could be fixed. I have plans to go a similar route with HTML::Template in the future. I'd like to build a system that dynamically assembles itself based on the usage pattern of the program. That way if the programmer sticks to the basics they get a smaller, faster system. If they need the big guns then the more complete systems can be loaded at some moderate penalty. -sam
ANNOUNCEMENT: HTML::Template 2.6
CHANGES - New Feature: HTML::Template will combine HTML_TEMPLATE_ROOT environment variable and path option if both are available. (Jesse Erlbaum) - New Feature: __counter__ variable now available when loop_context_vars is set (Simran Gambhir) - New Feature: The default attribute allows you to specify defaults for tmpl_var tags. - Bug Fix: fixed parser to reject tmpl_vars with no names. (crazyinsomniac) - Doc Fix: fixed documentation to correctly describe the interaction of case_sensitive and loop_context_vars. (Peter Claus Lamprecht) - Doc Fix: updated mailing-list information to reflect move from vm.com to sourceforge.net DESCRIPTION This module attempts to make using HTML templates simple and natural. It extends standard HTML with a few new HTML-esque tags - TMPL_VAR, TMPL_LOOP, TMPL_INCLUDE, TMPL_IF, TMPL_ELSE and TMPL_UNLESS. The file written with HTML and these new tags is called a template. It is usually saved separate from your script - possibly even created by someone else! Using this module you fill in the values for the variables, loops and branches declared in the template. This allows you to separate design - the HTML - from the data, which you generate in the Perl script. This module is licensed under the GPL. See the LICENSE section below for more details. TUTORIAL If you're new to HTML::Template, I suggest you start with the introductory article available on the HTML::Template website: http://html-template.sourceforge.net AVAILABILITY This module is available on SourceForge. Download it at: http://html-template.sourceforge.net The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]). You can join the HTML::Template mailing-list by visiting: http://lists.sourceforge.net/lists/listinfo/html-template-users
ANNOUNCEMENT: HTML::Template::JIT 0.04
CHANGES - Added support for HTML::Template 2.6's new DEFAULT attribute. - Added support for HTML::Template 2.6's new __counter__ variable. - Updated mailing-list information to reflect move from vm.com to sourceforge.net - Fixed bug where tmpl_var's with the escape attribute would cause a crash if not set with a value. DESCRIPTION This module provides a just-in-time compiler for HTML::Template. Templates are compiled into native machine code using Inline::C. The compiled code is then stored to disk and reused on subsequent calls. HTML::Template::JIT is up to 8 times as fast as HTML::Template using caching. NOTE This module is not feature-complete. Be sure to read the CAVEATS section in the documentation before using! AVAILABILITY This module is available on SourceForge. Download it at: http://html-template.sourceforge.net The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]). You can join the HTML::Template mailing-list by visiting: http://lists.sourceforge.net/lists/listinfo/html-template-users
ANNOUNCEMENT: HTML::Template::Expr 0.04
CHANGES - Fixed parser to recognize negative numbers. Thanks to Fran Fabrizio for the report. - Fixed parser to allow for HTML-comment style tags. Thanks to Stuhlpfarrer Gerhard for the spot. - Updated mailing-list information to reflect move from vm.com to sourceforge.net DESCRIPTION This module provides an extension to HTML::Template which allows expressions in the template syntax. This is purely an addition - all the normal HTML::Template options, syntax and behaviors will still work. Expression support includes comparisons, math operations, string operations and a mechanism to allow you add your own functions at runtime. AVAILABILITY This module is available on SourceForge. Download it at: http://html-template.sourceforge.net The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]). You can join the HTML::Template mailing-list by visiting: http://lists.sourceforge.net/lists/listinfo/html-template-users
Re: HTML::Template
On Mon, 19 Aug 2002, Pierre Vaudrey wrote: with the following starnge error (The Title is displayed but not the vignette.gif file) [Mon Aug 19 07:22:24 2002] [error] Missing right curly or square bracket at /Library/WebServer/Documents/perl/vignette.gif line 1, at end of line syntax error at /Library/WebServer/Documents/perl/vignette.gif line 1, at EOF For some reason vingette.gif is being interpreted as a Perl script instead of an image. This is probably a case of a misconfigured web server, although I don't know enough about your setup to be sure. What happens if you try to load this image separate from HTML::Template, just by typing the URL into your browser? -sam
Re: Static vs. DSO on Linux specifically
On Tue, 23 Jul 2002, WC -Sx- Jones wrote: Back in RH 6.2 I would hazard that the segfault was more related to Perl being set to uselargefiles and Apache NOT being set. This only became visible when one tried to build mod_perl as a DSO. Building as STATIC caused Apache to be rebuilt using the now current uselargefiles setting. I don't think so. Rebuilding Apache/mod_perl static with the exact same Perl that shipped with Redhat 6.2 solved the segfaults. Perhaps it is a problem in Perl, I wouldn't know, but I guarantee it wasn't a result of using a different Perl. -sam
Re: Static vs. DSO on Linux specifically
On 22 Jul 2002, David Dyer-Bennet wrote: So, specifically for the Linux environment, what are the downsides of running mod_perl as a DSO? (Pointers to the FM so I can R it would be fine.) Segmentation faults, pure and simple. The Apache/mod_perl that ships with Redhat, and I assume other DSO Apache/mod_perl setups, is unstable. Here's one place I've seen this mentioned: http://masonhq.com/docs/faq/#why_am_i_getting_segmentation_fa -sam
Re: CGI::Application
On Sun, 16 Jun 2002, Eric Frazier wrote: I have been looking into HTML::Template which is a lot simper than Embed perl or the template tool kit. I am wondering if anyone has experence with using both of these with Registry.pm I do! Back when I worked for Jesse Erlbaum (the author of CGI::Application) most of our development was in CGIs designed to be run under Apache::Registry. CGI::Application uses CGI.pm for all its CGI services and CGI.pm works great under Apache::Registry. The big points I want to achieve right now, is to make everything I write OOP, separate HTML from code as much as possible, and to not make it impossible to deal with for the people I work with who don't know as much perl as I do. That sounds like an excelent goal. Feel free to drop by the CGI::Application (and HTML::Template) mailing-list if you run into trouble. -sam
[ANNOUNCE] HTML::Template::JIT 0.03
HTML::Template::JIT - a just-in-time compiler for HTML::Template CHANGES - Added support for case_sensitive option to new(). - Added new print_to_stdout option to new() to have output printed to STDOUT as it is generated. - Added support for ESCAPE. Template syntax support is now complete - Improved the quality of generated code - variables are now looked-up once and stored in lexical variables. This has improved performance a small amount. - Fixed bug in escaping of template text. This caused templates containing the characters any of ($, @, %, \) to be rendered incorrectly. Thanks to Smejkal Petr for the report. - Fixed bug where parameters from previous runs were persisting across calls to new(). Thanks to Tugrul Galatali for the spot. - Arguments to new() that modify the compiled object are now included in hashing to create package names. This means that a single template can be used with different options and different compiled objects will be generated. Thanks to Tugrul Galatali for the spot. DESCRIPTION This module provides a just-in-time compiler for HTML::Template. Templates are compiled into native machine code using Inline::C. The compiled code is then stored to disk and reused on subsequent calls. HTML::Template::JIT is up to 8 times as fast as HTML::Template using caching. NOTE This module is not feature-complete. Be sure to read the CAVEATS section in the documentation before using! AVAILABILITY This module is available on SourceForge. Download it at: http://prdownloads.sf.net/html-template/HTML-Template-JIT-0.03.tar.gz?download The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
Re: Logging under CGI
On Mon, 10 Jun 2002, Bill Moseley wrote: You are correct to worry. You should use flock() to prevent your log file from becoming corrupted. See perldoc -f flock() for more details. Maybe it's a matter of volume. Or size of string written to the log. But I don't flock, and I keep the log file open between requests and only reopen if stat() shows that the file was renamed. So far been lucky. Nope, just plain luck. Keep it running long enough without locking and you will eventually have a corrupted log file. -sam
Re: Logging under CGI
On Mon, 10 Jun 2002, Tom Brown wrote: ?? AFAIK, Files opened in append mode, and written to without buffering, should _not_ get corrupted in any manner that flock would prevent. (basically small writes should be atomic.) Right, and does Perl write with buffering when you call print()? Yes, it does! that should be pretty universal for most UNIXs I've actually never heard this before. I've been taught that if you have multiple processes writing to one file you must use flock() or another equivalent mechanism to prevent overwrites. Do you have a source where I could learn about guaranteed atomic file writes without locking under UNIX? -sam
Re: Logging under CGI
On Tue, 11 Jun 2002, Tom Brown wrote: Right, and does Perl write with buffering when you call print()? Yes, it does! huh? That's what $| is all about, and $|++ is a pretty common line of code. A pretty common line of code that wasn't in the example shown! And that only unbuffers the currently selected filehandle. His example showed a print to a named filehandle, so a simple $|++ isn't even enough. Your advice to skip the flock() without explaining any extra steps has a pretty decent chance of resulting in a corrupt logfile given enough time. man(2) open. see the O_APPEND option... the only footnote is that it doesn't work properly via NFS... Interesting stuff. But are you sure it works with Perl? Does it work with PerlIO, which is the new default IO scheme in 5.8.0? p.s. I'm not the only one who considers it impolite to have off-list messages taken back onto the list... I generally don't post AFAIK comments to lists, prefering to keep the signal to noise ratio higher. My apologies. I assumed you omitted the mod_perl address from the CC: by accident. I actually think this discussion is still mostly signal. I would like to make sure your advice is either correct for the situation given or taken back publicly to avoid potential harm. Either outcome would be fine with me, actually. -sam
Re: [OT+RFC] Template.pm-patch
On Tue, 11 Jun 2002, Nico Erfurth wrote:
It changes the way arrays/loops are handled.
1.) If you pass in a array-reference, it will be not dereferenced anymore
I did this, so i can use a small Wrapper-class, which allows me to
tie a database-statement to an array, and returning the results row by
row, so i don't need to waste memory inside of mod_perl(Reading all
results at once).
This is incorrect. People like to do:
my loop = ( { row = 'foo' }, { row = 'bar'} );
$template-param(LOOP_ONE = \@loop);
loop = ( { row = 'bif' }, { row = 'bop'} );
$template-param(LOOP_TWO = \@loop);
If you don't copy out the contents of loop in the first param() call then
you'll end up referencing the same array twice. This was actually a bug
fixed in the early development of HTML::Template.
2.) HTML::Template::Loop::output was changed, so it appends to a given
scalar-reference(the one from HTML::Template::output), this saves much
memory if you have a big loop and combine it with the print_to-option.
That sounds interesting, but have done tests to confirm that it helps? I
suspect that you'd have to choose a truely pathalogical data-set to see
any improvement.
I send this patch to Sam Tregar weeks ago, and i never answered, but maybe
someone here thinks that it's worth to have a look at it, because AFAIK
many ppl use mod_perl+HTML::Template (i do it myself) ;)
Sorry about that! I must have let it fall through the cracks. Did you
send it directly to me or to the HTML::Tempate mailing-list? Things sent
to the mailing-list tend to stay on my radar slightly longer.
-sam
Re: [OT+RFC] Template.pm-patch
On Tue, 11 Jun 2002, Nico Erfurth wrote: I thought about this, and i'm wondering how much ppl realy use it in this way. IMHO it should be a Don't try this, it will break, instead introducing this copy-workaround. But i think i will use this patch only for my private-version, because i don't use such constructs ;) Well, someone used it that way - I got it as a bug-report in an early version of HTML::Template. Maybe we could add an option like no_loop_copy that people could set on to get better performance? I have to print out much lines in a big loop, and these two patches helped me to decrease the memusage from 50MB per instance to 5MB, but i haven`t checked both things seperatly. Well, that does sound significant. Please do determine which change caused this improvement. -sam
[ANNOUNCE] Bricolage 1.3.2
The Bricolage development team is proud to announce the release of Bricolage version 1.3.2. This is a development release with new features as well as numerous bug fixes. Summary of major changes (see the Changes file in the distribution for details): * New installation system tested on Linux and FreeBSD (other systems should work too) * Enhanced system for tracking published status of stories and media * New Check-in Publish feature enables one-click publishing from the story editor * New caching system improves performance throughout the application * Support for Apache::SizeLimit helps keep memory usage under control * New search paging enables Bricolage to work with large data sets * Code and database profilers for performance tuning * Numerous bug fixes, major and minor Here's a brief description of Bricolage: Bricolage is a full-featured, open-source, enterprise-class content management system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming language support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. More information on Bricolage can be found on its home page. http://bricolage.thepirtgroup.com/ And it can be downloaded from SourceForge. http://sourceforge.net/project/showfiles.php?group_id=34789 --The Bricolage Team
Re: Logging under CGI
On Tue, 11 Jun 2002, Sergey Rusakov wrote: open(ERRORLOG, '/var/log/my_log'); print ERRORLOG some text\n; close ERRORLOG; This bit of code runs in every apache child. I worry abount concurent access to this log file under heavy apache load. Is there any problems on my way? You are correct to worry. You should use flock() to prevent your log file from becoming corrupted. See perldoc -f flock() for more details. -sam
Re: Logging under CGI
On Mon, 10 Jun 2002, Sam Tregar wrote: You are correct to worry. You should use flock() to prevent your log file from becoming corrupted. See perldoc -f flock() for more details. Gah, these fingers... That should be perldoc -f flock. -sam
Re: Separating Aspects (Re: separating C from V in MVC)
On Thu, 6 Jun 2002, Perrin Harkins wrote: For posterity, and possible inclusion in the next rev of the templating tutorial, how would you recommend people handle this sort of situation without using HTML::Template::Expr? Suppose you have a model object for a concert which includes a date. On one page, the designers want to dipslay the date in a verbose way with the month spelled out, but on another they want it abbreviated and fixed length so that dates line up nicely. Would you put that formatting in the controller? In the script: $template-param(long_date = $long_date, short_date = $short_date); In the template: The long date: tmpl_var long_date br The short date: tmpl_var short_date What if you had a model object that generates a list of these concerts, and on a certain page the designers want to show it in two columns. Would you split it into two arrays in the controller? I'm not sure I understand what you mean. You're asking about how to flow a list between two columns? With vanilla HTML::Template that would requrie a small amount of work in the script. Either there would need to be a column_break variable thrown in at the appropriate place or two separate loops. I think I would prefer the former. In the template that would look like: tabletr tmpl_loop concerts tmpl_if column_break /trtr /tmpl_if td tmpl_var long_date /td /tmpl_loop /tr/table In the script you'd just set the column_break in the appropriate row (or rows for a multi-column layout). Is that a point in favor of scripting in the templates? Perhaps. Of course by limiting the power of template syntax I've made some things more difficult. If simple things should be simple and hard things should be possible then not everything can be simple! -sam
Re: Separating Aspects (Re: separating C from V in MVC)
On Wed, 5 Jun 2002, Andy Wardley wrote:
In TT, you would usually pre-declare a particular format in a config
file, pre-processed templates, or some other global style document.
e.g.
[% USE money = format('%.02f') %]
In your main page templates you would do something like this:
[% money(order.total) %]
Then you can change the money format in one place and your designers
don't have to worry about sprintf formats.
In HTML::Template::Expr:
sub money { sprintf %.02f, $_[0] }
HTML::Template::Expr-register_function(money = \money);
Then in the template:
tmpl_var expr=money(order_total)
Now, I don't use HTML::Template::Expr. I think it's generally not such a
good idea. But it's there if you want it...
See, the problem is that MVC is just one particular decomposition. It's
generally a good one because application, data and presentation are typically
the three biggest aspects that you want to separate. However, it doesn't
take into account any of the other dozen or so aspects that you might want
to model in your system. Nowhere in MVC or any other Design Pattern does
it tell you to define all your URLs in one place in case you ever need to
change them en masse. You have to think of that all by yourself. MVC is
no substitute for thinking
Oh, absolutely. MVC is just a framework, and it only addresses a subset
of the problems in any large system. I think that's actually a strength.
I would be deeply suspicious of any paradigm that claimed to solve ALL my
problems. I prefer small, simple (tools|paradigms) that do one thing and
do it well.
I've seen far too many example of people who didn't pass objects into their
templates, didn't embed Perl code, or didn't do this or that because they
thought that it might violate the MVC principal.
Here!
The end result was that they jumped through hoops and made the system
more complex than it needed to be for the sake of purity.
It was? I don't think this is the only result. It might be that these
people you've observed were just the hoop-jumping, complexifying types.
I've built quite a number of large systems without embedded Perl and object
variables without excessive hoop-jumping.
Here's my theory: the best usage of most templating systems are virtually
indistinguishable and all result in reasonably maintainable systems.
However, the bad usage of some templating systems is much worse than
others. Also, the general usage of a templating system, even by otherwise
bright people, tends more towards the bad than the good.
Thus my solution: a templating system that simply will not allow you to
put anything significantly complicated in the template. You can't. If
you want complexity you'll just have to put it in the code, where it
belongs. That's HTML::Template in a nutshell.
[% silver.bullet %] isn't the answer by itself...
Here here. Neither is tmpl_var silver_bullet but I'd rather get shot
with mine than yours!
-sam
Re: separating C from V in MVC
On Sat, 1 Jun 2002, Barry Hoggard wrote: I don't think the standard HTML::Template has support for formatting numbers, dates, etc. And thank the sweet lord it doesn't! HTML::Template is a do one thing and do it well module. If you want routines for formatting numbers, dates, etc. then CPAN has just what you need. How do you make sure that it's done consistently in your applications? Code reviews and testing. I don't know of any other way, module support or no module support. It seems problematic to me to require the programmers to do work when a designer wants to change the number of decimals in a page, for example. HTML::Template::Expr may present a solution to this particular desire, although it isn't one I've come across. How often are HTML designers fiddling with numeric formats? Are they really HTML designers if they can deal with, say, a printf-style format string? -sam
Re: PDF generation
On Fri, 19 Apr 2002, Andrew Ho wrote: DWThis looks pretty good to me. Can anyone suggest how I might DWprogrammtically send a PDF to a printer once I've generated it in DWPerl/mod_perl? Use either Ghostscript or Adobe Acrobat Reader to convert to Postscript, then print in your normal manner (if you usually use Ghostscript as a print filter anyway, you can just print directly using it). For Adobe Acrobat Reader, use the -toPostScript option. Use Acrobat Reader if you can. The font support is significantly better in my experience, at least under Linux. -sam
Re: Apache::DProf seg faulting
On Wed, 17 Apr 2002, Paul Lindner wrote: I think that this may be a problem with the use of Perl sections. I believe your original post had something like this: Perl use Apache::DProf use Apache::DB Apache::DB-init(); /Perl Nope. That was Perrin Harkins, but I tried it too! Geoffrey and I tested our environments today and the recipe given in the book seems to work just fine: PerlModule Apache::DB PerlModule Apache::DProf With those lines I get a seg-fault on the first hit to the server. Reversing the lines I can get a few hits before seg-faulting. I doubt it's a problem in your example - something inside Devel::DProf is seg-faulting as far as I can tell. I'm planning to build a debugging Perl and see if I can get more information. But while I have your attention, why are you using Apache::DB at all? The Apache::DProf docs just have: PerlModule Apache::DProf -sam
Re: Sharing Variable Across Apache Children
On Wed, 17 Apr 2002, Perrin Harkins wrote: Benjamin Elbirt wrote: Well, lets assume that I were to go with the shared memory option anyway... what would the pitfalls be / concerns? As mentioned before, you'd probably be better off with MLDBM::Sync or Cache::Cache. You can try IPC::Shareable, but a lot of people seem to have trouble getting it to work. I agree with you 100% - file-based caches are generally as-fast and far easier to manage. Still, I can't resist the urge to plug my IPC::SharedCache module. It's much easier than using IPC::Shareable (or even the better alternative, IPC::ShareLite). -sam
Apache::DProf seg faulting
Hello all. I'm trying to use Apache::DProf but all I get is seg faults. I put these lines in my httpd.conf: PerlModule Apache::DB PerlModule Apache::DProf Then I start the server, and it looks ok: [Tue Apr 16 17:22:12 2002] [notice] Apache/1.3.20 (Unix) mod_perl/1.25 mod_ssl/2.8.4 OpenSSL/0.9.6a configured -- resuming normal operations [Tue Apr 16 17:22:12 2002] [info] Server built: Aug 17 2001 13:29:44 [notice] Apache::DB initialized in child 2234 [notice] Apache::DB initialized in child 2235 I hit the server and I get: [Tue Apr 16 17:22:17 2002] [notice] child pid 2235 exit signal Segmentation fault (11) [notice] Apache::DB initialized in child 2237 Looking in logs/dprof I see a bunch of numeric directories with tmon.out files in them. All the around same size (400 bytes). Any suggestions on how to proceed? -sam
Re: Apache::DProf seg faulting
On 16 Apr 2002, Garth Winter Webb wrote: Sam, try getting rid of the 'PerlModule Apache::DB' line. I've used Apache::DProf w/o any problems by including only the one PerlModule line. Since they both want to use perl debugging hooks, I'm guessing that Apache::DProf is getting crashed up when it tries to use hooks already grabbed by Apache::DB... Same result. Thanks though! -sam
Re: Apache::DProf seg faulting
On Tue, 16 Apr 2002, Sam Tregar wrote: On 16 Apr 2002, Garth Winter Webb wrote: Sam, try getting rid of the 'PerlModule Apache::DB' line. I've used Apache::DProf w/o any problems by including only the one PerlModule line. Since they both want to use perl debugging hooks, I'm guessing that Apache::DProf is getting crashed up when it tries to use hooks already grabbed by Apache::DB... Same result. Thanks though! Aw nuts, that was the problem! I thought I'd tried that already, but I guess not. I actually got those PerlModule lines from the mod_perl Developers Cookbook - guess this is an errata! Thanks! -sam
Re: Apache::DProf seg faulting
On Tue, 16 Apr 2002, Perrin Harkins wrote: Strange, that works for me. I do it like this: Perl use Apache::DProf; use Apache::DB; Apache::DB-init; /Perl That works, but this doesn't: Perl use Apache::DB; use Apache::DProf; Apache::DB-init; /Perl It looks like the poison pill is loading Apache::DB before Apache::DProf. Odd, eh? -sam
ANNOUNCE: Bricolage 1.3.1
The Bricolage development team is proud to announce the release of Bricolage version 1.3.1. This is a development release with new features as well as numerous bug fixes. Summary of major changes (see the Changes file in the distribution for details): * SOAP interface fully implemented * New FTP distribution move method * New preferences to change the way URIs are formatted Here's a brief description of Bricolage: Bricolage is a full-featured, open-source, enterprise-class content management system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming language support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. More information on Bricolage can be found on its home page. http://bricolage.thepirtgroup.com/ And it can be downloaded from SourceForge. http://sourceforge.net/project/showfiles.php?group_id=34789 --The Bricolage Team
Re: [?] Same Named Modules, Different Paths
On Sat, 2 Feb 2002, John Heitmann wrote: Here is what I had to do to force correct module loading (mostly stolen from the great mod_perl guide): %INC = (); # Possibly unnecessary do 'FindBin.pm'; unshift @INC, $FindBin::Bin; # There are also modules in the same dir as the script unshift @INC, $FindBin::Bin/../lib/; require MyModule; import MyModule; This isn't going to work if your modules store anything in package globals. You should probably empty the package stash before you load the new module. That'll also save you subroutine redefined warnings too, I think. One obvious answer is to move the devel tree off of the same server as the release tree. This is undoubtably the best way to go. Any other ideas or places to RTFM? I've sometimes been able to get away with running the live version through Apache::Registry while developing small changes under mod_cgi. Then when the .cgi version is ready I just copy it into the .pl and restart. However, a full staging server is definitely preferable. -sam
Re: [?] Same Named Modules, Different Paths
On Sun, 3 Feb 2002, Stas Bekman wrote: I think the best solution is to run your staging server on a different port and use a front-end proxy to rewrite to the right server based on the Host: name. Alternatively put 2 NICs with 2 IPs, that will work if you don't hardcode the server name in your code/html. Or 1 NIC with 2 IPs if your OS supports it (Linux does). BTW, mod_perl 2.0 solves this problem. How? Is the one global namespace per server changed in 2.0 perhaps? -sam
ANN: HTML::Template 2.5
HTML::Template - a Perl module to use HTML Templates CHANGES 2.5 - Doc Fix: added reference to new HTML::Template website at http://html-template.sourceforge.net - Bug Fix: global_vars fixed for loops within loops - Bug Fix: include paths were broken under Windows (David Ferrance) - Bug Fix: nested include path handling was wrong (Gyepi Sam) - Bug Fix: MD5 signatures for file cache corrected (Martin Schroth) - Bug Fix: print_to was broken for tied filehandles (Darren Chamberlain) - Doc Fix: added mailing-list archive URL to FAQ, added link to tutorial, fixed typos and formatting DESCRIPTION This module attempts to make using HTML templates simple and natural. It extends standard HTML with a few new HTML-esque tags - TMPL_VAR, TMPL_LOOP, TMPL_INCLUDE, TMPL_IF, TMPL_ELSE and TMPL_UNLESS. The file written with HTML and these new tags is called a template. It is usually saved separate from your script - possibly even created by someone else! Using this module you fill in the values for the variables, loops and branches declared in the template. This allows you to separate design - the HTML - from the data, which you generate in the Perl script. This module is licensed under the GPL. See the LICENSE section below for more details. TUTORIAL If you're new to HTML::Template, I suggest you start with the introductory article available on the HTML::Template website: http://html-template.sourceforge.net AVAILABILITY This module is available on SourceForge. Download it at: http://sourceforge.net/project/showfiles.php?group_id=1075 The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]). You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
Re: IPC::ShareLite
On Thu, 31 Jan 2002, Rasoul Hajikhani wrote: I have created a data structure and used IPC::ShareLite to save it in the main memeory. Can someone tell me how to look at it and destroy it. Your system should have a program called ipcs you can use to examine IPC shared structures (memory, semaphores and message queues). Look at the ipcs manpage for details. -sam
Re: performance coding project? (was: Re: When to cache)
On Sat, 26 Jan 2002, Perrin Harkins wrote: It all depends on what kind of application do you have. If you code is CPU-bound these seemingly insignificant optimizations can have a very significant influence on the overall service performance. Do such beasts really exist? I mean, I guess they must, but I've never seen a mod_perl application that was CPU-bound. They always seem to be constrained by database speed and memory. Think search engines. Once you've figured out how to get your search database to fit in memory (or devised a cachin strategy to get the important parts there) you're essentially looking at a CPU-bound problem. These days the best solution is probably some judicious use of Inline::C. Back when I last tackled the problem I had to hike up mount XS to find my grail... -sam
Re: slow regex [BENCHMARK]
On Wed, 23 Jan 2002, Paul Mineiro wrote: i've cleaned up the example to tighten the case: the mod perl code snippet is: Fascinating. The only thing I don't see is where $seq gets assigned to in the CGI case. Where is the data coming from? Is it perhaps a tied variable or otherwise unlike the $seq in the command-line version? If that's not it then I think you might have to build a debugging version of Apache and Perl and break out GDB to get to the bottom of things. -sam
Re: kylix: rad!
On Sat, 12 Jan 2002, Perrin Harkins wrote: Well, does this product actually have any users to compete for? GUI builders usually don't work for anything but the most trivial websites that could be written in anything and do fine. People seem to come to mod_perl because they need more performance or more control than they can get from CGI. Agree. I'm not sure I want to try and draw in users who can't program at all. Tangential thought: we may not want to draw individual non-programmers but we undoubtably do work with non-programmers - artists and HTML writers. I think a GUI system that made it easier for these non-programmers to interface with our creations would have some utility. I've got a half-baked module sitting in my workspace, HTML::Template::Explorer, that was an attempt to do something along these lines for HTML::Template. I didn't get very far before I realized I didn't have a strong enough design to be coding... -sam
Re: kylix: rad!
On Sun, 13 Jan 2002, brian moseley wrote: altho kylix was discussed in the first post of the thread, my actual reply to you stood on its own as a condemnation of a general cliquish attitude. Oh, consider me properly chastened then. BTW - kylix is actually the subject of this thread, supposedly. I didn't think addressing it directly was too out of bounds! And Kylix *is* aimed at non-programmers, or at least it was when it was Delphi. but microsoft visual studio blah blah .net blah blah is quite popular, isn't it? Have you used MS visual studio? There isn't much visual about it. In my experience it's pretty much on par with the various C/C++ IDE's around for Linux already. All of which are pretty close to useless, IMO. People use MS Visual Studio because they have to. Same reason they'll use .NET. If there's anything Borland has proved it's that providing a better development environment than Microsoft doesn't get you more developers. Kylix is, as I understand it, something much closer to original Delphi aim of programming without coding. I'm not saying it wouldn't be neat if you could do Kylix for Perl. I'm just saying I don't think it would be a fantastic success. So, yeah, I'm agreeing with Perrin, but I don't think that makes me some kind of horrible elitist. -sam
Re: ANNOUNCE: Bricolage 1.2.0
On Fri, 11 Jan 2002, Matt Sergeant wrote: Any chance of supporting more template systems in the future, like TT and XSLT? Adding more Burners (brictalk for templating system) is definitely something we're interested in. If you'd like to give it a try there's a brief set of instructions in the Bric::Util::Burner docs: http://bricolage.thepirtgroup.com/docs/Bric/Util/Burner.html Look for the ADDING A NEW BURNER section. For general information about the templating system, see: http://bricolage.thepirtgroup.com/documentation.html -sam
ANNOUNCE: CGI::Application::MailPage 1.0
I've got a new module to introduce - CGI::Application::MailPage. It's a little CGI::Application module that allows users to send HTML documents to their friends via email. It's configurable in a number of useful directions and useful if you need this sort of thing. However, it's also a proof of concept - that CGI::Application can enable the distribution of small, configurable CGI apps via CPAN. So, without further ado, I give you a module created almost two years ago and aged to perfection in the moldy depths of my home directory: CGI::Application::MailPage - module to allow users to send HTML pages by email This module is a CGI::Application module that allows users to send HTML pages to their friends. This module provides the functionality behind a typical Mail This Page To A Friend link. AVAILABILITY This module is available on SourceForge. Download it at: http://sourceforge.net/project/showfiles.php?group_id=12636 The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ AUTHOR Copyright 2000-2002, Sam Tregar ([EMAIL PROTECTED]). Questions, bug reports and suggestions can be sent to the CGI::Application mailing list. You can subscribe by sending a blank message to [EMAIL PROTECTED] See you there! LICENSE This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
ANNOUNCEMENT: HTML::Template::JIT 0.02
HTML::Template::JIT - a just-in-time compiler for HTML::Template CHANGES - Added support for loop_context_vars. - Added support for global_vars. - Fixed bug in loop param handling that made loop variables case-sensitive. DESCRIPTION This module provides a just-in-time compiler for HTML::Template. Templates are compiled into native machine code using Inline::C. The compiled code is then stored to disk and reused on subsequent calls. HTML::Template::JIT is up to 4 times as fast as HTML::Template using caching. NOTE This module is not feature-complete. Be sure to read the CAVEATS section in the documentation before using! AVAILABILITY This module is available on SourceForge. Download it at: http://prdownloads.sourceforge.net/html-template/HTML-Template-JIT-0.02.tar.gz The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
ANNOUNCEMENT: HTML::Template::JIT 0.01
HTML::Template::JIT - a just-in-time compiler for HTML::Template DESCRIPTION This module provides a just-in-time compiler for HTML::Template. Templates are compiled into native machine code using Inline::C. The compiled code is then stored to disk and reused on subsequent calls. HTML::Template::JIT is up to 4 times as fast as HTML::Template using caching. NOTE This module is not feature-complete. Be sure to read the CAVEATS section in the documentation before using! AVAILABILITY This module is available on SourceForge. Download it at: http://prdownloads.sourceforge.net/html-template/HTML-Template-JIT-0.01.tar.g The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
ANNOUNCEMENT: HTML::Template::Expr 0.03
CHANGES - Added register_function() class method add functions globally. (Tatsuhiko Miyagawa) - Fixed broken cache mode. DESCRIPTION This module provides an extension to HTML::Template which allows expressions in the template syntax. This is purely an addition - all the normal HTML::Template options, syntax and behaviors will still work. Expression support includes comparisons, math operations, string operations and a mechanism to allow you add your own functions at runtime. AVAILABILITY This module is available on SourceForge. Download it at: http://prdownloads.sourceforge.net/html-template/HTML-Template-Expr-0.03.tar.gz The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANNOUNCEMENT: HTML::Template::Expr 0.02
CHANGES - Fixed bug where numeric functions all returned 1. (reported by Peter Leonard) - Improved performance over 300% with a new grammar and expression evaluator. - Enhanced grammar to support call(foo 10) syntax. DESCRIPTION This module provides an extension to HTML::Template which allows expressions in the template syntax. This is purely an addition - all the normal HTML::Template options, syntax and behaviors will still work. Expression support includes comparisons, math operations, string operations and a mechanism to allow you add your own functions at runtime. AVAILABILITY This module is available on SourceForge. Download it at: http://prdownloads.sourceforge.net/html-template/HTML-Template-Expr-0.02.tar.gz The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ CONTACT INFO You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
Re: ANNOUNCEMENT: NEW VERSION: HTML::Template 2.1
On Mon, 18 Dec 2000, Eric Cholet wrote: ANNOUNCEMENT: NEW VERSION: HTML::Template 2.1 Does it support ELSIF yet? Nope, but you can build your own now with the new filter option. I expect someone to post up an "ELSIF" = "ELSE IF" filter to the HTML::Template mailinglist any time now. -sam
ANNOUNCEMENT: NEW VERSION: HTML::Template 2.0
ANNOUNCEMENT: NEW VERSION: HTML::Template 2.0 HTML::Template - a Perl module to use HTML Templates CHANGES 2.0 - New Feature: new 'search_path_on_include' option (Jody Biggs) - New Feature: much requested variable __ODD__ added to set of loop_context_vars. - New Feature: new 'no_includes' option (Scott Guelich) - Doc Addition: Added link to Japanese translation (Kawai Takanori) - Bug Fix: loop_context_vars broken again (T.J. Mather, Martin Schroth and Dave Wolfe) - Bug Fix: vanguard_compatibility_mode was broken on first line of included files. (uchum) DESCRIPTION This module attempts make using HTML templates simple and natural. It extends standard HTML with a few new HTML-esque tags - TMPL_VAR, TMPL_LOOP, TMPL_INCLUDE, TMPL_IF, TMPL_UNLESS and TMPL_ELSE. The file written with HTML and these new tags is called a template. It is usually saved separate from your script - possibly even created by someone else! Using this module you fill in the values for the variables, loops and branches declared in the template. This allows you to seperate design - the HTML - from the data, which you generate in the Perl script. A Japanese translation of the documentation is available at: http://member.nifty.ne.jp/hippo2000/perltips/html/template.htm This module is licenced under the GPL. See the LICENCE section of the README. AVAILABILITY This module is available on SourceForge. Download it at: http://download.sourceforge.net/HTML-Template/HTML-Template-2.0.tar.gz The module is also available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ MOTIVATION It is true that there are a number of packages out there to do HTML templates. On the one hand you have things like HTML::Embperl which allows you to freely mix Perl with HTML. On the other hand lie home-grown variable substitution solutions. Hopefully the module can find a place between the two. One advantage of this module over a full HTML::Embperl-esque solution is that it enforces an important divide - design and programming. By limiting the programmer to just using simple variables and loops in the HTML, the template remains accessible to designers and other non-perl people. The use of HTML-esque syntax goes further to make the format understandable to others. In the future this similarity could be used to extend existing HTML editors/analyzers to support this syntax. An advantage of this module over home-grown tag-replacement schemes is the support for loops. In my work I am often called on to produce tables of data in html. Producing them using simplistic HTML templates results in CGIs containing lots of HTML since the HTML itself could not represent loops. The introduction of loop statements in the HTML simplifies this situation considerably. The designer can layout a single row and the programmer can fill it in as many times as necessary - all they must agree on is the parameter names. For all that, I think the best thing about this module is that it does just one thing and it does it quickly and carefully. It doesn't try to replace Perl and HTML, it just augments them to interact a little better. And it's pretty fast. DOCUMENTATION The documentation is in Template.pm in the form of POD format perldocs. Even the above text might be out of date, so be sure to check the perldocs for the straight truth. CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]) for Vanguard Media (http://www.vm.com). You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Nelson Correa de Toledo Ferraz wrote:
I still think that this:
? foreach $name (@names) { ?
Name: ?=$name? P
Job: ?=$job{$name}? P
? } ?
Is cleaner (well, as much as perl can be :-)) than this:
TMPL_LOOP NAME=EMPLOYEE_INFO
Name: TMPL_VAR NAME=NAME P
Job: TMPL_VAR NAME=JOB P
/TMPL_LOOP
That's because you're a Perl programmer. The template syntax wasn't
designed for your tastes. It was designed for the HTML designers you will
eventually have to work with - wether while you're actually on the project
or when it moves into maintainance and needs design changes.
And the first one has two major advantages: 1) requires less code in the
Perl modules and 2) allows designers to know how Perl looks like.
1) The more code you put in your modules the better. This promotes code
reuse and better documentation.
2) Say what? Are you running a school or trying to things done? Putting
raw Perl in your HTML isn't helping you designers is any way I understand.
-sam
Re: HTML Template Comparison Sheet ETA
On Mon, 4 Sep 2000, Perrin Harkins wrote: Embedded perl is absolutely the best answer sometimes, but don't underestmate the value of turning your example into this: [% FOREACH thing = list %] a href="[% thing.url %]"b[% thing.name %]/b/a [% END %] That isn't really much better, in my opinion. It's still too much of a departure from the HTML around it. Contrast the above to HTML::Template's looping: TMPL_LOOP list a href="TMPL_VAR url"bTMPL_VAR name/b/A /TMPL_LOOP With a little education an HTML designer can learn to manipulate the template syntax. You'll have to teach them to program before they can deal with a full "foreach" no matter how you dress it up. -sam
Re: HTML Template Comparison Sheet ETA
On Mon, 28 Aug 2000, Nelson Correa de Toledo Ferraz wrote: "This approach has two problems: First, their little language is crippled. If you need to do something the author hasn't thought of, you lose. Second: Who wants to learn another language? You already know Perl, so why not use it?" To which HTML::Template responds: "Sure you know Perl, but does the HTML designer you're working with?" HTML::Template has a simple, HTML-esque syntax for its template files that is aimed at HTML designers. Keep the Perl in your modules and keep the HTML in your template files. Go the other direction and soon enough you've got your programmers changing font colors. You can put that in your sheet and, er... smoke it? -sam
Re: IPC::ShareLite and garbage collection
On Tue, 11 Jan 2000, Dave Hodson wrote:
I'm trying to implement IPC::ShareLite on a Red Hat Linux box. I've
successfully stored/fetched the data I want between proc's, and am now
attempting to "clean up" once the httpd is killed/restarted.
Anyone has a good suggestion on how to do this? The POD for ShareLite
doesn't address this topic.
Basically, you can delete an IPC::ShareLite segment 'FOOO' like this:
{
my $share = IPC::ShareLite-new('-key' = 'FOOO', '-create' = 0,
'-destroy' = 1);
}
Since destroy is set true the segment is deleted when $share goes out of
scope. As for where this code should go in your application, I think
you'll need to figure that out.
Of course, if you're only interested in doing it manually, 'ipcs' and
'ipcrm' are what you're looking for.
-sam
ANNOUNCEMENT: NEW VERSION: HTML::Template 1.4
NAME HTML::Template - a Perl module to use HTML Templates CHANGES 1.4 - New feature: new() option 'shared_cache' enables experimental IPC shared memory caching! - TMPL_IF now works on TMPL_LOOP variables. - Public CVS server available at www.sourceforge.net. - Bug Fix from Doug Steinwand: loop_context_vars not working on one-item loops. DESCRIPTION This module attempts make using HTML templates simple and natural. It extends standard HTML with a few new HTML-esque tags - TMPL_VAR, TMPL_LOOP, TMPL_INCLUDE, TMPL_IF, TMPL_UNLESS and TMPL_ELSE. The file written with HTML and these new tags is called a template. It is usually saved separate from your script - possibly even created by someone else! Using this module you fill in the values for the variables, loops and branches declared in the template. This allows you to seperate design - the HTML - from the data, which you generate in the Perl script. This module is licenced under the GPL. See the LICENCE section of the README. AVAILABILITY The module is available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ If you don't find it there then you can try: http://sourceforge.net/project/?group_id=1075 MOTIVATION It is true that there are a number of packages out there to do HTML templates. On the one hand you have things like HTML::Embperl which allows you to freely mix Perl with HTML. On the other hand lie home-grown variable substitution solutions. Hopefully the module can find a place between the two. One advantage of this module over a full HTML::Embperl-esque solution is that it enforces an important divide - design and programming. By limiting the programmer to just using simple variables and loops in the HTML, the template remains accessible to designers and other non-perl people. The use of HTML-esque syntax goes further to make the format understandable to others. In the future this similarity could be used to extend existing HTML editors/analyzers to support this syntax. An advantage of this module over home-grown tag-replacement schemes is the support for loops. In my work I am often called on to produce tables of data in html. Producing them using simplistic HTML templates results in CGIs containing lots of HTML since the HTML itself could not represent loops. The introduction of loop statements in the HTML simplifies this situation considerably. The designer can layout a single row and the programmer can fill it in as many times as necessary - all they must agree on is the parameter names. For all that, I think the best thing about this module is that it does just one thing and it does it quickly and carefully. It doesn't try to replace Perl and HTML, it just augments them to interact a little better. And it's pretty fast. DOCUMENTATION The documentation is in Template.pm in the form of POD format perldocs. Even the above text might be out of date, so be sure to check the perldocs for the straight truth. CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]) for Vanguard Media (http://www.vm.com). You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
Looking for Maurice Aubrey maurice@hevanet.com
Hello all. Has anyone heard from Maurice Aubrey lately? Does anyone know how I could contact him (other than his email above)? My searches show that he last posted here in '98, and I can't find any further traces of him after that. Emails have gone unanswered. I'm looking for him because I'm using his *excelent* IPC::ShareLite module in my HTML::Template module. I found, and fixed, a seg-fault in IPC::ShareLite which HTML::Template triggers. Currently I'm holding up releasing a new version of HTML::Template that uses IPC::ShareLite until the fix can get into a real version. Thanks! -sam
ANNOUNCEMENT: NEW VERSION: HTML::Template 1.3
NAME HTML::Template - a Perl module to use HTML Templates CHANGES 1.3 - Omnibus regex patch from Matthew Wickline: a faster and more robust parse(). - New tag: TMPL_UNLESS, the opposite of TMPL_IF. - Numerous bug fixes: mixed-case filenames in includes, recursive TMPL_INCLUDEs, reporting filename and line number inside included files, better syntax-error detection. - Optional loop context variables - __FIRST__, __LAST__ and __INNER__. DESCRIPTION This module attempts make using HTML templates simple and natural. It extends standard HTML with a few new HTML-esque tags - TMPL_VAR, TMPL_LOOP, TMPL_INCLUDE, TMPL_IF, TMPL_UNLESS and TMPL_ELSE. The file written with HTML and these new tags is called a template. It is usually saved separate from your script - possibly even created by someone else! Using this module you fill in the values for the variables, loops and branches declared in the template. This allows you to seperate design - the HTML - from the data, which you generate in the Perl script. This module is licenced under the GPL. See the LICENCE section of the README. AVAILABILITY The module is available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ MOTIVATION It is true that there are a number of packages out there to do HTML templates. On the one hand you have things like HTML::Embperl which allows you to freely mix Perl with HTML. On the other hand lie home-grown variable substitution solutions. Hopefully the module can find a place between the two. One advantage of this module over a full HTML::Embperl-esque solution is that it enforces an important divide - design and programming. By limiting the programmer to just using simple variables and loops in the HTML, the template remains accessible to designers and other non-perl people. The use of HTML-esque syntax goes further to make the format understandable to others. In the future this similarity could be used to extend existing HTML editors/analyzers to support this syntax. An advantage of this module over home-grown tag-replacement schemes is the support for loops. In my work I am often called on to produce tables of data in html. Producing them using simplistic HTML templates results in CGIs containing lots of HTML since the HTML itself could not represent loops. The introduction of loop statements in the HTML simplifies this situation considerably. The designer can layout a single row and the programmer can fill it in as many times as necessary - all they must agree on is the parameter names. For all that, I think the best thing about this module is that it does just one thing and it does it quickly and carefully. It doesn't try to replace Perl and HTML, it just augments them to interact a little better. And it's pretty fast. DOCUMENTATION The documentation is in Template.pm in the form of POD format perldocs. Even the above text might be out of date, so be sure to check the perldocs for the straight truth. CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]) for Vanguard Media (http://www.vm.com). You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
RE: Configuring Apache with Perl Problems
On Fri, 10 Dec 1999, O'Fallon, Paul (MAN-Atlanta) wrote:
$FilesMatch{'^.*\.pl$'} =
and see if that works (no double quotes).
Nope. Actually, I've given up in the Perl block stuff. I switched to a
templatized conf setup which outputs standard Apache configuration syntax
at runtime and a lot of problems have gone away. Configuring in a giant
Perl gave me random seg-faults and strange Apache::DBI errors.
Ah well, it was pretty anyway!
-sam
Re: Configuring Apache with Perl Problems
On Fri, 10 Dec 1999, Ken Williams wrote: I had similar problems and discovered that bugs had been fixed in the latest CVS version, and those fixes fixed my problems. Might be worth a shot. I figured as much - I'm saddled with an old mod_perl here, with almost no ability to upgrade. Another time perhaps... Besides, using HTML::Template to configure Apache dynamically has a certain sureal quality that appeals to me. Probably that's because I'm obsessed with HTML::Template, but who's counting? -sam
Re: Limitations of DBI::ProxyServer (was: pool of DB connections?)
On Mon, 29 Nov 1999, Tim Bunce wrote: Ignoring 'thread' (unsafe for production use) and 'debug' modes, the normal 'fork' mode means that each client gets a seperate ProxyServer process. And because of that, clients have no way to share connections with each other. Is that necessarily the case? Perhaps the parent server could handle the connection-pooling and hand off live connection to the forked child. That way you could get the best of both worlds - de-coupled clients and a shared pool of database connections. It seems to me that moving to a single-process architecture has some BIG downsides when you consider the wide variation in database query runtimes. -sam
Re: Limitations of DBI::ProxyServer (was: pool of DB connections?)
On Tue, 30 Nov 1999, Tim Bunce wrote: You're quite right, but both cases need to be allowed for as some database (notably Oracle) get upset if a child process tries to use a connection established by the parent process. Interesting. So Oracle snoops on the PID of the process calling it? How rude! Or does it have some other mechanism I'm not aware of? But mixing a connection pool with fork mode ought work for some of the DBI drivers. Thanks for pointing that out. Does that mean you're volunteering? :-) I'm willing to take a look at it... I've never played with DBD::Proxy*, although I've meant to. Let me take a look and then I'll tell you if it's something I think I could accomplish. -sam
ANNOUNCEMENT: NEW VERSION: HTML::Template 1.2.1
ANNOUNCEMENT: NEW VERSION: HTML::Template 1.2.1 NAME HTML::Template - a Perl module to use HTML Templates CHANGES 1.2.1 - Added multi-parameter and hash-ref syntax for param() calls. - Added DTD-compliant !-- TMPL_* -- syntax patch from Matthew Wickline - Thanks! - vanguard_compatibility_mode = 1 implies die_on_bad_params = 0 - tiny bug fix DESCRIPTION This module attempts make using HTML templates simple and natural. It extends standard HTML with a few new HTML-esque tags - TMPL_VAR, TMPL_LOOP, TMPL_INCLUDE, TMPL_IF and TMPL_ELSE. The file written with HTML and these new tags is called a template. It is usually saved separate from your script - possibly even created by someone else! Using this module you fill in the values for the variables, loops and branches declared in the template. This allows you to seperate design - the HTML - from the data, which you generate in the Perl script. This module is licenced under the GPL. See the LICENCE section of the README. AVAILABILITY The module is available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ MOTIVATION It is true that there are a number of packages out there to do HTML templates. On the one hand you have things like HTML::Embperl which allows you to freely mix Perl with HTML. On the other hand lie home-grown variable substitution solutions. Hopefully the module can find a place between the two. One advantage of this module over a full HTML::Embperl-esque solution is that it enforces an important divide - design and programming. By limiting the programmer to just using simple variables and loops in the HTML, the template remains accessible to designers and other non-perl people. The use of HTML-esque syntax goes further to make the format understandable to others. In the future this similarity could be used to extend existing HTML editors/analyzers to support this syntax. An advantage of this module over home-grown tag-replacement schemes is the support for loops. In my work I am often called on to produce tables of data in html. Producing them using simplistic HTML templates results in CGIs containing lots of HTML since the HTML itself could not represent loops. The introduction of loop statements in the HTML simplifies this situation considerably. The designer can layout a single row and the programmer can fill it in as many times as necessary - all they must agree on is the parameter names. For all that, I think the best thing about this module is that it does just one thing and it does it quickly and carefully. It doesn't try to replace Perl and HTML, it just augments them to interact a little better. And it's pretty fast. DOCUMENTATION The documentation is in Template.pm in the form of POD format perldocs. Even the above text might be out of date, so be sure to check the perldocs for the straight truth. CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]) for Vanguard Media (http://www.vm.com). You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
Re: Ye Ol' Template System Thread
On Mon, 15 Nov 1999, Leslie Mikesell wrote: What I'm looking for is a 'nestable' way of handling the logic flow and HTML construction that will allow a page to be used as a stand-alone item (perhaps displayed in a frameset) or included in another page, but when it is included I'd like to have the option of letting its execution return a status that the including page could see before it sends out any HTML. Ok, here's how you can do this with HTML::Template. I can't really address the solution as "pages that execute" since with HTML::Template, only scripts execute. But anyway: First, define your component that you want to use both stand-alone and as an included component: component.tmpl: TMPL_IF NAME="STAND_ALONE_MODE" HTML HEAD TITLEI'm all alone.../TITLE /HEAD BODY /TMPL_IF Some stuff that users will love to pay for : BR by the way, my name is TMPL_VAR NAME="NAME"P TMPL_IF NAME="STAND_ALONE_MODE" /BODY /HTML /TMPL_IF Now, when you want to use it stand-alone: stand_along.cgi: my $template = HTML::Template-new(filename = 'component.tmpl'); $template-param(STAND_ALONE_MODE = 1); $template-param(NAME = 'Sam'); print "Content-Type: text/html\n\n"; print $template-output; Or within a larger entity: larger.tmpl: HTML HEAD TITLEThis is a big ol' page/TITLE /HEAD BODY Some stuff...PP The component: TMPL_VAR NAME="COMPONENT"P /BODY /HTML together.cgi: my $component = HTML::Template-new(filename = 'larger.tmpl'); $template-param(STAND_ALONE_MODE = 0); $template-param(NAME = 'Sam'); my $template = HTML::Template-new(filename = 'larger.tmpl'); $template-param(COMPONENT = $component_template-output()); print "Content-Type: text/html\n\n"; print $template-output; Now to support the whole "returning an error code" idea you'd need to wrap component.tmpl in a module that knows when to return an error. For something that approaches this level of complexity with HTML::Template, take a look at HTML::Pager. As you can see, HTML::Template doesn't send any output prematurely to the user - the enclosing CGI or module can do whatever it wants with the output before printing it. So, did I totally misunderstand what you're looking for, or have I answered your prayers? -sam
Re: Ye Ol' Template System Thread
On Sun, 14 Nov 1999, Leslie Mikesell wrote: I think a lot of unnecessary complexity comes from the fact that most of the template systems (and apache modules in general) want to output the html as a side effect instead of accumulating the page in a buffer or just returning a string containg the html plus a status value to the caller. That's a very strange analysis. HTML::Template (my small contribution to the genre) does no printing to the user - it returns a chunk of HTML ready for the consumer or an error if something went wrong. I don't really see that this significantly reduces the complexity of using a templating system! Rather, I think that most of the simplicity of HTML::Template comes from its strictly "one-way" interface. The template file contains only output-oriented structures. Input can only come from the perl side. I think that much of the "slippery slope" refered to previously comes from allowing the template file to perform processing of its own - to set variables and call procedures, for example. H... Shouldn't someone be suggesting a grand-unified templating system right about now? Or maybe we're finally beyond that? I hope so! The truth of the matter is that there is no one ultimate way to tackle generating HTML from Perl. The only question I'm really itching to answer is which template system is fastest? Maybe I should cook up a benchmark suite. I suppose the hardest part about that will be finding a set of templates/scripts that constitute roughly equal tasks. What do you all think? After all, what's a 4H without a bake-off? -sam
RE: Trying not to re-invent the wheel
I've written up a few test benches for HTML::Parser.. it works ok, but it's not as fast as I would like it to be. IS there some reason you don't just use HTML::Mason? Patient: My tooth aches. Doctor: Is there some reason you haven't replaced your teeth with dentures? -sam
Re: Trying not to re-invent the wheel
On Wed, 10 Nov 1999, Ian Mahuron wrote: The code in HTML::Template may work.. though it seems that it would be very slow. Actually, I like to think it's some pretty fast code... Of course, that's because it's only looking for TMPL_* tags, and it's allowing them to break all kinds of HTML laws. Thus, it's not really useable for "HTML parseing" at all! I think you need to give us a little more information about what you're trying to do with the HTML. My knee-jerk reaction is to say "You need HTML parseing? Use HTML::Parser!" but perhaps that's not what you really need? -sam
ANNOUNCEMENT: NEW VERSION: HTML::Template 0.96
ANNOUNCEMENT: NEW VERSION: HTML::Template 0.96 NAME HTML::Template - a Perl module to use HTML Templates CHANGES 0.96 - Added "ESCAPE=1" option to TMPL_VAR to HTML-escape variable values. (Peter Marelas, thanks!) - more bug fixes (David Glasses, James William Carlson - thanks) - even *more* code cleanup! - new FAQ concerning pre-loading templates and mod_perl. DESCRIPTION This module attempts make using HTML templates simple and natural. It extends standard HTML with a few new HTML-esque tags - TMPL_VAR, TMPL_LOOP, TMPL_INCLUDE, TMPL_IF and TMPL_ELSE. The file written with HTML and these new tags is called a template. It is usually saved separate from your script - possibly even created by someone else! Using this module you fill in the values for the variables, loops and branches declared in the template. This allows you to seperate design - the HTML - from the data, which you generate in the Perl script. This module is licenced under the GPL. See the LICENCE section of the README. AVAILABILITY The module is available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ MOTIVATION It is true that there are a number of packages out there to do HTML templates. On the one hand you have things like HTML::Embperl which allows you to freely mix Perl with HTML. On the other hand lie home-grown variable substitution solutions. Hopefully the module can find a place between the two. One advantage of this module over a full HTML::Embperl-esque solution is that it enforces an important divide - design and programming. By limiting the programmer to just using simple variables and loops in the HTML, the template remains accessible to designers and other non-perl people. The use of HTML-esque syntax goes further to make the format understandable to others. In the future this similarity could be used to extend existing HTML editors/analyzers to support this syntax. An advantage of this module over home-grown tag-replacement schemes is the support for loops. In my work I am often called on to produce tables of data in html. Producing them using simplistic HTML templates results in CGIs containing lots of HTML since the HTML itself could not represent loops. The introduction of loop statements in the HTML simplifies this situation considerably. The designer can layout a single row and the programmer can fill it in as many times as necessary - all they must agree on is the parameter names. For all that, I think the best thing about this module is that it does just one thing and it does it quickly and carefully. It doesn't try to replace Perl and HTML, it just augments them to interact a little better. And it's pretty fast. DOCUMENTATION The documentation is in Template.pm in the form of POD format perldocs. Even the above text might be out of date, so be sure to check the perldocs for the straight truth. CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]) for Vanguard Media (http://www.vm.com).
ANNOUNCEMENT: NEW VERSION: HTML::Template 1.1
NAME HTML::Template - a Perl module to use HTML Templates CHANGES 1.1 - Lifted requirement that TMPL_INCLUDEs be alone on a line - Added "path" option to new() to manipulate search path for templates. - bug fixes DESCRIPTION This module attempts make using HTML templates simple and natural. It extends standard HTML with a few new HTML-esque tags - TMPL_VAR, TMPL_LOOP, TMPL_INCLUDE, TMPL_IF and TMPL_ELSE. The file written with HTML and these new tags is called a template. It is usually saved separate from your script - possibly even created by someone else! Using this module you fill in the values for the variables, loops and branches declared in the template. This allows you to seperate design - the HTML - from the data, which you generate in the Perl script. This module is licenced under the GPL. See the LICENCE section of the README. AVAILABILITY The module is available on CPAN. You can get it using CPAN.pm or go to: http://www.cpan.org/authors/id/S/SA/SAMTREGAR/ MOTIVATION It is true that there are a number of packages out there to do HTML templates. On the one hand you have things like HTML::Embperl which allows you to freely mix Perl with HTML. On the other hand lie home-grown variable substitution solutions. Hopefully the module can find a place between the two. One advantage of this module over a full HTML::Embperl-esque solution is that it enforces an important divide - design and programming. By limiting the programmer to just using simple variables and loops in the HTML, the template remains accessible to designers and other non-perl people. The use of HTML-esque syntax goes further to make the format understandable to others. In the future this similarity could be used to extend existing HTML editors/analyzers to support this syntax. An advantage of this module over home-grown tag-replacement schemes is the support for loops. In my work I am often called on to produce tables of data in html. Producing them using simplistic HTML templates results in CGIs containing lots of HTML since the HTML itself could not represent loops. The introduction of loop statements in the HTML simplifies this situation considerably. The designer can layout a single row and the programmer can fill it in as many times as necessary - all they must agree on is the parameter names. For all that, I think the best thing about this module is that it does just one thing and it does it quickly and carefully. It doesn't try to replace Perl and HTML, it just augments them to interact a little better. And it's pretty fast. DOCUMENTATION The documentation is in Template.pm in the form of POD format perldocs. Even the above text might be out of date, so be sure to check the perldocs for the straight truth. CONTACT INFO This module was written by Sam Tregar ([EMAIL PROTECTED]) for Vanguard Media (http://www.vm.com). You can join the HTML::Template mailing-list by sending a blank message to [EMAIL PROTECTED]
