правильная модель для бокового хранилища в SharePoint? - PullRequest
1 голос
/ 22 сентября 2009

Мы хотели бы создать пользовательский тип - или просто добавить пользовательские столбцы к существующему типу - которые можно отображать в обычных списках (или библиотеке документов), не требуя специальной страницы или вида сетки. Этот столбец извлекает сложные / структурированные данные из внешней службы и представляет их как «значение» столбца. Я понимаю, что это будет препятствовать тому, чтобы некоторые функции столбцов работали должным образом (т. Е. Вы не можете сортировать по ним, осуществлять поиск по ним и т. Д.), Но это нормально, если столбец может интегрироваться в интерфейс дисплея.

Как относительный новичок в SharePoint, у меня возникают проблемы при построении модели или определении «лучших практик» для такой области. Я видел много статей о построении вычисляемых / вычисляемых полей, но есть несколько основных проблем с его использованием:

  1. Я не могу сделать сервисный вызов для каждого элемента в представлении списка (и по причинам перфекта, не хотел бы), поэтому, если я хочу дать этому столбцу представление списка, мне нужно сохранить «кэшированная» копия служебных данных. Но SP позволяет мне хранить только одно текстовое значение в моем столбце без какого-либо простого способа сохранить структурированные данные. Я мог бы сериализовать его каким-то образом, но не могу понять, как я мог бы определить RenderPattern, который правильно выделяет структурированные данные для отображения. Есть ли лучший способ хранить структурированные данные в настраиваемом поле? Я полагаю, что я должен просто сохранить небольшой текст, который я буду отображать в списке, хотя это не позволяет мне хранить другую полезную информацию в значении столбца.

  2. В полном представлении элемента можно использовать вызов службы для получения полной структурированной информации. Но я хотел бы использовать локальный кеш для хранения данных, которые я уже получил, по соображениям производительности и для удаления зависимости от внешнего сервиса. Предположительно, это должно быть даже постоянным, но где мне его хранить? Уже есть хороший постоянный кеш для SP?

  3. Предполагая, что кэш из # 2 завершен, мне нужен первичный ключ для хранения / извлечения кэшированных данных для определенной строки в списке. Но, насколько я могу судить, элементы списка не имеют такого ключа - только идентификатор списка (guid) и порядковый номер. Это означает, что удаление строки выше может сломать то, что раньше было моим «инвариантным» ключом. Есть ли лучший идентификатор, который я могу использовать для элементов списка?

Любая помощь или указатели очень ценятся - спасибо! Стив

Ответы [ 2 ]

2 голосов
/ 22 сентября 2009

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

Вопрос в том, как вы будете регулярно обновлять кэшированные данные в списке.

Создание настраиваемого поля управления для соответствия типу позволит вам настроить ввод и рендеринг. Таким способом можно создавать довольно сложные экраны ввода полей.

1 голос
/ 22 сентября 2009

Я сам никогда не пробовал этого, но пытались ли вы использовать BDC, чтобы заполнить элементы из вашего внешнего хранилища данных в списке и ссылаться на ваш список BDC в качестве столбца поиска во втором списке?

Проверьте этот Блог BDC . В нем рассказывается о том, как привязать данные BDC к списку. Предположительно, вы сможете использовать это значение для поиска во втором списке.

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

Cheers, Адам

...