Ports Search

This module provides a CodeGenerator for Petal that inherits almost everything from Petal::CodeGenerator but modifies how expressions are dealt with. Petal normally includes code like this $hash->get( "not:user" ) in the compiled template. This means the path has to be parsed and interpreted at runtime. Using Petal::CodePerl, Petal will now produce this ! ($hash->{"user"}) which will be much faster. It uses Parse::RecDescent to parse the PETALES expressions which makes it a bit slow to load the module but this won't matter much unless you have turned off caching. It won't matter at all for something like Apache's mod_perl.

This is a generalized API that allows a module that generates PDFs to transparently target multiple backends without changing its code.

Petal::Mail processes a Petal XML template, and then turns the resulting XML into a text email which can be sent through sendmail or other. The XML has to follow a certain syntax which is defined in this documentation. Since Petal::Mail's is a subclass of Petal, its API is the same. Which means you need to read about Petal before you can use Petal::Mail.

The Petal::Utils package contains commonly used Petal modifiers (or plugins), and bundles them with an easy-to-use installation interface. By default, a set of modifiers are installed into Petal when you use this module. You can change which modifiers are installed by naming them after the use statement: # use the default set: use Petal::Utils qw( :default ); # use the date set of modifiers: use Petal::Utils qw( :date ); # use only named modifiers, plus the debug set: use Petal::Utils qw( UpperCase Date :debug ); # don't install any modifiers use Petal::Utils qw(); You'll find a list of plugin sets throughout this document. You can also get a complete list by looking at the variable: %Petal::Utils::PLUGIN_SET; For details on how the plugins are installed, see the "Advanced Petal" section of the Petal documentation.

This is a port of the glibc gnu regex engine into perl. There are few reasons you would need this. The few I can think of include: 0) You wish to use untrusted user expressions in such a way as to be able to catch errors. Example: eval { alarm 2; m/((){1024}){1024}/ } is an instant uncatchable segmentation fault. GNU's regexps will still fail, but in a timeout way rather than an instant segfault way. 1) You wish to have POSIX compliance on ... something ... Perl's regexps are slightly different -- arguably better, but different.

Petal is a XML based templating engine that is able to process any kind of XML, XHTML and HTML. Petal borrows a lot of good ideas from the Zope Page Templates TAL specification, it is very well suited for the creation of WYSIWYG XHTML editable templates. The idea is to further enforce the separation of logic from presentation. With Petal, graphic designers can use their favorite WYSIWYG editor to easily edit templates without having to worry about the loops and ifs which happen behind the scene.

Dikt is a dictionary for KDE. Dikt is a network application that implements the Dict protocol, with a browser interface specialized for querying dictionaries.

This is a text analyzer for analyzing CJK texts. Plucene does not support CJK texts natively. This module encodes terms in MIME::Base64 format to get around this problem. Texts are assumbed to be in UTF-8 encoding.

An analyzer plugin for p5-Plucene search engine, which filters StandardTokenizer with SnowballAnalyzer.

This provides a simple interface to Plucene. Plucene is large and multi- featured, and it expected that users will subclass it, and tie all the pieces together to suit their own needs. Plucene::Simple is, therefore, just one way to use Plucene. It's not expected that it will do exactly what *you* want, but you can always use it as an example of how to build your own interface.