[Zope-dev] Externalize or Adapt? (ZPatterns)

[Mike]

Great! Excellent!
Thank you Phillip for a good explanation.
I guess you should write something like this for the ZPatterns Wiki.

One more thing we still need is a set of 'right hand' rules.
Let me try to formalize ZPatterns-based design process.

1. Write scenario (client comes to skydiving office blah blah blah...)
2. Detect roles learning scenario (Orders, Planes, Students etc)
3. Create an empty (blackbox) Specialist for each role
4. Populate the specialists with methods implementing roles
5. Create (whitebox) specialists implementing scenario

Thus, the object classes (Customer, Order) went nowhere. The things
ruled by black specialists are just identity markers, without methods,
types and names.

That's right?

Or is the object an specialist specific internal abstraction which never 
leaves specialist's frames and have methods and type just for
specialist's fun?


"Phillip J. Eby" wrote:
> First, I'm going to create some ZClasses, and specialists to go with them:
> SkyDiver, Pilot, Airplane, FlightManifest, RentalTicket, RentalItem
> (w/subclass for Parachute, Helmet, and certain other specific items).  Then
> I'm going to set up the Resources and Products specialists to access my own
> specialists for these ZClasses.  (Notice that I am going in and directly

How you will set up those specialists? By adding 
get(Resources|Products)Specialist methods?

> that a Party plays in a resource scheduling system.  SkyDiver, then should
> implement a Party interface, allowing it to be *used as* a Customer or
> ResourceUser.  Thus, SkyDiver can be used by *any* framework that needs to
> collaborate with a Party object, although it may have a new *role* in which
> the party will be used.  For example, if I later add a curriculum
> management system to cover my skydiver training courses, I will want
> SkyDiver to fill the Student role.

Well, we have two specialists, implementing roles (again, who _actually_ 
implements the role, specialist or class, CustomerSpecialist or
Customer?). 

Now, "SkyDiver ... *used as*" means we should:

 1. subclass (not a good choice)
 2. implement interface
    2.1. by copying and pasting methods code (or whole methoids)
    2.2. by proxiyng (SkyDiver has a references to actual Customer 
         and ResourceUser)
    2.3. by transmitting messages to SkyDiverSpecialist which will pass 
         unhandled messages to CustomerSpecialist and
         ResourceUserSpecialist (this is a variant of 2.2. case)

The 2.3. case means we should use objects without types (identity
markers).

> I will also make some changes to each of these specialists to replace
> certain common UI snippets to be relevant to the kinds of things I'm
> dealing with.  For example, in the Customers and ResourceUsers Specialists,
> I will replace the findForm method (if that's what it's called) to be a
> call to SkyDivers.findForm - a form that searches for skydivers by their
> ratings, certification, or freefall style, as well as name or phone number.

How about Editor and Renderer plug-ins for each specialist?

> lifting" machinery and plug it into their local specialists, then gut the
> collaborator specialist and wire it to the appropriate local specialist.

If I understand something at all, whitebox specialist (Script?) called
SkyDiverSpecialist must have its own data source (rack) for SkyDiver
class and use 2.2. strategy mentioned above. (I just see no other way).


Thanks again,
Mike