Dirty entity identification.

[Neil Williams]

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.

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.

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.

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

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

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050722/dfc2386b/attachment.bin