Re: [Openledger-developer] Random jottings

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

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

on 03/23/05 19:08 Tony Fraser wrote:
[SNIP]

|
| So, say I'm writing a Tk based POS because I'm unhappy with the
| data entry rate of a web interface. Each POS machine is making
| conntions directly to the DB. Now, because customers are
| unpredictable creatures and often change their mind half way
| through a POS transaction I create a hold function. ie. Take the
| current transaction and set it aside and start a new transaction so
| the clerk can help the next person in line.
|
| Your saying that I would have to create a OpenLedger.pm object when
| I put a transaction on hold?

Ehh - why would that have ANYTHING to do with OpenLedger transactions?
situations like that is helped, because the clerk is NOT going to
"post" the transaction, before he actually finishes defining it (ie.
filling the object) and has received payment from the customer. And if
he puts a case on hold -that just means he'll put that
"invoice/whatever-POS" object aside, and then perhaps post it to
OpenLedger, when he finalizes the transaction. Starting a
db-transaction at all, before every data has been collected, and the
clerk is actually certain it needs to be done, is simply a waste of
time, and IMHO bad practice.

|> 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.
|
|
| That would be fine but the objects would have to be read only. And
| hence wouldn't have to have a backing DB connection. When the user
| decides on a particular invoice to edit, a new connection should be
| opened and an new DB transaction started by re-retrieving the
| invoice.
|
I don't like that the object should have it's own db-connection, and
if it hasn't, there's no need for the code to re-retrive the invoice
once it is seeked to be editted. I would prefer it be posted to an
"invoiceEdit" function, and then the invoicenr is used as the ref. and
the old invoice is removed, and the new one posted. Making the code
having to re-retrive the invoice, and then do the exact same thing
they could have done to the original object makes no sense.
The code using the OpenLedger API should be able to alter the
invoices, as they see fit. Even if you "try" to make it more
troublesome, by forcing them to re-retrive it, they can still do the
exact same things, which just means its a waste of code, and
unnecessarily troublesome to work with.

| Or you could just use a different (generic) ResultSet type object
| that only retrieves the fields that the user requests for the
| search in the fist place.

We could. But seeing as how we need to fetch and search the DB
anyways, and chances are they need the invoice-object, we might as
well fetch them all as invoice-objects, and then they can simply pull
out the invoice from the array, that they want to work with.

Don't like to have more datatypes or different types of resultsets, if
it isn't necessary.

In short, I'd like to make it as simple as possible - and don't force
complexity on it, that does not need to be there. Then we can always
alter/enhance the code, if we find something needs to be rethought,
but I doubt we'll actually see the "right way" before having tried and
learned - and that's why I prefer the KISS approach :) - a simple
design (and mind you, simple is not necessarily bad - it is most often
- - also in security, a good thing) will also make it easier/quicker for
us to get OpenLedger off the ground.

You totally missed commenting on:

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


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

iD8DBQFCQoJrPToLeX4GPGIRAouHAJ9VIbms5kk9gpMYjVWOLeW+4sRylwCfalHX
4mvTrYS21Q1x3VlmvD3Zr9I=
=1ipI
-----END PGP SIGNATURE-----