GDA: A few questions

Chris Shoemaker c.shoemaker at cox.net
Mon Dec 11 22:06:38 EST 2006


On Mon, Dec 11, 2006 at 09:22:15PM -0500, Derek Atkins wrote:
> Chris Shoemaker <c.shoemaker at cox.net> 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



More information about the gnucash-devel mailing list