A year or so ago I burst back onto the list with some ideas about
boosting Embperl support, and then I promptly disappeared (my
apologies, work and personal stuff took over my life). Those comments
still stand, but I need to approach things a bit more slowly and
realistically.
I think you should look at Catalyst, perhaps the most active Perl Web
development framework. It's a full-featured MVC framework that meets
all of
the above requirements.
I actually have a library that integrates Embperl into Catalyst so
that you ca use it instead of the default system (Template Toolkit).
Embperl is faster and uses less memory than TT. I have the module
working in a production site, and while it needs documentation and
code cleanup, I'd be happy to share it with folks and even set up a
source repository if people are interested in assisting with the
development.
I've also added some Embperl syntax additions (see below).
I think the biggest barrier to expanding Embperl's audience (and
development) is its heavy reliance on some pretty obfuscated C code.
On the other hand, that's one of the reasons it's faster and less
memory hungry than the alternatives. A cleaner rewrite would be nice,
but I think that even just making it more extensible in Perl would be
a big bonus. In particular, the ability to write syntax extensions in
Perl would be a big win and would make it easier to create libraries
to help people move from other systems. The other piece that would
greatly help adoption would be integrating an AJAX system into
Embperl. I'm a big fan of MooTools (it has a *very* well designed
object model, it's clean, and it's small). Anything we could do to
make developing AJAX-based systems in Embperl would be a big win.
Aside from the speed/memory issues, the place Embperl excels is
security. Embperl understands the syntax of the HTML. Every other
templating language out there relies on the programmer to properly
escape their code to prevent XSS vulnerabilities. Embperl *defaults*
to properly escaping output--that's a huge win. Finally, Embperl's
ability to auto-fill forms *greatly* reduces the amount of code in
many applications. Embperl's MVC support is definitely limited, and
that's why I moved to Catalyst as an MVC platform. At some point a
version of Embperl that blocks out the code no longer needed in that
environment might be a good idea.
Syntax Additions
[% %]
Unescaped output. Much easier than [+ do { local($escmode) = 4; ... }
+], particularly useful for generating Javascript.
[$ set VARIABLE EXPRESSION $]
Sets a module-local "variable" (actually a method call) to the
passed-in value[s]. E.g.
[$ set TITLE "My Web Page" $]
The magic comes in retrieval. The simple case works as
expected.
<title>[+ $epreq->TITLE() +]</title>
Will return the value appropriate for the current context.
Which means the value set in the current file, or (if this file
was a template (object_base), the file that is the actual
object. In this sense it's just a slightly easier way to do
what is already possible. More interesting, however is when
the method is passed a non-zero value.
In our template, we define the following.
[$ set CSS qw(template helper $]
In our html file that it executes, we define this:
[$ set CSS qw(index helper $]
Back in the template, we have the following code. Note that
this can occur before any of the other files are included.
<style type="text/css">
<!--
[$ foreach $file ($epreq->CSS(1)) $]
@import url("/styles/[+ $file +].css");
[$ endforeach $]
-->
</style>
The call with the "all" argument set to true will return all of
the values of of all of the "CSS()" methods (with non-unique
elements removed). It will include all methods of all files
that list this file as an "ISA".
[- Execute({ isa => 'filename.epl' }) -] or the case of
"Execute('*')" where the ISA relationship is implicit.
So the above code will generate:
<style type="text/css">
<!--
@import url("/styles/template.css");
@import url("/styles/helper.css");
@import url("/styles/index.css");
-->
</style>
This allows you to create templates which will include CSS,
Javascript or
other elements that are required by individual Embperl files that
aren't
even known about at the time the template is created.
There are a few other additions I've made as well, but the [$ set $]
command is
probably the most useful.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
