perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From calypso singer man <al...@netherrealm.net>
Subject Re: Embperl Abandoned: Next Steps?
Date Tue, 21 Oct 2008 13:48:33 GMT
Thanks for these additions Kee. This fixes two of my biggest frustrations
with Embperl. Good job and keep on keeping on.

-Allen

On Fri, Oct 17, 2008 at 08:47:28PM -0400, Kee Hinckley wrote:
> 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
> 

-- 
Happy random title from the Fox News Channel reading list:

'The Lies of George W. Bush: Mastering the Politics of Deception', by David Corn

(http://www.foxnews.com/story/0,2933,77956,00.html)


*******************************************************************
keep it between you and me: get my pgp key with
   gpg --keyserver wwwkeys.nl.pgp.net --recv-keys DEDDEE19
key fingerprint: 68B5 83BA 42CE 3305 F274 3D9E 71BF 4E42 DEDD EE19
*******************************************************************


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


Mime
View raw message