Dirty entity identification.

[Chris Shoemaker]

On Fri, Jul 22, 2005 at 12:01:56AM +0100, Neil Williams wrote:
> On Thursday 21 July 2005 11:09 pm, Chris Shoemaker wrote:
> > David wants to put a '*' in the window title when the book is dirty.
> > No problem, query all the collections' dirty flag.  Now, say we wanted
> > to extend the HIG usage to the sub windows.
> >
> > We want an account window's title to have '*' is the account is dirty.
> > Of course, what we actually mean is "does the account contain any
> > dirty splits?"  You may think this can be handled completely by CM
> > events, but perhaps not.  Consider this scenario:
> 
> > User opens an Account and adds a Trans with two splits.
> > Theoretically, we could catch a CM event here and mark that account
> > with a '*'.  But, the the user jumps to the other Account in the
> > Transaction.  This window wasn't around with the dirtying was done, so
> > it couldn't catch any events.  But, it is dirty, so we'd want to mark
> > it with a '*'.
> >
> > How do we dicover that it contains a dirty split?  Either we have to
> > search through *every* split in the Collection, seeing if it's in our
> > account and is dirty, OR, we just check our Account's "contains
> > something dirty" flag.  Big difference.
> 
> This clearly illustrates the nature of the search: It is an OBJECT issue and 
> it needs to be done in the objects.

Ok.  as opposed to .... where?

> 
> There is no harm in the dirty flag being set in the s->parent and passing that 
> back to the trans->parent (although this isn't currently part of how a Trans 
> is handled and there is no trans->parent). What cannot be done is for the 
> engine to follow that trail backwards because it cannot know that the Split 
> is a child of Trans. It's just another parameter of an object that happens to 
> have a name string consisting of "S""p""l""i" and "t" ("\0"). The engine has 
> no concept of what a Split actually IS - it's just an object of a specific 
> type with a set of pre-determined parameters.
> 
> What you describe above is an upward cascade which is already part of the 
> dirty flag setup and can easily be added to the *objects*. It has no part in 
> the marking of the QofCollection as dirty.

Ok.  Sounds good.

> 
> The Split can set the dirty flag in it's parent account (and does already) as 
> this pointer is part of the Split struct. The Trans, in contrast, knows 
> nothing about the parent account directly - it is currently notified via the 
> event mechanism after a call from the Split. So the tree doesn't even exist 
> in the source code as we conceptualise it. The Account cannot call the Trans 
> directly, it would have to call the Split which would call instead.
> 
> Rather than:            Account -> Trans -> Split
> 
> we have:                Split -> Account, Split -> Trans.
> 
> From the top:
> 		Trans -> list of Splits in the Trans
> 		Account -> list of Splits in the account.
> 
> So the Account can only iterate over all it's splits and the Trans can only 
> iterate over all it's splits. Neither can identify a single split without 
> iteration. The hierarchy is not symmetrical neither is does it accord with 
> the tree model.

I'm not sure it's all that complicated.  I think split cascades to
account, account cascades to book, and transactions can just cascade
to book, too.  With a few other things cascading up to book, I think
David would have what he wants.

> 
> You've also switched to only knowing IF there is a dirty split in the account, 
> not positively identifying WHICH split is dirty.

These are quite related.  Knowing the an account does or doesn't
contain a dirty split makes it much easier to find the dirty splits.

> 
> The only reason for a tree search is to find WHICH entity is dirty. Setting a 
> single gboolean flag is trivial.

That's right, and that flag makes the tree search possible.

-chris

> 
> Try this in ASCII / Fixed font display:
> 
>                          Split
> 			   |
> 		Trans------------Account
> 		  |                 |
> 	    GList of Splits      GList of Splits
> 	     in this Trans       in this Account
> 
>                         Account
> 			   |
> 		     GList of Splits
> 			   |
> 		     g_list_foreach
> 			   |
> 			 Split
> 			   |
> 			 Trans
> 
> 
> 			Trans
> 			  |
> 		    GList of Splits
> 			  |
> 		    g_list_foreach
> 			  |
> 			Split
> 			  |
> 		       Account
> 
> 
> That's how the source code implements the "tree".
> (events notwithstanding.)
> 
> -- 
> 
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
> 



> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel