FW: Templating System (preview Embperl 2.0)

[Gerald Richter <ri...@ecos.de>]

I forward this to the Embperl mailing list for those who do not read the
mod_perl list, because I think it's interestinh here too...

-----Original Message-----
From: modperl-return-7180-richter=ecos.de@apache.org
[mailto:modperl-return-7180-richter=ecos.de@apache.org] On Behalf Of
Gerald Richter
Sent: Thursday, July 27, 2000 8:52 PM
To: modperl@apache.org
Subject: RE: Templating System (preview Embperl 2.0)


>
> Jonathan and I spoke briefly at the conference about working together on a
> combined effort of some sort - I could really use Mason's caching
> technology, and he could really use my XML stuff. So maybe something will
> come of that, who knows.

That's exactly what I already started with Embperl 2.0. Embperl 1.3b4
(http://perl.apache.org/embperl/) has already a component handling with the
same power like Mason (also the approach is a little different). Additionaly
it handles some html specific things, that Mason doesn't (like dynamic
tables, formfiled processing, etc.).

Embperl 2.0 add's the possibility to define/modify your own syntax, so you
are able to define custom html/xml tags that call's subroutines (or generate
arbitary perl code, like loops etc.). Also I personaly don't like that
approach, you are able to define very easy things like using the id
attribute of an existing tag, like it was requested earlier in this thread,
to genrate perl code from it. On my talk at the Perl conference I had an
example how at dynamicly rewrite the source url of every image tag, just by
defining a perl subroutine with three lines of code. To keep it fast Embperl
is written in C. It parses the html/xml into a DOM Tree and precompiles the
Perl code into an a Perl sub (That is done by Embperl 1.x already for three
years). Up to this point Embperl 2.0 is already working (also the current
version is called alpha, this is mainly due to the missing features and not
a problem a stability). Next I will add caching of the output or
intermediate steps (the currenty alpha already caches the Source DOM tree
and the compiled Perl code). Unless Mason, Embperl is not only able to cache
plain HTML (or other ascii) files, but also cache DOM trees in any step of
the the processing. To make this memory efficient, I have written a DOM
storage for Embperl which is very memory efficient (e.g. able to store only
differences between serveral modification of a DOM tree) and fast. Like
AxKit Embperl will be able to join any number of processors (stylesheets in
AxKit terminology) to form a processing pipe that modifies the DOM tree.
This will for example make it possible to use EMbperl and SSI in the same
page, while the file must be parsed only once. Since Embperl can replace any
of these steps by custom modules, there will also be the possiblity to use
an XML parser (instead of the Embperl parser, which is optimized for the
current usage) and use things like XSLT to create the HTML (or whatever)
output. For XML processing Embperl 2.0 will offer similar features like
AxKit, but written in C, so it will be faster.

Let me say one word to mixing design and code. Template::Toolkit (and other
modules, which don't directly include perl code), reclains, that they better
separate code and design, but form my point of view they simply create a new
"language". If you want to separate code and design, that could also be done
with modules like Embperl, Mason, ASP which directly inlcude Perl code.
Simply create a Perl module which contains your code and do only calls to
this module and not include the real code in your page. That's only a matter
of discipline. The main adavatage I see for this modules is, that they don't
restrict you to do so. For small projects, it's often very handy to inlcude
the few lines of Perl code you need directly in the page.

Gerald





-------------------------------------------------------------
Gerald Richter    ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:       Tulpenstrasse 5         D-55276 Dienheim b. Mainz
E-Mail:     richter@ecos.de         Voice:    +49 6133 925151
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------

RE: FW: Templating System (preview Embperl 2.0)

[Gerald Richter <ri...@ecos.de>]

>
> Are the different bits of embperl 2 tightly integrated? I would love
> for things like the C DOM tree part to be seperated so we can use that
> kind of thing in other projects. Time to get hacking I suppose ;-)
>

The C DOM tree is mostly spearated, but at the moment not totaly (e.g. it
uses the logging of Embperl). At a later point of developement I plan to
release it as separate module, so it maybe a replacement for XML::DOM. Also
currently it only implements the parts of the DOM API that are neccessary
for Embperl and not the full Specs.

On the Perl conference I talk to some poeple who had a great intereset in
makeing it a fully useable standalone module, because they need it for there
bussines. If they (or anybodyelse) supports this developement (by paying me
for doing so), I can speed up things and this will happen much more
faster... Otherwise it has to wait until I get some free time or anybody
else starts to hacking on it.

Gerald

-------------------------------------------------------------
Gerald Richter    ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:       Tulpenstrasse 5         D-55276 Dienheim b. Mainz
E-Mail:     richter@ecos.de         Voice:    +49 6133 925151
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------

Re: FW: Templating System (preview Embperl 2.0)

[Leon Brocard <ac...@astray.com>]

Gerald Richter sent the following bits through the ether:

> I forward this to the Embperl mailing list for those who do not read the 
> mod_perl list, because I think it's interestinh here too... 
 
What a long thread on the mod_perl list indeed! 
 
> defining a perl subroutine with three lines of code. To keep it fast Embperl 
> is written in C. It parses the html/xml into a DOM Tree  
 
Are the different bits of embperl 2 tightly integrated? I would love
for things like the C DOM tree part to be seperated so we can use that
kind of thing in other projects. Time to get hacking I suppose ;-)

Leon
-- 
Leon Brocard.............................http://www.astray.com/
yapc::Europe - September 22-24 London - http://yapc.org/Europe/

... Error 404: .signature generator ran out of tuits