Home | Wiki | OI 1.x Docs | OI 2.x Docs OI logo

NAME

OpenInteract2::Config::Initializer - Observable configuration initialization events

SYNOPSIS

 # Add an initializer in your package.conf
 
 name    mypackage
 version 1.10
 ...
 config_watcher OpenInteract2::MyInitializerSpops
 config_watcher OpenInteract2::MyInitializerAction
 
 # And the code in our package -- we'll dynamically add a rule from
 # 'My::Googlable' to a class where 'is_googlable' is set to 'yes'
 
 package OpenInteract2::MyInitializerSpops;
 
 use strict;
 
 sub update {
     my ( $class, $type, $config ) = @_;
     return unless ( $type eq 'spops' );
     if ( $config->{is_googlable} eq 'yes' ) {
         push @{ $config->{rules_from} }, 'My::Googable';
     }
 }
 
 # Here's we'll dynamically add a filter to an action where
 # 'is_googlable' is 'yes'
 
 package OpenInteract2::MyInitializerAction;
 
 use strict;
 use OpenInteract2::Context qw( CTX );
 
 sub update {
     my ( $class, $type, $config ) = @_;
     return unless ( $type eq 'action' );
     if ( $config->{is_googlable} eq 'yes' ) {
         OpenInteract2::Filter->add_filter_to_action(
                              'google', $config->{class} );
     }
 }

DESCRIPTION

How it works

This class provides a hook for observers to react to individual configuration events at server startup. The pseudocode for processing action and SPOPS configurations looks like this:

 foreach package
    foreach config from package
        set core data
        do basic sanity checking
        trigger event

You can also catch events generated when we create the classes used for localization (via Locale::Maketext, although the pseudocode for processing these is a little different:

 foreach package
    foreach message_file from package
        add messages to server-wide message store
 process all messages into generated classes
 foreach generated class
     trigger event

The event code can do whatever you like. This can be additional (but boring) checks on the data, such as ensuring that certain parameters are always arrayrefs, or always sorted in the same manner. This allows your implementation code to assume that everything will always be setup properly

More interesting: you can provide concise hooks in your configuration that get expanded at runtime to something more complex.

Built-in examples

For example, if you've read OpenInteract2::Manual::SPOPS you know that OpenInteract 2.x allows you to declare security for an SPOPS object with:

 is_secure = yes

In 1.x you had to add a class to the ISA.

Or to enable fulltext searching of your object you can just add to your SPOPS configuration:

 is_searchable = yes

and list the fields you'd like indexed. These are both implemented using this same event-based scheme.

What happens in the first case is that for every object that's tagged with 'is_secure' we simply add SPOPS::Secure to the object's 'isa' field. And in the second case we add OpenInteract2::FullText to the 'isa'.

Why?

Everything (or nearly everything) you can do in the event can be done in the configuration, so why bother? The primary reason is that it makes for much more concise configuration files. More concise configuration means you're less likely to mess it up and that you'll hopefully be more willing to modify it when necessary rather than throwing up your hands and hacking an ugly solution.

This is also done for the same reason that you create accessors instead of allowing direct access to your object's data structures. For instance, we may modify the full text indexing implementation to require only an SPOPS ruleset rather than full inheritance.

With the simple declaration we don't have to change any of our SPOPS configurations with the change. If we added the class directly to the 'isa' people would have to change the configuration manually, or we'd have to add a runtime hook to modify the 'isa' anyway.

OBSERVERS

This class also contains the default SPOPS and action configuration observers.

SPOPS

These are the initialization handlers for SPOPS events.

Action

These are the handlers for action configuration events:

Localization

There are no built-in observers to catch localization events. If you would like to write your own, the type is 'localization' and the only argument is the name of the class generated:

 sub my_localization_observer {
     my ( $init_class, $type, $localization_class ) = @_;
     return unless ( $type eq 'localization' );
     print "Processing '$localization_class':\n";
     # browse the keys for these localization messages
     no strict 'refs';
     my $this_lexicon = \%{ $localization_class . '::Lexicon' };
     foreach my $msg_key ( keys  %{ $this_lexicon } ) {
         print "   $msg_key: $this_lexicon->{ $msg_key }\n";
     }
 }

METHODS

You should never be using this class directly. But just in case...

new()

Creates a new object. (Doesn't hold anything right now.)

read_observers()

Class method to read the configuration observers from the server configuration and ask each package for its observers. These are collected and added to the observer list for this class -- this means you can create new objects at will and each will use the observers from the class.

COPYRIGHT

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

AUTHORS

Chris Winters <chris@cwinters.com>

Generated from the OpenInteract 1.99_04 source.

Home | Wiki | OI 1.x Docs | OI 2.x Docs
SourceForge Logo