В този пост разглеждам как работят формите на списъци и Content Types в SharePoint 2007 (в случая WSS v3) и какви са ни възможностите за разширяване и разработка. В тази първа част ще обясня как да използваме наши си ASPX форми, а във втора – как да заменим стандартните Rendering Templates с нови. С втория пост ще сложа и линк към решение с пример за двата варианта.
Когато създадем списък в SharePoint, ние всъщност създаваме копие на базата на съществуващ шаблон – List Template. Тези шаблони са дефирнирани в Features, и всеки Feature с шаблон за списък ще съдържа дефиниращ файл: schema.xml. Този schema.xml може се разгледа за всеки списък, който WSS v3 ни предлага: разгледайте 12\TEMPLATE\FEATURES папката, там има Features като CustomList, ContactList, DocumentLibrary. Всичките имат schema.xml, който дефинира особеностите им.
В края на този XML (CAML) файл може да видим „Form” елемент, който дефинира ASPX страниците, които ще бъдат използвани за списъка, на който схемата принадлежи.
Когато се създава списък, платформата прави копие на файл-а дефиниран в “SetupPath” атрибута на “Form” елемента, и го качва в базата данни с посоченото име в “Url” атрибута. След като страницата е създадена (това е обикновен Web Part Page), SharePoint слага ListFormWebPart в посочения WebPartZoneID. “pages\form.aspx”, и подобни други ASPX страници се намират в 12\TEMPLATE\Pages, и там можете да сложите своите. Горният screenshot е от CustomList, но можете да разгледате и всички останали.
Интересното става, когато Content Types са добавени в списъци. Всеки Content Type може да има свои DisplayForm, EditForm или NewForm зададени, а всеки списък може да има множество Content Types. Съответно за създаването на различен вид съдържание в един списък можете да имате различни форми за различните Content Types – това е много добра гъвкавост. От друга гледна точка, всеки Content Type може да има един и същ интерфейс (форма) навсякъде, когато е използван многократно.
Как работи всичкото това зад сцената?
В SharePoint SPContentType обектът ни позволява да му зададем EditFormUrl, DispFormUrl, и NewFormUrl (притежания):
cType.EditFormUrl = “_layouts/ourprojectfolder/customedit.aspx”;
cType.NewFormUrl = “_layouts/ourprojectfolder/customnew.aspx”;
cType.DisplayFormUrl = “_layouts/ourprojectfolder/customdisplay.aspx”;
Ако тези са дефинирани от нас, SharePoint прави следното:
· С избирането на “New” бутона или съответните опции от менюто на всеки ред в списъка, SharePoint ни праща на EditForm.aspx, NewForm.aspx или DispForm.aspx според избора.
· Когато създава списъка, платформата конфигурира ListFormWebPart на всяка от тези ASPX страници (откопирани са от Pages\form.aspx). WebPartZoneID атрибута определя къде точно да се добави този Web Part. Тези страници не могат без този Web Part – SharePoint се оплаква ако се опитате да го насочите към страница без ListFormWebPart.
· Този ListFormWebPart проверява текущия SPControlMode (Edit, New, Display), и дали съответното притежание (EditFormUrl, DispFormUrl, или NewFormUrl) на текущия Content Type е зададен. Логиката може да бъде проследена ако разгледаме кода на този web part – в OnInit метода се прави проверка на притежанието this.FormPageUrl, което всъщност е obfuscated и не мога да ви го покажа.
Независимо дали е зададен от нас или не (EditFormUrl, DispFormUrl, или NewFormUrl), SharePoint ни праща към съответната страница – NewForm.aspx, EditForm.aspx или DispForm.aspx. На тези страници ListFormWebPart проверява текущия Content Type (всеки List Item в SharePoint има зададен Content Type) и ни препраща към съответната форма (ако тя е зададена от нас). this.FormPageUrl определя коя е тя на база на текущия SPControlMode (New, Edit, Display), но не мога да ви покажа кода на this.FormPageUrl защото е obfuscated. Така всъщност става конфигурирането на поризволни форми.
Проблемът на този дизайн, е че SharePoint първо ни праща към NewForm.aspx (или една от другите) и след малко код отново ни препраща чрез SPUtility.Redirect (което зад сцената е по-украсен Response.Redirect). Това са два post-back-a, и можете да ги проследите с Firebug или Fiddler, или който и да е друг HTTP listener. Освен, че препратките са две, NewForm.aspx е Web Part Page, а те не са хич леки.
Това, което все още не знам е как да конфигурираме EditFormUrl, NewFormUrl или DispFormUrl в схемата на ContentType елемента (чрез CAML). Примерът по-горе е чрез код и обектния модел, но той не е идеален за всички случаи. В WSS v3 “Form” елемента е “obsolete”, така че начина, по който го правихме в WSS v2 е вече невалиден. Втория ни вариант всъщност е да работим с XmlDocuments елемента в CAML – той ни позволява да сменим съответния Rendering Template на формата. Така става чрез CAML, но двата метода работят по коренно различен начин.
Във втората част на този пост ще разгледам как да заменим стандартните Rendering Templates с произволни, и съответно алтернативния вариант да разширяваме формите на списъци и Content Types.
Надявам се това ще помогне на някой.
