NAME

OpenInteract2::Manual::Changes - Significant changes to OpenInteract2

NOTE

Each package maintains its own changelog. These changes are not mentioned here except to note the package version changes with successive OI2 releases.

1.99_01

Major Changes

• Log4perl is now used for all logging. This is a major change in how OI2 presents its state to you, allowing you far more flexibility than you previously had.

• Lots of documentation additions and updates.

• Different content generators than the Template Toolkit exist and can be used. They're not as featureful (e.g., nothing similar to the TT plugin) but may be useful when porting applications. They are Text::Template (using OpenInteract2::ContentGenerator::TextTemplate) and HTML::Template (using OpenInteract2::ContentGenerator::HtmlTemplate).

  You can find examples of using them in the 'news' package -- look at the bottom of the conf/action.ini file to enable the different actions.

• The controller has been decoupled from the content generator. Each controller is associated with a content generator, but a content generator doesn't map to a single controller. (This probably doesn't make sense to anybody who didn't read the code or try to use a different content generator, but trust me that it's better.)

• OpenInteract2 now has content filters. And they're easy! A filter is just an observer (see Class::Observable) that catches 'filter' observations and has an opportunity to modify the content generated before it's optionally cached.

• ...which leads to caching of action content, now implemented. It's mostly transparent to your action as long as the cached content doesn't depend on any non-request parameters. (See OpenInteract2::Manual::Caching for lots of info.)

• OpenInteract2::Exception now uses Exception::Class rather than SPOPS::Exception, and E::C is a depdendency.

• The standalone daemon (oi2_daemon) respects the OPENINTERACT2 environment variable and will use it to find the server configuration and the daemon configuration if unspecified.

Minor changes

Too many small fixes and improvements to note, sorry. As we stabilize to 2.0 this will get explicit.

Broken stuff

Full text searching doesn't seem to work. A number of other actions have not been fully tested by hand, much less in an automated fashion.

Also, tests for other areas of the system are lagging.

1.99_00, 10 June 2003

This is the first BETA release. DO NOT run production systems on it.

Compatibility

Since OpenInteract 2.x uses a separate namespace than OpenInteract 1.x (OpenInteract2 vs. OpenInteract), you should have no problems installing this on a machine with OpenInteract 1.x.

There is currently no automated way to upgrade the server configuration or everything about a custom package. (You can translate the conf/action.perl and conf/spops.perl into the new INI format -- see scripts in script/.) In addition, a number of core packages have upgraded schemas so you can't simply dump your table and reload it.

Before 2.0 final is released there should be tools to:

• Do a simple translation of content handlers and other classes. This would just translate most of the $R calls to CTX calls (or CTX->request, CTX->response calls).

• Do a translation of Template Toolkit directives that have changed (there aren't many).

Major Changes

These are the highlights. Many others are lurking under the covers.

• There is no longer a package repository and a website, only a website. This greatly simplifies development.

• You can deploy OI2 under a specific URL-space so that, for instance, all requests under '/OI2/' will get translated to the proper action.

• And along with deployment you can easily rewrite URLs to fit in the deployment scheme.

• Tight integration with SPOPS object persistence still exists and has been enhanced to make development easier -- you do not have to specify 'SPOPS::Secure' in the ISA, just set the 'is_secure' key to 'yes'. You also do not have to specify the database type in your persistent object -- it's wired to a datasource which knows this information, so we generate it at startup time.

• An entirely new management scheme replaced the massive oi_manage with programmable tasks to create a website, create and install packages, install database schemas along with associated data and security settings, and more.

• Request parameters that OI2 deals with are separate from the how those parameters are retrieved. This means it's easy to deploy an OI2 server in different environments -- it ships with interfaces for Apache 1.x/mod_perl 1.x, CGI, and a standalone server based on LWP. It's easy to create interfaces for other systems as well. (See "OI2 INTERFACES".)

• Content handlers are now objects instead of classes, all deriving from OpenInteract2::Action. This simplifies development, making each action stateful rather than passing around a dumb hashref.

• You can now generate any kind of content from OI2. OI2 is still heavily biased toward the Template Toolkit (can you blame it?), but you can plugin any type of content generator you like. A sample one is in the distribution: OpenInteract2::ContentGenerator::TextTemplate.

• The OpenInteract::CommonHandler megalith has been split up into separate classes to deal with searching, displaying, updating, adding, and removing objects.

• All actions in the core packages have been modified to use these common handlers where possible, and when not possible they don't overload as much functionality into a single task. For instance, 'display' will just display a non-editable object; 'display_form' will just display an existing object in a form for updating; 'display_add' will display a form without an object.

• The procedures for installing SQL structures, initial data and security has been totally overhauled. It's much to create an installer now.

• Authentication is more flexible and can be adapted to different systems (e.g., HTTP authentication instead of cookies) more easily.

• The package and repository code was entirely rewritten. The repository now holds the bare minimum to keep track of objects and it should never become corrupted.

• Everything in OI2 should throw an exception object rather than issue a die. This allows us to discern the different types of errors more easily, keep track of where they were thrown, etc.

• An ever-growing testing suite ensures that OI2 can adapt easily and also provides a separate bunch of documentation.

OI2 INTERFACES

An 'interface' refers to how OpenInteract2 interacts with the outside world. An interface consists of three parts:

• Adapter to take the user's request, login the user and create the necessary OpenInteract2 objects (OpenInteract2::Request, OpenInteract2::Response, OpenInteract2::Controller).

• Subclass of OpenInteract2::Request to take the parameters, cookies, and other user information from the user's request and put it into the OpenInteract2 framework.

• Subclass of OpenInteract2::Response to take the generated headers, cookies, and content generated by OpenInteract2 and send it back to the client.

Since most of the functionality is pushed down into the Request and Response subclasses, adapters are generally pretty simple. For instance, here's an example of the Adapter for Apache 1.x/mod_perl 1.x:

package Apache::OpenInteract2;

use strict;
use OpenInteract2::Auth;
use OpenInteract2::Request;
use OpenInteract2::Response;

sub handler($$) {
    my ( $class, $r ) = @_;
    my $response = OpenInteract2::Response->new({ apache => $r });
    my $request  = OpenInteract2::Request->new({ apache => $r });
    OpenInteract2::Auth->login( $r->pnotes( 'login_user' ) );
    my $controller = eval {
        OpenInteract2::Controller->new( $request, $response )
    };
    if ( $@ ) {
        $response->content( $@ );
    }
    else {
        $controller->execute;
    }
    $response->send;
    return $response->status;
}

COPYRIGHT

Copyright (c) 2002-2003 Chris Winters. All rights reserved.

AUTHORS

Chris Winters <chris@cwinters.com>

cpanm OpenInteract2::URL

perl -MCPAN -e shell
install OpenInteract2::URL