AxKit versus Embperl2

Introduction to AxKit

Introduction to Embperl

From 'README.v2' and 'Changes', which are included with the distribution. The Embperl core now works in a totaly different way. It is divided into smaller steps.

  1. reading the source
  2. parseing
  3. compiling
  4. executing
  5. outputing

Further version will allow to replace every single step of this pipeline with custom modules. Also it will be possible to cascade multiple processors. This allows for example to have Embperl and SSI in one file and to parse the file only once, feeding it first to the SSI processor and afterwards to the Embperl processor. Also the parser will be exchangeable in future version to allow for example to use an XML parser and an XSLT stylesheet processor.

Recentely added is Embperl::Object application object, which is invoked during request initialization. Any application code can now go there. This allows a proper separation of Code and Design and building of MVC (Model, Controller, View), 2-Tier and 3-Tier applications with Embperl.

Starting with 2.0b4 Embperl introduces the concept of recipes. A recipe basicly tells Embperl how the request should be processed. While before 2.0b4 you can have only one processor that works on the request (the Embperl processor, also you are able to define different syntaxes), now you can have multiple of them arragend in a pipeline or even a tree. While you are able to give the full recipe when calling Execute, this is not very convenient, so normaly you will only give the name of a recipe, either as parameter 'recipe' to Execute or as EMBPERL_RECIPE in your httpd.conf. Of course you can have different recipes for different locations and/or files. A recipe is constructed out of providers. A provider can either be read some source or do some processing on a source. There is no restriction what sort of data a provider has as in- and output you just have to make sure that output format of a provider matches the input format of the next provider.

Embperl::Syntax provides a base class from which all custom syntaxes should be derived. Currently Embperl comes with the following derived syntaxes.

The two platforms compared

Now that Embperl2 is basically done, it is more then just perl embedded into HTML. It is really a whole new web application platform, and it appears to be fully capable, or nearly fully capable, of what AxKit is capable.

For example, it is now very simple to set up a base template (base.html), and XSL stylesheet. Then, drop in all the content, and the template and stylesheet get applied to it. Embperl2 comes with a POD example for this. One of the tests takes a bunch of plain POD files, and transforms it into HTML on the fly. Extremely cool. So, one could set up multiple base templates, to make it simple to generate PDF, RTF, or TXT output formats.

If you read the description of AxKit on their site, with the documentation for Embperl 2.0 (which doesn't exist yet), they are quite similiar.

That fact really shows why Embperl is not getting mass exceptance yet, compared to other technologies like TemplateToolkit, PHP, and so on. The really cool stuff isn't being documented and demonstrated yet.

see also Perl, PHP, TemplateToolkit, Embperl, AxKit