FreqSpec and SchedXaction as QOF objects

[Derek Atkins]

Quoting Josh Sled <jsled at asynchronous.org>:

> On Sat, 2005-04-23 at 10:19, Neil Williams wrote:
> > It's currently only GnuCash that puts limits on top level and sub objects
> and 
> > it gets confusing sometimes. Certainly, within GnuCash there should not be
> 
> > GncAddress or FreqSpec objects on their own - they simply won't get written
> 
> > out by the normal backends. However, when QSF can deal with partial
> QofBooks 
> 
> Hmm.  There may be cases where GnuCash wants to have a run-time FreqSpec
> that should not be persisted.  The scheduled transaction setup dialog,
> for instance, internally uses a transient FreqSpec to maintain state. 
> 
> But the rest of your text sounds like that is fine; I just want to make
> sure.
> 
> ...jsled

Gnucash does this in a LOT of places with a lot of objects..  NOt just the FS.
Gnucash FREQUENTLY uses an internal transient object to maintain state during a
dialog (or register) interaction, and then deletes the transient or commits the
transient as needed.

This is a general issue, not specific to Freqspec.  But it's a good point to
make.

-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
       warlord at MIT.EDU                        PGP key available