Apache-iNcom

 view release on metacpan or  search on metacpan

NEWS  view on Meta::CPAN

Apache::iNcom NEWS -- History of User-Visible Changes.  

Changes in Apache::iNcom 0.08 Mar 30 2000

- New configuration directive : INCOM_SESSION_SERIALIZE_ACCESS

    If you set this directive to 1, only one request by session will 
    be processed simultaneously. This is necessary if you are using
    frames and your database doesn't support full serializable
    transaction isolation level, so that one request overwrites changes
    made in the other request. 

    You will need to add a field locked_by of type INT to your 
    sessions table.


- Periodic garbage collection of of expired sessions.

- New input filters : 

README  view on Meta::CPAN

        - HTML::Embperl 1.2.1
        - Apache::Session 1.03 + generate_id patch
        - MIME::Base64
        - Locale::Maketext 0.17   + currency patch
        - apache 1.3.6 or later
        - Database which supports transactions. (tested with PostgreSQL 6.5.x)

Description
-----------

    Apache::iNcom is an e-commerce framework. It is not a ready-to-run
    merchant system. It is an integration of different
    components needed for e-commerce into a coherent whole.

    The primary design goals of the framework are flexibility and
    security. Most merchant systems will make assumptions in the way
    your catalog's data, customer's data are structured or on how
    your order process works. Most also imposes severe restrictions
    on how the user will interface to your electronic catalog. This
    is precisely the kind of constraints that Apache::iNcom was
    designed to avoid.

    Apache::iNcom provides the following infrastructure :

        - Session Management

lib/Apache/iNcom.pm  view on Meta::CPAN

    return OK;
}

1;
__END__

=pod

=head1 NAME

Apache::iNcom - An e-commerce framework.

=head1 SYNOPSIS

    - Configure Apache and mod_perl
    - Create databases
    - Install Apache::iNcom
    - Design your e-commerce site.
    - Wait for incomes.

=head1 DESCRIPTION

Apache::iNcom is an e-commerce framework. It is not a ready-to-run
merchant systems. It is an integration of different components needed
for e-commerce into a coherent whole.

The primary design goals of the framework are flexibility and
security. Most merchant systems will make assumptions in the way your
catalog's data, customer's data are structured or on how your order
process works. Most also imposes severe restrictions on how the user
will interface to your electronic catalog. This is precisely the kind
of constraints that Apache::iNcom was designed to avoid.

Apache::iNcom provides the following infrastructure :

    - Session Management
    - Cart Management

lib/Apache/iNcom.pm  view on Meta::CPAN

=head2 SESSION DIRECTIVES

=over

=item INCOM_SESSION_SERIALIZE_ACCESS

Set this to 1 to serialize access through session. This will make sure
that only one session's request is processed at a time. You should set
this to 1 if your site uses frameset.

=item INCOM_SESSION_SECURE

Sets this to true if you want the cookie that contains the session id
to be only transmitted over SSL connections. Be aware that setting
this variable to true will require that all Apache::iNcom transactions
be conducted over SSL.

=item INCOM_SESSION_DOMAIN

lib/Apache/iNcom.pm  view on Meta::CPAN

=head1 USER MANAGEMENT

User management is handled through the DBIx::UserDB(3) module.

=head1 LOCALIZATION

Apache::iNcom is designed to make it easy to adapt your e-commerce
application to multiple locale.

The framework uses Locale::Maketext(3) for message formatting.

All pages may have a localized version available. The localized should
have an extension describing its language. (.en for English, .fr for
French, .de for German, etc.)

The user locale will
be negotiated through the Accep-Language header which is part of the
HTTP protocol. It can also be set explicitely by sending the user to
a special link (since not many users took the time to configure their
browser for language negotiation).

lib/Apache/iNcom.pm  view on Meta::CPAN

Session ID are 128bits truly random number.

=item 2

Session ID are transmitted only by cookies to assure confidentiality.

=item 3

There are no user transmitted magic variables. Form data doesn't act upon
the framework. All actions are triggered by the application and not the
user. All form data that should be used for action are determined by the
application through the various profiles. This means that you won't be
burned by a magic feature that sprung without you knowing it.

=item 4

Regular access control of Apache can be used. Also see the ACLs
mechanism offered by the DBIx::UserDB(3) for access control with finer
resolution than URL or file based.

lib/Apache/iNcom/CartManager.pm  view on Meta::CPAN

shopping cart. 

=head1 SYNOPSIS

    $Cart->order( \%item );
    my $items = $Cart->items;
    $Cart->empty;

=head1 DESCRIPTION

This is the part of the Apache::iNcom framework that is responsible for
managing the user shopping cart. It keep tracks of the ordered items and
is also responsible for the pricing of the order. It this is module that
computes taxes, discount, price, shipping, etc.

=head1 DESIGN RATIONALE

Well not completly since all these operations are delegated to user
implemented functions implemented in a pricing profile. The idea
behind it is to make policy external to the framework. One thing that
varies considerably between different applications is the pricing,
discount, taxes, etc. So this is left to the implementation of the
application programmer.

=head1 PRICING PROFILE

The pricing profile is a file which is C{eval}-ed at runtime. (It is also
reloaded whenever it changes on disk. It should return an hash reference
which may contains the following key :

lib/Apache/iNcom/CartManager.pm  view on Meta::CPAN

	    my $gsp = ($taxable + $gst) * 0.075

	    return [ $gst, $gsp ];
	} else {
	    return undef;
	}
    }

=back

If one of these functions is left undefined. The framework will create
one on the fly which will return 0. (No taxes, no discount, no
shipping charges, item is free, etc).

All those functions are defined and execute in the namespace of the
pages which will use the $Cart object. This means that those functions
have access to the standard Apache::iNcom globals ($Request, %Session, 
$Localizer, $Locale, etc ). DONT ABUSE IT. Also, don't call any methods
on the $Cart object or you'll die of infinite recursion.

=head1 WHAT IS AN ITEM

An item is simply an hash with some reserved key names. All other keys
are ignored by the CartManager. Each item with the same (non reserved)
key values is assumed to be identic in terms of price, discount, etc.

This design was chosen to handle the infinite variety of item
attributes (color, size, variant, ...). The framework doesn't need
knowledge of those, only the application specific part. (The pricing
functions.)

These are reserved names and can't be used as item attributes :
C<quantity>, C<price>, C<discount>, C<subtotal>

=head1 INITIALIZATION

An object is automatically initialized on each request by the
Apache::iNcom framework. It is accessible through the $Cart global
variable in Apache::iNcom pages.

=cut

sub new {
    my $proto = shift;
    my $class = ref $proto || $proto;

    my ( $cart, $package, $profile_file ) = @_;

lib/Apache/iNcom/Localizer.pm  view on Meta::CPAN

Apache::iNcom::Localizer - Object responsible for the localization of the
generated request.

=head1 SYNOPSIS

    my $file	= $Localizer->find_localized_file( $filename );
    my $bundle	= $Localizer->get_handle( "Site_L10N" );

=head1 DESCRIPTION

This module is used for localization in the Apache::iNcom framework.
It should be used for operation which are locale sensitive. (Messages
display, currency and date formatting, etc.)

=head1 INITIALIZATION

An object is automatically initialized on each request by the
Apache::iNcom framework. The list of preferred languages is determined
by using the Accept-Language HHTP header. The default language is set
to the one specified in the configuration. It is accessible through
the $Localizer gobal variable in the Apache::iNcom pages.

=cut

sub new {
    my $proto = shift;
    my $class = ref $proto || $proto;

lib/Apache/iNcom/OrderManager.pm  view on Meta::CPAN

Apache::iNcom::OrderManager - Module responsible for order management.

=head1 SYNOPSIS

    my $order = $Order->checkout( "order", $Cart, %fdat );
    my $report $Order->order_report( $order );

=head1 DESCRIPTION

This is the part of the Apache::iNcom framework that is responsible
for managing the order process. Once the user is ready to check out,
the OrderManager rides in. This module enters the user's order in the
database according to an order profile. It can also generate order
reports and such.

It is in that module that future development will place links with
CyberCash (tm) and other online payment systems.

=head1 DATABASE

The order should be entered in two tables. One table table contains
the global order informations : order no, client's information,
status, total, taxes, etc., and another table contains the ordered
items.

To make order customizable, the OrderManager uses DBIx::SearchProfiles
to insert the information. That design is similar to DBIx::UserDB in
that only a few fields are required by the framework and the schema
can easily be adapted for application specific needs.

The mandatory fields in the main table are the C<order_no> field,
which should be a primary key on the table, and the C<status> field.
The status field is used to track the order process.

You may also want to add monetary fields for C<total>, C<subtotal> and
for the taxes, shipping and discount informations since that will
always be available in the order.

lib/Apache/iNcom/OrderManager.pm  view on Meta::CPAN

	    order_template	    => "order",
	    order_item_template	    => "order_items",
	    order_no		    => "order_no",
	    taxes_fields	    => [qw( gst gsp ) ],
	},
    }

=head1 INITIALIZATION

An object is automatically initialized on each request by the
Apache::iNcom framework. It is accessible through the $Order global
variable in Apache::iNcom pages.


=head1 METHODS

=cut

sub new {
    my $proto = shift;
    my $class = ref $proto || $proto;

lib/Apache/iNcom/OrderManager.pm  view on Meta::CPAN

The cart that contains the user's order.

=item $order_data

An hash reference which contains other informations that should be stored
with the order. (Like customer's name and address for example.)

=back

The cart is emptied if the checkout is successful. NOTE: This is the
only method in the framework that will do an explicit commit to make
sure that the order is correctly entered in the database.

The method returns an hash references which contains the order
informations.

=cut

sub checkout {
    my ( $self, $name, $cart, $order_data ) = @_;

lib/Apache/iNcom/Request.pm  view on Meta::CPAN

This module is responsible for managing the environment in which the
Apache::iNcom page will execute. It setups all the objects that will
be accessible to the pages through globals and also provides the
page with a bunch of utility functions. It also provides a bunch
of methods for managing the information associated with the request.


=head1 INITIALIZATION

An object is automatically initialized on each request by the
Apache::iNcom framework. It is accessible through the $Request global
variable in Apache::iNcom pages.

=cut

sub new {
    my $proto	= shift;
    my $class	= ref $proto || $proto;

    my $req_rec = shift;
    my $package = shift;

lib/Apache/iNcom/Session.pm  view on Meta::CPAN

=head1 NAME

Apache::iNcom::Session - Apache::Session implementation for Apache::iNcom

=head1 SYNOPSIS

use Apache::iNcom::Session;

=head1 DESCRIPTION

This is a subclass of Apache::Session used by the iNcom framework.
This Apache::Session implementation used the DBIBase64Store and NullLocker
for handling session persistence.

The other special thing about this implementation is that session IDs
are 128bits long and generated using the /dev/urandom device if
available.

This is a security feature to make session id very hard to guess.

=head1 AUTHOR

lib/Apache/iNcom/UserDBAuthz.pm  view on Meta::CPAN

    require user foo and write

    require group baz; exec on test

    require valid-user, admin code

=head1 DESCRIPTION

This module integrates the DBIx::UserDB module used by the
Apache::iNcom framework with the apache authorization phase.

This module will set the authorization on the authenticated user by
checking the DBIx::UserDB ACL.

=head1 CONFIGURATION

The DBIx::UserDB used is configured via the normal Apache::iNcom
directives.

=head1 REQUIREMENTS DIRECTIVES