*** Although documentation in this file provides some overview, it is
mainly intended for API documentation. See the
HTML::FormHandler::Manual::Intro manpage for a more detailed introduction.

HTML::FormHandler maintains a clean separation between form construction
and form rendering. It allows you to define your forms and fields in a
number of flexible ways. Although it provides renderers for HTML, you can
define custom renderers for any kind of presentation.

HTML::FormHandler allows you to define form fields and validators. It can
be used for both database and non-database forms, and will automatically
update or create rows in a database. It can be used to process structured
data that doesn't come from an HTML form.

One of its goals is to keep the controller/application program interface as
simple as possible, and to minimize the duplication of code. In most cases,
interfacing your controller to your form is only a few lines of code.

With FormHandler you'll never spend hours trying to figure out how to make
a simple HTML change that would take one minute by hand. Because you CAN do
it by hand. Or you can automate HTML generation as much as you want, with
template widgets or pure Perl rendering classes, and stay completely in
control of what, where, and how much is done automatically. You can define
custom renderers and display your rendered forms however you want.

You can split the pieces of your forms up into logical parts and compose
complete forms from FormHandler classes, roles, fields, collections of
validations, transformations and Moose type constraints. You can write
custom methods to process forms, add any attribute you like, use Moose
method modifiers. FormHandler forms are Perl classes, so there's a lot of
flexibility in what you can do.

HTML::FormHandler provides rendering through roles which are applied to
form and field classes (although there's no reason you couldn't write a
renderer as an external object either). There are currently two flavors:
all-in-one solutions like the HTML::FormHandler::Render::Simple manpage and
the HTML::FormHandler::Render::Table manpage that contain methods for
rendering field widget classes, and the the HTML::FormHandler::Widget
manpage roles, which are more atomic roles which are automatically applied
to fields and form if a 'render' method does not already exist. See the
HTML::FormHandler::Manual::Rendering manpage for more details. (And you can
easily use hand-build forms - FormHandler doesn't care.)

The typical application for FormHandler would be in a Catalyst,
DBIx::Class, Template Toolkit web application, but use is not limited to
that. FormHandler can be used in any Perl application.

More Formhandler documentation and a tutorial can be found in the manual at
the HTML::FormHandler::Manual manpage.

This module provides three utility subroutines that make it easier to
develop interactive applications...

* 'is_interactive()'

This subroutine returns true if '*ARGV' and the currently selected
filehandle (usually '*STDOUT') are connected to the terminal. The test is
considerably more sophisticated than:

-t *ARGV && -t *STDOUT

as it takes into account the magic behaviour of '*ARGV'.

You can also pass 'is_interactive' a writable filehandle, in which case
it requires that filehandle be connected to a terminal (instead of the
currently selected). The usual suspect here is '*STDERR':

if ( is_interactive(*STDERR) ) {
carp $warning;
}

* 'interactive()'

This subroutine returns '*STDOUT' if 'is_interactive' is true. If
'is_interactive()' is false, 'interactive' returns a filehandle that does
not print.

This makes it easy to create applications that print out only when the
application is interactive:

print {interactive} "Please enter a value: ";
my $value = <>;

You can also pass 'interactive' a writable filehandle, in which case it
writes to that filehandle if it is connected to a terminal (instead of
writinbg to '*STDOUT'). Once again, the usual suspect is '*STDERR':

print {interactive(*STDERR)} $warning;

* 'busy {...}'

This subroutine takes a block as its single argument and executes that
block. Whilst the block is executed, '*ARGV' is temporarily replaced by a
closed filehandle. That is, no input from '*ARGV' is possible in a 'busy'
block. Furthermore, any attempts to send input into the 'busy' block
through '*ARGV' is intercepted and a warning message is printed to
'*STDERR'. The 'busy' call returns a filehandle that contains the
intercepted input.

A 'busy' block is therefore useful to prevent attempts at input when the
program is busy at some non-interactive task.

The 'Lingua::EN::Sentence' module contains the function get_sentences,
which splits text into its constituent sentences, based on a regular
expression and a list of abbreviations (built in and given).

Certain well know exceptions, such as abreviations, may cause incorrect
segmentations. But some of them are already integrated into this code and
are being taken care of. Still, if you see that there are words causing the
get_sentences() to fail, you can add those to the module, so it notices
them.

It's boring to deal with opening files for IO, converting strings to
handle-like objects, and all that. With the Mixin::Linewise::Readers
manpage and the Mixin::Linewise::Writers manpage, you can just write a
method to handle handles, and methods for handling strings and filenames
are added for you.

sorry, no description found

A logging role building a very lightweight wrapper to the Log::Log4perl
manpage for use with your the Moose manpage classes. The initialization of
the Log4perl instance must be performed prior to logging the first log
message. Otherwise the default initialization will happen, probably not
doing the things you expect.

For compatibility the 'logger' attribute can be accessed to use a common
interface for application logging.

For simple logging needs use the MooseX::Log::Log4perl::Easy manpage to
directly add log_ methods to your class instance.

$self->log_info("Dummy");