Thank you! Here are some followup comments: You are right that using "OFS: Folder" as a base class lacks the customizable "add list"; that's why I wanted to redo my base classes. And, yes, I saw the howto posted somewhere on zope.org, but I thought it would be cleaner to redefine the product "from scratch", but still keep the Class ID's so that my existing "test sites" would still work. I did not realize that my method was unsupported, actually (how should I have found this out? What have I not read?), although I did know that redefining base classes was not going to be easy. I did discover that it was necessary to completely delete (rather than rename and/or change the Class ID of) the old ZClass before defining the new one. In case anyone else ends up trying this. I'm pushing the limits of the web management interface, perhaps, and I realize that - I'm trying to sort of approach Zope as a kind of "black box" and see how far I get. However, I have a conceptual question that is related to this: What's the best way to manage two "versions" of the same product on a single Zope server? I have an iMeme account, and I'm about to set up maybe three web sites with the first version of my product. However, I'd like to continue to refine the product, without messing with my live sites (that belong to paying clients). Is there a generally accepted way of doing this with only one Zope server available? And of making "upgrades" to the production version product easily? Thanks, Am Dieter Maurer wrote:

3. You provide the missing registration as ZClass base for "PropertyManager". It can look like this:

from ZClasses import createZClassForBase from OFS.PropertyManager import PropertyManager

createZClassForBase(PropertyManager,globals(), 'PMBase', 'Property Manager')

...

Breaking the connection between ZInstances and the origin ZClass and reconnecting as you did, is not an officially supported operation (as you surely know). This means, there are side effects, which an official support need to take into account:

The class id is used as a module name in "sys.modules".

When you change the class id of a ZClass, then probably neither is a new module (with the new name) created nor is the old module replaced in "sys.modules".

Try to restart and see whether the effect disappears.

Dieter

Thanks, Steve, I prefer PropertyManager to property sheets at the moment for a couple of reasons: 1) I don't have to "group" my properties, I don't have to remember what property is in what sheet, I don't have to use quite so long a command to update the properties, and 2) If I create an instance of a ZClass with a propertysheet, it seems to always define the properties, and I want to inherit them from a parent object unless I specifically define them in the new object. I may be missing something, but I seemed to get this effect, and that's why I switched to using PropertyManager. I understand why one would be nervous about ZClasses. It is a pain not to be able to change base classes easily! Deleting instances and starting over will probably not be an option in the future, though, as my product will be used in some live sites, but I may still have to make significant changes. Thanks hugely for the response! Am Steve Spicklemire wrote:

Hi Am,

ZClasses have "propertsheets" already.. so you shouldn't really need to inherit from PropertyManager. Also.. changing ZClasses by deleting and recreating is a sort of "last ditch" scenario and likely to cause problems. You're probably better off deleting all your old instances and starting over. This is one of the "major problems" with ZClasses that makes so many developers nervous about them. Having said all that, I still find them useful in conjunction with a product like ZPatterns that permits you to keep the actual data/relations in SQL or LDAP or whatever.

-steve

On Saturday, April 20, 2002, at 03:52 PM, A M Thomas wrote:

...

Hello there, and thank you very much in advance for any help.

I'm working on my Zope (2.5.0) product through the management interface, and realized that if I just created a ZClass with base classes of ObjectManager and CatalogAware, I couldn't add properties to it :( So, I went to re-create my ZClass - and discovered that PropertyManager isn't in the list of selectable base classes. Why is this? Is there some way I can inherit directly from PropertyManager?

I went ahead and created it with an additional base class of DTMLDocument, since it's got PropertyManager as one of its base classes, but this isn't what I really want -- in addition to being slightly inelegant, now the manage_findForm method doesn't appear in the available methods for creating Views.

Must I create my product in Python only to get PropertyManager cleanly? Would this even work? And would converting be easy?

Also, I noticed a curious effect: I re-created my ZClass by moving all the methods into a temp ZClass, renaming the add and addform methods, and saving out the Class ID, then deleting the ZClass and the remaining constructor objects (Permission, and Factory). Then I created a new ZClass with the same name as the old one, and put in the saved ClassID, replaced the new Add and Addform methods with my original ones (by deleting the new ones and renaming the original ones back to their original names), and pasting in the methods again.

However, old instances of this ZClass _gradually_ started showing "broken product" messages. First one, then overnight, two more - and the first one didn't seem to change immediately. They shouldn't be broken anyway, right? Is there some known issue about deleting and re-creating ZClasses in a product? To make matters even more interesting, now one of them isn't broken anymore. Yes, I've re-created this ZClass more than once today, and this isn't a good diagnostic report, I know, but I just wanted to know if anyone knew what might be going on based on similar past experience.

Thanks, Am

_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

Hi Steve, Thanks for the follow up! I have to respond about property sheets again... what I want is to take advantage of the famous "acquisition" mechanism, but I want my class instances to acquire from their _containing objects_ rather than from their class property sheet values. They seem to be inheriting from the property sheet values even if the value is "blank" in the property sheet. Is there some way to control this, other than testing each thing? Creating an "undefined" value is not really going to work here; I've got a whole bunch of different properties, some are selections, some boolean (hard to set an undefined value for those), some text... I could, of course, define an additional property for each property already defined, that specifies whether the property should come from the containing object (true by default), but isn't the whole acquisition model supposed to make this unneccessary? I'm trying to do things the "right" way within Zope, but I'm still not sure what that is for what I'm trying to accomplish. I'm starting to suspect that the ZClass approach may not be the best for what I want. Many thanks, Am Steve Spicklemire wrote:

...

2) If I create an instance of a ZClass with a propertysheet, it seems to always define the properties, and I want to inherit them from a parent object unless I specifically define them in the new object. I may be missing something, but I seemed to get this effect, and that's why I switched to using PropertyManager.

Hmmm... the property sheet only gives the class a value for the named properties. This "class" value gets used if the instance doesn't have a value of it's own. You can give the class value some "special" value (e.g., 'uninitialized') if you want to check an instance to see if you've set a custom value for that instance.