perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kee Hinckley <naz...@somewhere.com>
Subject Re: Embperl Abandoned: Next Steps?
Date Sat, 18 Oct 2008 00:47:28 GMT
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: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Mime
View raw message