NAME

AxKit::App::TABOO::Data - Base class of abstracted Data objects for TABOO

DESCRIPTION

You would rarely if ever use this class directly. Instead, you would call a subclass of this class, depending on what kind of data you are operating on. This class does, however, define some very useful methods that its subclasses can use unaltered.

It is to be noted that I have not, neither in this class nor in the subclasses, created methods to access or set every field. Instead, I rely mainly on methods that will manipulate internal data based on the for example objects that are passed as arguments. For example, the write_xml-method (below), will create XML based on all the available data in the object. This is usually all you want anyway.

In some subclasses, you will have some degree of control of what is loaded into the object data structure in the first place, by sending the names of the fields of the storage medium (e.g. database in the present implementation).

Similarly, if data is sent from a web application, the present implementation makes it possible to pass an Apache::Request object to a Data object, and it is up to a method of the Data object to take what it wants from the Apache::Request object, and intelligently store it.

Some methods to access data will be implemented on an ad hoc basis, notably timestamp()-methods, that will be important in determining the validity of cached data.

Methods

new()

The constructor of this class. Rarely used.

load($key)

Will load and populate the data structure of an instance with the data from a the data source, given a key in the string $key.

write_xml($doc, $parent)

Takes arguments $doc, which must be an XML::LibXML::Document object, and $parent, a reference to the parent node. The method will append the object it is handed it with the data contained in the data structure of the class in XML. This method is the jewel of this class, it should be sufficiently generic to rarely require subclassing. References to subclasses will be followed, and write_xml will call the write_xml of that object. Arrays will be represented with multiple instances of the same element. Fields that have undefined values will not be included.

apache_request_data(\%args)

This method takes as argument a reference to the args hash of a Apache::Request object. Note that in a request, the Request object is available as $r, so you may create this hash by

my %args = $r->args;

It will populate the data object by adding any data from a parameter having the same name as is used in the data storage. Fields that are not specified by the data object or that has uppercase letters are ignored.

apache_request_changed(\%args)

Like the above method, this method takes as argument a reference to the args hash of a Apache::Request object. Instead of populating the Data object, it will compare the \%args with the contents of the object and return an array of fields that differs between the two. Fields that are not specified by the data object, that has uppercase letters or has no value, are ignored.

save([$olddbkey])

This is a generic save method, that will write a new record to the data store, or update an old one. It may have to be subclassed for certain classes. It takes an optional argument $olddbkey, which is the primary key of an existing record in the data store. You may supply this in the case if you want to update the record with a new key. In that case, you'd better be sure it actually exists, because the method will trust you do.

It is not yet a very rigorous implementation: It may well fail badly if it is given something with a reference to other Data objects, which is the case if you have a full story with all comments (see _addinfo below). Or it may cope. Only time will tell! Expect to see funny warnings in your logs if you try.

stored()

Checks if a record with the present object's identifier is allready present in the datastore. Returns 1 if this is so.

xmlelement($string)

This method is intended for internal use, but if you can use it without shooting somebody in the foot (including yourself), fine by me... It sets the root element that will enclose an object's data to $string.

xmlns($string)

Like xmlelement(), this method is intended for internal use. It sets the namespace URI of the XML representation of an object to $string.

_addinfo($add, $this, $that)

This method is for use by subclasses only. It can be used by methods like adduserinfo(), and will be used to replace a field ($this) with another field ($that) containing a reference to a different class that will be added, $add.

Class Data Methods

dbstring($string)

A string to be passed to the DBI constructor. Currently defaults to "dbi:Pg:dbname=skepsis". Yeah, it will change...

dbuser($string)

The user name to be passed to the DBI constructor. Currently defaults to 'www-data'.

dbpasswd($string)

The password to be passed to the DBI constructor. Currently defaults to an empty string.

STORED DATA

The data is stored in named fields, currently in a database, but there is nothing stopping you from subclassing the Data classes and storing it somewhere else. TABOO should work well, but if you want to make it less painful for yourself, you should use the same names or provide some kind of mapping between your names and the names in these Data classes. Note that any similarity between these names and the internal names of this class is purely coincidential (eh, not really).

Consult the documentation for each individual Data class for the names of the stored data.

BUGS/TODO

Except for still being in alpha, and should have a few bugs, there is the issue with the handling of references to other objects in the save() method. It's possible it will cope, but it definately needs work.

Every load-type method should throw an exception or do something similar if it finds that the record it tries to retrieve doesn't exist.

I think I may have slightly misdesigned the Data classes, in that they are only designed to operate on one entry at a time. Probably, it is easy to fix this by adding plural versions of each data class, but I need to try to keep some independence from SQL syntax, and I haven't quite figured that out yet.

FORMALITIES

See AxKit::App::TABOO.