Re: [Zope] Private Product Objects (was: object icons)
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
From: Tres Seaver <tseaver@palladion.com> Sent: February 23, 2000 01:30 PM
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.
I'm beginning to think that way too. I haven't really dealt with priority or permissions yet (and I probably won't until Phase II), but trying to enforce a singleton is more trouble than it's worth.
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").
I guess I envisioned a single Schedule, because I imagined only a single Dispatcher thread. If there are more Schedules, either the Dispatcher will need a catalog to find all of the Schedules, or each Schedule will need it's own dispatcher. Let me hold that last thought for awhile...
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. Check.
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.
I sort of agree. One problem with deleting a Schedule is if it has events cataloged in it -- currently that breaks the event objects. A manage_beforeDelete method could just block a delete in that case. Also the Dispatcher task has to be terminated. There must be a way to do that in a manage_beforeDelete method. Martijn what do you think? You clearly went to a lot of trouble to put the Product in control of deleting the Schedule catalog.
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',)
Thanks. I'll use that.
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!
Like learning to swim by jumping into the deep end of the pool. 8^O Thanks for all your good ideas. -- Loren
participants (2)
-
Loren Stafford -
Tres Seaver