Create Content and Service/Tool Events

Base Content Events:

IContentAdd, IContentModify, IContentRemove

Base Service Events:

IServiceAdd, IServiceModify, IServiceRemove

Base Security Events:

IOwnershipModify, ISecurityLocalRolesAdd, ISecurityLocalRolesModify, ISecurityLocalRolesRemove.

These should probably inherient from ISecurityModify.

Base Zope Events:

IPermissionsModify (changing the Permissions through the ZMI), IObjectAdd (object is called through the ZMI and added), IObjectRemoved? (object is removed through the ZMI). IOFSImportEvent? (someone imports data through the web, after its successful), IOFSExportEvent? (someone exports an object through the web).

We should come with core services (without have tons of interfaces) that allow programmers to easily register and catch those events. But some aspects in CMF/Plone are fairly course grain like DublinCore? modification. That would be a IContentModify? event but should probably allow for people to specify they want to catch specifically only metadata change events.

Events will only be generated inside of folders that support Events. I believe we should make it clear that OFS.Folder and CMFCore?.PortalFolder? will not support events. We should not try to monkey with them. Basically if you have a Plone Site (root PortalObject?), and PloneFolders? or ArchetypeFolders? (which should probably merge with the PloneBaseFolder?) then your system should work with all Events. Some of the API calls override ObjectMananger? calls.

Nothing is allowed to be committed until the Event is processed. Since this is a syncronous framework there should be no commmits before the Events are published. This is an example I could think of: I do not want anyone to create (Script) Pythons in the systems (even Managers) besides the owner. When a Script Python is called a IObjectAdd? event is fired, the processor could look at the person creating it and if it were not the owner of the system (say another manager) it could abort the creation. This is an abuse but allows Events to set policies very easily. Implementation impacts:

Content:

• Content creation:

  o On portal_workflow.notifyCreated (the defacto standard hook point for content creation) after the object is created and has gone through all of its pre/post TTW script changes. An event should be raised, IObjectCreated?

• Content modification

  o modification is tricky. I think of Modification in the sense of: content worked editing an existing piece of content through the Plone interface. This could be properties or the edit form(s). I do not think of Security modification as Content modification and I think this is ok.

• Content removal

  o requires us to hook the OFS.ObjectManager? _delObject method. I do not believe manage_beforeDelete is guarantee'd to be called. Also hooked _delObject is dangerous. We need to understand the implications.

• Content events

  o It should be possible for people to create their own content events. It is pretty simple: they create a Interface that inherients from IContentEvent?. Register it. And in their content object they get a hold of the Event serivce and publish the object with their customized Interface.

  Services/Tools:

  o Tool creation

  • Services during adding may want to notify the system. For instance when CMFLinkChecker? is installed by the system an Event should be raised after addTool is called. NOTE: This requires fiddling with addTool unless the factory method can easily be changed.

  o Tool changes

  • When you modify the SkinsTool? path for instance. This would publish a IServiceModify? with the SkinTool? as an instance. One problem (how do you know what specifically changed without a specific interface?). i.e. How do I know what skinpaths have changed. Do I need to go back into the history of the zodb for that object and introspect its properties and compare them?

  o Tool removal

  • When _delObject is called on a folder with a tool it should raise an IServiceRemove? event. With the object that is being deleted. If an exception is raised the removal action would fail.

Deliverables

• Write examples of Tool Events, Content Events and how to make a 3rd Party Event.
• Modify existing PloneTools? to raise Events.
• Incorporate (fork) cvs.zope.org/Products/Event and EventListenerTool? (similiar to what Nuxeo has done in their CVS). We need to be conscious of submitting diff's of our changes back to Zope Corp Product Maintainers.
• PloneEvents? package
• Unit Tests of Event interaction