App-Framework
view release on metacpan or search on metacpan
Corrected Extension & Filter modules
Updated some more POD
0.92 Tue May 18 12:30:00 2009
Tweak to Makefile to correct removal of old installation
0.91 Tue May 18 08:07:00 2009
MANIFEST corrections
0.90 Mon May 18 12:30:00 2009
Major re-write to make the framework modular. Now has core/extensions/features
NOTE: Application 'run' subroutine renamed to 'app'
0.07 Sat Mar 14 20:33:00 2009
Bug fix: Corrected Sql initialisation (was claiming DBI not installed)
Added: -man-dev option to display app developer man pages
Added: allow 'dev:' prefix to make option only show in developer man pages
Added: Sql support for 'group by'
0.06 Thu Mar 05 15:09:00 2009
Updated script pod. Modified so that scripts can be used without DBI. Corrected build fail when DBI not installed.
App-Framework
A framework for making script development simpler. The framework does all of the common jobs for you, you just concentrate
of writing the application itself.
Also provides various useful utility functions via the 'Feature' modules.
INSTALLATION
To install this module, run the following commands:
perl Makefile.PL
examples/eg1.pl view on Meta::CPAN
#=================================================================================
__DATA__
[HISTORY]
28-May-08 SDP New
[SUMMARY]
An example of using the application framework with named arguments
[ARGS]
* src_dir=d Source directory
* backup_dir=d Backup directory
[OPTIONS]
-database=s Database name [default=test]
examples/eg2.pl view on Meta::CPAN
#=================================================================================
#=================================================================================
# SETUP
#=================================================================================
__DATA__
[SUMMARY]
An example of using the application framework with config file
[OPTIONS]
-int=i An integer
Example of integer option
-float=f An float
lib/App/Framework.pm view on Meta::CPAN
package App::Framework;
=head1 NAME
App::Framework - A framework for creating applications
=head1 SYNOPSIS
use App::Framework ;
App::Framework->new()->go() ;
sub app
{
my ($app, $opts_href, $args_href) = @_ ;
# options
my %opts = $app->options() ;
# aplication code here....
}
=head1 DESCRIPTION
App::Framework is a framework for quickly developing application scripts, where the majority of the mundane script setup,
documentation etc. jobs are performed by the framework (usually under direction from simple text definitions stored in the script).
This leaves the developer to concentrate on the main job of implementing the application.
To jump straight in to developing applications, please see L<App::Framework::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.pm view on Meta::CPAN
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 Personalities
Single line selection of the base application type (i.e. command line script, Tk application, POE application etc).
Modular application framework allows for separate installation of new personalities in the installed Perl library space, or locally under
an application-specific directory.
=item Extensions
Single line selection of one or more application extension plugins which modify the selected personality behaviour.
Modular application framework allows for separate installation of new extensions in the installed Perl library space, or locally under
an application-specific directory.
Example extensions (may not be installed on your system):
=over 4
=item Daemon
Selecting this extension converts the command line script into a daemon (see L<App::Framework::Extension::Daemon>)
=item Filter
Sets up the application for file filtering, the framework doing most of the work in the background (see L<App::Framework::Extension::Filter>).
=item Find
Sets up the application for file finding, the framework doing most of the work in the background
=back
=item Features
Single line selection of one or more application feature plugins which provide application targetted functionality (for example Sql support,
mail handling etc).
Modular application framework allows for separate installation of new features in the installed Perl library space, or locally under
an application-specific directory.
Example features (may not be installed on your system):
=over 4
=item Config
Provides the application with configuration file support. Automatically uses the configuration file for all command line option
settings (see L<App::Framework::Feature::Config>).
lib/App/Framework.pm view on Meta::CPAN
=item Mail
Provides mail send support (including file attachment) (see L<App::Framework::Feature::Mail>).
=back
=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 Framework Components
The diagram below shows the relationship between the application framework object (Framework) and the other components:
+--------------+
| Core |
+--------------+
^
|
|
+--------------+
| Personality | Script, POE etc
+--------------+
lib/App/Framework.pm view on Meta::CPAN
use App::Framework '::Daemon ::Filter'
(See L<App::Framework::ExtensionModules> for your currently installed extensions)
Like the personality, all of the methods defined in the selected extensions add to the core methods and are available to the application
object ($app).
=head3 Features
Features provide additional application capabilities, optional modifying what the application framework does depedning on the feature. A feature
may also simply be an application-specific collection of useful methods.
Unlike core/personality/extension, features are not part of the application object - they are kept in a "feature list" that the application can
access to use a feature's methods. For convenience, all features provide an accessor method that is aliased as an application method
with the same name as the feature. This access method provides the most commonly used functionality for that feature. For example, the 'data'
feature provides access to named data sections as:
my $data = $app->data('named_section') ;
Alternatively, the data feature object can be retrieved and used:
lib/App/Framework.pm view on Meta::CPAN
=head2 Using This Module
To create an application you need to declare: the personality to use, any optional extensions, and which features you wish to use.
You do all this in the 'use' pragma for the module, for example:
use App::Framework ':Script ::Filter +Mail +Config' ;
By default, the 'Script' personality is assumed (and so need not be declared), and the framework ensures that all of the features it requires are always loaded (so you don't
need to declare +Args, +Options, +Data, +Pod, +Run). So, the minimum is:
use App::Framework ;
=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->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.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. The most common sections are described below.
=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
has used one (of many) of the variables available: $name (which expands to the script name, without any path or extension).
lib/App/Framework.pm view on Meta::CPAN
For full details, see L<App::Framework::Feature::Args>.
=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.pm view on Meta::CPAN
my $contents2 = $app->data('a_bit_of_sql.sql') ;
# or
$contents2 = $app->data('data2') ;
See L<App::Framework::Feature::Data> for further details.
=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.
=head3 Feature modules
When the application framework loads in the various required and user-specified features, then it attempts to load the following feature modules until one is sucessfully loaded:
* App::Framework::Feature::${personality}::${feature}
* App::Framework::Feature::${feature}
Where ${feature} is the name of the feature being loaded (e.g. Config), and ${personality} is the specified core personality (e.g. Script). Note that it does this using the L</@INC path>, so
an application can bundle it's own feature's in under it's own install directory.
=head2 Settings
lib/App/Framework.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 at rt.cpan.org>, or through
the web interface at L<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=App-Framework>. I will be notified, and then you'll
automatically be notified of progress on your bug as I make changes.
=head1 SUPPORT
You can find documentation for this module with the perldoc command.
perldoc App::Framework
lib/App/Framework/Base/Object/ErrorHandle.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> >>
lib/App/Framework/Debugging.pod view on Meta::CPAN
=head1 NAME
App::Framework::Debugging - Debugging tools/methods
=head1 DESCRIPTION
There are some mechanisms built into the application framework that provide methods of getting extra script debugging information. I have also
described below some of the external tools I've found useful when debugging my scripts.
=head2 Printing
The application framework object (referred to as B<$app> here) has a B<prt_data> method that provides a hierarchical printout of HASHes, ARRAYs,
and scalars. This method always outputs.
An alternative is to use the B<debug_prt> method. This prints out information, but only if the debug command line option has been set. You may also
specify the debug level above which the debug option has to be set before any output appears. Some examples are:
sub app
{
my ($app, $opts_href, $args_href) = @_ ;
my %a_hash ;
lib/App/Framework/Debugging.pod view on Meta::CPAN
=head2 Debugger
In certain circumstances, I've had to resort to a GUI debugger. The one I use is Devel::ptkdb at L<http://search.cpan.org/~aepage/Devel-ptkdb/>
and you run your script as:
perl -d:ptkdb your_script.pl
Note that on startup you won't see the various B<Feature> modules loaded up in the 'open file' menu. This is because the framework dynamically loads them.
If you set a breakpoint in your B<app()> subroutine, then they are all loaded by then.
=head2 Profiler
I have also found it useful to profile scripts to find whatever is slowing the script down. I've found that the default Perl profiler (Devel::prof)
doesn't like my framework! The alternative I use is Devel::FastProf at L<http://search.cpan.org/~salva/Devel-FastProf/> which produces
counts per module line. You gather the data as:
perl -d:FastProf your_script.pl
to produce a binary file B<fastprof.out> which you convert into text using B<fprofpp>:
fprofpp > your_script.txt
As I also prefer to see which function the line number is refering to, I use my script (using the App::Framework Filter extension!) to post-process
the data. My script is available from L<ftp://www.cpan.org/authors/id/S/SD/SDPRICE/Examples/App-Framework/Filter/> and is run as:
lib/App/Framework/Extension/Filter.pm view on Meta::CPAN
$state_href->{'output'} = $line if $ok ;
}
#=================================================================================
# SETUP
#=================================================================================
__DATA__
[SUMMARY]
Filter Doxygen created html removing frames etc.
[DESCRIPTION]
B<$name> does some stuff.
The script takes in HTML of the form:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<title>rctu4_test: File Index</title>
lib/App/Framework/Feature.pm view on Meta::CPAN
=over 4
=item B<app> - Parent application
Set by App::Framework as a reference to the application object. If this is not set, then the feature will skip any application-specific
logic (allowing a feature to be used in the user part of an application as a stand alone object).
=item B<registered> - list of registered application functions
ARRAY ref to list of functions that this feature wants to register in the application. When a registered function is called by the framework,
then the feature's method (of the same name) is also called.
Function name is of the form <name>_entry (called at the start of <name>) or <name>_exit (called at the end of <name>)
=item B<name> - feature name
Set to the feature name (by the App::Framework). This is the name used by the application to access the feature
=back
lib/App/Framework/Feature.pm view on Meta::CPAN
=cut
#============================================================================================
#-----------------------------------------------------------------------------
=item B< register_app() >
Registers this feature with the parent application framework (if specified)
=cut
sub register_app
{
my $this = shift ;
my $app = $this->app ;
if ($app)
{
## if we need to, register our methods with the application framework
my $methods_aref = $this->registered ;
if (@$methods_aref)
{
$app->feature_register($this->name, $this, @$methods_aref) ;
}
}
}
lib/App/Framework/Feature/Args.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.
=head3 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>)
=head3 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/Feature/Args.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
=head3 summary
The summary is a simple line of text used to summarise the argument. It is used in the man pages in 'usage' mode.
=head3 default
lib/App/Framework/Feature/Args.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/Feature/Args.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/Feature/Data.pm view on Meta::CPAN
# Data feature is loaded by default as if the script contained:
use App::Framework '+Data' ;
=head1 DESCRIPTION
System feature that provides the application core with access to the setup information stored
in the __DATA__ section.
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/Feature/Data.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
=head2 Named Data
lib/App/Framework/Feature/Logging.pm view on Meta::CPAN
=over 4
=cut
#============================================================================================
#----------------------------------------------------------------------------
=item B<application_entry()>
Called by the application framework at the start of the application.
This method checks for the user specifying any of the options described above (see L</ADDITIONAL COMMAND LINE OPTIONS>) and handles
them if so.
=cut
sub application_entry
{
my $this = shift ;
lib/App/Framework/Feature/Mail.pm view on Meta::CPAN
=cut
*Mail = \&mail ;
#----------------------------------------------------------------------------
=item B<application_entry()>
Called by the application framework at the start of the application.
This method checks for the user specifying any of the options described above (see L</ADDITIONAL COMMAND LINE OPTIONS>) and handles
them if so.
=cut
sub application_entry
{
my $this = shift ;
lib/App/Framework/Feature/Options.pm view on Meta::CPAN
both the command line options data, but also the man pages, help text etc.
=head2 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.
=head3 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/Feature/Options.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
=head2 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/Feature/Options.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/Feature/Pod.pm view on Meta::CPAN
App::Framework::Feature::Pod - Application documentation
=head1 SYNOPSIS
# Data feature is loaded by default as if the script contained:
use App::Framework '+Pod' ;
=head1 DESCRIPTION
Used by the application framework to create pod-based man pages and help.
=cut
use strict ;
use Carp ;
our $VERSION = "1.002" ;
#============================================================================================
lib/App/Framework/Feature/Pod.pm view on Meta::CPAN
=over 4
=cut
#============================================================================================
#----------------------------------------------------------------------------
=item B<application_entry()>
Called by the application framework at the start of the application.
This method checks for the user specifying any of the options described above (see L</ADDITIONAL COMMAND LINE OPTIONS>) and handles
them if so.
=cut
sub application_entry
{
my $this = shift ;
lib/App/Framework/GetStarted.pod view on Meta::CPAN
# do something more useful...
}
#=================================================================================
# SETUP
#=================================================================================
__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/GetStarted.pod view on Meta::CPAN
# Create application and run it
go() ;
It's usually a "good thing" to define a version number (and better still, keep it updated as the script changes!). If you do define a $VERSION
at the start of the script, App::Framework will use it when displaying script manual pages.
=head2 Set-up
The command-line arguments and options are defined in a text section at the end of the program. In fact it's actually part of a
__DATA__ definition. 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 since the framework sets most of them to useful defaults, then the most common
settings are:
=over 4
=item *
SUMMARY
=item *
lib/App/Framework/GetStarted.pod view on Meta::CPAN
[ (<|>|>>) ] [b] (f|d|s) [@|*]
The optional I<direction> can be one of: <, >, or >> signifying input, output, or appended output.
The I<type> can be: s, f, or d for string, file, or directory.
An optional 'b' after the direction specifies that the file is binary mode (only used when the type is file).
Additionally, an optional multiple can be specified as: @ or *. 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 (don't worry, an example should make this clear).
The difference between @ and * is that @ specifies that there must be at least one argument specified, whereas * expects 0 or more arguments.
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.
Defaults, where specified, are in the format:
[default=<value>]
If a default is specifed, this makes this argument optional. It also makes all subsequent arguments optional. Optional arguments are not checked for by the application (and if
they are not specified will take the default value).
The main reason for specifying arguments is to get the framework to do all the work of checking for you. All (non optional) values are checked to ensure that the user specified
something on the command line. This is all the checking string arguments are given. However, input file and directory arguments are also checked for presence, causing an error
message if they are not present.
For the lazy, you'll appreciate the fact that the framework does even more for you. By default, any arguments specified as input files will be opened for reading; output files will be opened for writing; output directories will be created. In additio...
specified with >> will be appended to (rather than truncated). All of these opened files are passed in as file handles in the arguments HASH named with the argument name suffixed
by '_fh' (you can turn this off by declaring the Args feature with 'open' settings - see L<App::Framework::Feature::Args>).
For example, with the following specifications
* infile=<f
* outfile=>f
the command line arguments (and opened files) can be accessed with the argument HASH keys:
lib/App/Framework/GetStarted.pod view on Meta::CPAN
=head2 Application body
sub app
{
my ($app, $opts_href, $args_href) = @_ ;
....
}
The application framework calls the subroutine B<app> with 3 parameters:
=over 4
=item *
$app - The application object
=item *
$opts_href - An HASH ref of the options
lib/App/Framework/GetStarted.pod view on Meta::CPAN
$infile = $args[0] ;
}
=head2 Advanced
In addition to the straightforward cases described above, additional features may be optionally included into the script as described below.
=head3 Data sections
The framework installs the 'Data' feature automatically in order to process the script settings. The user may then add additional data sections
below the setup. These data sections can be named, and the data contents accessed via this name. Also, the contents (text) of the data sections
may contain variables the are expanded from the current settings of options, application setup, or the environment variables.
For example, the following data definition:
__DATA__
[SUMMARY]
Tests the application object with SQL
lib/App/Framework/GetStarted.pod view on Meta::CPAN
`date` date NOT NULL,
`start` time NOT NULL,
KEY `pid` (`pid`),
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
For further details see L<App::Framework::Feature::Data>
=head3 Configurations
A configuration file may be used to provide all of the application's option settings, rather than supplying them at the command line. The default setup of the Config feature
is to attempt to read the configuration file named ${name}.conf (where ${name} is the script name). The framework, by default, will search for this file in three directories depending
on operating system. For example, a script 'test_script' will look for it's configuration file on Linux in:
$HOME/.test_script
/etc/test_script
/usr/local/bin/config
The configuration file contents, at simplest, are just variable=value pairs with optional descriptive comments. For example:
# Server port number
port = 32023
lib/App/Framework/GetStarted.pod view on Meta::CPAN
You use the B<Run> feature to execute external programs. First, you should specify which programs you want to run in the script. This
step is not necessary, but it checks up front that all the programs you want to use are actually installed:
use App::Framework '+Run'
...
my $run = $app->run ;
# get the framework to abort if some programs are not installed
$run->on_error('fatal') ;
# check your programs
$run->required(
{
'lsvob' => 1,
'ffmpeg' => 1,
'transcode' => 1,
'vlc' => 1,
},
lib/App/Framework/Settings.pm view on Meta::CPAN
package App::Framework::Settings ;
=head1 NAME
App::Framework::Settings - Application framework configuration
=head1 DESCRIPTION
Contains various configuration settings for the application framework objects.
=cut
use strict ;
use Carp ;
our $VERSION = "1.000" ;
#============================================================================================
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
my $required = $run->required({ %progs }) ;
$app->prt_data("Required stats=", $required) ;
foreach my $exe (keys %progs)
{
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") ;
}
}
}
( run in 1.560 second using v1.01-cache-2.11-cpan-e1769b4cff6 )