view release on metacpan or  search on metacpan

lib/App/quickstart.pod  view on Meta::CPAN

#!perl -w
# run this document through perl to check its syntax
use Pod::Checker;
podchecker(\*DATA);
__END__

=head1 NAME

App::quickstart - App::Context Developer's Quick-Start Guide

=head1 INTRODUCTION

This is the Developer's Quickstart Guide to the App::Context Framework.
Its focus is to give a minimum amount of theoretical or explanatory
background and get right into learning by example.

=head1 DOCUMENTATION OVERVIEW

That having been said, it is also important to let you know
what documentation exists and what state it is in.

I got started building the App::Context framework a while ago.
The documentation is very limited.  This is an effort to bring it all together.
This list shows how all of the documentation fits together and in what state
it is.

=head2 PURE DOCUMENTATION

The following documentation is in good shape.
To get started, read them more or less in the order shown.
 
=over

=item * L<App::quickstart> - This quick start guide.

=item * L<App::installguide::hosted> - Installing the App::Context Framework on a non-root web hosting account

=back

The following documentation also is in good shape.
It is background reference material.

=over

=item * L<App::datetime> - Guidance on date, time, and datetime types in perl.

=item * L<App::exceptions> - Guidance on exceptions in perl.

=back

The following documentation is in a state that needs review, modification, or completion.
 
=over

=item * L<App::perlstyle> - A perl style guide that builds minimally on L<perlstyle>.

=item * L<App::faq> - Questions about P5EE.

=item * L<App::installguide> - Installing the App::Context Framework on Unix.

=item * L<App::installguide::win32> - Installing the App::Context Framework on Windows.

=item * L<App::devguide> - Developers' Guide.

=item * L<App::devguide> - Developers' Guide.

=item * L<App::adminguide> - Administrators' Guide.

=item * L<App::adminguide::cvs> - Admin Guide, setting up CVS source control.

=back
 
=head2 CLASS/MODULE DOCUMENTATION (indented entries are subclasses)

Most of this documentation needs review, modification, and completion.
 
=over

=item * L<App> - The module that bootstraps the use of the App::Context Framework.

=item * L<App::Context> - Abstract class representing the the runtime context of the program.

=item *  +-- L<App::Context::Cmd> - A program running in a command-line context.

=item *  +-- L<App::Context::HTTP> - A program running in a CGI/mod_perl context.

=item *  +-- L<App::Context::Server> - A program running in a multi-process server context.

=item *  =====+-- L<App::Context::ClusterController> - Running in a multi-node cluster context.

=item *  =====+-- L<App::Context::ClusterNode> - Running on a single node of a cluster.

=item *  +-- L<App::Context::NetServer> - Another flavor of server context (not yet implemented).

=item * L<App::Exceptions> - Defines the exceptions used in the framework.

=item * L<App::UserAgent>

=item * L<App::Request>

=item *  +-- L<App::Request::CGI>

=item * L<App::Response>

=item * L<App::Session>

=item *  +-- L<App::Session::HTMLHidden>

=item *  +-- L<App::Session::Cookie>

=item * L<App::Reference>

=item *  +-- L<App::Conf>

=item *  =====+-- L<App::Conf::File>

=item * L<App::Service>

=item *  +-- L<App::Serializer>

=item *  =====+-- L<App::Serializer::Properties>

=item *  =====+-- L<App::Serializer::Ini>

=item *  =====+-- L<App::Serializer::Perl>

=item *  =====+-- L<App::Serializer::Xml>

=item *  =====+-- L<App::Serializer::Yaml>

=item *  =====+-- L<App::Serializer::OneLine>

=item *  =====+-- L<App::Serializer::TextArray>

=item *  =====+-- L<App::Serializer::Storable>

=item *  +-- L<App::SessionObject>

=item *  +-- L<App::Authentication>

=item *  +-- L<App::Authorization>

=item *  +-- L<App::ValueDomain>

=item *  +-- L<App::SharedDatastore>

=item *  +-- L<App::MessageDispatcher>

=item *  +-- L<App::CallDispatcher>

=item *  =====+-- L<App::CallDispatcher::HTTPSimple>

=item *  +-- L<App::ResourceLocker>

=item *  =====+-- L<App::ResourceLocker::IPCSemaphore>

lib/App/quickstart.pod  view on Meta::CPAN

Choose a root directory for your system, assigning it to the PREFIX variable.

vi ~/.bash_profile

  export PREFIX=/usr/mycompany/prod

vi $PREFIX/etc/app.conf

  dbhost  = localhost
  dbname  = test
  dbuser  = scott
  dbpass  = tiger

vi $PREFIX/etc/app.pl

  $conf = {
    Repository => {
      default => { alias => "db", },
      db => {
        class => "App::Repository::MySQL",
      },
    },
  };

vi $PREFIX/bin/prog

  #!/usr/bin/perl -w
  use strict;
  use App::Options (
      options => [qw(dbhost dbname dbuser dbpass)],
      option => {
          dbhost => {
              description => "database host",
              required => 1,
          },
          dbname => {
              description => "database name",
              required => 1,
          },
          dbuser => {
              description => "database user",
              required => 1,
          },
          dbpass => {
              description => "database password",
              required => 1,
          },
      },
  );
  use App;
  use App::Repository;
  {
      my $context = $App->context();
      my $db = $context->repository();
      # perform database ops like ...
      # my $rows = $db->get_rows("customer", { last_name => "Smith" }, ["first_name", "last_name", "birth_dt"]);
      # my $hashes = $db->get_hashes("customer", { "birth_dt.le" => "2000-01-01" }, ["first_name", "last_name", "birth_dt"]);
      # my $age = $db->get("customer", { customer_id => 45 }, "age");
  }

The best parts about writing database programs with App::Repository in the App::Context framework
is that all of your programs get automatic SQL debugging, timing, and explaining.

  prog --debug_sql      # show all SQL statements and their timings
  prog --debug_sql=2    # show all SQL statements and their timings and all rows returned from selects
  prog --debug_sql --explain_sql   # show SQL statements and explain them

See L<App::Options>, L<App::Repository::quickstart>, and L<App::Repository::devguide> for more info on this.

=head1 QUICK START TO OBJECT-ORIENTED COMMAND LINE PROGRAMS

Another of the big advantages of using the App::Context Framework for
command line programs is in developing programs which use and operate on Business Objects
(the object-oriented analysis concept, not the commercial reporting software).

Many "object-oriented" programs are written without ever using a true Business Object.
The reason for this is that the issues of maintaining object state are so tricky that
people rarely get around to using Business Objects in their command line programs.

Business Objects come in two types: Business Entity Objects and Business Process Objects.
Business Entity Objects represent things in the business realm: Customer, Store, Employee,
Product, PurchaseOrder.  Business Process Objects are those objects that model business
processes.

The following abstractions exist in order to subclass for your business objects.
As you get into using them, you will learn when to use which one, and you will find that
there is of course more than one way to do it.

=over

=item * L<App::RepositoryObject> - An object whose state is shared across multiple sessions as a single row in a database (repository).  These are generally the Business Entity Objects.

=item * L<App::SessionObject> - A named object whose state is maintained throughout the session.  These are generally the Business Process Objects.

=item * L<App::SessionObject::RepositoryObjectSet> - A named object with session state and shared state consisting of a set of rows from a single table in a database (repository).

=item * L<App::SessionObject::RepositoryObjectDomain> - A named object with session state and shared state consisting of a set of related sets of rows from multiple tables in a database (repository).

=back

The big advantage of writing object-oriented programs is for code reuse.
Whenever someone whips up a perl script to do some processing on the system, that
programming logic is unavailable for use in any other program (such as an interactive
web application).

One way to cure this is to have an L<App::SessionObject> where all of the logic
for a command line program is implemented as a single method call.

The choice of how many SessionObjects to use for all of the logic is a matter of
preference.  You could put all this logic on one kitchen-sink-style SessionObject
or you could group the functions into like types and put them on different
SessionObjects.  You may wish to have these SessionObject take on the responsibilities
of different "roles" played by members of the organization or tasks performed by
different departments.  These can easily be reorganized later.  The important
thing is to get the logic out of the command line programs and into objects
so that the logic can be reused later.

When viewed in this light, the command line program only becomes a user interface
for a method call provided by a SessionObject.  The easy way to start is just to
pass the %App::options hash (shown below).  However, in many cases the program
will do a few more steps to make a more natural call to the SessionObject's method.