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.