Thread: [Openledger-developer] API Design Idea
Brought to you by:
klavs
From: Tony F. <to...@sy...> - 2005-03-01 21:43:53
|
I have been thinking quite a bit about how to implement an API for 3rd party/custom apps to use SL. The solution I have come up with is not exactly what has been talked about on this list in the past, but I think it could work quite well. It won't help future SL development at all though. 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. 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. 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. -- Tony Fraser to...@sy... Sybaspace Internet Solutions System Administrator phone: (250) 246-5368 fax: (250) 246-5398 |
From: Klavs K. <kl...@vs...> - 2005-03-02 16:26:33
|
-----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 :) - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCJelDPToLeX4GPGIRAsVSAKCSCf3/qmgRUFmzh5R9DQBY3ouVqwCeIWFI lSLUypk9djvZl5aIQHJpAX4= =WS6U -----END PGP SIGNATURE----- |
From: Tony F. <to...@sy...> - 2005-03-03 09:21:05
|
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 |
From: Klavs K. <kl...@vs...> - 2005-03-03 16:16:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 03-03-2005 10:20 Tony Fraser wrote: [SNIP] | Well I went ahead and created a possible API design that uses | LWP::UserAgent and HTML::Form anyway. hehe. The freedom of choice ;) - glad it's a community thing - otherwise I could dictate what got into OpenLedger :) | 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. Looking forward to see it in CVS :) | | 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; hmm - I'm looking forward to seeing the Api you created here (or is it the soap-api/Api.pm ?) | | 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. sleep well :) - -- Regards, Klavs Klavsen, GSEC - kl...@vs... - http://www.vsen.dk PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 "Those who do not understand Unix are condemned to reinvent it, poorly." ~ --Henry Spencer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCJzhCPToLeX4GPGIRAk6JAJ4sIKud7D1joSVaobf23ksKmVxnMACfUK0a I7Z0TpQI04tZlwg9oE0Sd1Q= =0t1p -----END PGP SIGNATURE----- |
From: Tony F. <to...@sy...> - 2005-03-03 18:58:55
|
On Thu, 2005-03-03 at 01:20, Tony Fraser wrote: > 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 Well tomorrow's here now. I didn't want to check this into CVS yet. I'd like to get some comments on it first. I tar'd everything up and put the tarball on the project webspace. You can download it from: http://openledger.sf.net/SL-Api.tar.gz Once you've downloaded and untar'd it make sure you have LWP::UserAgent and HTML::Form installed from CPAN and have a look in test.pl. You'll need to change the constructor arguments and probably the account numbers in the add_(debit|credit) method calls. -- Tony Fraser to...@sy... Sybaspace Internet Solutions System Administrator phone: (250) 246-5368 fax: (250) 246-5398 |