Re: GDA: A few questions
On Mon, Dec 11, 2006 at 10:21:36PM -0500, Derek Atkins wrote:
> Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>
> >I'm not disagreeing about Invoices. AFAICT, Invoices already have the
> >design feature that I think SXs should have - they use real accounts,
> >transactions, and splits, and just note in the transaction KVP that
> >this is an invoice transaction.
>
> Not at all. An unposted invoice has no Account, Transaction,
> or Split objects.. It has references, but it uses a GncEntry
> object as the line item entries.. A GncInvoice is like a Transaction,
> and a GncEntry is like a Split, but no, it doesn't re-use the
> core engine objects.
Ah, I see. I really don't know the business code well enough to
comment on Invoices then.
> >Invoices basically reuse the engine objects. But SXs have:
> >
> >struct TTInfo_s
> >{
> > /* FIXME add notes field */
> > char *description; /* owned by us */
> > char *num; /* owned by us */
> > gnc_commodity *common_currency; /* not freed */
> >
> > GList *splits; /* list of template splits, owned by us */
> >};
> >
> >which look suspiciously like a Transaction, and
> >
> >struct TTSplitInfo_s
> >{
> > char *action; /* owned by us */
> > /* FIXME: What about the split's KvpFrame */
> > char *memo; /* owned by us */
> > char *credit_formula, *debit_formula; /* owned by us */
> > Account *acc;
> >};
> >
> >which looks suspiciously like a Split. And then the whole duplicated
> >accounts setup. I'm just saying SXs could use the real engine
> >objects, just like Invoices. The only difference is that the engine
> >has to learn that "real" SX transactions aren't _that_ real. :)
>
> Except Invoices don't either, for the same reason that it's causing
> trouble that SXes do -- it complicates all the code when EVERYONE has
> to be aware that a foo-object is really part of a bar-object. Much
> easier to just have foo object and bar object and then use KVP GUIDs
> to link back and forth.
I can see your point, but I just don't agree that the benefit of not
requiring the engine to know how to provide a list of transactions
that excludes SXs is greater than the benefit of reusing the
data-structures and constraint code.
I'm not saying the same argument holds for invoices.
> >Just to clarify, as for the GUI, I'm not suggesting that the register
> >is a good place to edit or view the SX data structure - just the real
> >transactions it would link to.
>
> Except an SX isn't a real transaction, it's a Template Transaction.
Well, I think of an SX as different from, and containing many,
template transactions, but I think your point is just that template
transactions aren't "real". My point is just that the difference
between a template transaction and a "real" transaction is 95%
semantic and 5% syntactic, and that therefore, it's better to adjust
the syntax just a little to represent both concepts than to duplicate
95% of the syntax to represent the "not real" transaction.
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
> I'm not disagreeing about Invoices. AFAICT, Invoices already have the
> design feature that I think SXs should have - they use real accounts,
> transactions, and splits, and just note in the transaction KVP that
> this is an invoice transaction.
Not at all. An unposted invoice has no Account, Transaction,
or Split objects.. It has references, but it uses a GncEntry
object as the line item entries.. A GncInvoice is like a Transaction,
and a GncEntry is like a Split, but no, it doesn't re-use the
core engine objects.
> Invoices basically reuse the engine objects. But SXs have:
>
> struct TTInfo_s
> {
> /* FIXME add notes field */
> char *description; /* owned by us */
> char *num; /* owned by us */
> gnc_commodity *common_currency; /* not freed */
>
> GList *splits; /* list of template splits, owned by us */
> };
>
> which look suspiciously like a Transaction, and
>
> struct TTSplitInfo_s
> {
> char *action; /* owned by us */
> /* FIXME: What about the split's KvpFrame */
> char *memo; /* owned by us */
> char *credit_formula, *debit_formula; /* owned by us */
> Account *acc;
> };
>
> which looks suspiciously like a Split. And then the whole duplicated
> accounts setup. I'm just saying SXs could use the real engine
> objects, just like Invoices. The only difference is that the engine
> has to learn that "real" SX transactions aren't _that_ real. :)
Except Invoices don't either, for the same reason that it's causing
trouble that SXes do -- it complicates all the code when EVERYONE has
to be aware that a foo-object is really part of a bar-object. Much
easier to just have foo object and bar object and then use KVP GUIDs
to link back and forth.
> Just to clarify, as for the GUI, I'm not suggesting that the register
> is a good place to edit or view the SX data structure - just the real
> transactions it would link to.
Except an SX isn't a real transaction, it's a Template Transaction.
> -chris
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
[EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
On Mon, Dec 11, 2006 at 09:22:15PM -0500, Derek Atkins wrote:
> Chris Shoemaker <[EMAIL PROTECTED]> writes:
>
> >> (*) This really should be fixed: the template-transaction accounts
> >> should probably be a more literal mirror of the real account tree, in
> >> terms of types and commodities. The whole point of using real Accounts
> >> and Transactions for the template transactions was to leverage the
> >> editor (register) and the implicit application constraints for the
> >> template transactions ... I didn't want to re-implment or re-specify a
> >> bunch of logic around "template" transactions seperate from "real"
> >> transactions, and especially not the register component. But for a few
> >> reasons, they did diverge. In any case, it'd be nice if they were
> >> closer together, but that's not a focus of the branches/sx-cleanup/,
> >> right now.
> >
> > I know I've mentioned this to jsled, but FTR, I would recommend taking
> > this one step farther... by making SXs real transactions, using real
> > accounts and real splits, but simply flagged at the transaction-level
> > as "SX". Then, we make the normal transaction queries exclude SX
> > transactions.
> >
> > As far as register integration goes, then it's just a matter of adding
> > a treeviewcolumn that knows how to display, edit and store (in KVP)
> > the formula-amounts.
>
> See, I think it should go the other way.. I think each object
> should be unique and have its own tree-model. If the register
> rewrite is general enough then that's all we should need, right?
> We could do a test based on an Invoice register
I'm not disagreeing about Invoices. AFAICT, Invoices already have the
design feature that I think SXs should have - they use real accounts,
transactions, and splits, and just note in the transaction KVP that
this is an invoice transaction.
Invoices basically reuse the engine objects. But SXs have:
struct TTInfo_s
{
/* FIXME add notes field */
char *description; /* owned by us */
char *num; /* owned by us */
gnc_commodity *common_currency; /* not freed */
GList *splits; /* list of template splits, owned by us */
};
which look suspiciously like a Transaction, and
struct TTSplitInfo_s
{
char *action; /* owned by us */
/* FIXME: What about the split's KvpFrame */
char *memo; /* owned by us */
char *credit_formula, *debit_formula; /* owned by us */
Account *acc;
};
which looks suspiciously like a Split. And then the whole duplicated
accounts setup. I'm just saying SXs could use the real engine
objects, just like Invoices. The only difference is that the engine
has to learn that "real" SX transactions aren't _that_ real. :)
Just to clarify, as for the GUI, I'm not suggesting that the register
is a good place to edit or view the SX data structure - just the real
transactions it would link to.
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
Chris Shoemaker <[EMAIL PROTECTED]> writes: >> (*) This really should be fixed: the template-transaction accounts >> should probably be a more literal mirror of the real account tree, in >> terms of types and commodities. The whole point of using real Accounts >> and Transactions for the template transactions was to leverage the >> editor (register) and the implicit application constraints for the >> template transactions ... I didn't want to re-implment or re-specify a >> bunch of logic around "template" transactions seperate from "real" >> transactions, and especially not the register component. But for a few >> reasons, they did diverge. In any case, it'd be nice if they were >> closer together, but that's not a focus of the branches/sx-cleanup/, >> right now. > > I know I've mentioned this to jsled, but FTR, I would recommend taking > this one step farther... by making SXs real transactions, using real > accounts and real splits, but simply flagged at the transaction-level > as "SX". Then, we make the normal transaction queries exclude SX > transactions. > > As far as register integration goes, then it's just a matter of adding > a treeviewcolumn that knows how to display, edit and store (in KVP) > the formula-amounts. See, I think it should go the other way.. I think each object should be unique and have its own tree-model. If the register rewrite is general enough then that's all we should need, right? We could do a test based on an Invoice register -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
On Sat, Dec 09, 2006 at 12:53:35PM -0500, Josh Sled wrote: > On Fri, 2006-12-08 at 17:34 -0500, Phil Longstaff wrote: > > I'm working on saving/restoring scheduled transactions, and have some > > questions: > > > > 1) Accounts - The only difference I can see between regular accounts and > > the accounts created for scheduled transactions is in the currency - the > > currency for scheduled transactions is in the "template" namespace. > > Anything else? Could we have a new account type called TEMPLATE so that > > I wouldn't need a really complex query to load just the regular > > accounts? > > Until this is fixed (*), I think it's safe to have a separate > account-type, yes. As per the other thread, I agree: a bit isn't > sufficient, a whole separate rooted tree is The Right Thing, and a bit > will probably suffice for the moment. :) > > (*) This really should be fixed: the template-transaction accounts > should probably be a more literal mirror of the real account tree, in > terms of types and commodities. The whole point of using real Accounts > and Transactions for the template transactions was to leverage the > editor (register) and the implicit application constraints for the > template transactions ... I didn't want to re-implment or re-specify a > bunch of logic around "template" transactions seperate from "real" > transactions, and especially not the register component. But for a few > reasons, they did diverge. In any case, it'd be nice if they were > closer together, but that's not a focus of the branches/sx-cleanup/, > right now. I know I've mentioned this to jsled, but FTR, I would recommend taking this one step farther... by making SXs real transactions, using real accounts and real splits, but simply flagged at the transaction-level as "SX". Then, we make the normal transaction queries exclude SX transactions. As far as register integration goes, then it's just a matter of adding a treeviewcolumn that knows how to display, edit and store (in KVP) the formula-amounts. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Registers (was Re: GDA: A few questions)
Josh Sled <[EMAIL PROTECTED]> writes: > (*) This really should be fixed: the template-transaction accounts > should probably be a more literal mirror of the real account tree, in > terms of types and commodities. The whole point of using real Accounts > and Transactions for the template transactions was to leverage the > editor (register) and the implicit application constraints for the > template transactions ... I didn't want to re-implment or re-specify a > bunch of logic around "template" transactions seperate from "real" > transactions, and especially not the register component. But for a few > reasons, they did diverge. In any case, it'd be nice if they were > closer together, but that's not a focus of the branches/sx-cleanup/, > right now. I'm hoping that with the "register rewrite" it'll be much easier to create a register for different data types just by creating the appropriate data model. Granted, the original register was an attempt to do that, but I dont think it was abstracted at the right places. I haven't looked at Chris' work to see how much easier it'll be But I'm still hopeful. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
On Fri, 2006-12-08 at 17:34 -0500, Phil Longstaff wrote:
> I'm working on saving/restoring scheduled transactions, and have some
> questions:
>
> 1) Accounts - The only difference I can see between regular accounts and
> the accounts created for scheduled transactions is in the currency - the
> currency for scheduled transactions is in the "template" namespace.
> Anything else? Could we have a new account type called TEMPLATE so that
> I wouldn't need a really complex query to load just the regular
> accounts?
Until this is fixed (*), I think it's safe to have a separate
account-type, yes. As per the other thread, I agree: a bit isn't
sufficient, a whole separate rooted tree is The Right Thing, and a bit
will probably suffice for the moment. :)
(*) This really should be fixed: the template-transaction accounts
should probably be a more literal mirror of the real account tree, in
terms of types and commodities. The whole point of using real Accounts
and Transactions for the template transactions was to leverage the
editor (register) and the implicit application constraints for the
template transactions ... I didn't want to re-implment or re-specify a
bunch of logic around "template" transactions seperate from "real"
transactions, and especially not the register component. But for a few
reasons, they did diverge. In any case, it'd be nice if they were
closer together, but that's not a focus of the branches/sx-cleanup/,
right now.
> 2) SXRegister() registers the class with qof using GNC_SX_ID rather than
> GNC_ID_SCHEDXACTION (which would agree with how every other object is
> registered). I don't think it will break anything to change this, but
> want to know if there is anywhere else I should check i.e. where else
> are getters/setters used?
Yeah, I think that's simply incorrect. It looks like the
qof_instance_init(...) calls are with GNC_ID_SCHEDXACTION, but the
qof_class_register is with GNC_SX_ID. You should feel free to change
it; ideally as a seperate physical/logical commit, so I can patch it
over to branches/sx-cleanup/ ...
FYI, the branches/sx-cleanup/ also has a new separate GNC_ID_SXES type
for the collection, in order to support insertion/removal events of SXes
overall. It's the same stuff from SX-book{,-p}.[ch], but qof-ized a bit
more. I don't think that implies anything for the storage, though; it's
just a runtime change at present.
--
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
On Fri, 2006-08-12 at 23:10 -0500, Derek Atkins wrote: > Quoting Phil Longstaff <[EMAIL PROTECTED]>: > > >> The main difference is the root.. SXes all live in their own AccountGroup, > >> separate from the CoA. Why do you need anything special? Why can't you > >> load the SXes too? > > > > I can. I need to look into how AccountGroups are used. Right now, what > > happens is that the sx accounts show up in the CoA. Hmmm... The sx > > accounts have no parent, but I am also not saving/restoring any > > indication of which AccountGroup each account should belong to. I guess > > I need another boolean indicating whether the Account is in the template > > account group or the CoA account group. If there can be more than these > > account groups in the future, perhaps something more general is > > required, though there is no identifier in an account group. > > No, a boolean is the wrong thing. We need DavidH to finish the AccountGroup > removal which would add a new account type, a TopLevel account. This would > replace the root accountgroup. Then you'd have the different accounts > based on the (new) root accountgroup. > > I dont know what David hasn't merged into trunk, yet. Once he does, you > could pull up those changes onto your branch. > > Regardless, a boolean is DEFINITELY the wrong answer; what happens if > down the road we add something that adds a third accountgroup? I know boolean is wrong. I'll wait for the TopLevel changes. I may add a boolean as a temporary measure to get me past this problem so I can finish with scheduled transactions. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
Quoting Phil Longstaff <[EMAIL PROTECTED]>: >> The main difference is the root.. SXes all live in their own AccountGroup, >> separate from the CoA. Why do you need anything special? Why can't you >> load the SXes too? > > I can. I need to look into how AccountGroups are used. Right now, what > happens is that the sx accounts show up in the CoA. Hmmm... The sx > accounts have no parent, but I am also not saving/restoring any > indication of which AccountGroup each account should belong to. I guess > I need another boolean indicating whether the Account is in the template > account group or the CoA account group. If there can be more than these > account groups in the future, perhaps something more general is > required, though there is no identifier in an account group. No, a boolean is the wrong thing. We need DavidH to finish the AccountGroup removal which would add a new account type, a TopLevel account. This would replace the root accountgroup. Then you'd have the different accounts based on the (new) root accountgroup. I dont know what David hasn't merged into trunk, yet. Once he does, you could pull up those changes onto your branch. Regardless, a boolean is DEFINITELY the wrong answer; what happens if down the road we add something that adds a third accountgroup? -derek > Phil -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
On Fri, 2006-08-12 at 18:20 -0500, Derek Atkins wrote: > Quoting Phil Longstaff <[EMAIL PROTECTED]>: > > > I'm working on saving/restoring scheduled transactions, and have some > > questions: > > > > 1) Accounts - The only difference I can see between regular accounts and > > the accounts created for scheduled transactions is in the currency - the > > currency for scheduled transactions is in the "template" namespace. > > Anything else? Could we have a new account type called TEMPLATE so that > > I wouldn't need a really complex query to load just the regular > > accounts? > > The main difference is the root.. SXes all live in their own AccountGroup, > separate from the CoA. Why do you need anything special? Why can't you > load the SXes too? I can. I need to look into how AccountGroups are used. Right now, what happens is that the sx accounts show up in the CoA. Hmmm... The sx accounts have no parent, but I am also not saving/restoring any indication of which AccountGroup each account should belong to. I guess I need another boolean indicating whether the Account is in the template account group or the CoA account group. If there can be more than these account groups in the future, perhaps something more general is required, though there is no identifier in an account group. Phil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GDA: A few questions
Quoting Phil Longstaff <[EMAIL PROTECTED]>: > I'm working on saving/restoring scheduled transactions, and have some > questions: > > 1) Accounts - The only difference I can see between regular accounts and > the accounts created for scheduled transactions is in the currency - the > currency for scheduled transactions is in the "template" namespace. > Anything else? Could we have a new account type called TEMPLATE so that > I wouldn't need a really complex query to load just the regular > accounts? The main difference is the root.. SXes all live in their own AccountGroup, separate from the CoA. Why do you need anything special? Why can't you load the SXes too? > 2) SXRegister() registers the class with qof using GNC_SX_ID rather than > GNC_ID_SCHEDXACTION (which would agree with how every other object is > registered). I don't think it will break anything to change this, but > want to know if there is anywhere else I should check i.e. where else > are getters/setters used? Maybe jsled can answer. > Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
