perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kee Hinckley <>
Subject Using Catalyst to revitalize Embperl
Date Wed, 08 Aug 2007 20:45:02 GMT
This is going somewhere.  Hang with me through the intro.  The goal  
is simple.  I want Embperl back in the limelight where it belongs.  I  
haven't run this past Gerald, so I hope I'm not stepping on any toes,  
but here goes...

It's been a long time since I've been active on this list.  I spent  
several years in Java hell, learning how *not* to do web frameworks.   
Then I was back doing some consulting.  Now I have a new startup  
under way.

When I started the new company, I looked around to see what the state  
of Perl web frameworks was.  Mason is still around, but frameworks  
have moved on.  Jifty is interesting, but it's not polished enough  
yet.  Embperl::Object still does what it used to, but it too hasn't  
really moved with the times. Everyone buzzes about Ruby on Rails, and  
there are clear advantages to having a structured development  
environment.  I wanted to find the Perl successor to RoR.  I settled  
on Catalyst with Template::Toolkit.  (Frankly, the dearth of choices  
is depressing.  Far too many of the key Perl players have gone off to  
play with Perl 6 when Perl's survival is much more dependent upon Web  
and Application frameworks.  Right now Catalyst and POE are about all  
we've got.  But that's another discussion.)

Catalyst provides an MVC framework in the Perl tradition--by which I  
mean that it provides a nice framework, and then lets you bypass it  
if you need to.  As opposed, for instance, to Java Struts, about  
which the less said, the better.  Catalyst also has a very nice  
plugin model, and it uses the NEXT module, so it's possible to insert  
plugin logic into the existing stream of things.  Additionally, the  
support for class variables is very useful.  There's also some  
progress towards providing tools to create a basic application  
framework, so you can get up and running fast.  The documentation  
isn't wonderful, but it's not bad.

TT is interesting.  At first blush I kind of liked it.  You don't  
have to worry about whether something is a scalar, an array or a  
method--it just works. "$" might translate to "$foo->{bar}" or  
"$foo->bar()", you don't need to know. It has an interesting object/ 
method model.  And it has good plugin support as well.  However, a  
couple things bugged me.

1. The scripting meta language is kinda like Perl6, and kinda like  
nothing else.  Yet another thing to learn.  Furthermore, while it's  
all very fine to say that you aren't supposed to do much coding in  
the "View".  Practically it's not that simple.  So when you need to  
do something fancy to make the presentation work on the server side-- 
you really want the full power and syntax of Perl available to you.   
TT is just not designed for that.

2. While not worrying about your data structures may make life easier  
for the web designer, it can lead to sloppy and confusing code.  And  
the programmer *does* have to translate between the backend and the  
frontend, and looking at the two sides, using different syntaxes, can  
be very confusing.  And it's inefficient.

3. Which led to the next issue. Performance. I heard SixApart had  
been having issues with TT.  I got worried and did some checking  
around.  That took me to  Which claims  
that on non-trivial templates, Embperl2 uses half as much memory, and  
is a third faster, than Template::Toolkit.  On small templates their  
speed is comparable, but TT uses 3x the memory of Embperl.

4. Security.  There's one thing that Embperl does that nobody else  
does.  It auto-escapes your output.  You have to go out of your way  
to let something get displayed to the user that isn't escaped.   
(Perhaps too far out of your way, but that's easily fixed.   
Furthermore, the escaping is contextual.  TT, like all the other  
systems out there, leaves it up to the programmer to "do the right  
thing."  In a URL?  Then you want "$foo | url".  In HTML?  you want  
"$foo | html".  And so on.  We all know that programmers *don't*  
always do the right thing.  And I'll put up with an awful a lot of  
grief for a template system that virtually guarantees I won't have  
cross-site scripting holes.

So, I bailed on Template::Toolkit and installed  

The Embperl::Object View plugin for Catalyst kind of gets you up and  
running, but it's really not useable overall.  It neither integrates  
with Catalyst, nor gives you full access (at least in the Catalyst  
debug server) to the EO functionality.  A week later I had a  
completely new implementation, with much tighter integration.  It's  
not quite ready for public release, but it will be soon. More on that  
in a minute.

The traffic on the Embperl list is sadly low.  I don't know how many  
readers there are (should I post this to the mod_perl lists as  
well?)  Unfortunately the community has never really taken Embperl  
and run with it the way they have with some other systems.  I think  
there are a variety of reasons for that.  There's a fair amount of C  
code, and it's pretty hairy (although it rarely needs to be  
touched).  It could really use a good community effort to come up  
with better documentation and examples--I have enough trouble  
documenting my code, I don't know how Gerald rights the code, the  
docs AND translates them.  Also, because there's no high-level  
framework like Catalyst, everyone does things somewhat differently,  
so it's difficult to separate out the cool stuff you've did in your  
web site and make it useable by others.  There's also no good way to  
provide compatible plugins.  (The syntax modules go a long way in  
this direction, but they really need to be subclassed and simplified  
one more level.)  Some parts of Embperl are also a bit hard to  
subclass (the model of mapping global variables temporarily into  
local space is a bit messy and hard to extend, and some things are  
virtually impossible to subclass/replace (the C-based ::Config  
modules, or anything that gets called as Embperl::foo($ref) instead  
of $ref->Embperl::foo()).  And I won't go into the things I had to do  
in order to make Embperl hold off configuring itself until my  
application was in control.  Or trying to make it run as a simple  
library under mod_perl without compiling it with the mod_perl libraries

But all of those things can be fixed.  Catalyst provides a robust  
framework.  Embperl fits in it very well.  And Embperl is  
demonstrably better in many ways than any of the other templating  
libraries available in Catalyst or elsewhere.

So.  Here's where my head is at.

1. I've got a new startup (social-networking related, needs to scale  
massively, the usual Web2.0 requirements).  I'm committed to using  
Catalyst and Embperl::Object, and I'm committing to feeding back any  
enhancements of those to the community.  But I'd hate to make all  
this effort and be left as the last user.  Never mind that I have  
another project in mind in which Embperl would run within an  
application context, rather than over the internet.  So I want to see  
a growing Embperl community again.

2. Embperl provides a number of features that simply don't exist  
elsewhere. I believe those features make it a far better View  
component for Catalyst (or any other framework) than any other  
templating solutions.

a. A fast, low-memory implementation with critical pieces written in C.

b. An efficient, well tested caching and pre-caching system.

c. A parser that understands HTML and provides needed security in  
presenting user-provided data in HTML.

d. An extensible templating language.
Want a way to output unescaped content when you need to, without  
using $escmode?  Subclass Syntax::EmbperlBlocks and add a new  
directive. [% %] for unescaped data.

e. An excellent object-oriented framework for managing templates,  
includes and libraries of HTML functions.

f. Form autofill.
It amazes me how many hoops other developers have to jump through  
just to display the stuff the user already entered a minute ago.

3. Embperl integrated with Catalyst provides (so far) the following  

a. The Catalyst "stash" elements automatically become modifiable  
variables in the Embperl context.
E.g.  If you do "$c->stash->{myhash} = {a => 1, b => 2}" in your  
Catalyst Controller, the variable %myhash will be instantiated in the  
Embperl files.

b. Error to exception handling.
Embperl errors are translated into exception objects before being  
passed to Catalyst.  Embperl logging is also intercepted and moved  
into the Catalyst context.

c. Contextual error debugging
Embperl errors (and warnings, if there was an error) are displayed on  
the Catalyst debug screen in context (line numbers, context, error  
line highlighted, error text, if any, underlined).

d. Catalyst cookie/session/parameter information is integrated with  
traditional Embperl mechanisms.
%fdat and friends are available so that you can continue to use them,  
although the Catalyst "$c" variable also gives you access to them.  
(In addition, %nfdat exists with arrays for multiple values instead  
of tab separations--however I'd like to make that an Embperl option.)

e. Plugin mechanism in progress.
I'm starting with things like the HTML::Prototype library.  There  
needs to be an easy way to import that into Embperl and make sure  
that all the escaping is done right.  I'm also looking at easy ways  
to install multiple syntax extensions.  (E.g. when I want to use my  
EmbperlBlock syntax extension AND yours).

f. Everything Embperl already did.
It may seem obvious, but it's a big boon for development when I can  
put the display, controller logic, and database code all in the same  
HTML file.  Didn't I just say that MVC was the way to go?  Yes,  
absolutely.  But it's a *lot* faster to do the testing in one HTML  
file, and then once it works, move all the pieces where they really  
belong.  The power of Embperl, and the flexibility of Catalyst, let  
you do that when you need to.  Could you do it in Template::Toolkit?   
Maybe.  But when it came time move the code to the Controller and  
Model, you'd have to rewrite it all--because TT doesn't use Perl as  
the scripting language.  With Embperl it's just cut and paste.

The question is very simple.  Are other people interested in going in  
this direction?  If I put out an Embperl::Object View component for  
Catalyst, is anyone going to use it?  And if I start discussing how  
we can grow and extend Embperl, is anyone going to answer back?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message