[Zope-dev] ZPatterns: DropZone example

[Phillip J. Eby]

At 02:21 AM 7/5/00 +0000, Scott Parish wrote:
>
>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.

You might look at some of the recent posts which included an example of
using GenericAttributeProviders to read from a MySQL database, and my reply
explaining how to use a GenericTrigger to update that same database.


>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.

Peter Coad's design approach (which ZPatterns is heavily based on/biased
towards) emphasizes four major layers of classes in an application:

1) User Interface (GUI, forms, etc.)
2) Problem Domain (the actual application purpose)
3) Data Management (object persistence/lifecycle management)
4) System Interaction (interfaces w/hardware or other software)

ZPatterns is focused on providing tools for transparent mappings between
layers 2 and 3, while DatabaseAPI, as far as I can see (and I actually did
play around with it today to get a feel for it), is focused on tools for
building clean mappings between layers 3 and 4.  In my mind, this makes
them complementary tools, rather than competitors in any real sense.

Indeed, looking at DatabaseAPI has shown me that there are some features
I'd planned for ZPatterns (or already started) that I can scrap because
DatabaseAPI has them and can easily interoperate.  (Personally, I'd like to
see a version of DatabaseAPI using PlugIns to structure its user interface,
which I think could easily make it even cleaner and easier to use than it
already is.  It might then also be possible to reuse some of its plug-ins
for functionality in areas of ZPatterns.  But I digress.)

So where do DatabaseAPI and ZPatterns overlap?  DatabaseConnector has some
functional overlap with Specialist.  If you ignore the attribute, sheet,
and trigger providing aspects of ZPatterns (and also look only at the raw
functionality), the primary difference between a Specialist and a
DatabaseConnector is that DatabaseConnectors will probably have methods to
delete objects or change their data, which is a no-no for a Specialist
because it's an encapsulation breach.

Beyond this, there's a significant difference in intent between a
Specialist and a DatabaseConnector (IMHO).  A Specialist serves as a broker
to access objects which fill a certain role in a framework, while a
DatabaseConnector represents an object which manipulates "records" which
are of "record types" and have "fields".  Specialists use Racks to
explicitly distinguish between problem-domain and data-domain concerns; you
can probably do this with nested DatabaseConnectors but you'll have to do
some additional work to support it.

ZPatterns could definitely benefit from some ideas found in DatabaseAPI,
primarily in the aspect of documenting API's and supporting better design
contracts.  For example, it would be nice for a Specialist to be able to
define the API expected from its Racks, and a for an application framework
to somehow define the API expected from the Specialists it will interact
with.  One could of course use the existing DatabaseAPI product to do these
things, but the integration would be less than smooth, since you'd have to
make the Specialist ask the Racks for their DatabaseConnectors, or else
have a Rack class that delegated to a DatabaseConnector, or something like
that.  Anyway, I'm going to have to give these possibilities some more
thought.