On Tuesday 03 May 2005 4:21 pm, Derek Atkins wrote: > Quoting Neil Williams <[EMAIL PROTECTED]>: > Yes, it's likely to break a LOT of places!
(thought it might!) ;-) I hope you don't mind the request though - I had to ask. > You should grep through the > code, it's not easy to grep for a QOF parameter - it gets hidden behind param_getfcn(). Yes, you can call the function directly but that's not the point - I wasn't ever going to replace the function, just replace the parameter. > but it's going to cause no end to grief in a lot of places (including > the reports, which makes grepping a bit more challenging). v.true. > It's too bad you can't "special-case" objects in QOF. The GncOwner REALLY > is just a placeholder, a way to store one of a set of types. Yes, what we need is a way to bypass GncOwner from GncInvoice - to return the type. I'll work on that instead. This is an important area for QOF - it's going to come up in other areas and it's worth solving it generically. Special cases are difficult when I'm trying to maintain handling that is as generic as possible. One way I've solved this elsewhere is "wrapping" - if there is more than one type of object for a parameter, wrap all types in one and hide the internal objects completely. This would mean that there would be no separate GncCustomer, for example, or GncJob. I'd simply query the Owner and be done with it. That's OK in certain situations but I wouldn't do it in GnuCash. I was considering wrapping GncAddress within GncCustomer etc. though. Make the address parameters appear as customer parameters and don't expose anything of GncAddress itself to QOF. Repeat for employee, vendor etc. Too much duplication though possibly? The same address would only appear twice if a user had a customer who is also an employee or vendor. Again, this is only changing the QofParam params[] array, not removing any of the existing functions. > Perhaps > instead of trying to fit GncOwner into QOF, we should change QOF to handle > superclass storage types like GncOwner? Would that make more sense? It would, but I agree that running queries against GncOwner as either an object OR a superclass is just as pointless. All that's needed is *access* from GncInvoice to GncCustomer/GncJob/GncEmployee etc. QOF doesn't actually have to know about GncOwner as long as it can access the data behind it. It's a similar thing to AccountGroup - GncOwner is not a part of the data, it's part of the data handling / organisation. I'll commit an unchanged GncOwner, modified GncBillTerm and the recursive copying routines in qofsession and consider things over the next few days. This means that although the routines will work, they won't - yet - be able to locate the GncCustomer and thereby the Address for invoices. That will come later. With AccountGroup it was easier - the AccountGroup only ever contains Accounts, so it was easy to bypass because the destination type was known. > Frankly I really see no reason to turn a GncOwner into a full fledged > object. That's REALLY stupid, IMHO. It was worth consideration though! :-) > There's no reason to make a table out > of them, either, because all the information in GncOwner _already exists_. Agreed, it's just finding it. The invoice (or whatever else is using GncOwner) just needs to tell me what kind of Owner it has, as a parameter. A string is the obvious choice - use the e_type? > Effectively GncOwner is just a QofEntity with a limited range of values. But a QofEntity is an instance, QofObject is the definition and that's the basis of the tables. I've looked at changing QofObject a couple of times and each time I've found a better solution. > So perhaps the right way to fix this is make a QofLimitedEntity type that > has a limit of the types of objects and have QoF treat the LimitedEntity as > a special type in the I/O routines? Then we can recode GncOwner as a > QofLimitedEntity<Customer,Vendor,Employee> (to use a C++ term). I'll have a think on that. It looks a lot like an enum actually. > > The rest of the changes can be internal to the object and not affect > > existing functions. > > Unfortunately a lot of code assumes it can get the actual underlying guid > from that API. As it should, if GncOwner is going to be transparent. > I'd have to do a LOT of research to figure out where, but a > number of searchparams use that API (both in C and Scheme). It's OK, I'll take another route. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpCqWbH9WQn3.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
