On Tue, 04 Jul 2000, Rob Browning wrote:
> Well, we had been planning, and I think Bill's been working on,
...
> Does this seem to match OK with what everyone needs?
In a word, NO!
Although it might work, I see some real problems. Which brings me to the
fundamental question: "Why is anyone IMPLEMENTING something BEFORE we have
discussed the GLOBAL DESIGN of how these things will fit together?"
As I read your description, you are presently implementing a database of
"Thing"s. Each "Thing" has a collection of "Property"s and each "Property"
has an associated "Value".
"Property"s are addressed by name and the "Value" can be either a value such
as a "String" or a reference to another "Thing". I suspect that we can assume
that we know the "Type" of each "Value", a priori.
I concur with you when you assert that it probably not a good idea to expect
to use a hash store for the properties that are required.
The problem that I have is related to "factoring" common properties.
If you take my previous description, each LedgerEntry will have a large
number of properties. However, I don't think that we can afford to record
each property on each LedgerEntry. However, for reporting purposes, we will
need to attach the right properties to each entry.
* * *
Now, about the idea of simply having a "dividend-from" field, I think this is
perhaps what the GUI will want to generate. However, I think that we will
want to store a "Template" in the data store that allows the calculation of
which actions are permitted and which accounts are affected.
Not only would we use a template (which the user can edit) to associate
accounts, but I think we can have a template to describe the generic GUI
elements that are displayed for the ledger.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
