/ 
Data-Conveyor-0.03
River stage zero No dependents
/ Data::Conveyor::Plugin

NAME

Data::Conveyor::Plugin - stage-based conveyor-belt-like ticket handling system

SYNOPSIS

Data::Conveyor::Plugin->new;

DESCRIPTION

Data-Conveyor supports plugins. The concept of a plugin, much like an aspect in aspect-oriented programming, is orthogonal to object-oriented programming. That is, objects have a vertical class hierarchy while plugins are more horizontal because their functionality cuts across the application's concerns.

First of all, plugins are optional. You don't have to use them, and if you want to add plugins to your application, you can do so step by step without having to rewrite large parts of your application.

Data::Conveyor::Plugin uses Hook::Modular to implement the plugin mechanism, so see the Hook::Modular documentation for an explanation of how this works.

Your plugins should subclass Data::Conveyor::Plugin. You can declare hooks by implementing a HOOKS() method returning a hash of hook-to-coderef mappings. The results of HOOKS() are accumulated across the plugin class hierarchy using Data::Inherited's every_hash().

For example:

sub HOOKS {
    (
        'some.hook'    => $_[0]->can('some_hook_method'),
        'another.hook' => $_[0]->can('another_hook_method'),
    );
}

The Data-Conveyor distribution provides the following hooks:

<stage>.start

This hook is run by Data::Conveyor::Stage::TransactionIterator before actually iterating over the transactions. <stage> is replaced by the stage name, that is, the stage object's associated ST constant as defined in the environment. For example, you might have policy.start, notify.start etc.

Named arguments passed to the hook:

stage

The stage object.

<stage>.end

This hook is run by Data::Conveyor::Stage::TransactionIterator after iterating over the transactions. <stage> is replaced by the stage name, that is, the stage object's associated ST constant as defined in the environment. For example, you might have policy.end, notify.end etc.

Named arguments passed to the hook:

stage

The stage object.

<stage>.<object-type>.<command>

This hook is run by Data::Conveyor::Stage::TransactionIterator for each transaction. <stage> is replaced by the stage name, that is, the stage object's associated ST constant as defined in the environment. <object-type> is replaced by the transaction's object type as defined by the environment's OT constants. <command> is replaced with the transaction's command. For example, you might have policy.delegation_domain.create.

Named arguments passed to the hook:

transaction_handler

The transaction handler object. It has the current transaction and the current ticket as attributes.

stage

The stage object.

exception.errcode_for_class

This hook is run by Data::Conveyor::Exception::Handler when determining the appropriate errcode for an exception. Not only are the ERRCODE_FOR_EXCEPTION_CLASS_HASH definitions traversed across the class hierarchy, but plugins are also given the chance to define their mappings. The hook is expected to return a hashref of class-to-errcode mappings that is then merged with the results gathered from ERRCODE_FOR_EXCEPTION_CLASS_HASH.

However, Data::Conveyor::Plugin defines this hook itself so that you can use the familiar ERRCODE_FOR_EXCEPTION_CLASS_HASH mechanism in your plugins.

exception.rc_for_class

Like exception.errcode_for_class, but applies to RC_FOR_EXCEPTION_CLASS_HASH and rc determination, respectively.

exception.status_for_class

Like exception.errcode_for_class, but applies to STATUS_FOR_EXCEPTION_CLASS_HASH and status determination, respectively.

METHODS

Data::Conveyor::Plugin inherits from Hook::Modular::Plugin, Data::Inherited, and Class::Scaffold::Delegate::Mixin.

The superclass Hook::Modular::Plugin defines these methods and functions:

new(), assets_dir(), class_id(), conf(), decrypt_config(),
dispatch_rule_on(), do_walk(), init(), load_assets(), log(),
plugin_id(), rule(), walk_config_encryption()

The superclass Class::Accessor::Fast defines these methods and functions:

make_accessor(), make_ro_accessor(), make_wo_accessor()

The superclass Class::Accessor defines these methods and functions:

_carp(), _croak(), _mk_accessors(), accessor_name_for(),
best_practice_accessor_name_for(), best_practice_mutator_name_for(),
follow_best_practice(), get(), mk_accessors(), mk_ro_accessors(),
mk_wo_accessors(), mutator_name_for(), set()

The superclass Data::Inherited defines these methods and functions:

every_hash(), every_list(), flush_every_cache_by_key()

The superclass Class::Scaffold::Delegate::Mixin defines these methods and functions:

delegate()

TAGS

If you talk about this module in blogs, on del.icio.us or anywhere else, please use the dataconveyor tag.

VERSION

This document describes version 0.03 of Data::Conveyor::Plugin.

BUGS AND LIMITATIONS

No bugs have been reported.

Please report any bugs or feature requests to <bug-data-conveyor@rt.cpan.org>, or through the web interface at http://rt.cpan.org.

INSTALLATION

See perlmodinstall for information and options on installing Perl modules.

AVAILABILITY

The latest version of this module is available from the Comprehensive Perl Archive Network (CPAN). Visit <http://www.perl.com/CPAN/> to find a CPAN site near you. Or see <http://www.perl.com/CPAN/authors/id/M/MA/MARCEL/>.

AUTHORS

Marcel Grünauer, <marcel@cpan.org>

Florian Helmberger <fh@univie.ac.at>

Achim Adam <ac@univie.ac.at>

Mark Hofstetter <mh@univie.ac.at>

Heinz Ekker <ek@univie.ac.at>

COPYRIGHT AND LICENSE

Copyright 2004-2008 by Marcel Grünauer

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.