Ok, so I just completed a major upgrade of my websites from Apache 1.3,
mod_perl 1, Embperl 1.3 to Apache 2.2, mod_perl 2 and Embperl 2.3.0. It
was not a simple or painless experience, to say the least. Why on earth
didn't the Apache/mod_perl people provide a compatibility layer for
their API. It's simple enough using the new version if you're building a
site from scratch, but not if you're upgrading a large existing
configuration. But that's not my main point. I have some observations
and a couple of questions:
1. What is up with Embperl? I have written to Gerald Richter both via
this list and directly to his email address, and had no answer. I also
wrote to Angus Lees about the Debian Lenny Embperl package being broken
but got no reply. The email archives here are full of spam. It really
gives an "abandoned house" impression which is sure to turn off any
prospective new users. If I was a potential user, and I came onto the
Embperl site to check out the community, I would assume that this is a
dying or dead project. Is Embperl still being actively developed, or has
Gerald effectively put this to sleep? Has the likes of Ruby on Rails and
PHP put Embperl firmly into the history books, or is this actually still
an active project? If Gerald isn't all that "into" developing it any
more, is there any potential for someone else to take it on in a more
active way?
2. When I upgraded my sites to Embperl 2, I noticed that some things
broke, in particular forms handling. I tracked down the problems to
Embperl not apparently failing to include fdat values in the [$hidden$]
block, when the fdat value was not passed into the request or included
in the form explicitly as a hidden input tag, but was rather created in
the code. This worked in Embperl 1.x; I could create for example
$fdat{xxx} and then xxx would be included as a hidden variable in the
[$hidden$] block. I fixed the problem by explicitly inserting a "hidden"
input tag for the relevant variables, and these are now set from fdat by
Embperl. I don't know whether this new behavior is somehow "correct" and
the old behavior was just accidentally working. I do think that it would
be desirable for anything inserted into fdat to be included in a
[$hidden$] block, even if it didn't come into the request in fdat.
3. Embperl 2 was supposed to be much more flexible with respect to
Syntaxes. However I haven't found this to be the case. For example, I
have a lot of existing code which now breaks because of the TABLE and TR
handling which doesn't seem to handle these elements being parts of
conditional blocks. It seems to look at the straight number of such
tags, without consideration as to whether they are conditionally being
applied or not in [$if$] blocks. I wanted to turn off handling of just
the table tags, but couldn't find a way to do that easily using the
Syntax functionality. I would have to use EmbperlBlocks by itself,
leaving out EmbperlHTML. But as far as I can tell, EmbperlHTML is
necessary to enable forms handling, which I do very much use. In any
case, I couldn't even get the 'syntax' parameter to Embperl::Execute to
work when preloading my pages. It didn't seem to make any difference if
I put 'syntax => "EmbperlBlocks"', the table errors still came up during
the preload phase, as if it was still just using the Embperl syntax
(i.e. EmbperlBlocks + EmbperlHTML). The only way I could work around
this to get it to work was to abandon the concept of setting the syntax,
and just manually hack the EmbperlHTML.pm module in the Embperl codebase
to remove all the bits that seemed to deal with table processing, then
recompile Embperl. Given the supposed flexibility of the Syntax
functionality, I think this is a very clumsy way to do it. Every time I
compile a new version of Embperl, I will have to remember to go and
manually edit that file before compiling. Surely it would be better if
there was a (working) method of specifying exactly what aspects of the
HTML processing you would like to keep, and what you would like to
switch off.
4. The test phase of Embperl seems to be broken in 2.3. It comes back
with this:
...
#7 plainblock.htm... ok
#8 plainblock.htm... ok
#12 error.htm...
[-1]Missing right curly or square bracket at
/usr/src/Embperl-2.3.0/test/html/error.htm line 60, at end of line
In closing, I'd like to comment that I'm very grateful to Gerald for
writing Embperl. However I honestly think it was a case of "over
abstraction" to completely rewrite everything for version 2, which then
took so long to get to being stable. I am a major user of Embperl, but
put off upgrading to version 2 of the whole Apache/mod_perl/Embperl
stack because it was just so buggy for so long. I know that Gerald
wanted to design a better version which would then be so much more
flexible and powerful, but all I really wanted was a simple, working
Embperl that lets me embed Perl in HTML. The original version of Embperl
did just that, and very well too. So we were stuck for a long time with
this "second system" effect, where we can either use the old, stable
version which isn't being maintained any more, or the new, buggy,
incompatible version which is the new "official" version. Who uses
'recipes' or 'syntaxes' anyway? I just want to embed Perl in HTML. Isn't
this a case of too much abstraction? Especially when the new version
breaks existing code. I wonder if all that time where mod_perl has been
stuck in limbo because version 2 wasn't ready for prime time yet was one
of the things that made people leave it behind for things like PHP and
Ruby on Rails. I find that I committed myself to a technology eight
years ago (Embperl) which I felt (and still feel) is a wonderful
concept, but the world in the meantime seems to have moved on and this
is now something of a backwater. Nobody is looking for Embperl skills. I
think that's kind of sad, given the potential we had here. There used to
be a vibrant community of new users asking how to do this or that, but
now all we have is a bunch of Japanese porn in the email archives, and
no answers from Gerald. I find this very sad, to be honest.
Thanks,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
