sorry, I can't reproduce the error I talked about yesterday. All the insights given by philip has lighted up my path :-) There are four points I want to discuss: *** Some thought about RackMountables: they should subclass Acquisition.Implicit for bobotraversing to work. indeed, the __bobo_traverse__ code says: return getattr(ob, 'aq_base', ob).__of__(self) ob has the __of__ attribute only if it subclass an extension class (Acquisition.Implicit is an easy choice) *** in AttributeProviders.py, around line 199, definition of _DelAttributeFor is bogus. Instead of: def _DelAttributeFor(self,client,name): return self.aq_parent.aq_parent._SetAttributeFor(client,name) it should read: def _DelAttributeFor(self,client,name): return self.aq_parent.aq_parent._DelAttributeFor(client,name) *** It is desirable for me to enumerate the objects stored in the racks for a specialist. Because the __readableStorage is not accessible from derived classes (magic of ExtensionClasses ???), I can't add that behavior without patching Rack.py I'm thinking of a method 'rsValues' that enumerate values in the readableStorage. In Rack.Rack: def rsValues(self): """rsValues like 'readableStorageValues' why on earth are there __readableStorage and __writableStorage ??? """ values = [] slots = self.__readableStorage.values() for slot in slots: # the following took from retrieveItem item = slot[SelfKey] item._setSlot(slot) item._clearPerTransactionCache() # associate the rack to the item item._setRack(getattr(self, 'aq_inner', self)) ## the above line could be written # item._setRack(self.aq_inner) ## if racks objects where always wrapped. values.append(item) return values Or is it best to create a catalog in the specialist that index all objects stored in the rack as they get added? The default ZODB storage should give the ability to enumerate the objects, even if it does not belong to the standard "interface" of the rack. *** I understand now that the RackMountable is only a placeholder class, and that attributes and sheets are managed by AttributeProviders and SheetProviders, right? any comments? jephte clain minf7@educ.univ-reunion.fr
At 09:46 PM 5/19/00 +0400, Jephte CLAIN wrote:
Some thought about RackMountables: they should subclass Acquisition.Implicit for bobotraversing to work. indeed, the __bobo_traverse__ code says:
return getattr(ob, 'aq_base', ob).__of__(self)
ob has the __of__ attribute only if it subclass an extension class (Acquisition.Implicit is an easy choice)
Good point, but ordinarily one mixes RackMountable with another Zope class such as SimpleItem.Item, or uses it as part of a ZClass. In either case, Acquisition gets added in. I prefer to keep the base class as free as possible of things that will be mixed in later to avoid repeated inheritance. Also, for what it's worth, future versions of RackMountable will define their own __of__ method, as it will be required to support placement of rackmountable-ish objects in places other than racks.
in AttributeProviders.py, around line 199, definition of _DelAttributeFor is bogus. Instead of:
Noted and fixed for next release.
It is desirable for me to enumerate the objects stored in the racks for a specialist. Because the __readableStorage is not accessible from derived classes (magic of ExtensionClasses ???), I can't add that behavior without patching Rack.py
I'm thinking of a method 'rsValues' that enumerate values in the readableStorage. In Rack.Rack:
def rsValues(self): """rsValues like 'readableStorageValues' why on earth are there __readableStorage and __writableStorage ??? """
__readableStorage and __writeableStorage are designed to prevent side-effect transactions occurring. It's a little bit tricky, but basically __readableStorage doesn't create a storage if it hasn't already been created - it instead returns an empty dictionary. __writeableStorage creates the storage if it doesn't exist. Thus, operations that only intend to read data from the storage don't cause a write transaction when the storage doesn't yet exist.
values = [] slots = self.__readableStorage.values() for slot in slots: # the following took from retrieveItem item = slot[SelfKey] item._setSlot(slot) item._clearPerTransactionCache() # associate the rack to the item item._setRack(getattr(self, 'aq_inner', self)) ## the above line could be written # item._setRack(self.aq_inner) ## if racks objects where always wrapped. values.append(item) return values
Or is it best to create a catalog in the specialist that index all objects stored in the rack as they get added?
Yes, that is the best route for the current version. Future versions will support an "Indexes" tab for plugins that manage search and retrieval. This tab will be on both Specialists and Racks, as well as on the new ZDataManager class that allows Providers and Indexes on objects stored in Folders or other "normal" ZODB locations.
The default ZODB storage should give the ability to enumerate the objects, even if it does not belong to the standard "interface" of the rack.
Something like that will be included, but it will be in the form of a plugin that goes on the Indexes tab, which the Rack can call. At that point, searching/enumerating *will* be part of the Rack interface.
I understand now that the RackMountable is only a placeholder class, and that attributes and sheets are managed by AttributeProviders and SheetProviders, right?
That is correct. RackMountables are like abstract classes that only have domain knowledge (application-level intentions) with no data storage implementation knowledge. In ZPatterns 0.4.0 and beyond, RackMountables will probably change their name to DynamicDataObjects, or DDO's for short. This is to reflect their new, wider scope, which does not require them to be mounted in a Rack to have their dynamic features. They will be able to have providers manage their data no matter where they are in a Zope application, so long as the DDO is in acquisition context of a ZDMFolder ("Folder w/Data Management Support") that has a ZDataManager plug-in registered for the DDO's meta_type. I'm not actually real fond of the DDO term, because "Dynamic Data Object" doesn't quite do justice to what these things actually are. I am definitely open to suggestions for a better name. (Facade? PlaceHolder? InsideOutObject? ExternalDataObject? BrainInjectedObject?) Also, while I'm babbling about versions, it's important to note at this point that ZPatterns versions below 1.0.0 should be considered subject to change even with respect to developer-level API's. They get more stable as the number gets higher, which is why LoginManager changed a lot less between 0.8.0 and 0.8.5 than half as much as ZPatterns changed between 0.2.0 and 0.3.0. The change to 0.4.0 will probably be another big jump, due to the DDO stuff as well as the Indexes stuff. Predicates may even make it in, in some small way.
Phillip J. Eby:
In ZPatterns 0.4.0 and beyond, RackMountables will probably change their name to DynamicDataObjects, or DDO's for short. This is to reflect their new, wider scope, which does not require them to be mounted in a Rack to have their dynamic features. They will be able to have providers manage their data no matter where they are in a Zope application, so long as the DDO is in acquisition context of a ZDMFolder ("Folder w/Data Management Support") that has a ZDataManager plug-in registered for the DDO's meta_type.
This sounds amazingly flexible.
I'm not actually real fond of the DDO term, because "Dynamic Data Object" doesn't quite do justice to what these things actually are. I am definitely open to suggestions for a better name. (Facade? PlaceHolder? InsideOutObject? ExternalDataObject? BrainInjectedObject?)
ZopeTupperware, AloofAttributeObjects, DataSkins :)
Also, while I'm babbling about versions, it's important to note at this point that ZPatterns versions below 1.0.0 should be considered subject to change even with respect to developer-level API's. They get more stable as the number gets higher, which is why LoginManager changed a lot less between 0.8.0 and 0.8.5 than half as much as ZPatterns changed between 0.2.0 and 0.3.0. The change to 0.4.0 will probably be another big jump, due to the DDO stuff as well as the Indexes stuff. Predicates may even make it in, in some small way.
This is one of the reasons I am just looking a tinkering. But this is definately is the future of instance data and data presentation in Zope. All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
At 05:28 PM 5/19/00 +0000, Jason Spisak wrote:
Phillip J. Eby:
I'm not actually real fond of the DDO term, because "Dynamic Data Object" doesn't quite do justice to what these things actually are. I am definitely open to suggestions for a better name. (Facade? PlaceHolder? InsideOutObject? ExternalDataObject? BrainInjectedObject?)
ZopeTupperware, AloofAttributeObjects, DataSkins :)
I think I'm going to go with DataSkins. Thanks for the suggestion. :) Now I need a name for another interesting ZPatterns 0.4.0 object... I was working on "indexing" plugins for DataManagers (Racks, Specialists, and DataInjectors) and at one point I realized that you could use them for things besides indexing. The basic idea is that an "indexing" plugin receives objectAdded(), objectChanging(), objectChanged(), and objectDeleted() messages from its DataManager. The idea was that it would then be able to update an index (such as a ZCatalog) accordingly. But during one of the PTK discussions about member registration, it occurred to me that a "registration index" could note the addition of a user, and then e-mail them or do other operations specific to that portal's business rules. That seemed like an interesting hack of indexes, but then after a while I realized that these plugins could enforce any other business rules related to changes of objects or their addition/deletion. They could, for example, be reverse indexes that, whenever a new information item was added, they looked up saved search preferences to find who was looking for the new item. They could notify a manager about an expenditure greater than a certain amount. They could roll back transactions if certain conditions weren't met. And it all could be done outside the object itself, in the sense that these things would be extensions to the object's class, based on its location in the Zope filesystem. So anyway, "index" now seems rather inadequate to describe these indexing, search-agenting, business-ruling objects. (Change Monitors? Knowbots? Indexing Agents? Index Rules? Object Matchers?) If you have any name suggestions, I'd love to hear 'em. :) I think it would be good if the name implied both major capabilities, although I think I might just end up having two seperate tabs ("Indexes" and "Rules") just to make the capabilities clearer. It's just that DataManager derivatives already have so darn many tabs (Methods, Attribute Providers, Sheet Providers, etc.).
----- Original Message ----- From: "Phillip J. Eby" <pje@telecommunity.com> To: "Jason Spisak" <444@hiretechs.com> Cc: <zope-dev@zope.org> Sent: Sunday, May 21, 2000 11:14 AM Subject: Re: [Zope-dev] ZPatterns framework improvements
The basic idea is that an "indexing" plugin receives objectAdded(), objectChanging(), objectChanged(), and objectDeleted() messages from its DataManager. The idea was that it would then be able to update an index (such as a ZCatalog) accordingly. But during one of the PTK discussions about member registration, it occurred to me that a "registration index" could note the addition of a user, and then e-mail them or do other operations specific to that portal's business rules. [other great examples of this capability snipped]
You could call these "ChangeBrains". It's got a bit of alliteration to it :) After reading Steve Alexander's message this morning, I started thinking about how the Portal capabilities could be refactored into one or more Specialists. This feature is also a very neat way for people to set up their review policies for the Portal. I'll send a message with more detail about my thoughts on a Portal Specialist over on the zope-ptk list. I just wanted to chime in and say that I agree that ChangeBrains (or whatever) are a Really Useful Thing. Kevin
"Phillip J. Eby" wrote:
So anyway, "index" now seems rather inadequate to describe these indexing, search-agenting, business-ruling objects. (Change Monitors? Knowbots? Indexing Agents? Index Rules? Object Matchers?) If you have any name suggestions, I'd love to hear 'em. :)
- PushMePullYu ;-) - MetaManager - Trigger (TriggerManager) - IndexManager - RuleManager HTH, Michael Bernstein
Phillip J. Eby:
I'm not actually real fond of the DDO term, because "Dynamic Data Object" doesn't quite do justice to what these things actually are. I am definitely open to suggestions for a better name. (Facade? PlaceHolder? InsideOutObject? ExternalDataObject? BrainInjectedObject?)
ZopeTupperware, AloofAttributeObjects, DataSkins :)
I think I'm going to go with DataSkins. Thanks for the suggestion. :)
Hey, I did something for you for a change. ;)
Now I need a name for another interesting ZPatterns 0.4.0 object...
I was working on "indexing" plugins for DataManagers (Racks, Specialists, and DataInjectors) and at one point I realized that you could use them for things besides indexing.
Oh no, the extendability bug has bit him on the ...
The basic idea is that an "indexing" plugin receives objectAdded(), objectChanging(), objectChanged(), and objectDeleted() messages from its DataManager. The idea was that it would then be able to update an index (such as a ZCatalog) accordingly. But during one of the PTK discussions about member registration, it occurred to me that a "registration index" could note the addition of a user, and then e-mail them or do other operations specific to that portal's business rules. That seemed like an interesting hack of indexes, but then after a while I realized that these plugins could enforce any other business rules related to changes of objects or their addition/deletion. They could, for example, be reverse indexes that, whenever a new information item was added, they looked up saved search preferences to find who was looking for the new item. They could notify a manager about an expenditure greater than a certain amount. They could roll back transactions if certain conditions weren't met. And it all could be done outside the object itself, in the sense that these things would be extensions to the object's class, based on its location in the Zope filesystem.
So anyway, "index" now seems rather inadequate to describe these indexing, search-agenting, business-ruling objects. (Change Monitors? Knowbots? Indexing Agents? Index Rules? Object Matchers?) If you have any name suggestions, I'd love to hear 'em. :) I think it would be good if the name implied both major capabilities, although I think I might just end up having two seperate tabs ("Indexes" and "Rules") just to make the capabilities clearer. It's just that DataManager derivatives already have so darn many tabs (Methods, Attribute Providers, Sheet Providers, etc.).
Hmmm. Behaviorators, DoAsISayDammit, DispatchAgents, ConventionBots, Facilitators Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (5)
-
Jason Spisak -
Jephte CLAIN -
Kevin Dangoor -
Michael Bernstein -
Phillip J. Eby