Within the next two months the next generation (2.0) of Embperl will most likely be released. The current Beta release is 2.0b7, which is most likely stable enough for a production environment, the author uses it in production, but then again he can fix it if it breaks :). The focus of HTML::Embperl has always been on web applications and now with the release of 2.0 the ability to use Embperl outside of an HTML environment is finally achieved. Here is a quick run down of the new features available in 2.0
Most of this information is in the README.v2 that comes with the 2.0b7 module and is not in the main documenation. Some of it is also still "hidden" in the Changes.pod file.
- XML and XSLT support: Multiple transformers are supported for XSLT including setting it to your own "non-standard" one
- Syntax Definitions: So far there are syntax definitions for SSI, Text only, Perl only,
ASP, POD, RTF and a Mail taglib. You can also specify more then one syntax at the same
time, e.g. [$syntax Embperl SSI $] to mix Embperl tags and SSI tags in the same
page.
- Faster - Benchmarks show a 50 - 100% increase
- Now consists of three major objects: Application, Request, and Component. These can be overriden as needed
- Debugging can now be done via the interactive debugger, or with the graphical GNU debugger ddd
- Better configuration options for Virtual, Location, and Directory directives in your httpd.conf. Each can have its own set of EMBPERL directives.
- Recipes - Tells Embperl how a component should be built. You can alter any stage of the processing of the file through the Recipes directives. 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.
- 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.
Internationalisation (I18N) - You can create language files and set the language via an EMBPERL directive in the httpd.conf based on Location, Directory, Virtual host etc. This feature could also be handy even if you wanted to use it for just one language and have it act as a repository for various messages in your app.
Added form data validation. Embperl is now capable of server-side
and client-side validation of form input. You just have to define
a set of rules and Embperl generates the correct JavaScript code and
does the validation when the form data is posted to the server. By
writing or overriding class, the validatior could be extented.
See Embperl::Form::Validate for details.
Those are just some of the high points. You can see my
review of HTML::Embperl for some insight into why I like it and all the good features are carrying forward to Embperl.
You can visit the Embperl
site here.