view release on metacpan or  search on metacpan

lib/App/Chained.pm  view on Meta::CPAN

 
 This will be automatically extracted as we set the B<help> fields to B<\&App::Chained::get_help_from_pod> 
 
 =cut

 sub run
 {
 my ($invocant, @setup_data) = @_ ;
 
 my $chained_app = 
	App::Chained->new
		(
		help => \&App::Chained::get_help_from_pod, 
		version =>  $VERSION,
		apropos => undef,
		faq => undef,
		getopt_data => [] ;
		
		sub_apps =>
			{
			test_application =>
				{
				description => 'executable',
				run =>
					sub
					{
					my ($self, $command, $arguments) =  @_ ;
					system './test_application ' . join(' ', @{$arguments}) ;
					},
				...
				},
			},
			
		@setup_data,
 		) ;
 
 bless $chained_app, $class ;
 
 $chained_app->parse_command_line() ;
 $chained_app->SUPER::run() ;
 }
 
 #--------------------------------------------------------------------------------- 
 
 package main ;
 
 App::Chained::Test->run(command_line_arguments => \@ARGV) ;

=head1 DESCRIPTION

This module implements  an application front end to other applications. As the B<git> command is a front end 
to many B<git-*> sub commands

=head1 DOCUMENTATION

This module tries to provide the git like front end with the minimum work from you. Your sub commands can be implemented in 
perl scripts, modules or even applications written in other languages. You will not have to derive your sub commands from a class I define
nor will you have to  define specific soubrourines/methods in your sub commands. In a word I tried to keep this module as non-intruisive as 
possible.

Putting a front end to height sub applications took a total of 15 minutes plus another 15 minutes when I decided to have a more advanced command
completion. More on completion later.

=head2 What you gain

The Wrapper will handle the following options

=over 2

=item * --help

=item * --apropos

=item * --faq

=item * --version

=item * --generate_bash_completion

=back

=head3 Defining sub commands/applications

 sub_apps =>
  {
  check => # the name of the sub command, it can be an alias
	{
	description => 'does a check', # description
	run => 
  	  sub
	  {
	  # a subroutine reference called to run the sub command
	  # This is a simple wrapper. You don't have to change your modules or scripts
	  # or inherite from any class
			
	  my ($self, $command, $arguments) =  @_ ;
	  system 'your_executable ' . join(' ', @{$arguments}) ;
	  },
			
	help => sub {system "your_executable --help"}, # a sub to be run when help required
	apropos => [qw(verify check error test)], # a list of words to match a user apropos query
	
	options => sub{ ...}, # See generate_bash_completion below
	},
  ...
  }
			
=head1 EXAMPLE

L<App::Requirement::Arch> (from version 0.02) defines a front end application B<ra> to quite a few sub commands. Check the source
of the B<ra> script for a real life example with sub command completion script.

=head1 THIS CLASS USES EXIT!

Some of the default handling will result in this module using B<exit> to return from the application wrapper. I may remove the B<exit> in future
versions as I rather dislike the usage of B<exit> in module.

=head1 SUBROUTINES/METHODS

=cut