/ 
OpenInteract-1.99_04
River stage zero No dependents
/ OpenInteract2::SPOPS

NAME

OpenInteract2::SPOPS - Define common behaviors for all SPOPS objects in the OpenInteract Framework

SYNOPSIS

# In the server configuration ($WEBSITE_DIR/conf/server.ini)

# First define the datasource type ('DBI') and associate that type
# with an OI2::SPOPS subclass...

[datasource_type DBI]
connection_manager = OpenInteract2::Datasource::DBI
spops_config       = OpenInteract2::SPOPS::DBI

# Then declare a datasource and associate it with that type; SPOPS
# objects associated with this datasource will have 'OI2::SPOPS::DBI'
# automatically placed in the 'isa'.

[datasource main]
type          = DBI
...

DESCRIPTION

Here we provide some common operations within OpenInteract that are not implmented within the data abstraction layer itself. Since we want to continue using both separately we cannot embed ideas like a configuration object or a particular cache implementation within SPOPS. Think of this class as a bridge between the two.

Note that while most of the functionality is in this class, you will always want to use one of the implementations-specific child classes -- see OpenInteract2::SPOPS::DBI and OpenInteract2::SPOPS::LDAP.

OBJECT TRACKING METHODS

There are a number of methods for dealing with object tracking -- when a create/update/remove action is taken on an object and by whom.

log_action( $action, $id )

Wrapper for the log_action_enter method below, decides whether it gets called. (Wrapper exists so subclasses can call log_action_enter directly and not deal with this step.)

Parameters:

  • action ($)

    Should be 'create', 'update', 'remove'.

    id ($)

    ID of the object.

Returns undef on failure, true value on success.

log_action_enter( $action, $id )

Makes an entry into the 'object_track' table, which logs all object creations, updates and deletions. We do not note the content that changes, but we do note who did the action and when it was done.

Parameters:

  • action ($)

    Should be 'create', 'update', 'remove'.

    id ($)

    ID of the object.

Returns undef on failure, true value on success.

fetch_creator()

Retrieve an arrayref of all user objects who have 'creator' rights to a particular object.

is_creator( $uid )

Parameters:

  • uid ($)

    User ID to check and see if that user created this object.

Returns 1 if the object was created by $uid, undef if not.

fetch_updates()

Returns an arrayref of arrayrefs, each formatted:

[ uid of updater, date of update ]

OBJECT KEY METHODS

We use a object key to uniquely identify each object in the system. (Generally the object key is a digest formed from the class and object ID.)

generate_object_key()

Creates a unique key based on the class and ID. (Currently using Digest::MD5.)

save_object_key( \%params )

Checks to see if an object key already exists for this class and ID and if not, creates a new key and saves it to the lookup table.

Returns: the object key retrieved or saved

fetch_object_key()

Retreives an object key based on the class and ID of an object.

Returns: the object key associated with the class and ID, or undef if none found.

fetch_object_info_by_key( $key, \%params )

Given an object key, lookup the object class and ID associated with it.

Returns: If matching information found, a two-element list -- the first element is the object class, the second is the object ID. If no matching information is found, undef. matching information found, re

fetch_object_by_key( $key, \%params )

Given an object key, fetch the object associated with it.

Returns: If key matches class and ID in lookup table, the object with the class and ID. If no match found, return undef.

RULESET METHODS

We create one rule in the ruleset of each object. In the post_save_action step we ensure that this object has an entry in the object key table. (See description of save_object_key() for information about the implementation.)

METHODS

notify()

Either call from an object or from a class passing an arrayref of objects to send to a user. Calls the as_string() method of the object, which (if you look in the SPOPS docs), defaults to being a simple property -> value listing. You can override this with information in your class configuration which specifies the fields you want to use in the listing along with associated labels.

Parameters:

  • email ($)

    Address to which we should send the notification.

  • email_from ($) (optional)

    Address from which the email should be sent. If not specified this defaults to the 'admin_email' setting in your server configuration (under 'mail').

  • subject ($) (optional)

    Subject of email. If not specified the subject will be 'Object notification # objects in mail'.

  • object (\@) (optional if called from an object)

    If not called from an object, this should be an arrayref of objects to notify someone about.

  • notes ($) (optional)

    Notes that lead off an email.

COPYRIGHT

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

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

AUTHORS

Chris Winters <chris@cwinters.com>