App-Framework-Lite
view release on metacpan or search on metacpan
App-Framework-Lite
A (lighter) framework for making script development simpler. The framework does all of the common jobs for you, you just concentrate
on writing the application itself.
Also provides the facility to embed itself into a script to create a stand-alone version that can be distributed.
In other word, this modules provides the basic facilities of App::Framework, but in a more compact manner that can also be wrapped up
into a single-file script.
INSTALLATION
To install this module, run the following commands:
lib/App/Framework/Lite.pm view on Meta::CPAN
package App::Framework::Lite ;
=head1 NAME
App::Framework::Lite - A lightweight framework for creating applications
=head1 SYNOPSIS
use App::Framework::Lite ;
go() ;
sub app
{
my ($app, $opts_href, $args_href) = @_ ;
# options
my %opts = $app->options() ;
# aplication code here....
}
=head1 DESCRIPTION
App::Framework::Lite is a framework for quickly developing application scripts, where the majority of the mundane script setup,
documentation jobs are performed by the framework (under direction from simple text definitions stored in the script). This leaves
the developer to concentrate on the main job of implementing the application.
The module also provides the facility of embedding itself into a copy of the original script, creating a self-contained stand-alone
script (for further details see L</EMBEDDING>).
Note that this module provides a subset of the the facilities provided by L<App::Framework>, In particular, it provides the L<App::Framework::Features:Args>,
L<App::Framework::Features:Options>, and L<App::Framework::Features:Data> features.
To jump straight in to developing applications, please see L<App::Framework::Lite::GetStarted>.
=head2 Capabilities
The application framework provides the following capabilities:
=over 2
=item Options definition
Text definition of options in application, providing command line options, help pages, options checking.
Also supports variables in options definition, the variables being replaced by other option values, application field values,
or environment variables.
lib/App/Framework/Lite.pm view on Meta::CPAN
=item Named data sections
Multiple named __DATA__ sections, the data being readily accessible by name from the application.
Variables can be used in the data definitions, the variables being replaced by command line option values, application field values,
or environment variables.
=item Application directories
The framework automatically adds the location of the script (following any links) to the Perl search path. This means that perl modules
can be created in subdirectories under the application's script making the application self-contained.
The directories used for loading personalities/extensions/features also include the script install directory, meaning that new personalities/extensions/features
can also be provided with a script.
=back
=head2 Using This Module
lib/App/Framework/Lite.pm view on Meta::CPAN
use App::Framework::Lite '+Args(open=none)' ;
=head3 Creating Application Object
There are two ways of creating an application object and running it. The normal way is:
# Create application and run it
App::Framework::Lite->new()->go() ;
As an alternative, the framework creates a subroutine in the calling namespace called B<go()> which does the same thing:
# Create application and run it
go() ;
You can use whatever takes your fancy. Either way, the application object will end up calling the user-defined application subroutines
=head3 Application Subroutines
lib/App/Framework/Lite.pm view on Meta::CPAN
=item * app()
Called once all of the arguments and options have been processed
=item * app_end()
Called when B<app()> terminates or returns (usually of more use to extension developers)
=back
The framework looks for these 3 functions to be defined in the script file. The functions B<app_start> and B<app_end> are optional, but it is expected that B<app> will be defined
(otherwise nothing happens!).
=head3 Setup
The application settings are entered into the __DATA__ section at the end of the file. All program settings are grouped under sections which are introduced by '[section]' style headings. There are many
different settings that can be set using this mechanism, but the framework sets most of them to useful defaults.
For more details see L</Options> and L</Args>.
=head4 Summary
This should be a single line, concise summary of what the script does. It's used in the terse man page created by pod2man.
=head4 Description
As you'd expect, this should be a full description, user-guide etc. on what the script does and how to do it. Notice that this example
lib/App/Framework/Lite.pm view on Meta::CPAN
=head4 Example
An example script setup is:
__DATA__
[SUMMARY]
An example of using the application framework
[ARGS]
* infile=f Input file
Should be set to the input file
* indir=d Input dir
Should be set to the input dir
lib/App/Framework/Lite.pm view on Meta::CPAN
Arguments are specified in the application __DATA__ section in the format:
* <name>=<specification> <Summary> <optional default setting>
<Description>
The parts of the specification are defined below.
=head4 name
The name defines the name of the key to use to access the argument value in the arguments hash. The application framework
passes a reference to the argument hash as the third parameter to the application subroutine B<app> (see L</Script Usage>)
=head4 specification
The specification is in the format:
[ <direction> ] [ <binary> ] <type> [ <multiple> ]
The optional I<direction> is only valid for file or directory types. For a file or directory types, if no direction is specified then
it is assumed to be input. Direction can be one of:
lib/App/Framework/Lite.pm view on Meta::CPAN
A directory
=item s
Any string
=back
Additionally, an optional multiple can be specified. If used, this can only be specified on the last argument. When it is used, this tells the
application framework to use the last argument as an ARRAY, pushing all subsequent specified arguments onto this. Accessing the argument
in the script returns the ARRAY ref containing all of the command line argument values.
Multiple can be:
=over 4
=item '@'
One or more items
=item '*'
Zero or more items. There is also a special case (the real reason for *) where the argument specification is of the form '<f*' (input file multiple). Here, if the script user does not
specify any arguments on the command line for this argument then the framework opens STDIN and provides it as a file handle.
=back
=head4 summary
The summary is a simple line of text used to summarise the argument. It is used in the man pages in 'usage' mode.
=head4 default
lib/App/Framework/Lite.pm view on Meta::CPAN
infile.txt outfile.txt
Results in the arguments HASH:
'file' => 'infile.txt'
'out' => 'outfile.txt'
'file_fh' => <file handle of 'infile.txt'>
'out_fh' => <file handle of 'outfile.txt'>
If this behaviour is not required, then you can get the framework to open just input files, output files, or none by using the 'open' option.
Specify this in the App::Framework 'use' line as an argument to the Args feature:
# Open no file handles
use App::Framework '+Args(open=none)' ;
# Open only input file handles
use App::Framework '+Args(open=in)' ;
# Open only output file handles
lib/App/Framework/Lite.pm view on Meta::CPAN
=item *
Environment variables - if no application fields match the variable name, then the environment variables are used
=back
=head2 Script Usage
The application framework passes a reference to the argument HASH as the third parameter to the application subroutine B<app>. Alternatively,
the script can call the app object's alias to the args accessor, i.e. the B<args> method which returns the arguments value list. Yet another
alternative is to call the args accessor method directly. These alternatives are shown below:
sub app
{
my ($app, $opts_href, $args_href) = @_ ;
# use parameter
my $infile = $args_href->{infile}
lib/App/Framework/Lite.pm view on Meta::CPAN
both the command line options data, but also the man pages, help text etc.
=head3 Option Definition
Options are specified in the application __DATA__ section in the format:
-<name><specification> <Summary> <optional default setting>
<Description>
These user-specified options are added to the application framework options (defined dependent on whatever core/features/extensions are installed).
Also, the user may over ride default settings and descriptions on any application framework options by re-defining them in the script.
The parts of the specification are defined below.
=head4 name
The name defines the option name to be used at the command line, along with any command line option aliases (e.g. -log or -l, -logfile etc). Using the
option in the script is via a HASH where the key is the 'main' option name.
Where an option has one or more aliases, this list of names is separated by '|'. By default, the first name defined is the 'main' option name used
as the option HASH key. This may be overridden by quoting the name that is required to be the main name.
lib/App/Framework/Lite.pm view on Meta::CPAN
Application fields - any fields of the $app object may be used as variables
=item *
Environment variables - if no application fields match the variable name, then the environment variables are used
=back
=head3 Script Usage
The application framework passes a reference to the options HASH as the second parameter to the application subroutine B<app>. Alternatively,
the script can call the app object's alias to the options accessor, i.e. the B<options> method which returns the options hash. Yet another
alternative is to call the options accessor method directly. These alternatives are shown below:
sub app
{
my ($app, $opts_href, $args_href) = @_ ;
# use parameter
my $log = $opts_href->{log}
lib/App/Framework/Lite.pm view on Meta::CPAN
-n|'name'=s Test name [default=a name]
String option, accessed as $opts_href->{name}.
-nomacro Do not create test macro calls
Boolean option, accessed as $opts_href->{nomacro}
-log=s Override default [default=another default]
Over rides the default log option (specified by the framework)
-int=i An integer
Example of integer option
-float=f An float
Example of float option
-array=s@ An array
lib/App/Framework/Lite.pm view on Meta::CPAN
'hash' => {
'key1' => 'val1',
'key2' => 'val2',
}
=head2 Data
After the settings (described above), one or more extra data areas can be created by starting that area with a new __DATA__ line.
The __DATA__ section at the end of the script is used by the application framework to allow the script developer to define
various settings for his/her script. This setup is split into "headed" sections of the form:
[ <section name> ]
<settings>
In general, the <section name> is the name of a field value in the application, and <settings> is some text that the field will be set to. Sections
of this type are:
=over 4
lib/App/Framework/Lite.pm view on Meta::CPAN
(Stored in the application's I<summary> field).
=item B<[DESCRIPTION]> - Application description text
Multiple line description of the application. Used for man pages.
(Stored in the application's I<description> field).
=item B<[SYNOPSIS]> - Application synopsis [I<optional>]
Multiple line synopsis of the application usage. By default the application framework creates this if it is not specified.
(Stored in the application's I<synopsis> field).
=item B<[NAME]> - Application name [I<optional>]
Name of the application usage. By default the application framework creates this if it is not specified.
(Stored in the application's I<name> field).
=back
__DATA__ sections that have special meaning are:
=over 4
=item B<[OPTIONS]> - Application command line options
These are fully described in L<App::Framework::Features::Options>.
If no options are specified, then only those created by the application framework will be defined.
=item B<[ARGS]> - Application command line arguments [I<optional>]
These are fully described in L<App::Framework::Features::Args>.
=back
=head3 Named Data
lib/App/Framework/Lite.pm view on Meta::CPAN
__#
are treated as comment lines and not included in the data.
=head2 Directories
The framework sets up various directory paths automatically, as described below.
=head3 @INC path
App::Framework automatically pushes some extra directories at the start of the Perl include library path. This allows you to 'use' application-specific
modules without having to install them globally on a system. The path of the executing Perl application is found by following any links until
an actually Perl file is found. The @INC array has the following added:
* $progpath
* $progpath/lib
i.e. The directory that the script resides in, and a sub-directory 'lib' will be searched for application-specific modules.
Note that this is the path also used when the framework loads in the core personality, and any optional extensions.
=head2 EMBEDDING
A script may be developed and debugged using the App::Framework::Lite module installed on a system, and then turned into a standalone Perl
script by embedding the App::Framework::Lite module into the script file. Also, a developer may choose to also embed any user library modules
related to this script (or may just deliver them in their dubdirectory along with the standalone script).
=head3 Embedding Procedure
lib/App/Framework/Lite.pm view on Meta::CPAN
=back
=head1 AUTHOR
Steve Price, C<< <sdprice at cpan.org> >>
=head1 BUGS
Please report any bugs or feature requests to C<bug-app-framework-lite at rt.cpan.org>, or through
the web interface at L<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=App-Framework-Lite>. I will be notified, and then you'll
automatically be notified of progress on your bug as I make changes.
=head1 TODO
This version actually contains support for the 'run' and 'logging' features (from L<App::Framework>) as experimental add-ons. Feel free
to use them, but don't expect any support yet!
The next release will have better documentation, feature support, testing etc.
t/05-Data.t view on Meta::CPAN
my $stdout="" ;
my $stderr="" ;
diag( "Testing data" );
my $NAMED1 =<<'NAMED1';
=head2 Named Arguments
The [NAMEARGS] section is used to specify the expected command line arguments used with the application. These "named arguments" provide
a mechanism for the framework to determine if all required arguments have been specified (generating an error message if not), creates
the application documentation showing these required arguments, and allows for easier access to the arguments in the application itself.
Along with specifying the name of arguments, specification of
certain properties of those arguments is provided for.
Argument properties allow you to:
* specify if arg is optional
* specify if arg is a file/dir
* specify if arg is expected to exist (autocheck existence; autocreate dir if output?)
* specify if arg is an executable (autosearch PATH so don't need to specify full path?)
t/05-Data.t view on Meta::CPAN
[DESCRIPTION]
B<$name> does some stuff.
__#================================================================================
__DATA__ named1
=head2 Named Arguments
The [NAMEARGS] section is used to specify the expected command line arguments used with the application. These "named arguments" provide
a mechanism for the framework to determine if all required arguments have been specified (generating an error message if not), creates
the application documentation showing these required arguments, and allows for easier access to the arguments in the application itself.
Along with specifying the name of arguments, specification of
certain properties of those arguments is provided for.
Argument properties allow you to:
* specify if arg is optional
* specify if arg is a file/dir
* specify if arg is expected to exist (autocheck existence; autocreate dir if output?)
* specify if arg is an executable (autosearch PATH so don't need to specify full path?)
t/10-Feature-Run.t view on Meta::CPAN
foreach my $exe (keys %progs)
{
if ($App::Framework::Lite::AVAILABLE_MOD{'File::Which'})
{
if ($exe eq 'not-there')
{
is($required->{$exe}, undef, "$exe status") ;
}
else
{
## if we can find it then the framework should find it
if (which($exe))
{
ok ($required->{$exe}, "Expected to find $exe") ;
}
else
{
is($required->{$exe}, undef, "Expected not to find $exe") ;
}
}
}
t/embed/lib/MyObj.pm view on Meta::CPAN
catch_fn set for this object instance
any registered global catch function (last registered first)
default handler
Global catch functions, when registered, are added to a stack so that the last one registered is called first.
Each handler must return either 1=handled, or 0=not handled to tell this object whether to move on to the next handler.
NOTE: The default handler may be over-ridden by any derived object.
This object is set up such that when used as stand-alone objects (i.e. outside of an application framework), then errors are handled
with die(), warn() etc.
=head1 DIAGNOSTICS
Setting the debug flag to level 1 prints out (to STDOUT) some debug messages, setting it to level 2 prints out more verbose messages.
=head1 AUTHOR
Steve Price C<< <sdprice at cpan.org> >>
( run in 0.812 second using v1.01-cache-2.11-cpan-e1769b4cff6 )