[Zope] Private Product Objects (was: object icons)

[Loren Stafford]

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