Any id with 'REQUEST' in it cannot be edited or viewed. If you don't believe me, try it out yourself. In my case, I *need* a URL named 'BIG_REQUESTS.html' -- it's a Zope-based mirror of content from somewhere else. This fixes it: /lib/python/ZPublisher/BaseRequest.py: 243c243 < if find(path, '/REQUEST/') >= 0: ---

if find(path, 'REQUEST') >= 0:

I'm not sure if I did quite the right thing here... are delimiters always slash? should we also check if the URL terminates in "/REQUEST"? What about cgi parameters named 'REQUEST'? Zope gurus, your comments please? -- Neil Kandalgaonkar <NeilK@ActiveState.com> Web Application Developer, ActiveState

I'm not sure I understand your question. If you don't have something special you want to do by subclassing Rack, then the answer would be "no". :)

You do answer my question below. I was wondering if this line would not cause an object to be stored in the ZODB by default.

The comment is perhaps misleading. What it means is that the _setSlot call isn't needed if your Rack implements a non-ZODB storage mechanism. The reason *why* it isn't needed, is that the DataSkin will ask for a slot on demand, so that a ZODB record is only created if something needs to be stored persistently. However, in the case where you have not set a "load" attribute (i.e., you are storing actual objects in the ZODB), then one might as well tell the object its slot, because the slot is where the object itself is going to be stored. Technically, the _setSlot call isn't necessary even then, because the DataSkin could still ask for it on demand. However, since the code at this point has gone to the trouble of getting the slot object, it might as well pass it to the DataSkin immediately.

Here I loose you. What does "setting the load attribute" mean? I did manage to store objects in a SQL RDBMS through some skinscript methods that call sql methods. I assumed selecting a ZClass on the storage tab simply informs the ZClass what it's rack is. I couldn't verify if these objects were stored in the ZODB as well as in my RDBMS. Besides writing some skinscript and sql methods is there anything else one should do to only use non-ZODB storage. When will I use attribute and sheetproviders and do they come into play at all with non-ZODB storage. Roché

It's determined by the radio button setting on the Storage tab. If you neglected to set it to "loaded by accessing attribute ____" and fill in the blank, then your objects have been stored in the ZODB, as well as in the RDBMS.

Thanks. I set "loaded by accessing attribute" to the attribute "id". Storing items in the RDBMS works fine. But when I try to retrieve them with getPersistentItemIDs() nothing is returned? I have a skinsript method getCustomer: WITH getCustomerSQL(CUSTOMER_ID=self.id) COMPUTE id=CUSTOMER_ID, name=NAME and getCustomerSQL is a SQL method. Roché

At 10:45 AM 11/9/00 +0100, Rik Hoekstra wrote:

[rh]I've been following this thread. This may be a bit of a newbie question, but it's been bugging me for a while. I see how I can store propertysheets in Racks using ZClasses and Skinscripts, but the propertysheet term suggests that there should always be an object that the properties are attached to.

Depends on what you mean by "attached". One of the most annoying things about Zope propertysheets is that there are two kinds. ZPatterns implements one of the kinds (WebDAV sheets), but not the one that most people have encountered (the kind used in ZClasses). Although WebDAV sheets are associated with a particular object, they are objects in themselves. ZClass instance sheets are "virtual" and store all their data in the associated object. To do ZClass-style sheets in ZPatterns, all you need to do is implement the attributes; the sheets can take care of themselves. To do WebDAV-style sheets in ZPatterns, you need a SheetProvider or you need to simulate propertysheets using an attribute provider to make an attribute that is actually another object, and which supports appropriate methods.

Is that an actual ZODB object or is it the Specialist object that can 'create' virtual objects on the fly?

Racks create "virtual" objects when set to "load by accessing attribute ___".

[rh] If I read this right, this suggests that an object stored in a SQL database and 'masquerades' as a Zope object? Or does an object always have to exist in the ZODB (with it's own id that corresponds to the id in the RDB or knows how to retrieve it). In other words, does the ZPatterns framework need an 'anchor' in the ZODB to connect it's properties to, or can you create pure virtual objects, that retrieve all of their properties from a specialist, including the ID.

When set to store objects persistently, "real" Zope objects are made and stored in the rack. When set to load via an attribute, the rack creates a dummy Zope object with its "id" attribute set appropriately, then tries to access the specified attribute. If the attribute exists (i.e., an attribute provider succeeds in loading the data from the external data source), then the object is considered to "exist" and can be returned. This would be a "pure virtual object" in your question.

If the last is the case, could someone give an example how to implement it. A very simple one would suffice I suppose (hope).

Roche's situation is an example, at least if he used the "name" attribute as the load attribute, rather than the "id" attribute.

At 09:18 AM 11/9/00 +0200, Roch'e Compaan wrote:

I set "loaded by accessing attribute" to the attribute "id".

You should only do that if you want an "infinite rack". That is, one which contains all possible objects. Using "id" means that if the Rack tries to see if an object exists, it will *always* exist, whether it really exists or not. (Because the "id" attribute will always exist.) Given your example SkinScript below, you should probably be using "name" as the attribute to load off of. Then, the rack will only return an object if it exists in the SQL database. (Btw, you should probably be using WITH QUERY in your SkinScript.)

Storing items in the RDBMS works fine. But when I try to retrieve them with getPersistentItemIDs() nothing is returned?

That's because getPersistentItemIDs() only returns the id's of objects which are stored in the ZODB. That method exists only so you have some way of iterating over objects when you're using the "stored persistently" storage mode. It can also be used to find the id's of objects which have some of their attributes or propertysheets stored persistently. It is *not* a "get me everything in the rack" method.

I have a skinsript method getCustomer:

WITH getCustomerSQL(CUSTOMER_ID=self.id) COMPUTE id=CUSTOMER_ID, name=NAME

and getCustomerSQL is a SQL method.

If your objects are stored in an SQL database, then to get a list of objects you need to use an SQL method. Here is the "recommended approach" for iterating over objects in ZPatterns: 1. Define domain-specific retrieval methods in your specialist. For example, "getPastDueToDoItems()" and "getAllToDoItems()". 2. Create methods in your rack(s) which actually implement the retrieval; these may be named the same, or depending on your application, they may be smaller chunks of code which you aggregate or pass parameters to, in order to implement the higher-level functioning. If a given rack uses ZODB storage, its implementation methods may use getPersistentItemIDs(), but they should otherwise be using SQL methods, catalog searches, or other means of retrieving a list of objects. 3. Have the domain-specific methods call the methods in the racks to implement the desired behavior, and have *all* other code call the methods in the Specialist. The key here is to remember that: 1. A Specialist is a singleton object (i.e. only one instance per app) that is responsible for dealing with objects of a particular interface. Specifically, it is responsible for: a) Creating objects which supply that interface, according to given criteria b) Retrieving objects which supply that interface, given an identifier c) Manipulating groups of objects which supply that interface, through a domain-specific API (e.g. getPastDueItems(), purgeCompletedItems(), etc.) d) Providing an application-level UI for all of the above, as/when needed by the application e) Providing UI "snippet" methods to create selectors (e.g. form fields, dropdowns, etc.) for other objects to use in their UI's, so that they can relate to or otherwise interact with objects the Specialist is responsible for. (Notice, by the way, that this list effectively puts everything that an application integrator might want to customize all in one place...) 2. Racks are essentially *private objects* belonging to the Specialist to help it carry out its responsibilities. Each rack is responsible for retrieving objects of a *particular class and storage location* which implement the interface the Specialist serves. Multiple racks are used when there is more than one class that implements the interface in the application. 3. Because Racks belong to the Specialist, it's okay for the Specialist to "know" things about its racks as a whole (e.g. which ones provide what concrete classes, what search order to use, how to combine the results of queries from them, etc.), but it should still delegate the actual *implementation* of behaviors to them wherever possible. If you follow this approach, you will end up with an application whose functioning is cleanly divided, and any developer familiar with ZPatterns will know where to call things, and where to go to change implementations. Further, if that developer needs to change from an SQL database to using the ZODB, or vice versa, or change from one database schema to another, they will be able to do so without changing code outside the racks, or at most, the specialist, and all other application code, including your classes and ZClasses, will be unaffected by the changes.