Re: [Openledger-developer] Random jottings

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

On Tue, 2005-03-22 at 00:30, Klavs Klavsen wrote:
> | 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]

So if I'm using your API in a persistent environment (Gtk App, App
Server, whatever) I would have to create a new OpenLedger object for
each concurrent transaction I have running?

> | 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 :)

Ahh... Now I see your concern. It is IMHO unfounded but I see.

If you look at the UML I posted Business::Ledger::Transaction::GL would
be a standalone class and you are free to use it as such. Code is always
good, here's a sudo implementation of the start_transaction sub:

sub start_transaction {
	my $self = shift;
	my $trans_class = shift;

	UNIVERSAL::require($trans_class);
	my $trans_obj = new $trans_class (
				BACKEND => $self->{_BACKEND},
	);

	return $trans_obj;
}

So you see, start_transaction would just be a convenience that passes
standard parameters to the transactions constructor.

> | 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 :)

I'll see if I have time to check something into CVS but the code above
is a completely functional TransactionLine.pm. It is functionally
identical to the one that is in CVS now I just removed the
comments/copyright to make it more email friendly. Class::Accessor is a
CPAN module you will have to install before it will work though.

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