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...
PICKING A WEB FRAMEWORK
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 AND TEMPLATE::TOOLKIT
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. "$foo.bar" 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 http://www.chamas.com/bench/. 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
Catalyst::View::Embperl::Object.
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 EMBPERL COMMUNITY (NOT)
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.
WHERE I WANT TO GO
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
features.
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.
WHAT I WANT TO KNOW
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?
Well?
-kee
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
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...
PICKING A WEB FRAMEWORK
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 AND TEMPLATE::TOOLKIT
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. "$foo.bar" 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 http://www.chamas.com/bench/. 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
Catalyst::View::Embperl::Object.
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 EMBPERL COMMUNITY (NOT)
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.
WHERE I WANT TO GO
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
features.
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.
WHAT I WANT TO KNOW
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?
Well?
-kee
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
