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

Loren Stafford lstaffor@dynalogic.com
Wed, 23 Feb 2000 16:36:57 -0800


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