QofCollection

[Derek Atkins]

(sorry for the delay -- i'm still catching up on a week's worth of mail)..

Neil Williams <linux at codehelp.co.uk> writes:

> From the previous thread on containers, Derek wrote:
>> that is basically just a 
>> container class.  It's effectively a special QOF type that contains other
>> QofClasses.  When you output a "reference" to this container class you get
>> back a tuple: <container name, contained type, guid>.
>
> As noted, this is a special QOF type rather than an entity of itself and I've 
> been working on that idea.
>
> Possible new QOF data type:
> #define QOF_TYPE_COLLECT  "collection"

I do like this concept..  Except...

> Template for additional GncInvoice parameters:
> { INVOICE_ENTRIES, QOF_TYPE_COLLECT, (QofAccessFunc)qofInvoiceGetEntries, 
> (QofSetterFunc)qofInvoiceSetEntries },
> { Q_INVOICE_OWNER, QOF_TYPE_COLLECT, (QofAccessFunc)qofInvoiceGetOwner,
> (QofSetterFunc)qofInvoiceSetOwner },
> { Q_INVOICE_BILLTO, QOF_TYPE_COLLECT, (QofAccessFunc)qofInvoiceGetBillTo,
> (QofSetterFunc)qofInvoiceSetBillTo },
>
> (these are all additional parameters, the existing GNC_ID_OWNER params would 
> stay, just without my added (QofSetterFunc).)

I'm not sure I agree that the Entries belong here...  Maybe they do --
I'm not sure.  I still have to convince myself.  In some ways, yes,
they do belong (because an invoice is sort of like a template
transaction).  However there's still the issue of an Entry attached to
multiple invoices (a vendor invoice and a customer invoice).

I'm not sure how you'd plan to handle that case in the current
implementation.  I'm starting to think that the pointer resolution
might be better handled in a different way.  Instead of QSF trying to
determine what to pull in, perhaps we should have a higher-level set
of functions that pull in all the required QOF Objects required to
export a particular object, and then you can serialize that set.

For example, perhaps something like:

  void qofExportAddObject(QofCollection*, QofEntity*);

Where this will add all the dependent entities to the collection for
export.  It would resolve the Entries in an Invoice, and then also the
other invoice(s) required for each entry.  I.e. it would be a deeply
recursive copy into the collection.

Then you just need to qsfSerialize(QofCollection*) to push the
collection of objects into XML...  (Perhaps QofCollection isn't quite
the right object here, but hopefully you get my point).

This way you don't need to special-case the GetEntries (and you
SPECIFICALLY don't need the SetEntries!), and the GetOwner and
GetBillTo can remain using your current QOF_TYPE_COLLECTION idea
(which is nice for a way to specify _ONE_ object of multiple,
potential types).

I'm worried about what happens in your current implementation if
someone hand-writes XML that puts two customers into the Owner
Collection?  Or worse, puts a customer and a vendor.  Then what do you
do?

-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