RE: Some observations (correction)

["Thompson, Jon" <jt...@midwestern.edu>]

It is true that Embperl has become somewhat of a deserted house (at
least that's the impression I get), but like you I believe it is
superior to other alternatives. As far as the fdat hash not working for
you. I think the trick is to also put the keys of %fdat into the @ffld
array. Something like this should work:

[- $fdat{hello} = 'test' -] [# I had this incorrect last time #]
[- push @ffld, 'hello' -]

Since I'm using CGI.pm (don't ask) and not mod_perl I actually set fdat
up manually myself like this:

[- %fdat = %input -]
[- @ffld = keys %fdat -]

Works well. I do wish the community was more active. I dislike PHP (it's
like Perl...just not as elegant) and don't know Ruby.

-----Original Message-----
From: Neil Gunton [mailto:neil@nilspace.com] 
Sent: Wednesday, July 23, 2008 3:35 PM
To: embperl@perl.apache.org
Subject: Some observations

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: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org

Re: Some observations (correction)

[Neil Gunton <ne...@nilspace.com>]

Thompson, Jon wrote:
> Since I'm using CGI.pm (don't ask) and not mod_perl I actually set fdat
> up manually myself like this:
> 
> [- %fdat = %input -]
> [- @ffld = keys %fdat -]

Thanks for that! I have never used ffld, since fdat always seemed to do 
the trick - I could add things to fdat and they would automatically get 
added by any [$ hidden $] blocks. Now, apparently in Embperl 2.x this 
isn't the case.

I just tried adding this before all my [$ hidden $] blocks:

[- @ffld = keys %fdat -]

At first test, it does seem to fix at least some of the issues I've been 
seeing (I have a *lot* of code, so it's going to take a while to track 
down everything that's broken due to the upgrade).

Thanks! This is certainly an easier fix than going around and manually 
adding those fields that were not in the fdat originally.

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org