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

[Tres Seaver]

Loren Stafford <lstaffor@dynalogic.com> writes:
> 
> 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.

Hmm, I guess I don't see the necessity of making it a Singleton here.  Suppose
you need to segregate events into separate priority classes, or guarantee that,
when executed, the run with the permissions of different users?  Splitting up
the schedule _might_ not be a terrible thing to do.  Your default case could
then just require dropping a single instance of the Schedule class at the root
of your Zope hierarchy, and leaving it there.

> 
> 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.

If Schedule derives from ZCatalog, as it seems, and the Event class uses the
well-known schedule ID as its default_catalog_id, then it isn't even necessary
to "contain" the events within the schedule object -- they will find it anywhere
above them in the tree by acquisition (think "uncle Schedule" instead of "papa
Schedule").

> 
> 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.

Solved if Schedule is an "ordinary" ZClass.

> 
> 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.

Again, solved for "ordinary" ZClass instances -- just set the permissions so.

> 
> 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.

You can override the setId() method to prefent changing the id;  BasicUserFolder
does this::


    def _setId(self, id):
        if id != self.id:
            raise Globals.MessageDialog(
                title='Invalid Id',
                message='Cannot change the id of a UserFolder',
                action ='./manage_main',)

> 
> 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?

Sounds like an interesting project!

Tres.
-- 
=========================================================
Tres Seaver         tseaver@palladion.com    713-523-6582
Palladion Software  http://www.palladion.com