Re: [Openledger-developer] Random jottings

[Klavs K. <kl...@vs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

on 03/21/05 21:50 Tony Fraser wrote:
[SNIP]

| Bad? I would argue that it is good. In a web-gui environment it
| wouldn't matter one way or the other. HTTP is stateless and can't
| maintain things like DB connections between requests. Think of a
| Perl-Gtk app though, it would make sense to maintain a DB
| connection for each transaction, actually it would be mandatory in
| order to maintain transaction isolation.

To me it seems I'm doing the exact same thing? the client creates a
new OpenLedger object, and at that point the a unique db connection is
opened for that client.
Used in a webgui environment, I agree that "almost" everytime it will
not matter, as the webgui will only make 1 transaction pr. request.
But it could do more than that - depending on the design.
[SNIP]

| Copying transactions from system to system would have to be allowed
| for. Using them for "something else" is fine What does the API care
| what you do with an object.

But embedding the transaction object inside the $acct object, means
the program that reuses the transaction object, has to use the $acct
object too - and IMHO that is unnecessary. I see no advantage to
embedding the transaction/invoice etc. objects inside the accounting
object (so that you have to call the accounting object to create a
transaction object) and IMHO it is a lot nicer, if I have the freedom
to create a transaction, and then use the same object to post
transactions to f.ex. two OpenLedger DB's. In your design, I do not
have that freedom.
My reasoning for creating seperate invoice/transaction/etc. objects,
is also that programs interfacing with OpenLedger, could use the same
objects for representing their "accounting" data internally - and thus
make it much easier for them to use OpenLedger. An invoice is an
invoice - no matter which system uses it :)

|> I'd prefer having GL etc. as seperate objects (as we have now) -
|> which the user who creates the objects, can decide to use for
|> whatever they see fit - and then accept these as parameters for
|> f.ex. post_transaction - - which could be made to accept both
|> AR,AP and GL transactions.
|
|
| So you plan on putting the whole 20,000 lines of code that makes up
| the backend of SL (SL/*.pm) into one package? That sounds like an
| even worse maintenance problem than SL has now to me.

It could be seperate functions - or we could internally in OpenLedger
- - split it out into sub-packages.
To the user - it should IMHO be as simple as creating an OpenLedger
object - and then calling it's methods/functions to do whatever they
see fit.
I see no reason to tie the data-structures (invoice, transaction etc.)
to the OpenLedger object.

|
| BTW, I was looking at your code in CVS, Why don't you use
| Class::Accessor? You could write TransactionLine.pm as:
|
| -SNIP- package TransactionLine;
|
| use strict; use vars qw($VERSION);
|
| $VERSION = "0.1"; sub Version { $VERSION }
|
| use Class::Accessor; use base qw/Class::Accessor/;
|
| sub new { bless { }, shift; }
|
| TransactionLine->mk_accessors(qw/debit credit accNo/);
|
| 1; __END__ -SNIP-
|
| You get the idea (Copyright info removed for brevity).

Looks very interesting. I definetely agree that we should embrace that
we are using GPL, and reuse every bit of code that is sensible to
reuse. This def. seems to make the data objects smaller :)
If you'd convert one of the objects - then I could use that as a
working example :)

[SNIP]

|
| The reason is because post_debit would take a reference to a
| account object and how that object reference is found is up to the
| user of the API. I could just have easily said:
|
| ( $chart->find_account( type => ASSET, name => "%Office
| Equipment%") )[0]
|
| to use the first account that is an asset account with "Office
| Equipment" in its name.

I'll buy that - so have we an accountobject too :)

- --
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.4.0 (GNU/Linux)

iD8DBQFCP9ePPToLeX4GPGIRAsSxAJ9MXXf4+ykhKok6d8HRV1+4RALPsACfRx8y
HhcU3SIDSmim44zBnxKNddE=
=2thp
-----END PGP SIGNATURE-----