A Review of the Publishing Events

As we mentioned in the previous section, extending the CMS workflow is all about state management. However, it's impossible to manage state if you can't "see" events as they fire. To solve this problem, CMS has several workflow events that are fired at various times in the workflow process. You extend the CMS workflow by adding business-specific logic to the appropriate event or events.

CMS workflow events are "fired" at various times in the workflow process. Each event is really an event pair one event in the pair fires before a state change occurs, and one fires after. All events that fire before the state change end with "ing." All events that fire after a state change end in "ed." To make things a little more interesting, any given state change may involve one or more event pairs. In fact, there are always at least two event pairs firing for every posting state change, but there may be more.

In Table 31-2, we've provided a list of the standard workflow events and a brief description of when they fire.

To help you better understand how events fire, let's look at one example. In Figure 31-1, we show the flow of an event firing sequence for an approval action on an existing posting. As we described earlier, you can see how the "ing" event fires first and then the "ed" event fires. Also, you can see that there are actually two pairs of events in the sequence. CMS will always fire the Changing and Changed events regardless of what action is taken; in reality, the Changing and Changed events may fire more than once for certain workflow actions.

Figure 31-1. The event firing order for an approval action

Table 31-2. Standard Workflow Events in CMS

Workflow Event	Description
Approved	Fires after a posting has been approved
Approving	Fires just before a posting is approved
Changed	Fires after any change has occurred
Changing	Fires just before a change is made
Created	Fires after a posting has been created
Creating	Fires just before a posting is created
CustomPropertyChanged	Fires after a custom property value has been changed
CustomPropertyChanging	Fires just before a custom property value is changed
Declined	Fires when a posting has been declined
Declining	Fires just before a posting state is changed to declined
Deleted	Fires after a posting has been deleted
Deleting	Fires just before a posting is to be deleted
Moved	Fires after a posting has been moved
Moving	Fires just before a posting is moved
PlaceholderPropertyChanged	Fires after the value of a placeholder is changed
PlaceholderPropertyChanging	Fires just before the value of a placeholder is changed
PropertyChanged	Fires after a posting property has changed
PropertyChanging	Fires just before a posting property is changed
Submitted	Fires after a posting has been submitted
Submitting	Fires just before a posting is submitted

When you're extending the CMS workflow, it's likely that you don't need to catch all events, just the specific ones that are germane to your process. Further, adding code to multiple events may have unexpected results if you're not careful.