Re: [Openledger-developer] Random jottings

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

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

on 03/22/05 18:15 Tony Fraser wrote:
[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?

Yes (but usually in accounting each GUI has one user, there may be
several computers running the same GUI - but then they'll have
seperate objects/connections anyways, and thus performs one action at
a time). IMHO that is better than having a connection for each
transaction/invoice object.
When searching for invoices, I was planning on returning an array of
invoice-objects - ie. the resulting invoices. If we did that, a DB
connection for each of them would be inevitable, and very ressource
consuming.
Ofcourse one could argue, we should define some sort of result-subset
- - but, as the user needs to be able to define which data they want
shown from the search, a function that either retrives it all - or a
subset, as defined in the function call will be required. So the
result-set needs to be able to represent everything from 1 to every
data in an invoice/transaction/item etc., and thus it is IMHO best to
just return an array of the objects in question.
[SNIP]

|
|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.

Ahh - Then I have no problem with that - except for one thing. The
fact that you define a BACKEND on the invoice/transaction etc. object.
But that I've argued in the above segment :)
Having the BACKEND there, also means you can't just post the object to
another OpenLedger object (or crm or whatever uses the same objects),
as you'd have to redefine the BACKEND var in the object then.
This can be done, but is IMHO object-orientation. I see no reason for
the data-object to know anything about who uses it (ie. the BACKEND to
which is from or will be posted too).
[SNIP]

|
|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.

No problem.

Just checkout the openledger source from CVS and alter as you see fit
- - and do a cvs commit :)

If any of you have problems with handling the CVS - pls. ask on the
list, so I can help you.
Remember to read the relevant parts of the SF cvs howto - it's very
good and you can use their examples almost ad verbatim :)


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

iD8DBQFCQSY8PToLeX4GPGIRAhN3AJ917TxaPVS1BNSpkXbRCtGIu4bzlQCgjm+o
nxwCof/bYVU3MsVQqoapqPM=
=njVI
-----END PGP SIGNATURE-----