modulereview
trs80
<H4>Author</H4> Gerald Richter
<br>
<br>
<H4>Version</H4> 1.3.4 stable / 2.0.5 beta
<br>
<br>
<H4>Rating</H4> ***** 5 out of 5 stars
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
<H5>Form Data</H5>
The 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 <code>%fdat</code>
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 <code>pop</code> or <code>shift</code> the item you need or don't need.
<br>
<br>
<H5>Delimiters</H5>
One 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:
<br>
[- -] - execute, but don't send page<br>
[+ +] - execture and send to page<br>
[$ $] - meta commands or loops<br>
[* *] - EXPERIMENTAL and provides different scoping then [- -] tags.<br>
[# #] - Comment tags<br>
<br>
<br>
The documentation goes into detail on how each of the tags is processed
and provides some examples.
<br>
<br>
<H5>Sessions</H5>
The 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 <code>%udat</code> (a
"magical" hash like <code>%fdat</code>) 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:
<br>
<code>
$udat{user_name} = "fred";
</code>
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.
<br>
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.
<br>
<br>
<H5>Configuration</H5>
HTML::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:<br>
<code>[- $optDisableFormData = 1 -] </code>
<br>
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.
<br>
<br>
<H5>EmbperlObject</H5>
A 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.
<br>
<br>
<H5>Summary / Odds and Ends</H5>
So 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.
<br>
<br>
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.
<br>
<br>
HTML::Embperl has its own mailing list for support and most questions
are answered quickly and often by the author.
<br>
<br>
------------------------------------------------------------------
<br>
<br>
1 - HTML::Embperl does NOT require mod_perl to run however.
<br>
<br>
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 <% %>
<br>
<br>
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.
Allows for embedding Perl inside of HTML for server side processing.