|Do you know where your variables are?|
Version1.3.4 stable / 2.0.5 beta
Rating***** 5 out of 5 stars
HTML::Embperl is one of the earlier embedded Perl in HTML modules available via CPAN making its debut in 1996 if memory serves me correct. HTML::Embperl offers a robust range of features that can be very helpful in creating complex internet applications requiring form handling, database interaction and automated handling of URL (un)escaping.
I was first drawn to HTML::Embperl because it lent well to my style of coding and helped me achieve my goals without having to learn too much, what I call fluff, to get started. In martketing terms: It presented an intuitive interface. I started using HTML::Embperl in 1997 when it was at version 0.25b. I owned my own internet company and was creating a dynamic web site with a MySQL backend. Since I owned the apache server I was able to add in mod_perl(1) and all the additional goodies I would need for maximum speed. The documentation is geared toward a mod_perl environment and it was my intent to build additional sites and use the same server to power them so mod_perl seemed to make sense.
Form DataThe main thing that drew me to HTML::Embperl was how it interacted with form data. To me that seemed to be one of the most frequent issues with other CGI type development was managing the incoming variables. HTML::Embperl uses a glob called fdat to handle interaction with the incoming parameters. It appears inside of your "page" as a hash %fdat that you can treat just like a normal hash. It is also well named because of its interaction with HTML. It has several html generation automations for tables, forms, lists and hrefs just to name a few. There is also an array interface to the list of incoming variables, most likely in the order they appeared on the page that sent the parameters which makes it easy to pop or shift the item you need or don't need.
DelimitersOne thing that at the time I didn't really worry about, is its non standard(2) code delimiters more on that later in the review. The delimiters are:
[- -] - execute, but don't send page
[+ +] - execture and send to page
[$ $] - meta commands or loops
[* *] - EXPERIMENTAL and provides different scoping then [- -] tags.
[# #] - Comment tags
The documentation goes into detail on how each of the tags is processed and provides some examples.
SessionsThe next feature that I like about HTML::Embperl is its session management. It is as easy to use as the form data. You simply assign what you want to be in the user session to a hash called %udat (a "magical" hash like %fdat) and if Session handling is enabled in the Apache configuration it will handle the session transparently. Inside of you page you simply write something like:
The session id is created for you automaticly if the users doesn't currently have one and you can add as much as you like to the session. It allows for session data to be stored in several different methods.
The session handling can be a bit confusing at first, but with a through read of the documentation and a good understanding of the session backend module(3) it is manageable.
ConfigurationHTML::Embperl is very configurable. Almost every feature it has can be turned off either globally via a (Perl)SetEnv directive in the httpd.conf or at a page level via global variables accessible from the HTML::Embperl module, such as:
[- $optDisableFormData = 1 -]
That will turn off the form (param) handling for a single page. These options can be set in the httpd.conf using the EMBPERL_OPTIONS directive. EMBPERL_OPTIONS is a bitmask that controls options for the execution of HTML::Embperl. To specify multiple options, simply add the values together. This is covered in the documentation in depth so I won't repeat it here.
EmbperlObjectA newer feature of HTML::Embperl is HTML::EmbperlObject. This addition allows for simplification of site building if you have consistent headers, footers, or page level content (aka Objects). The EmbperlObject documentation explains it in full, but basicly it allows for a single page to be used as the base for each request. That "page" can compile in other "pages" by default that can either wrapper or augment the page actually requested. So if you setup your EMBPERL_OBJECT_BASE to be base.htm, when you request page1.htm it will read base.htm first and perform its actions and then place the compiled code from page1.htm in the location you specify.
Summary / Odds and EndsSo who should use HTML::Embperl? My opinion is that if you come from an HTML background and are creating robust online applications HTML::Embperl maybe a good match for you. If you are working in a mixed environment where non-programmers are looking at the source and make modifications in various WYSIWYG editors it can present some issues in dealing with what I previously called non-standard delimiters. There are various "plugins" for editors such as VI, emacs etc. that will do correct highlighting of HTML::Embperl delimiters if you need them. I think its ease of use is very high and its use of sessions and handling of form data make it much less cumbersome IMHO to read/write then Apache::ASP.
It is now a very mature package and the 2nd generation is in beta and from my testing it is very stable for use with existing code and will allow for interaction with XML and the ability to replace parts of the "page" processing with your own custom handler.
HTML::Embperl has its own mailing list for support and most questions are answered quickly and often by the author.
1 - HTML::Embperl does NOT require mod_perl to run however.
2 - standard in what is now considered the more accepted approach, but I don't think there is any standard body for embedded content. The general standard is <% %>
3 Older versions of HTML::Embperl used Apache::Session, the author has since created a wrapper module called Apache::SessionX which works in concert with Apache::Session and makes session handling even easier by prompting for information on installtion and automaticly setting the configuration files based on this. This method does not effect httpd.conf.