Hi all, I've started implementation of a simple ZPatterns based application, and so far things have been going well. The problem is, I'm not sure if I'm doing this right. Here is my setup: Zope 2.2.0 hosted at Codeit.com on a Linux box ZPatterns 0.4.3b2 'BookProduct' product *'BookClass' ZClass (inherits from _ZClass_for_CatalogAware, _ZClass_for_DataSkin) * Methods: editInstanceForm, editInstance, index_html, AllTextMethod 'Books' Specialist * defaultRack which stores 'Book' ZClasses * Methods: addBookForm, addBook, index_html, BookSearch, BookResults (the last two methods are a Z Search Interface) *'Catalog' ZCatalog The 'BookClass' editInstance method contains: [snip] <dtml-call "propertysheets.Standard.manage_changeProperties(REQUEST)"> <dtml-call reindex_object> [snip] The 'Books' Specialist's addBook method contains: [snip] <dtml-let ni="newItem(isbn)"> <dtml-call "ni.propertysheets.Standard.manage_changeProperties(Authors=Authors, Title=Title, Price=Price)"> <dtml-call "ni.index_object()"> </dtml-let> [snip] I've snipped out only the most relevant parts of these methods. As I said, so far this has worked ok. But it seems to me that either the reindex_object or the index_object is in the wrong place, but I'm not sure which. I'm also not sure it's a good or bad idea to place the ZCatalog directly into the Specialist. 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. So, I decided to ask for a critique of the application design (such as it is). I also seem to recall mention of 'indexing agents' that might make this a bit more elegant, but haven't found a how-to on the subject. Thanks, Michael Bernstein.
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
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.
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
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.
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
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.
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. :)
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 - Zope-Dev@zope.org 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 )
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
... 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
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
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 - Zope-Dev@zope.org 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 | jheintz@isogen.com w w w . d a t a c h a n n e l . c o m
participants (5)
-
Johan Carlsson -
John D. Heintz -
Michael Bernstein -
Phillip J. Eby -
Steve Alexander