您的位置：首页 > 运维架构

[转]烦人的BeforePropertie----BeforeProperties，AfterProperties，properties.ListItem

2011-05-13 17:54 232 查看

As
many of you know, event receivers are a great way to hook into various
SharePoint events. These can apply to Feature events such as
FeatureActivated, List events such as FieldAdded, and many others. The most
common set of receivers used, however, are part of SPItemEventReceiver which
let you wire your code up to a number of events that can occur to items on a
list or library.

When
working with events, you’ll quickly find that before (synchronous) and after
(asynchronous) events exist, and the method suffix such as “ing” (e.g.
ItemAdding) and “ed” (e.g. ItemAdded) will tell you whether it gets invoked
before or after the actual change is made. Basic stuff.

And,
as you get deeper, you’ll even find that you can extract the before and after
state of the change. For example, you can hook into the ItemUpdating event
for a document library and prevent a user from changing a certain column. The
code might look like this:

public override void  ItemUpdating(SPItemEventProperties properties)

{

if (properties.BeforeProperties["column"] != properties.AfterProperties["column"])

{

properties.Cancel = true;

properties.ErrorMessage = "This column cannot be changed";

}

}

For
a document library, this works just fine. However, you should know that the
BeforeProperties hash table is not populated for items on a list. As is
worded in the SDK: “For
documents, Before and After properties
are guaranteed for post events, such as ItemUpdated, but Before properties are not available for
post events on list items”

When
they say “not available for post events on list items”, do they mean after
events (like ItemUpdated, ItemDeleted, etc)? The wording is curious here, so
I thought I’d take some time to test each combination of common events such
as Add, Update and Delete. These were done across a custom list and then a
document library. Each test involved adding a new item, editing the item and
then deleting the item. Here are the results for a list:

List	BeforeProperties	AfterProperties	properties.ListItem
ItemAdding	No value	New value	Null
ItemAdded	No value	New value	New value
ItemUpdating	No value	Changed value	Original value
ItemUpdated	No value	Changed value	Changed value
ItemDeleting	No value	No value	Original value
ItemDeleted	No value	No value	Null

No
value means that column value in the hash table was not available.

New value means that the correct value for the column was available.

Changed value means that the correct updated value was available.

Original value means that the correct original value was available.

Here
is the same test against a document library:

Library	BeforeProperties	AfterProperties	properties.ListItem
ItemAdding	No value	No value	Null
ItemAdded	No value	No value	No value
ItemUpdating	Original value	Changed value	Original value
ItemUpdated	Original value	Changed value	Changed value
ItemDeleting	No value	No value	Original value
ItemDeleted	No value	No value	Null

Properties.ListItem
refers the the current value for the list item at that point in the event.
Null means that the item is not available. My analysis yields the following
results:

Not
surprisingly, we get null values for for ItemAdding (before item is added)
and ItemDeleted (after item is deleted). This was proven by Ishai
Sagi some
time ago.

As correctly
documented in the SDK, item events for lists do not expose
BeforeProperties.

ItemAdding and
ItemAdded correctly report the value in the AfterProperties for an list
item, but not a library item. This is curious.

We have no
visibility on the previous states during the ItemDeleted event. Once
it’s deleted, it’s clearly gone.

So,
if we go back to our original problem listed above. How can we prevent a user
from changing a certain column for an item in a list event? From the list
table, you can see if we hook into the ItemUpdating event, we can compare the
current item’s value (properties.ListItem) to the AfterProperties value. The
code would look like this:

if (properties.ListItem["column"] != properties.AfterProperties["column"])

{

properties.Cancel = true;

properties.ErrorMessage = "This column cannot be changed";

}

I
hope this post gives you a better idea of how before and after events work
for both lists and libraries. Your comments and feedback are always welcomed.

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航