[Zope-dev] ZPatterns: DropZone example

[Phillip J. Eby]

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.