Я не уверен, что это отличный ответ, или даже полностью тематический, но в основном это то, о чем я изначально хотел рассказать в блоге - в любом случае:
Это действительно боль, которую делает Client OMпохоже, не предоставляют метод / свойство с подробной информацией о текущем SPListItem.Тем не менее, я бы рискнул сказать, что это простая концепция, но на самом деле она имеет довольно широкие последствия для SharePoint, которые не проявляются, пока вы не перестанете думать об этом.
Подумайте:
- Несмотря на то, что перенаправление существует, сообщение для обсуждения может отображаться на 2 или 3 разных URL-адресах (например, Threaded.aspx / Flat.aspx)
- Аналогично, запись в блоге может существовать для пары (сообщение.aspx / EditPost.aspx, может быть, еще один)
- Элемент списка, очевидно, имеет DispForm.aspx / EditForm.aspx и (вроде) NewForm.aspx
- Также для элементов ссвязанный файл SPFile (например, документ, страница публикации), примите во внимание, что эти URL представляют один и тот же элемент: http://mydomain/sites/someSite/someLib/Forms/DispForm.aspx?ID=x, http://mydomain/sites/someSite/someLib/Filename.aspx
- Кроме того, могут существовать другие типы контента вне этого набора, которые имеют аналогичныеdeal
В нашем случае мы хотели «повесить» данные на внутренние и внешние элементы (например, лайки, комментарии).Мы подумали, что «все в SharePoint имеет URL, так что это может быть разумным способом идентификации элемента».Большая ошибка, и я все еще бью себя за то, что упал в нее.Это похоже на то, что нам нужен какой-то метод normalizeUrl в API, если мы хотим использовать URL-адреса таким образом.
Вы когда-нибудь замечали класс PageUrlNormalization в Microsoft.SharePoint.Utilities?Звучит многообещающе, не так ли?К сожалению, похоже, что это делает что-то, что я не описываю выше - он не работает с различными типами контента и т. Д. (Но имеет дело с расширенными веб-приложениями, HTTP / HTTPS и т. Д.).
Чтобы сократитьКороче говоря, мы решили, что наилучшим подходом было бы сделать сервер emit details, который позволил бы нам идентифицировать текущий SPListItem при передаче обратно на сервер (например, в запросе AJAX).Мы скрываем «канонический» идентификатор элемента списка в переменной JavaScript или в скрытом поле ввода (что бы то ни было на самом деле), и они оцениваются, когда возвращаются на сервер, чтобы повторно получить элемент списка.Не так эффективно, как получение всего из контекста, но для нас это нормально, потому что нам нужно разрешать только когда пользователь нажимает что-то, а не при каждой загрузке страницы.Под каноническим я подразумеваю:
SiteID|WebID|ListID|ListItemID
IIRC, один из ключевых объектов имеет свойство CanonicalId (или, может быть, оно внутреннее), которое может помочь вам создать такую строку.
Так что вУсловия использования window.location.href, я бы избегал этого, если вы находитесь в той же ситуации, что и мы.Предложите рассмотреть подход, аналогичный тому, который мы использовали, но помните, что есть некоторые местоположения (например, определенные формы), где даже на сервере SPContext.Current.ListItem имеет значение null, несмотря на тот факт, что SPContext.Current.Web (и, возможно, SPContext).Current.List).
В итоге: идентификаторы - это ваши друзья, а URL - нет.