Embperl - building dynamic websites with Perl


Recipes
[ << Prev: Session handling ] [ Content ] [ Next: XML, XSLT >> ]

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.


[ << Prev: Session handling ] [ Content ] [ Next: XML, XSLT >> ]


© 1997-2023 Gerald Richter / actevy