Re: [Openledger-developer] API Design Idea

[Tony F. <to...@sy...>]

On Wed, 2005-03-02 at 08:26, Klavs Klavsen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> on 01-03-2005 22:43 Tony Fraser wrote:
> [SNIP]
> | What I'm thinking is that the API could sit on top of the GUI. In the
> | past we've talked about something that could be used to re-implement the
> | GUI but I really think that anything we do to that layer of SL would be
> | best started as a re-write/re-implementation of SL that is DB schema
> | compatible.
> |
> Which is exactly what we talked about - reimplementing the features the
> GUI (and other programs/scripts) need in the API - and then make the GUI
> use that instead of running SQL-ledger gui on the side, which will be
> what I'll do until a new GUI, using the API is ready.
> 
> | In the meantime I think the immediate thing to do is to create an API
> | that interacts with SL through a combination of LWP::UserAgent and
> | HTML::Form. We could make the API SL specific or we could generalize the
> | API and make a backend for it that interacts with the current SL.
> |
> This is what I'm doing now - using lynx and posting what I need to do.
> One could use WWW::Mechanize to great benefit, but it is hard work, and
> because of the way the GUI works - you'll have to duplicate the data
> (like internal partnumbers etc.) unless, you use WWW::Mechanize (which
> acts as a browser). I hate this approach with my entire soul - which is
> why I wanted to start the openledger project :)
> 
> I currently post invoices this way - and am going to write the first 2
> functions for the API this/next week:
> 1) a function for registering a simple transaction (I need to move money
> around, when they've been charged from a credit card - I need to move
> them to my bank account - to reflect what happens in real life :)
> 
> 2) I need a "getInvoice" function, which will fill an Invoice object
> (see CVS for how that object looks) - so I can give the API an
> invoicenumber, and get the invoice, including the ordernumber, which is
> what I need in this case.
> 
> | I have some UML (created with Dia) of a possible generalized API. I
> | wouldn't mind getting some comments on the API. I'll post the UML on the
> | SF.net project webspace later today.
> |
> | So what do you people thing of interacting with SL through HTTP
> | requests? I think it will be the most straight forward and probably the
> | most SL-version-non-specific way I can come up with.
> |
> AFAIK the DB structure of SL has been more stable than the GUI design,
> and I have done what you are talking about - it is a very tiresome
> approach - and if Dieter gets tired of us - it wouldn't be hard to
> change the GUI a little bit -which would mean a lot of updating on our
> part. I use the same method (WWW::Mechanize) for updating modules in
> PostNuke.
> 
> I definetely prefer the path, which leads to a community-based
> accounting system :)

Well I went ahead and created a possible API design that uses
LWP::UserAgent and HTML::Form anyway. It has taken the biggest part of a
day to get where I am now but it is working. I have code for creating,
posting and editing GL entries. The implementation consists of 2 helper
classes that will be reused by other types of transactions and 1
transaction class for a total of 3 classes.

I'll post the full code on the web tomorrow but for now here's a driver
program that uses the API to post a new GL transaction:

#!/usr/bin/perl

use strict;
use warnings;

use SL::Api;

our $SL_API = SL::Api->new(
		location => 'http://accounting/sl/dev',
		login => 'tony',
		password => 'password'
);
our $TRANS = $SL_API->start_transaction('add', 'GL');

$TRANS->reference("API TEST1");
$TRANS->description("First test of the SL API");

$TRANS->add_debit('1060', 100);
#$TRANS->transaction->dump;
$TRANS->add_credit('3350', 100);
#$TRANS->transaction->dump;

$TRANS->post;
__END__

Right now it's about 1:30 in the morning and I need to get to bed.

-- 
Tony Fraser
to...@sy...
Sybaspace Internet Solutions                        System Administrator
phone: (250) 246-5368                                fax: (250) 246-5398