Backend customisation and be->price_lookup
linux at codehelp.co.uk
Thu Sep 22 16:05:32 EDT 2005
On Thursday 22 September 2005 8:29 pm, Derek Atkins wrote:
> You do a stack trace? Or are you expecting some calling convention where
> you have to do something like:
I've already decided to change that after your first email - you're right it
was a bad idea to do it so loosely - it needs the backend context.
> > Once the backend is loaded as a GModule, the only way to cast from
> > QofBackend to FileBackend (or whatever) is by including the header
> > file from the backend itself that declares the FileBackend struct,
> > which means that the module must always be loaded.
> That cast to a FileBackend shouldn't ever happen in QOF;
It wasn't going to - it was going to happen in gnc-pricedb.c if
be->price_lookup got simply moved to fbe->price_lookup. Don't worry about it,
I'd never have done that. I was just illustrating why I started thinking
about the extension.
> So you're tying the QOF Backend to the Application, and providing a
> way for QOF to translate across.
> Mkay, that makes sense to me.
> You're putting a generic layer in between the frontend and backend,
> and the two ends are necessarily tied together.
Yes. A supplementary layer that allows specific backends to do more than what
is currently supportable in QofBackend itself - especially tasks that are too
application-specific for QOF itself. The application, as you say, therefore
has to be tied closely to the backend for the task to become available.
I agree - I'd missed the need for the backend context.
I'll see about that QofQuery and put the whole thing on the back burner if
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050922/df091a3a/attachment.bin
More information about the gnucash-devel