Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

embperl tips?

by tstock (Curate)
on Jan 05, 2002 at 09:00 UTC ( [id://136479]=perlquestion: print w/replies, xml ) Need Help??

tstock has asked for the wisdom of the Perl Monks concerning the following question:

Hello fellow monks,

I have coded perl in CGIs and stand alone applications for about 4-5 years now, I use strict, -w, used to subscribed to the perl journal and feel pretty confident coding in Perl in general. However, my new job uses embperl and I have no experience in this. It's a strange new world this one of embedded perl in HTML... Any coding/style/debugging tips from more experienced users that have used embperl ?

A penny for your thoughts,

Replies are listed 'Best First'.
Re: embperl
by talexb (Chancellor) on Jan 05, 2002 at 10:10 UTC
    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.

Re: embperl
by IlyaM (Parson) on Jan 05, 2002 at 19:30 UTC
    One tip: do not put business logic of your application into HTML pages. Use perl code only for HTML generation and put business logic into Perl modules. It helps to keep perl code at minimum level in templates which is good for logic/presentation separation.

    Ilya Martynov (

Re: embperl
by Stegalex (Chaplain) on Jan 05, 2002 at 21:31 UTC
    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.
Re: embperl
by edebill (Scribe) on Jan 06, 2002 at 10:51 UTC

    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)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://136479]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2024-04-15 15:00 GMT
Find Nodes?
    Voting Booth?

    No recent polls found