At 05:26 PM 6/28/00 +0100, Steve Alexander wrote:
>The suggested specialists in the Accounting framework are:
>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
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
>The same goes for the Resource Scheduling framework. We have some
>White-box specialists, ripe for customisation:
>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
>Are specialists intended to be placed inside other specialists, as
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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -