Embperl - building dynamic websites with Perl

Starting with 2.0b4 Embperl introduces the concept of recipes. A recipe basically tells Embperl how a component should be build. While before 2.0b4 you could have only one processor that works on the request (the Embperl processor - you're also able to define different syntaxes), now you can have multiple of them arranged 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 normally 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 from some source or do some processing on a source. There is no restriction on 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. In the current implementation Embperl comes with a set of built-in providers:

	file
	read file data
	memory
	get data from a scalar
	epparse
	parse file into a Embperl tree structure
	epcompile
	compile Embperl tree structure
	eprun
	execute Embperl tree structure
	eptostring
	convert Embperl tree structure to string
	libxslt-parse-xml
	parse xml source for libxslt
	libxslt-compile-xsl
	parse and compile stylesheet for libxslt
	libxslt
	do an xsl transformation via libxslt
	xalan-parse-xml
	parse xml source for xalan
	xalan-compile-xsl
	parse and compile stylesheet for xalan
	xalan
	do an xsl transformation via xalan

There is a C interface, so new custom providers can be written, but what makes it really useful is that the next release of Embperl will contain a Perl interface, so you can write your own providers in Perl.

The default recipe is named Embperl and contains the following providers:

    +-----------+
    + file      +
    +-----------+
          |
          v
    +-----------+
    + epparse   +
    +-----------+
          |
          v
    +-----------+
    + epcompile +
    +-----------+
          |
          v
    +-----------+
    + eprun     +
    +-----------+

This cause Embperl to behave like it has done in the past, when no recipes existed.

Each intermediate result could be cached. So for example you are able to cache the already parsed XML or compiled stylesheet in memory, without the need to reparse/recompile it over and over again.

Another nice thing about recipes is that they are not static. A recipe is defined by a recipe object. When a request comes in, Embperl calls the get_recipe method of the application object, which by default calls the get_recipe of the named recipe object, which should return a array that describes what Embperl has to do. The get_recipe methods can of course build the array dynamically, looking, for example, at the request parameters like filename, formvalues, mime type or whatever. For example if you give a scalar as input the Embperl recipe replaces the file provider with a memory provider. Additionally you can specify more then one recipe (separated by spaces). Embperl will call all the new methods in turn until the first one that returns undef. This way you can create recipes that are known for what they are responsible. One possibility would be to check the file extension and only return the recipe if it matches. Much more sophisticated things are possible...

See perldoc Embperl::Recipe for how to create your own provider.