Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-05 Thread Johan Carlsson

 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.

Hi Steve,
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
(GoPlayers)?

How should I look at roles in ZPatterns?

Regards,
Johan Carlsson


 
 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 
application.
 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 
 information.
 
 --
 Steve Alexander
 Software Engineer
 Cat-Box limited
 http://www.cat-box.net
 
 
 
 
 
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )
 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-05 Thread Steve Alexander

Johan Carlsson wrote:

 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
 (GoPlayers)?

I need to be really really pedantic and picky about terminology here, or else
I think we'll get terribly lost!  :-)

"GoPlayers" is the name of a Specialist.

There is a class called "GoPlayer". The class defines what properties/attributes
a GoPlayer object may have, and what services it provides to the rest of the 
application. The class plays the role "definition of object metadata".
The class defines one or more roles that GoPlayer objects play.

Each instance of the class GoPlayer is an object. We can call such an object
"a GoPlayer". However, GoPlayer is an abstract class; it really only defines
the essential features that make up the most generic GoPlayer.

However, any object that derives part of its behaviour and interface from
the class GoPlayer can be treated like a GoPlayer by the rest of the 
application. So, a ProfessionalGoPlayer is treated like a GoPlayer. An
AmateurGoPlayer is treated like a GoPlayer, also.
I can imagine a class that derives from BankManager and also from
AmateurGoPlayer, called GoPlayingBankManager. An object of that class
plays the role of GoPlayer (under certain circumstances), and can be
treated as a GoPlayer by the rest of the application.

When you're thinking about a system, it is often helpful to think about
just a part of the system rather than the system as a whole. To do this, 
you define a limited "scope" around a particular subsystem.
In this case, an Actor represents the role something from outside your
subsystem plays when interacting with something inside your subsystem.

The "something" can be an object, a person, a separate computer system,
a corporation...


 How should I look at roles in ZPatterns?

This is all standard object-oriented stuff, and is not specific to ZPatterns.
Get the Coad book, read it, and things should get clearer :-)

Also, the Catalysis method puts an emphasis on defining interactions and 
collaborations between objects in terms of roles. You might want to take
a look at that.

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-05 Thread Steve Alexander

Johan Carlsson wrote:


 Also, the Catalysis method puts an emphasis on defining interactions and 
 collaborations between objects in terms of roles. You might want to take
 a look at that.
 
 Is Catalysis method a pattern in Coads book?

No. Catalysis is an object oriented analysis and design method. It is
separate from the Coad book.

Tnere is some information on http://www.catalysis.org, but it doesn't seem
to clearly lay out the concepts.

I'd recommend reading some of the Catalysis book by 
Desmond D'Souza and Alan Wills: "Objects, Components, and Frameworks 
With Uml : The Catalysis Approach"

   http://www.amazon.com/exec/obidos/ASIN/0201310120

It is a large book.

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-05 Thread John D. Heintz

Wow, it's fun to hear people talking about Catalysis!

Catalysis is an analysis and design methodology that focuses on 
components and frameworks.  It stresses being able to specify component 
interactions with invariants, pre/post conditions, and supporting graphics.

The book, "Objects, Components, and Frameworks with UML" by Desmond 
D'Souza and Alan Wills is no light read, but well worth it.  Composing 
multiple frameworks together with package substitutions is really cool. ;-)

We are actually combining the analysis precision from Catalysis with the 
code focus from XP and having really good success.

John "who worked for Desmond in past life" Heintz



Johan Carlsson wrote:

 ...
 When you're thinking about a system, it is often helpful to think about
 just a part of the system rather than the system as a whole. To do this, 
 you define a limited "scope" around a particular subsystem.
 In this case, an Actor represents the role something from outside your
 subsystem plays when interacting with something inside your subsystem.
 
 The "something" can be an object, a person, a separate computer system,
 a corporation...
 
 
 
 Thanks Steve,
 You cleared up my confusion.
  
 
 How should I look at roles in ZPatterns?
 
 This is all standard object-oriented stuff, and is not specific to ZPatterns.
 Get the Coad book, read it, and things should get clearer :-)
 
 
 It's on my ToReadList :-)
  
 
 
 Also, the Catalysis method puts an emphasis on defining interactions and 
 collaborations between objects in terms of roles. You might want to take
 a look at that.
 
 
 Is Catalysis method a pattern in Coads book?
 
 Regards,
 Johan Carlsson
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-04 Thread Steve Alexander

Michael Bernstein wrote:


 Thanks, Steve. That was very helpful. To summarize your
 explanation, if I understood correctly:
 
 This is strictly an implementation issue. 

You could say that. I would agree some of the time :-)

 If the SkinScript
 has functionality that should be shared by more than one
 Rack, it should go in the Specialist, 

Not quite. If the SkinScript has functionality that is shared by
all the Specialist's Racks, then it should go in the Specialist.

Another way of looking at this is that application logic lives
in the Specialist, and storage logic lives in the Rack. 

 otherwise keep it with
 the Rack that it's specific to. Or, looked at another way,
 common functionality should be factored out and acquired.

Although you can do that, it is not always the best thing to do.
Sometimes, a bit of redundancy helps ease a system through the 
pains of evolution :-)

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-04 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
  If the SkinScript
  has functionality that should be shared by more than one
  Rack, it should go in the Specialist,
 
 Not quite. If the SkinScript has functionality that is shared by
 all the Specialist's Racks, then it should go in the Specialist.

If the functionality is shared among *most* of the Racks,
can't you override the SkinScript in the exceptions?

 Although you can do that, it is not always the best thing to do.
 Sometimes, a bit of redundancy helps ease a system through the 
 pains of evolution :-)

On that subject, does anyone know why SkinScripts don't
support cut-n-paste or copy-n-paste?

Thanks,

Michael Bernstein.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-04 Thread Phillip J. Eby

At 08:38 AM 2/4/01 -0800, Michael Bernstein wrote:

On that subject, does anyone know why SkinScripts don't
support cut-n-paste or copy-n-paste?


'cause I never thought of implementing it, probably because I've never yet
needed to move a SkinScript.  Patches cheerfully accepted.  :)


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-04 Thread Steve Alexander

Phillip J. Eby wrote:

 At 08:38 AM 2/4/01 -0800, Michael Bernstein wrote:
 
 On that subject, does anyone know why SkinScripts don't
 support cut-n-paste or copy-n-paste? 
 
 'cause I never thought of implementing it, probably because I've never yet
 needed to move a SkinScript.  Patches cheerfully accepted.  :)

I've just patched ZPatterns so that SkinScript methods have a History 
tab. I guess I could work on cut and paste too :-)

I'll send a patch when I'm done and tested.

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-04 Thread Steve Alexander

Phillip J. Eby wrote:

 At 08:38 AM 2/4/01 -0800, Michael Bernstein wrote:
 
 On that subject, does anyone know why SkinScripts don't
 support cut-n-paste or copy-n-paste?
  
 'cause I never thought of implementing it, probably because I've never yet
 needed to move a SkinScript.  Patches cheerfully accepted.  :)

It turns out that copying and cutting is broken for PlugInContainers in
Zope 2.3. This is because of the changes in HTMLFile. HTMLFile needs to be
changed to DTMLFile in various places, with the appropriate imports.

SkinScript methods always could be cut/copied/pasted in Zope 2.2. They
just can't with 2.3 because of these changes.

I'll post a patch shortly.

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-03 Thread Steve Alexander

Michael Bernstein wrote:

 
 'BookProduct' product
  *'BookClass' ZClass (inherits from
   _ZClass_for_CatalogAware, _ZClass_for_DataSkin)

Don't derive from CatalogAware when you're also deriving from DataSkin.

Rather than use the CatalogAwareness mechanism to
manually call reindex() when your object changes, you
should use some SkinScript in your Specialist or in your
Customizer to catalog, uncatalog and recatalog on changes.

WHEN OBJECT ADDED CALL
Catalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/'))
WHEN OBJECT DELETED CALL 
Catalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/'))
WHEN OBJECT CHANGED CALL 
Catalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/')),
Catalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/'))


 I'm also not sure it's
 a good or bad idea to place the ZCatalog directly into the
 Specialist.

That's a good idea. The catalog is what the specialist uses to
answer questions from other parts of your application such as
"what instances have baz for the foo property".
So, it should live inside the Specialist, and you should
provide a set of methods in the Specialist that answer
the questions the rest of you application need answered.

 Also, I would like to replace the three indexes I'm
 maintaining on the books with a single text index on a
 computed attribute. I understand that this involves adding a
 SkinScript to the Rack containing something like 'WITH SELF
 COMPUTE AllText=AllTextMethod', but I'm unsure of the
 details. I have a method (AllTextMethod) on the ZClass that
 returns several fields concatenated as a single string,
 which I would like to use as a text index.

You don't need a method for this; do it all with SkinScript like this:

WITH SELF COMPUTE
  all_text='%s %s %s' % (title, headline, content)


--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-03 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
  'BookProduct' product
   *'BookClass' ZClass (inherits from
_ZClass_for_CatalogAware, _ZClass_for_DataSkin)

 Don't derive from CatalogAware when you're also deriving from DataSkin.

Ok.

 Rather than use the CatalogAwareness mechanism to
 manually call reindex() when your object changes, you
 should use some SkinScript in your Specialist or in your
 Customizer to catalog, uncatalog and recatalog on changes.
 
 WHEN OBJECT ADDED CALL
 Catalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/'))
 WHEN OBJECT DELETED CALL 
Catalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/'))
 WHEN OBJECT CHANGED CALL 
Catalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/')),
 Catalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/'))

Thanks, Steve. I'll try this a little later today. What are
your thoughts on placing this in the Specialist's 'Plug-ins'
tab vs. the Rack's?

 [snip]
  Also, I would like to replace the three indexes I'm
  maintaining on the books with a single text index on a
  computed attribute. I understand that this involves adding a
  SkinScript to the Rack containing something like 'WITH SELF
  COMPUTE AllText=AllTextMethod', but I'm unsure of the
  details. I have a method (AllTextMethod) on the ZClass that
  returns several fields concatenated as a single string,
  which I would like to use as a text index.
 
 You don't need a method for this; do it all with SkinScript like this:
 
 WITH SELF COMPUTE
   all_text='%s %s %s' % (title, headline, content)

Thanks again, Steve.

Cheers,

Michael Bernstein.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-03 Thread Steve Alexander

Michael Bernstein wrote:


 Thanks, Steve. I'll try this a little later today. What are
 your thoughts on placing this in the Specialist's 'Plug-ins'
 tab vs. the Rack's?

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.

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

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net







___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-03 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
 
  Thanks, Steve. I'll try this a little later today. What are
  your thoughts on placing this in the Specialist's 'Plug-ins'
  tab vs. the Rack's?

[snip excellent explanation]

Thanks, Steve. That was very helpful. To summarize your
explanation, if I understood correctly:

This is strictly an implementation issue. If the SkinScript
has functionality that should be shared by more than one
Rack, it should go in the Specialist, otherwise keep it with
the Rack that it's specific to. Or, looked at another way,
common functionality should be factored out and acquired.

All in all, a very 'Zopish' principle.

Cheers,

Michael Bernstein.

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )