Thus spake Phillip J. Eby ([EMAIL PROTECTED]):
> That's all quite true, but it would probably be simplest to do such a thing
> using AttributeProviders and SheetProviders in the white-box specialists.
> It does seem reasonable to have those providers talk to an
> AccountingProcessor object if you want to make your framework talk to
> different back-ends, but I think it is misleading and incorrect to call
> AccountingProcessor a specialist, as it's not an application-level service
> object, but a private implementation helper.
Does anybody out there have even the slightest clue about how to go about
using AttributeProviders and SheetProviders? A select few terse hints on
this subject would really help us (me) figure it out enough to start working
on some howto's.
> Interestingly, you've just given me what may be a motivating example for
> using Shane Hathaway's DatabaseAPI in conjunction with ZPatterns, assuming
> of course that I've correctly understood his most recent explanation of the
> DatabaseAPI product.
Am i wrong in thinking that DatabaseAPI is a completely separate solution to
the same problem that ZPatters is suppose to address? Personally i have to
give DatabaseAPI props for being quite easy to understand and use, while
not sacrificing power.