Loren Stafford wrote:

I'm not sure; but I inherited some code that works like this:

# Set the icon for the MyClass, because it doesn't act # like a regular object, so I can't use registerClass misc_ = { 'MyClassIcon': ImageFile('www/MyIcon.gif', globals()) }

Apparently, in this case, the ID is constructed as <MyClassID>+'Icon'; because there is no corresponding icon=... statement anywhere. But, I can't find the Zope code that does this; so, I might be deceived.

This is the old, but still backward compatable way to assign an icon to a class. You can also assign the icon as a class attribute of a class, or you can use the new, udocumented Product registration interface. I'm taking notes on undocumented interfaces, you just found one. Zope now looks for a method in your Product's __init__.py file. These methods are passed a registration context with which they register themselves with Zope. Here I have heavily commented ZCatalog's registration methods. The key of it is a function you define called 'initialize'. Zope will call this and pass a registration context which defines the interface for Products to register themselves with Zope's various services (like the managment interface, security, subclassability, the help system, and yes, icons). ## import your various classes and thingies: import ZCatalog, Catalog, CatalogAwareness, Vocabulary def initialize(context): ## to register a new Zope managable object, call this method on ## the context, passing it the class, permission to protect the ## 'constructors', the two constructors (form and action tuple) the ## permission protects, and lastly, the icon. context.registerClass( ZCatalog.ZCatalog, permission='Add ZCatalogs', constructors=(ZCatalog.manage_addZCatalogForm, ZCatalog.manage_addZCatalog), icon='www/ZCatalog.gif', ) ## registerClass can be called as many times as there are objects ## that your Product provides. In this case, we also register ## Vocabularies. context.registerClass( Vocabulary.Vocabulary, permission='Add Vocabularies', constructors=(Vocabulary.manage_addVocabularyForm, Vocabulary.manage_addVocabulary), icon='www/Vocabulary.gif', ) ## If you want your classes to be subclassable as ZClasses, call ## 'registerBaseClass' on the context, passing it the class. context.registerBaseClass(ZCatalog.ZCatalog) context.registerBaseClass(CatalogAwareness.CatalogAware) ## finally, register the Help system for your Product (if any) context.registerHelp() This is the new, 'supported' product registration, and we encourage everyone to evolve their product to it. -Michel

Now that I've had breakfast and thought about this a little more, I see there is broader issue: how to handle the special needs of objects that are private to a product. My product is an event scheduler. (Terry, who started the "object icons" thread, may have a different situation. Jump in and tell us about your product, Terry.) The Scheduler product registers an catalog-aware Event class so user's can define scheduled events. The product keeps track of all Events in a ZCatalog "Schedule". Now, Schedule is a persistent object and has a class definition, but the one and only instance is created by the product and load time, if an instance doesn't already exist. The Schedule has some special usage requirements: 1. There should be only one instance. That's why its class is not registered. 2. It probably shouldn't show up on users' navigation bars and folder lists. This probably is not a problem, because Schedule has a unique meta-type. But that's not a watertight solution. A standard method for marking it invisible would be better. 3. If and when it does show up (as on the manage_main menu) it should be identified with the product (to avoid the "Whaz dis?" confusion). That's why I want it to have an icon that shows it is part Scheduler product. 4. No one, not even a manager, should be able to delete it accidently. You can make an object undeletable by putting its ID in the list of reserved names, but I have found, during development of Scheduler, that this hack causes more problems than it's worth. I might settle for letting be deleted by a manager. 5. When the product is deleted (I mean really deleted, because you don't want to use it anymore), the Schedule should be deleted too. Failing this, it should at least be deletable (an iffy situation, if you use the reserved_names hack). On the other hand, if you are just updating the product code, you probably don't want to delete the Schedule object. It may contain scheduled events. This is complicated by the fact that when you load a product, Zope first deletes the old product. So a manage_beforeDelete method can't distinguish between a "real" delete and a code update. I've also discovered that any error in a product's manage_beforeDelete method makes the product not only undeletable, but (because of the implicit delete) unupdatable (un-update-able)! (Hmmm. There's an idea. You could make any object, including the Schedule, undeletable by giving it a manage_beforeDelete method that raises an error.) 6. The Schedule need to have a "well known" ID (I think). This is for use in the default_catalog property of the events. I wouldn't want someone to change the ID of the Schedule arbitrarily. This may be the same problem as accidental deletion. Anyway, I thought I'd mention this use case, so that changes to the Zope product API at least don't make implementation of such products any harder than they already are, and perhaps make them easier. Got any suggestions for the short or long term? -- Loren