At 05:26 PM 6/28/00 +0100, Steve Alexander wrote:
The suggested specialists in the Accounting framework are:
Invoices Orders Customers Products
What I'm finding is that these are just the White-box specialists. A clean design would seem to want all the specialists above, plus at least one Black-box specialist to do the "heavy lifting. Let's call it the "AccountingProcessor" specialist.
Keep in mind that a Specialist doesn't just "store" a bunch of objects, it also provides *methods for dealing with sets of objects*. So an Invoices specialist could usefully contain a wide variety of reporting methods, for example. Similarly, the Customers specialist might have a method to post balances forward on all customer accounts whose statement cycle is in a certain date range. These are all "heavy lifting" from an accounting point of view, but perfectly valid to have in the white-box specialists. White-box doesn't mean that there's no implementation; it just means that the implementation is intended to be extensible or integratable by someone other than the framework's original developer.
Now, if I had a third-party accounts package (something by Sage perhaps), I could make the AccountingProcessor specialist expose various functions to the four other White-box specialists. It would implement these by making equivalent calls on the underlying accounting package.
I could also swap the heavy-lifting portion of my framework by swapping the black-box AccountingProcessor specialist for one that talks to some
software by Quicken, or perhaps some software that is written in Python as a conventional Zope product.
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. 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.
The same goes for the Resource Scheduling framework. We have some White-box specialists, ripe for customisation:
Resources Reservations ResourceUsers
And then for the heavy-lifting we have the black-box ResourceScheduler specialist. Again, this might be a Zope Python Product, or it might be an interface to some application written on top of Microsoft Exchange.
Again, look to what these specialist would do besides look up objects. For example, utilization or load-balancing reports. Generating bills for usage. Generating calendars for individual resources. Checking for conflicts. Etc.
Are specialists intended to be placed inside other specialists, as "contents"?
You *can* do this, but I've not yet encountered a real-life situation where I *would* do this. (Mike has given some examples that suggest it might be useful under some circumstances, however.)
So in this case, would the white-box specialists live inside the black-box specialist -- so they become the customisable aspects of the overall framework? Or would both black-box and white-box specialists live inside an uber-specialist?
If anything, the black box should be inside the white. Otherwise, you are creating confusion between heaven and earth. :) Seriously, the white boxes are the parts you will reference in URL's most often, so why have /AccountingProcessor/Invoices/ when you can just have /Invoices/? If you have to share a black box among white boxes, acquire it. If your "root" gets too messy, then make an "Accounting" folder and put Invoices, AccountingProcessor, and the rest inside of it.