Как правильно изменять внешний вид List Form в SharePoint

Всё в SharePoint'е можно делать разными способами. Но в последнее время, очень хочется делать правильно...

На этот раз, мне потребовалось внести изменения на формы стандартного SharePoint'овского списка. Таких форм существует три вида, и вы все их прекрасно знаете:

1. DisplayForm - форма отображения элемента списка
2. EditForm - форма изменения элемента списка
3. NewForm - форма создания нового элемента списка

Из-за большого количества полей в одном из наших списков, мне захотелось разнести эти поля по вкладкам. Причем, захотелось также следующее:

1. Чтобы сохранилась возможность добавлять новые поля в список
2. Чтобы можно было перемещать поля из одной вкладки в другую, и менять порядок их следования
3. Чтобы поля рендерились стандартными средствами 

Для того, чтобы определить принадлежность полей к вкладкам, я раскопал способ добавления пользовательских данных в SPField, и создал симпатичный jquery-интерфейс для того, чтобы этим мог заниматься пользователь. Но дальше дело, неожиданно, застопорилось: оказалось, что народ повсеместно пользуется для подобных целей грязными js-хаками, а такой способ мне категорически не подошел!

И вот, после долгих исследований и поиска в интернетах, мне-таки удалось понять, как же это делается правильно, и воплотить в жизнь вот такую вот красивую форму:

Как видите, часть полей (ФИО и фотография) здесь рендерятся по-особому. Остальные поля рендерятся обычным образом, но разбиваются на вкладки (пользователь может менять порядок полей и принадлежность полей разным вкладкам).

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

Как делают все

Оказалось, что когда дело доходит до форм списков, большинство SharePoint-разработчиков использует крайне сомнительные подходы:

1. Создание новой формы в виде aspx-страницы, которая кладется в _layouts. Форма полностью "кастомная", и если в список добавить поле, это поле придется руками добавлять и на форму...
2. Javascript и jquery-хаки. К примеру, такие известные проекты, как Virto Ajax List Form Extender и SPServices - на самом деле парзят содержимое страницы с формой уже после её загрузки, и затем вносят свои изменения.

Ни один из этих подходов мне не понравился.

Создание целиком новой формы вообще пошло из SharePoint Designer, то есть это кустарное решение, решение для сисадминов.

Что же касается jquery, то это типичный клиентский подход, изобилующий собственными минусами:

• В таких решениях, чаще всего даже невооруженным взглядом видно, что сначала форма загружается в обычном виде, а через мгновение - меняется (например, добавляются вкладки, и т.д.). Чем больше полей, тем лучше это видно.
• jQuery использует механизм, который в профессиональной среде называется скринскрэпингом (screen scraping, data scraping), а даже само слово это - дурно пахнет! По сути, скрипт парзит HTML-код или же ищет элементы DOM-модели по некоторым признакам - в любом случае, признаки эти официально нигде не заявлены, и никто не гарантирует, что после очередного обновления SharePoint, ваш код останется работоспособным.

RenderingTemplate

Через некоторое время поисков, я понял, что если мне что-то и поможет, то только механизм RenderingTemplate. Этот механизм позволяет задавать т.н. шаблоны отображения форм списков для типов содержимого (класс SPContentType, свойства EditFormTemplateName, NewFormTemplateName и DisplayFormTemplateName).

RenderingTemplate представляет собой обычный ASP.Net контрол, реализующий интерфейс ITemplate, и позволяющий задать шаблон для отображения формы списка. Куча RenderingTemplate'ов лежит в файлике 14\TEMPLATE\CONTROLTEMPLATES\DefaultTemplates.ascx. Среди них, присутствует и шаблон под именем ListForm, который представляет собой стандартный шаблон для отображения всех форм списка.

Центральным элементом шаблона ListForm является контрол ListFieldIterator. Собственно, он и отображает все поля. И что интересно, от него можно отнаследоваться, а затем переопределить метод Render, чтобы изменить отображение так, как нам вздумается.

FormContext

Когда мы переопределяем метод Render в новосозданном потомке ListFieldIterator, сразу же возникает вопрос: а как рендерить поля? Откуда взять сведения о том, какие у нас есть поля, каковы их значения, и т.д. Оказалось, всё очень просто, и решается с помощью коллекции SPContext.Current.FormContext.FieldControlCollection. Эта коллекция хранит объекты типа BaseFieldControl, каждый из которых содержит, среди прочего, свойства Field и ItemFieldValue, которые позволяют получить любые сведения о поле, и значении этого поля.

Также, каждый из этих контролов имеет метод RenderControl, благодаря чему их можно спокойно отображать штатными средствами, ровно также, как это сделал бы SharePoint.

Ниже представлен шаблонный пример класса-потомка ListFieldIterator:

    public class CustomFieldIterator : ListFieldIterator
    {
        protected override void Render(HtmlTextWriter output)
        {
            foreach (BaseFieldControl fieldControl in SPContext.Current.FormContext.FieldControlCollection)
            {
                if (fieldControl.Field == null)
                    continue;

                // небольшой хак, если его не использовать,
                // IsFieldExcluded будет всегда возвращать true,
                // т.к. считает, что контрол уже есть, и еще раз
                // добавлять его не требуется.
                fieldControl.Visible = false;

                if (!this.IsFieldExcluded(fieldControl.Field))
                {
                    output.AddAttribute("class", "my-field");
                    output.AddAttribute("id", "field" + fieldControl.FieldName);
                    output.RenderBeginTag(HtmlTextWriterTag.Div);
                    output.Indent++;

                    // Восстанавливаем видимость и рендерим контрол
                    fieldControl.Visible = true;
                    fieldControl.RenderControl(output);

                    output.Indent--;
                    output.RenderEndTag();
                }

            }

        }
    }

В этом фрагменте, правда, отсутствует прорисовка заголовков и описаний полей, но пусть это будет домашним заданием :)

Кстати, возможностей данный подход открывает великое множество, если подумать...

Проект-пример

Проект, демонстрирующий описанный выше способ, доступен для скачивания.


P.S. Мои исследования во многом основывались на статье Виталия Баума Расширяем возможности ListFieldIterator, спасибо ему большое за эту статью!

Собственно, там описан практически такой же результат, который получил и я, только Виталий объединял поля не во вкладки, а в секции:

Кроме того, сведения о секциях хранились у Виталия в схеме типа содержимого, а не присоединенными к полям, что накладывало некоторые ограничения и неудобства.

Но вообще, статья обрывочная, вот честно. Фрагменты кода в надерганы очень куцо, мне по ним было крайне сложно сориентироваться, почти до всего пришлось доходить самому.

В целом, надеюсь, мой пост прольет еще больше света на это очень правильное направление.