MidCOM 2.4 Status Report: Component Base-Classes (Part 2)
2005-03-01 20:06

Making component writing easier is one of the main goals I have been working at in the last days. Since I have to modify the interfaces of the existing components anyway to incorporate the inexer backend I decided that this is as good as it could get to introduce such a unified interface.

The interfaces base class I wrote a few days ago was only the first part in a small series of helper classes. The next logical step was to introduce base classes for the viewer, admin and navigation triplet. These classes duplicated even more code then the interfaces base class. The main goal here was to unifiy the request handling as much as possible, which includes basic URL preprocessing by the request base class.

By continuing the event-based implementation approach, the new request handling base class introduces the notion of handlers, which are bound to URLs within the "URL-Space" of the component. This is, conceptionally, equivalent with the basic concept of components and their URL/Topic mapping.

A request handler is defined by a number of fixed and variable arguments. Fixed arguments (like 'registration/view') are always placed before variable ones (like Article-Names or GUIDs). For each handler you define you must specify both, the base class then matches the arguments passed by MidCOM to the component against these specifications taking the first matching event handler. Take the net.nemein.orders component, which has places in AIS where it scans for URLs like 'registration/view/$id.html'. A corresponding event handler declaration could look like this, defined during the constructor of your inherited class:

$this->_request_switch[] = Array
(
    'fixed_args' => Array ('registratons', 'view'),
    'variable_args' => 1,
    'handler' => 'view_registration'
);

If an request passed to the component matches this criteria, the two handler functions _handler_view_registration(...) and _show_view_registration(...) are called respectivly. Right now, the system only supports calling methods of the inherited class or of other, already instantinated classes. I have planned to add a way to dynamically instantinate handler classes, but the base classes required there are not yet written.

A few other interesting things about this:

A class specialized for AIS handling is available, providing a way to very simply add a "configuration datamanager" driven page to your AIS interface.
A similar base class is also available for the NAP interface, taking the basic tasks off you.

If you want to see the new base classes in action, you should take a look at the new midcom.helper.search component I have added to CVS today. It is not yet functional in terms of searching the index, but it gives an astonishing insight into how easy MidCOM 2.4 makes writing a component (compared to what we had before), check the WebCVS if you don't have a CVS trunk checkout handy.

I would appreciate any feedback regarding the documentation of the midcom.baseclasses package in the MidCOM API docs. Before you complain: The navigation base class has no class documentation yet, I'll add that part tomorrow.

MidCOM 2.4 Status Report: Component Base-Classes (Part 2) 2005-03-01 20:06

MidCOM 2.4 Status Report: Component Base-Classes (Part 2)
2005-03-01 20:06