On Thursday 28 August 2003 09:56 am, Martin Oldfield wrote:
This is the same basic approach I've always taken. It works well in that often
I have requirements to build non mod_perl (ie CGI etc) variations of some
applications, in which case the 'thin layer' approach is nice.
The thin layer also separates out certain concerns like interacting with
session storage which logically are not part of accessing the database but
which are required parts of web application logic.
Snippets of code might look like:
A function that appears in a taglib, note that it handles things like getting
the current user and handles context like setting '$currentmsg' for later use
by other tags, etc. 'mdb()' is a taglib static function to get a copy of the
singleton object that acts as the interface to the message store.
# Taglib function to get a message from the message database given its id.
sub message
{
my ($nid,$oid) = @_;
$currentmsg =
mdb()->get_message($nid,$oid,GEB::Session::get_attribute('user'));
my $auth =
mdb()->get_author($currentmsg,GEB::Session::get_attribute('user'));
return $currentmsg->to_xml(0,sub
{
return "<author
nodeid='".$currentmsg->ownernodeid()
."'
objectid='".$currentmsg->ownerobjectid()
."'>"
.$auth->handle()
."</author>";
}
);
}
Then the message store can concentrate totally on storing, retrieving, and
formatting messages.
sub get_message
{
my ($self,$nid,$oid,$actor) = @_;
my $msg = mkidpair($nid,$oid);
return $self->factory()->get('-idpair' => $msg,'-actor' => $actor,'-proto' =>
'GEB::OBJECTS::Message');
}
sub get_author
{
my ($self,$msg,$actor) = @_;
my $owner = mkidpair($msg->ownernodeid(),$msg->ownerobjectid());
return $self->factory()->get('-idpair' => $owner,'-actor' => $actor,'-proto'
=> 'GEB::OBJECTS::User');
}
(these aren't the most exciting functions, granted they just delegate most of
the work to a generic database abstraction 'factory' but you get the idea).
This same message base interface class is also used to export functionality
via SOAP::Lite over both HTTP and SMTP and accessed directly by CGI and
command-line perl scripts.
A provider could act as this thin skin just as easily as an XSP page, I just
find that XSP is more maleable. There are always endless little variations of
how you want to authenticate or muck with the format of the data a little bit
depending on who's looking at it, handle errors different ways etc and the
XSP page itself is where you can best do that IMHO.
>
> One of the problems I've had with all of the SQL taglibs is that I
> usually want at least some of the functionality in non-AxKit
> applications.
>
> I usually end up encapsulating the DB with a Perl module. For AxKit I
> wrap that in a thin taglib or provider; other applications just
> interact with the module directly. Is this what everyone else does, or
> is there a better way ?
>
> Cheers,
--
Tod Harter
Giant Electronic Brain
http://www.giantelectronicbrain.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
