> A Specialist manages objects that play a particular role in your application.
> You will usually have one Specialist for each role in your application; try
> listing all the roles, and what they do, and that's a good start for thinking
> about what specialists you need.
I'm a bit confused in regard to the roles.
What exactly is a role in this context?
At first I thought of a rola as "a role of an Actor", but
as you described it it's more like the role of the class
How should I look at roles in ZPatterns?
> A Rack manages the storage for a particular class of objects.
> Therefore, you will have different racks for different classes
> of object. You will also have different racks for different
> ways of storing the same class of object.
> For example, let's say I have a Specialist "GoPlayers", which manages
> objects that represent people who play the board-game Go with other people.
> I have two implementation classes: AmateurGoPlayer and ProfessionalGoPlayer.
> Objects of these classes have exactly the same interface to the rest of the
> However, the implementation of some of the methods varies.
> So, I'll need two racks in my GoPlayers specialist: one for
> AmateurGoPlayers and one for ProfessionalGoPlayers.
> Let's complicate things by saying that I have the records for some
> ProfessionalGoPlayers in a relational database, but the rest of the
> ProfessionalGoPlayers are stored in the ZODB. All the AmateurGoPlayers
> are stored in the ZODB.
> So, I need three Racks altogether:
> AmateurGoPlayers (stored in ZODB)
> ProGoPlayers_zodb (stored in ZODB)
> ProGoPlayers_rdbms (from legacy rdbms)
> I'm indexing all the players that are stored in the ZODB using a
> ZCatalog called Catalog, in the GoPlayers specialist.
> Now, when I want to answer a query such as "return all go players called
> 'bill'", I need to do the following:
> * create a PythonScript in GoPlayers called list_players_by_name(name)
> * implement this method as follows:
> - query the ZCatalog for players who have that name
> - query the RDBMS using an SQL query for players who have that name
> - return the union of the results of both queries
> In this scenario, I'd put the SkinScript to catalog AmateurGoPlayers in
> the AmateurGoPlayers rack, and likewise for the ProGoPlayers_zodb rack.
> I'm not indexing the players from the rdbms in a ZCatalog because, in
> this example, other systems external to Zope can independently update
> the RDBMS.
> If this wasn't the case, and the all changes to data in the RDBMS go
> through Zope, then I could put one set of cataloging skinscript as a
> data-plugin in the Specialist, and make the list_players_by_name(name)
> method just return the results from a ZCatalog search.
> The rest of my application uses the interface provided by the
> Specialist, and can remain ignorant of where a particular GoPlayer's
> records are stored.
> Note that the specialist provides exactly the methods that the rest of
> the application requires; ideally no more, and no fewer.
> Beware when returning results from a ZCatalog query that you are only
> returning Catalog Brains -- simple objects that record the meta-data
> archived when the original object was cataloged. Where speed of
> execution is not an issue, you should return a list of actual GoPlayer
> objects rather than a list of CatalogBrains.
> An alternative is to return a list of string ids.
> Often, a better plan is to determine exactly what information is needed
> by the part of your application that requires the
> list_players_by_name(name) method call; then provide exactly that
> Steve Alexander
> Software Engineer
> Cat-Box limited
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -