Обновление уже развернутых типов контента SharePoint для обработки дополнительных событий объекта
Вам нужно взглянуть на Одинаковая политика происхождения :
В вычислениях одна и та же политика происхождения является важной концепцией безопасности для ряда языков программирования на стороне браузера. , например, JavaScript. Политика разрешает сценариям, работающим на страницах, исходящих с одного и того же сайта, получать доступ к методам и свойствам друг друга без особых ограничений, но запрещает доступ к большинству методов и свойств на страницах разных сайтов.
Чтобы вы могли получать данные, это должно быть:
Тот же протокол и хост
Вам необходимо реализовать JSONP чтобы обойти это.
3 ответа
Вы вызывали ctype.Update ( true) после добавления EventReceiver? Если вы этого не сделаете, это не будет продолжаться. И не используйте тип содержимого List, используйте вместо него SPWeb.ContentTypes.
Этот код работает для меня:
var docCt = web.ContentTypes[new SPContentTypeId("0x0101003A3AF5E5C6B4479191B58E78A333B28D")];
//while(docCt.EventReceivers.Count > 0)
// docCt.EventReceivers[docCt.EventReceivers.Count - 1].Delete();
docCt.EventReceivers.Add(SPEventReceiverType.ItemUpdated, "ASSEMBLYNAME, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c5b857a999fb347e", "CLASSNAME");
docCt.Update(true);
Параметр true означает, что он также передается всем дочерним ContentTypes. (т.е. ко всем спискам, использующим тип содержимого).
Чтобы ответить на вторую часть вашего вопроса, это непростая вещь из-за того, что изменения типов контента в коллекции сайта не будут перенесены в списки, в которых они используются. «Копия», по сути, состоит из полей в коллекции сайтов, и после добавления типа содержимого в список между ними больше нет связи. Я думаю, это связано с тем, что вы должны вносить изменения в списки, не влияя на коллекцию сайтов. Как бы то ни было, мой вклад в эту «проблему» и то, как я ее решил, заключается в том, чтобы сделать xml «главным» и в featurereceiver я вытаскиваю xml и нахожу все места, где используется contenttype, и оттуда обновляю contenttypes (на самом деле fieldrefs) на уровне списка, чтобы они соответствовали тому, что в xml. Код выглядит примерно так:
var elementdefinitions = properties.Feature.Definition.GetElementDefinitions();
foreach (SPElementDefinition elementDefinition in elementdefinitions)
{
if (elementDefinition.ElementType == "ContentType")
{
XmlNode ElementXML = elementDefinition.XmlDefinition;
// get all fieldrefs nodes in xml
XmlNodeList FieldRefs = ElementXML.ChildNodes[0].ChildNodes;
// get reference to contenttype
string ContentTypeID = ElementXML.Attributes["ID"].Value.ToString();
SPContentType ContentType =
site.ContentTypes[new SPContentTypeId(ContentTypeID)];
// Get all all places where the content type beeing used
IList<SPContentTypeUsage> ContentTypeUsages =
SPContentTypeUsage.GetUsages(ContentType);
}
}
Следующее, что нужно сделать, это сравнить ссылки на поля в xml xml с полями в списке (выполняется с помощью атрибута ID) и убедиться, что они равны. К сожалению, мы не можем обновить все вещи в классе SPFieldLink (fieldref) и (да, я знаю, что он не поддерживается) здесь я фактически использовал отражение для обновления этих значений (например, ShowInEditForm).
Что касается второй части вашего вопроса, я хотел бы рассказать, что мы делали в подобных ситуациях в прошлом. В нашей ситуации нам потребовалась пара разных скриптов: один, который позволил бы нам распространять обновления типов контента на все списки во всех веб-сайтах, а другой, который сбрасывал бы главные страницы / макеты страниц до определения сайта (ненастроенная форма
Итак, мы создали несколько пользовательских команд stsadm для каждого из этих действий. Это удобно, потому что сценарии могут быть помещены в систему управления версиями, и он реализует уже существующий интерфейс stsadm.