[Zope-PTK] Another use case for reviewing

[Kevin Dangoor]

----- Original Message -----
From: "Mike Pelletier" <mike@digicool.com>
To: <zope-ptk@zope.org>
Sent: Sunday, January 30, 2000 9:54 AM
Subject: Re: [Zope-PTK] Another use case for reviewing

> As long as the PortalCatalog can be made smart enough not
> to change under Versions this should be doable.

If you're not using CatalogAware, it seems like you should be able to
control when objects will reindex themselves. Whatever interface you have
that allows a reviewer to check in the changes could check in the version
and reindex all of the objects that were changed. (Just as long as someone
doesn't just check in the version from the management screens...)

>     This is something I'm considering for 1.0, but not really for the
> first release this week.  I want to keep this option open.  Can anyone see
> any potential trouble while having a few dozen Versions open?  The UI
> issues are pretty straightforward, I'm more concerned about objects
> (and the catalog) locking themselves inconveniently.  The catalog should
> obviously refuse to update itself if it's in a Version.  If anyone knows
> any other potential problems, please speak up.

In my IMDB sort of scenario, having a whole object locked for a change (and
not just a property) could be inconvenient. Let's say that one user wanted
to list an additional writer on a movie, while someone else was updating the
plot summary. If the whole movie object was locked, then two people couldn't
submit changes simultaneously.

However, a solution to this problem could be created at an application-level
anyhow. Just make the change form for the object create it's own kind of
version object with the properties and the proposed changes, and then make a
form for the reviewer to accept/reject the changes. So, the Version method
is probably fine for most uses anyhow...

>     This thread also touched on collaboration.  The nature of the web
> makes this difficult (perhaps impossible) to get right.  I don't see that
> this is a design consideration we can realistically entertain.  The best
> I feel we could manage would be to prevent concurrent editing.

I think it's fine to not really deal with that aspect in PTK 1.0. I'm
guessing that we'll see some interesting solutions come up from the
community.

Kevin