Метод расширения, используемый для предотвращения справки по получению события элемента списка SharePoint - PullRequest
1 голос
/ 07 апреля 2011

Я натолкнулся на эту публикацию с отличным решением проблемы предотвращения приемника событий при срабатывании SPListItem при выполнении обновления извне приемника событий.Код работает на 100%, как описано, и я впечатлен решением, проблема в том, что я не до конца его понимаю.

Для простоты давайте проигнорируем методы SystemUpdate, поэтому мы имеем дело только сперегрузка SPListItem.Update и закрытый класс, объявленный в коде.

Бит, который я не "получаю", - это то, как класс rh "связан" или "связан" с элементом SPListItem.Воспроизведение метода для сохранения щелчка назад ...

public static void Update(this SPListItem item, bool doNotFireEvents)
{
    SPItemEventReceiverHandling rh = new SPItemEventReceiverHandling();
    if (doNotFireEvents)
    {
        try
        {
            rh.DisableEventFiring();
            item.Update();
        }
        finally
        {
            rh.EnableEventFiring();
        }
    }
    else
    {
        item.Update();
    }
}

Я вижу, что мы создаем экземпляр экземпляра SPItemEventReceiverHandling, rh, и, если doNotFireEvents имеет значение true, мы вызываем DisableEventFiring () для rh, а затем, когда закончим, вызываем EnableEventFiring() по рез.Ссылка, которую я не вижу, находится между "rh" и "item".Как SharePoint «узнает» об использовании rh в качестве получателя событий при выполнении обновления?

Надеюсь, я четко объяснил это.Если нет, дайте мне знать, и я постараюсь уточнить.

Ответы [ 2 ]

1 голос
/ 07 апреля 2011

Код отключает все Событие срабатывания для предметов, поэтому этот блок «Окончательно» так важен (он снова включается независимо от успеха обновления).

Документация: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spitemeventreceiver_members(v=office.12).aspx

0 голосов
/ 07 апреля 2011

Я предполагаю, что это глобально отключает получение события предмета. Я тоже не вижу, где создана ассоциация.

Интересно, пробовали ли люди, создавшие этот обходной путь, одновременно обновлять элементы? Если SharePoint делает это для каждого запроса (глобально для запроса, но не для экземпляра SharePoint), то это, вероятно, будет относительно безопасно.

Эти методы были помечены как устаревшие API в документации по SharePoint 2010.

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spitemeventreceiver_members.aspx

...