[Zope-dev] ZPatterns design question

[Phillip J. Eby]

At 11:09 PM 7/30/00 +0100, Steve Alexander wrote:
>Let's say I have an AddressBook specialist.

Why?  :)

Seriously, what is the function of "address book" in your application?  Is
it to find people in general?  Or...?


>Let's say I want to combine my AddressBook with a Suppliers specialist.
>The Suppliers specialist knows about DataSkin-ZClasses called Supplier.
>A Supplier has its own propertysheet "supplies" that has information
>about the kind of goods and services supplied. A Supplier also has an
>address.
>
>Suppliers appear in the AddressBook. When I get a Supplier from the
>Suppliers specialist, I want it to have two propertysheets: supplies and
>address.

I'm having a lot of trouble understanding your application.  Can you tell
me what you're trying to do in the problem domain?  ZPatterns design is
strongly rooted in the problem domain, not the programming side.  The
answer on the programming side is usually, "do whatever supports the
problem domain."  :)


>----
>Bunch of questions:
>
>Is this the ZPatterns ideomatic way to do this?

Dunno.  Explain the problem you're trying to solve, and I'll tell you the
simplest way I know to do it.


>Can I use SkinScript to get propertysheets from another specialist?

No.  I don't have SkinScript sheet providers yet.  I'm not sure exactly how
to make them just yet, because I haven't run into a spot where I've needed
them.  I hate trying to write something when I don't have a good feel for
what's needed yet...  :(


>Is the SheetProvider that gets the address for the Supplier objects also

>responsible for adding and deleting Address objects?

Eh?  A sheet provider is responsible for sheets.  If you want to have the
"same" sheetprovider being used for both objects' address sheet, that
should work just fine.  And it would be reasonable to have that sheet
provider also act as a catalog trigger, if you want it to be an invariant
that all address sheets are stored in the catalog.


>Do I need an Address object for each Supplier object?

No, just a propertysheet.


>What kind of propertysheet should I be using?

Depends on what your application needs.  I can see circumstances where the
best place for that sheet could be LDAP, SQL, or the ZODB.  Your app's
needs decide.  (That's the nice bit about ZPatterns, too...  you can always
change your mind later, as long as you don't build in your assumptions.)


>Should the method in the AddressBook specialist be returning an Address
>object, or just an address propertysheet?

Depends on what you want to do with it.  Generally speaking, though, I have
a hard time seeing what your addressbook specialist is FOR, unless it's
just to provide a combination of general search location for anything that
has an address plus a PIM-style addressbook.  In which case, I think your
confusion comes from terminology.  I would expect to store "Contacts" or
"Entries" in an addressbook, and these would have address sheets, as would
"Suppliers" or whatever else.  So the thing in an addressbook isn't a sheet
by itself, but it's kind of confusing to be mixing address objects and
address sheets.

Anyway, to answer your question - I think that your getItem() for an
address specialist wants to return some object with an address sheet.  But
not an address object.  Contact, Entry, Supplier, TennisBuddy...  whatever
the heck kind of object it is.


>Or, more generally: Adding sheets to a "party" seems to be one of the
>important ZPatterns ideas. What is the best way of implementing it,
>using the simple case of two specialists as an example?

Let's assume that the specialists are at different abstraction levels, e.g.
"Addresses" and "Suppliers", where other things exist that have addresses,
like "Customers".  Customers and suppliers both have an "address" property
sheet, which you want to be searchable, printable, etc. from your
"Addresses" specialist.  There are at least a few ways to do this:

1) Store all addresses in the same database, and implement a sheet provider
which you place in all the specialists.  Then create a Rack which returns
generic "addressbook entry" objects from this database.  (Downside: unless
you store URL's in the database, there's no easy way to jump back to the
"real" object from which the address entry derives.)

2) Store them in different places, but have all the sheet providers update
a catalog in the addresses specialist (which takes care of the URL problem)

3) Combine 1 and 2 - use the same database for storage but use a catalog
also anyway

Which you select depends on your application and the things you're
integrating.