It took me a while to get my head around EmbPerl. Instead of what I consider a normal path -- HTTP request from client comes to Apache, that request is passed to a page which in turn calls a Perl Module to actually output stuff, Apache passes the request to the EmbPerl page which in turn calls the Perl Module -- which cooks up a bunch of data then passes it back to the EmbPerl page, which then formats it nicely.
It's a bit like programming a TSR (boy am I dating myself now) where as soon as you start, the two things you have to check for are "Am I already running?" and "Am I trying to unload myself?" Sort of a doublethink approach to how your program behaves. (If both statements are true, then you have to unload the original copy, then exit, rather than doing the installation thing .. but that's not important right now.)
You can do as much Perl in an EmbPerl environment as you like, but it's recommended that the heavy crunching be done in a Perl Module, with just light work done in the EmbPerl file.
I can also recommend this documentation .. very handy.
--t. alex
"Excellent. Release the hounds." -- Monty Burns.
| [reply] |
| [reply] |
I have been using Embperl for two years now and it's worked very well for me. The documentation is a little hard to read, but the most important things to know about it have already been said (continue to use modules wherever possible rather than embedding logic in you html).
The most important features to familiarize yourself with are the %fdat hash, [- -] blocks, [$ $] blocks.
I haven't had much luck with using %udat and I have no use for %mdat. In fact, you will probably read much about past problems other people have had using the built-in cookie handling. For cookies, I still do a Set-Cookie just like in CGI and it works fine (only one cookie per page, but you can split them).
Here's a handy little snippet I put in all my emberl pages to facilitate debugging:
[- $debugmode = 0 -]
[$ if $debugmode $]
[$ while (($key, $val) = each(%fdat)) $]
[+ $key +], [+$val +]<br>
[$ endwhile $]
[$ endif $]
You can then toggle $debugmode to 0 or 1. If it's 1 then you will see the contents of %fdat at the top of your page.
Kudos to Gerald Richter, the author of Embperl.
I like chicken. | [reply]
[d/l] |
use strict doesn't work too well, since [ ] blocks define code blocks - and the lifetime of my variables. This means you end up having lots of variables which are effectively global to the page. This means shorter pages will have less mysterious interaction between variables in widely separated places.
Beware the [$ if $] blocks. If you have a single file that actually paints more than one "page" it can get really hard to work with. Break those two pages out into their own files, then have a controlling file Execute() them. This has the added benefit that the page being Execute()ed effectively gets it's own namespace - you don't have to worry about it picking up stray variables from the other pages.
Another embperl page executing in the same apache process (perhaps for a previous request) will leave perl modules in the cache. That's really good for speed, but it means that you can forget to use those modules and the page will execute most of the time - the functions you are using will be loaded and the interpreter finds them just fine. This is a recurring source of intermittent errors. You have to be really careful to get all the the appropriate use statements on each page.
In the same vein, assuming you're using mod_perl, the interpreter won't notice if you modify a .pm. So even though it's changed on disk your page will keep using the old one until a new apache process starts up. MaxRequestsPerChild=1 in the httpd.conf is a workaround for development (I also know several people who have * * * * * /usr/local/apache/bin/apachectl restart crontab entries)
| [reply]
[d/l]
[select] |