>
> 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: [EMAIL PROTECTED] Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
