Re: [Zope] ZPatterns Question
I've moved your question to zope-dev, as that's where ZPatterns questions probably belong. Roche wrote:
I created a ZClass called "Product" with Dataskin as baseclass.
I also added a specialist called ProductManager containing a default rack. Under storage for the rack I selected the newly created Product ZClass.
My product ZClass needs to query both a RDBMS and the ZODB for attributevalues. At this point I get lost. I guess i should add an attributeprovider plug-in???
The easiest way is to use a couple of SheetProviders. Use a PersistentSheetProvider for your ZODB values. You'll have to write your own one for SQL values. You will need to create the appropriate propertysheets in your ZClass class definition in your product.
What should go into the fromexpr and attrsexprs properties of the attributeprovider? Should one add an attributeprovider for each attribute of the product?
See the IRC chat log: http://www.zope.org/Documentation/Chats/zpatt_chat_log An attribute provider can provide multiple attributes. You can have multiple attribute providers if you like. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
I've added a propertysheet called "properties" to my ZClass and i notice there is Persistent Sheetprovider under the default rack already. The Sheetprovider has properties Sheet_Names and Sheet_Namespaces. I guess Sheet_Names should refer to the sheetname i created for my ZClass??? but how do Sheet_Namespaces come into play.
From the IRC_Chatlog: "Call "getItem(key)" to retrieve an item from the Specialist, and "newItem(key)" to create a new item in the specialist."
Does this imply that I can simply call "newItem(key)" from a dtml-method inside the specialist to create a new instance of my object? I think I understand ZPattern architecture somewhat but get lost on the implementation side, particularly at that place where attributes are retrieved from storage or more clearly how a specialist(datamanager) links up/communicates with a sheetprovider (data-plugin) and how the sheetprovider in turn communicates with the rack and how the rack retrieves from storage (dataskin). A very simple outline like this would help me a lot, eg: Specialist to Sheetprovider (handled in IDE - add a SheetProvider under Plugins) Sheetprovider to rack (handled in IDE - select Storage Class under rack) Rack to Dataskin (????) Dataskin to physical storage (????) Roché PS: I would be more than willing to document my enlightenment in a howto
-----Original Message----- From: alexande@cat-box.net [mailto:alexande@cat-box.net]On Behalf Of Steve Alexander Sent: 07 August 2000 06:19 To: RC Compaan; zope-dev@zope.org Subject: Re: [Zope] ZPatterns Question
I've moved your question to zope-dev, as that's where ZPatterns questions probably belong.
Roche wrote:
I created a ZClass called "Product" with Dataskin as baseclass.
I also added a specialist called ProductManager containing a default rack. Under storage for the rack I selected the newly created Product ZClass.
My product ZClass needs to query both a RDBMS and the ZODB for attributevalues. At this point I get lost. I guess i should add an attributeprovider plug-in???
The easiest way is to use a couple of SheetProviders. Use a PersistentSheetProvider for your ZODB values. You'll have to write your own one for SQL values.
You will need to create the appropriate propertysheets in your ZClass class definition in your product.
What should go into the fromexpr and attrsexprs properties of the attributeprovider? Should one add an attributeprovider for each attribute of the product?
See the IRC chat log:
http://www.zope.org/Documentation/Chats/zpatt_chat_log An attribute provider can provide multiple attributes. You can have multiple attribute providers if you like. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
At 01:57 PM 8/8/00 +0200, RC Compaan wrote:
I've added a propertysheet called "properties" to my ZClass and i notice there is Persistent Sheetprovider under the default rack already. The Sheetprovider has properties Sheet_Names and Sheet_Namespaces. I guess Sheet_Names should refer to the sheetname i created for my ZClass??? but how do Sheet_Namespaces come into play.
Actually, neither relates. Property sheets created on ZClasses always have their data stored in attributes of the object itself, so if you want to control those property sheets you would not use a sheet provider at all. Sheet providers are only used to provide property sheets whose data is stored external to the object. The "name" refers to sheet names, yes, although again these are not ones created on the ZClass, which will be handled by the ZClass. The "namespaces" refers to the XML namespaces of the property sheets, which is a WebDAV thing. In the WebDAV protocol, "property sets" are added/changed using URLs as XML namespaces. So you could have a property sheet whose XML namespace is "http://www.zope.org/PTK/MemberProperties" and whose name is just "MemberProperties" or "MemberInfo" or something else altogether. ZPatterns supports WebDAV, and WebDAV requires the ability to add arbitrary property sets with arbitrary properties to an object. Also, the XML namespaces concept can be useful as a way of avoiding name collisions between frameworks.
From the IRC_Chatlog: "Call "getItem(key)" to retrieve an item from the Specialist, and "newItem(key)" to create a new item in the specialist."
Does this imply that I can simply call "newItem(key)" from a dtml-method inside the specialist to create a new instance of my object?
Yes.
I think I understand ZPattern architecture somewhat but get lost on the implementation side, particularly at that place where attributes are retrieved from storage or more clearly how a specialist(datamanager) links up/communicates with a sheetprovider (data-plugin) and how the sheetprovider in turn communicates with the rack and how the rack retrieves from storage (dataskin).
A very simple outline like this would help me a lot, eg: Specialist to Sheetprovider (handled in IDE - add a SheetProvider under Plugins) Sheetprovider to rack (handled in IDE - select Storage Class under rack) Rack to Dataskin (????) Dataskin to physical storage (????)
Roché
PS: I would be more than willing to document my enlightenment in a howto
The Specialist does not talk to the sheet provider. The Specialist asks its racks for an object. The Rack which "retrieves" the object tells the object that it belongs to the rack and should ask the rack for anything it needs. When the object needs a property sheet or attribute or whatever, it asks the rack to give it a list of relevant providers for that attribute/sheet/whatever. It then walks the list asking those providers if they can perform the function it desires. If none of the providers are successful, it performs a default behavior (such as raising an AttributeError to indicate the attribute does not exist). This general pattern is followed for almost anything that can be delegated from a skin to a provider. When DataSkins are used outside a rack, the process is similar, except that the DataSkin itself notices it is being retrieved from somewhere and has not been told it belongs to a rack, so it searches its acquisition path asking for a Customizer. Once found, it then uses the Customizer in the same way as it would have used the Rack (i.e. to ask for lists of providers that might be useful for performing tasks it needs done).
"Phillip J. Eby" wrote:
Actually, neither relates. Property sheets created on ZClasses always have their data stored in attributes of the object itself, so if you want to control those property sheets you would not use a sheet provider at all.
Sheet providers are only used to provide property sheets whose data is stored external to the object.
I'm confused here. Please excuse me if these questions seem silly. What does "Property sheets created on ZClasses" mean, exactly? If I use some DataSkin-derived ZClass instances inside a Customizer folder, and if I want to store the data in the ZODB, do the propertysheets for one of these ZClass instances come from PersistentAttributeProviders or PersistentSheetProviders? What is the difference between a Common Instance Propertysheet and a Dataskin Attribute Propertysheet when added to a Dataskin-derived ZClass? Is the following true, part true, false, or irrelevant? If I want to add a propertysheet that contains information from an SQL database query to a ZClass-dataskin instance, I have to : * Declare in my Product that the ZClass has that propertysheet (unless I do clever stuff with triggers to add the sheet if it isn't there already) * Use a custom SQL SheetProvider? Or an AttributeProvider? Or some skinscript that calls various methods in my specialist? Thanks. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
At 06:07 PM 8/8/00 +0100, Steve Alexander wrote:
"Phillip J. Eby" wrote:
Actually, neither relates. Property sheets created on ZClasses always have their data stored in attributes of the object itself, so if you want to control those property sheets you would not use a sheet provider at all.
Sheet providers are only used to provide property sheets whose data is stored external to the object.
I'm confused here. Please excuse me if these questions seem silly.
What does "Property sheets created on ZClasses" mean, exactly?
I mean, if you go into the management screens for a ZClass, and add a property sheet to the *class*, the sheet's definition is stored in the class, and its contents are stored as attributes on the instances. Sheet providers have no effect on such property sheets, as they are defined in the class. However, if you use a "DataSkin Property Sheet", the attributes of the sheet are stored in the instance in a way that is compatible with attribute providers. Thus, you can use attribute providers to provide the content of the sheet. But you cannot provide the sheet object itself. This may seem a subtle distinction, but it is an important one for some applications. Sheet providers are primarily intended to add sheets outside the scope of the class of object being used.
If I use some DataSkin-derived ZClass instances inside a Customizer folder, and if I want to store the data in the ZODB, do the propertysheets for one of these ZClass instances come from PersistentAttributeProviders or PersistentSheetProviders?
If you create the sheets *in* the ZClass itself, then the *data* for the sheets comes from an AttributeProvider (actually, it's just stored in the instance, but the storage is controlled by an AttributeProvider). The sheet *itself* would come from the class. If you create the sheet with object.propertysheets.manage_addPropertySheet(), then the sheet will be created and managed by a SheetProvider.
What is the difference between a Common Instance Propertysheet and a Dataskin Attribute Propertysheet when added to a Dataskin-derived ZClass?
The difference is that a Common Instance property sheet stores default values in the class under the original attribute name, which makes __getattr__ unusable on the instances. A DataSkin property sheet stores default values in the class under the name "class_default_for_X" where "X" is the attribute name. This lets the DataSkin instances give an AttributeProvider a chance to supply the value of an attribute before falling back to a class-level default.
Is the following true, part true, false, or irrelevant?
If I want to add a propertysheet that contains information from an SQL database query to a ZClass-dataskin instance, I have to :
* Declare in my Product that the ZClass has that propertysheet (unless I do clever stuff with triggers to add the sheet if it isn't there already)
* Use a custom SQL SheetProvider? Or an AttributeProvider? Or some skinscript that calls various methods in my specialist?
You can do any of the above. Currently, the easiest way to do it would probably be to add the sheet to the class, and then use attribute providers to supply the data. If you needed to add this atop a class which needed to be "final" (in the Java sense, i.e. no modifications allowed), then the best route would be a custom SQL sheet provider.
Thanks for your answers, Phillip. Here's what I've learned. I still need to try these out on a test system, to prove to myself that they work the way I think they do. 1: ZClass instances can have PropertySheets added to them, independently of any sheets declared in the ZClass class definition. I've been working with Zope for a while, but this had never occurred to me. I guess this is just another one of those hangovers from writing in Java for so long. 2: If, in a dataskin-derived ZClass class definition, I define a "common instance" propertysheet, values in that propertysheet for instances get stored in the ZODB just like any other ZClass instances' propertysheets. However, if I define a "dataskin" propertysheet for my ZClass, I can provide the content of these sheets to my ZClass instances using AttributeProviders. (Are the above two paragraphs correct? Or can I use AttributeProviders to supply data for common instance propertysheets also, but I can't use default values for such sheets?) However, because of the way Attributes work, I cannot supply data for a dataskin-propertysheet as a separate independent sheet object. The sheet comes from the ZClass, the data comes from an Attribute Provider. 3: If I want to use a SheetProvider, and thus use some of the important features of ZPatterns, I need to use object.propertysheets.manage_addPropertySheet() on each ZClass instance that should have a sheet from a SheetProvider. One way of doing this is with a Trigger. 4:
If you needed to add this atop a class which needed to be "final" (in the Java sense, i.e. no modifications allowed), then the best route would be a custom SQL sheet provider.
...because the SQL sheet provider can provide sheets to ZClass-dataskin instances, even though the original ZClass was not defined to have this propertysheet. But I'd also have to add sheets to each applicablt instance, as in learning point 3 above. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Hmm... this is probably more of a plain Zope question than a ZPatterns question.. but since I'm *using* ZPatterns, I thought I'd check what other folks are doing to implement apps with ZPatterns. I've been creating Specialists with DataSkin subclassed objects in their defaultRacks. The methods of the objects are pretty easy, I can put them in the ZClass, or the Product class that I'm sub-ZClassing from. But since my Specialists are just 'plain' objects I can only make methods of Specialists as 'DTML Methods' or 'Python Methods'. I'd love to call these methods as: <dtml-in "TableManager.getAllProductCategories(_.None, _)"> .... but this doesn't work. The current namespace doesn't include any of the queries or other methods that I need to *implement* getAllProductCategories.. so I end up doing: <dtml-with TableManager> <dtml-in "getAllProductCategories(_.None, _)"> ... but this seems obtuse when the TableManager needs to talk to the ProductManager or other managers I end up with a *lot* of <dtml-with... > statements! What are other folks doing? thanks, -steve
At 11:58 PM 8/9/00 +0100, Steve Alexander wrote:
1: ZClass instances can have PropertySheets added to them, independently of any sheets declared in the ZClass class definition.
I've been working with Zope for a while, but this had never occurred to me. I guess this is just another one of those hangovers from writing in Java for so long.
It's not a very well-known feature of Zope. AFAIK, it was implemented to support WebDAV, which requires the capability to add arbitrary propertysets to an object, which must NOT interfere with one another or the object's base properties.
2: If, in a dataskin-derived ZClass class definition, I define a "common instance" propertysheet, values in that propertysheet for instances get stored in the ZODB just like any other ZClass instances' propertysheets.
Not exactly. What happens is that __getattr__ never gets called for those attributes, so you can't have a provider give a value for them. __setattr__ and __delattr__ *do* get called, so if you modify those values on an instance, the providers will get called. However, since they never get called for attribute retrieval, you will never see the effects of the change. In short, "common instance" property sheets are *broken* with respect to DataSkins and should be avoided in favor of DataSkin propertysheets which are built so as not to have this problem.
However, if I define a "dataskin" propertysheet for my ZClass, I can provide the content of these sheets to my ZClass instances using AttributeProviders.
Yes.
However, because of the way Attributes work, I cannot supply data for a dataskin-propertysheet as a separate independent sheet object. The sheet comes from the ZClass, the data comes from an Attribute Provider.
Yep. To supply an independent sheet object, you need a sheet provider. And ZPatterns "out of the box" only includes a Persistent Sheet Provider, primarily to support WebDAV's requirement for adding arbitrary property sets.
3: If I want to use a SheetProvider, and thus use some of the important features of ZPatterns, I need to use object.propertysheets.manage_addPropertySheet() on each ZClass instance that should have a sheet from a SheetProvider. One way of doing this is with a Trigger.
Yes. Another way is that if you write your own SheetProvider, you can define its _objectAdding() and _objectDeleting() methods to automatically create the sheet. Or, if existence of the sheet is predicated upon something else, you can simply answer the getSheet/getSheets() method calls by checking to see if that sheet exists, and if so, returning it. This is useful when, for example, you need to provide an object with a propertysheet that presents and/or updates data from a legacy database or other external system.
4:
If you needed to add this atop a class which needed to be "final" (in the Java sense, i.e. no modifications allowed), then the best route would be a custom SQL sheet provider.
..because the SQL sheet provider can provide sheets to ZClass-dataskin instances, even though the original ZClass was not defined to have this propertysheet. But I'd also have to add sheets to each applicablt instance, as in learning point 3 above.
Right, unless you write your sheet provider to just provide the sheet anyway. Sheet providers get asked what sheets are available for an object, and can simply provide some whether they've been "added" or not. The "manage_addPropertySheet" step is optional if you're creating custom sheet providers which can either add the sheet automatically, or have the sheet just always exist.
Hi guys, I'm trying to make a simple guestbook using ZClasses and ZPatterns, I suppose this is somewhat overkill, and would be alot easier to do using SQL, but it's for the sake of knowledge (as is everything I do). So I read the IRC-log and <msegarra> asked a question regarding storing a ZClass in a Specialist/Rack, and I suppose that is what I should do too. Also note that I have not done anything with ZClasses or ZPatterns and take this as an oppotunity to learn booth ;). So I have done the following: I created a product and put 2 ZClasses in it, Guestbook and Guestbook_entry. Guestbook_entry was created with Dataskin as baseclass and holds a propertysheet called entry_data. Guestbook has 2 methods that handles the adding of entries, one is the form, the other is the actual dataadder (the forms action) and it's called entry_addProcessor. I then added a specialist to Guestbook, and told it to store Guestbook_entrys, it's called entry_storage. entry_addProcessor contains the following code: <dtml-let newobj="entry_storage.newItem(_.str(_.int(ts)))"> <dtml-comment> Code is supposed to go here... I just have to figure out how to add the data sent to newobj... </dtml-comment> </dtml-let> But when I try to run this I get "Unauthorized" for newItem, and I don't know what settings to set for anonymous to be able to use it, since I can't seem to get it to work even with my user that has created everything. Now, am I correct to put the properties in the ZClass, or should they go into a PersistentSheet or a PersitentSheetProvider plugin? And if I should put it into PersistenSheets should I change anything in the Sheet_Names and Sheet_Namespaces boxes or just att my properties? And what about the Unauthorized error, should I change something in the define permissions tab? Now, if I could get this little question answered in english (not ZPatternish), I would be very happy, and if you get me to grasp these things I think quite a few others will grasp it too, and you will get less requests for basic dokumentation, and everyone will be happy and live long and prosper forever after. /Peter Toneby, who really should go to bed now. -- Alpha Test Version: Too buggy to be released to the paying public. Beta Test Version: Still too buggy to be released. Release Version: Alternate pronunciation of "Beta Test Version".
participants (5)
-
Peter Toneby -
Phillip J. Eby -
RC Compaan -
Steve Alexander -
Steve Spicklemire