Microsoft® Windows® SharePoint® 3.0 od środka

Transkrypt

Microsoft Windows
SharePoint 3.0
od środka
®
®
®
Ted Pattison
Daniel Larson
Microsoft® Windows® SharePoint® 3.0 od środka
Edycja polska Microsoft Press
Original English language edition © 2007 by Daniel Larson and Ted Pattison
Tytuł oryginału: Inside Microsoft® Windows® SharePoint® 3.0
Polish edition by APN PROMISE Sp. z o. o. Warszawa 2007
APN PROMISE Sp. z o. o., biuro: 00-108 Warszawa, ul. Zielna 39
tel. (022) 351 90 00, faks (022) 351 90 99
e-mail: [email protected]
Wszystkie prawa zastrzeżone. Żadna część niniejszej książki nie może być powielana
ani rozpowszechniana w jakiejkolwiek formie i w jakikolwiek sposób (elektroniczny,
mechaniczny), włącznie z fotokopiowaniem, nagrywaniem na taśmy lub przy użyciu innych
systemów bez pisemnej zgody wydawcy.
Microsoft, Microsoft Press, Active Directory, Excel, InfoPath, IntelliSense, Internet Explorer,
MSDN, Outlook, PowerPoint, SharePoint, SQL Server, Visual Basic, Visual Studio, Windows oraz
Windows Server są zarejestrowanymi znakami towarowymi Microsoft Corporation.
Wszystkie inne nazwy handlowe i towarowe występujące w niniejszej publikacji mogą
być znakami towarowymi zastrzeżonymi lub nazwami zastrzeżonymi odpowiednich firm
odnośnych właścicieli.
Przykłady firm, produktów, osób i wydarzeń opisane w niniejszej książce są fikcyjne i nie
odnoszą się do żadnych konkretnych firm, produktów, osób i wydarzeń. Ewentualne
podobieństwo do jakiejkolwiek rzeczywistej firmy, organizacji, produktu, nazwy domeny, adresu
poczty elektronicznej, logo, osoby, miejsca lub zdarzenia jest przypadkowe i niezamierzone.
APN PROMISE Sp. z o. o. dołożyła wszelkich starań, aby zapewnić najwyższą jakość tej
publikacji. Jednakże nikomu nie udziela się rękojmi ani gwarancji.
APN PROMISE Sp. z o. o. nie jest w żadnym wypadku odpowiedzialna za jakiekolwiek szkody
będące następstwem korzystania z informacji zawartych w niniejszej publikacji, nawet jeśli
APN PROMISE została powiadomiona o możliwości wystąpienia szkód.
ISBN: 978-83-7541-010-5.
Przekład: Natalia Chounlamany, Andrzej Bańkowski
Redakcja: Stefan Turalski, Marek Włodarz
Korekta: Magdalena Kalina-Swoboda
Skład i łamanie: Marek Włodarz
Spis treści
v
Spis treści
Podziękowania ............................................................................................................................... ix
Przedmowa ................................................................................................................................... xiii
Wstęp ............................................................................................................................................... xv
1 Wprowadzenie........................................................................................................................... 1
Inicjowanie obsługi administracyjnej witryn........................................................................... 1
Witryny i zbiory witryn............................................................................................................ 5
Tworzenie zbioru witryn ......................................................................................................... 9
Dostosowywanie witryn..............................................................................................................12
Strona Ustawienia Witryny ..................................................................................................12
Strona Utwórz ..........................................................................................................................13
Tworzenie list i bibliotek dokumentów.............................................................................14
Dostosowywanie i personalizacja witryn przy użyciu składników Web Part..........15
WSS jako platforma programistyczna ....................................................................................16
Dostosowywanie konta programowanie..........................................................................16
Możliwości rozwoju ................................................................................................................18
Wprowadzenie do funkcji.....................................................................................................20
Programowanie przy użyciu modelu obiektowego WSS ............................................21
Tworzenie pierwszej funkcji.......................................................................................................22
Dodawanie do funkcji procedury obsługi zdarzenia ...................................................27
Podsumowanie ..............................................................................................................................29
2 Architektura SharePoint .....................................................................................................31
Podstawy IIS i ASP.NET 2.0 ........................................................................................................31
Witryny sieci Web usług IIS a katalogi wirtualne ...........................................................31
Rozszerzenia ISAPI i filtry ISAPI ..........................................................................................33
Pule aplikacji a proces roboczy IIS .....................................................................................34
ASP.NET 2.0 Framework ..............................................................................................................36
Strony ASP.NET .......................................................................................................................37
Strony wzorcowe .....................................................................................................................38
Potok Żądań HTTP ..................................................................................................................40
Integracja technologii WSS z ASP.NET....................................................................................42
Aplikacje sieci Web .................................................................................................................43
Katalogi wirtualne z aplikacji sieci Web ...........................................................................48
Strony witryn konta strony aplikacji ..................................................................................49
Tworzenie niestandardowych stron aplikacji ........................................................................51
Wykorzystywanie kodu schowanego na stronach aplikacji ........................................54
Wsparcie nawigacji z poziomu stron aplikacji ................................................................56
Stworzenie strony aplikacji wykorzystującej formant SPGridView ............................57
Zastrzeganie dostępu do stron aplikacji dla administratorów witryn ......................58
Dodanie niestandardowego elementu do menu kontekstowego ...........................59
Podsumowanie ..............................................................................................................................62
vi
Spis treści
3 Strony i projekt ........................................................................................................................63
Podstawowe informacje na temat stron witryn ...................................................................63
Programowanie z użyciem obiektów SPFile ....................................................................64
Praca z szablonami stron ......................................................................................................67
Przetwarzanie w trybie bezpiecznym................................................................................70
Projektowanie stron witryn przy użyciu formantów...........................................................74
Konstruowanie stron z użyciem formantów niestandardowych ................................74
Konstruowanie stron z wykorzystanie formantów użytkownika ...............................76
Projektowanie stron składników Web Part .....................................................................79
Strony wzorcowe ..........................................................................................................................83
Strona wzorcowa default.master ........................................................................................84
Formanty delegowania .........................................................................................................87
Dostosowywanie strony default.master ............................................................................90
Tworzenie niestandardowego szablonu strony wzorcowej.........................................91
Stosowanie znaków firmowych w witrynach WSS przy użyciu plików CSS..................95
Plik core.css ...............................................................................................................................95
Najlepsze praktyki stosowania znaków firmowych ......................................................97
Podsumowanie ..............................................................................................................................98
4 Składniki Web Part ...............................................................................................................99
Składniki Web Part .......................................................................................................................99
Wprowadzenie do składników Web Part ..................................................................... 100
Podstawy formantów sieci Web....................................................................................... 102
Programowanie SharePoint kontra programowanie ASP.NET ............................... 105
Rozwijanie składników Web Part dla WSS 3.0 ............................................................. 106
Tworzenie funkcji do importowania składników Web Part...................................... 109
Debugowanie składników Web Part .............................................................................. 111
Dostosowywanie i personalizacja .................................................................................... 112
Bloki składników Web Part................................................................................................ 121
Czynności składnika Web Part ........................................................................................ 124
Połączenia składników Web Part .................................................................................... 125
Praca ze składnikami Web Part za pośrednictwem modelu witryny SharePoint .. 132
Podsumowanie ........................................................................................................................... 133
5 Składniki Web Part AJAX ............................................................................................... 135
Wprowadzenie ........................................................................................................................... 135
Budowanie bogatych aplikacji internetowych z wykorzystaniem ASP.NET AJAX ... 138
Zorientowany obiektowo kod JavaScript z ASP.NET AJAX ....................................... 139
Tworzenie komponentu JavaScript za pomocą ASP.NET AJAX ............................... 141
Budowanie składników Web Part AJAX dla usług WSS .................................................. 158
Składniki Web Part AJAX ................................................................................................... 159
Wprowadzenie do pakietu SharePoint AJAX Toolkit ................................................. 162
Wprowadzenie do SharePoint.Ajax.XmlComponent.................................................. 164
Budowanie biblioteki składników Web Part AJAX Litware ....................................... 169
Połączenia składników Web Part AJAX po stronie klienta ....................................... 174
Podsumowanie ........................................................................................................................... 176
Spis treści
vii
6 Listy i typy zawartości ...................................................................................................... 177
Listy i typy zawartości .............................................................................................................. 177
Dane z list WSS ..................................................................................................................... 177
Tworzenie niestandardowych elementów list .............................................................. 186
Definiowanie niestandardowych typów pól ................................................................. 192
Definiowanie elementów z wykorzystaniem typów zawartości ............................. 198
Typy zawartości w modelu obiektowym ....................................................................... 202
Definiowanie zawartości z wykorzystaniem schematów list .................................... 206
Tworzenie wystąpienia listy ............................................................................................... 210
Konfigurowanie list z wykorzystaniem źródeł danych RSS ...................................... 210
Odbiorniki zdarzeń ................................................................................................................... 212
Podsumowanie ........................................................................................................................... 218
7 Biblioteki dokumentów .................................................................................................. 219
Praca z bibliotekami dokumentów....................................................................................... 219
Klasa SPDocumentLibrary ................................................................................................ 220
Dodawanie nowego pliku do biblioteki dokumentów.............................................. 223
Biblioteki formularzy oraz Microsoft Office InfoPath ...................................................... 231
Formaty plików Office Open XML ........................................................................................ 235
Zalety formatu pliku Office Open XML ......................................................................... 235
Generowanie pierwszego pliku .docx ............................................................................ 239
Generowanie plików .docx na serwerze ........................................................................ 242
Zapisywanie pliku .docx w bibliotece dokumentów .................................................. 244
Bliższe spotkanie z relacjami............................................................................................. 246
Wiązanie danych z formantami zawartości Word ..................................................... 248
8 Przepływy pracy SharePoint......................................................................................... 255
Windows Workflow Foundation ........................................................................................... 255
Programy reaktywne ........................................................................................................... 255
Architektura Windows Workflow Foundation ............................................................ 258
Tworzenie programów WF ............................................................................................... 261
Środowisko uruchomieniowe WF .................................................................................. 263
Przepływy pracy SharePoint .................................................................................................. 266
Cele projektowe przepływów pracy SharePoint ......................................................... 267
Podstawy przepływów pracy SharePoint....................................................................... 268
Formularze wejściowe przepływów pracy .................................................................... 273
Tworzenie niestandardowych szablonów przepływów pracy ....................................... 274
Tworzenie szablonu przepływu pracy „Hello World”................................................. 276
Tworzenie zadań i oczekiwanie na nie ........................................................................... 288
Integrowanie formularzy wejściowych przepływu pracy ............................................... 295
Instrukcja wykorzystania formularzy wejściowych przepływu pracy
zatwierdzania ................................................................................................................... 297
Niestandardowe formularze skojarzenia....................................................................... 297
Niestandardowe formularze inicjowania....................................................................... 303
Niestandardowe formularze modyfikacji ...................................................................... 306
Implementacja niestandardowego formularza modyfikacji .................................... 307
viii
Spis treści
Niestandardowe formularze edycji zadań .................................................................... 310
Podsumowanie ........................................................................................................................... 313
9 Rozwiązania i instalacja ................................................................................................... 315
Wprowadzenie ........................................................................................................................... 315
Definicje witryn .......................................................................................................................... 315
Globalna definicja witryny................................................................................................. 318
Tworzenie niestandardowej definicji witryny ............................................................... 318
Pliki szablonów sieci Web .................................................................................................. 324
Dodawanie dostawcy obsługi administracyjnej witryny ........................................... 326
Rozmieszczanie aplikacji za pośrednictwem funkcji ........................................................ 328
Zależności aktywacji funkcji .............................................................................................. 328
Zszywanie funkcji ................................................................................................................. 330
Globalizacja i lokalizacja usług WSS ................................................................................... 331
Lokalizacja za pomocą zasobów...................................................................................... 332
Zasoby w plikach SharePoint XML .................................................................................. 335
Rozmieszczanie przy użyciu pakietów rozwiązań ............................................................ 336
Pakiet rozwiązania do instalowania funkcji .................................................................. 337
Pakiet rozwiązania do rozmieszczania składników Web Part .................................. 341
Pakiet rozwiązania do rozmieszczania definicji witryny............................................ 345
Zmiany konfiguracji sieci Web ......................................................................................... 346
Pakiety językowe ....................................................................................................................... 351
Lokalizowanie definicji witryny ........................................................................................ 353
Podsumowanie ........................................................................................................................... 355
10 Zabezpieczanie aplikacji ................................................................................................. 357
Wprowadzenie ........................................................................................................................... 357
Poziomy zaufania a zabezpieczenia dostępu kodu ......................................................... 358
Rozwiązywanie problemów z zabezpieczeniami dostępu kodu ............................. 366
Uwierzytelnianie, autoryzacja i tożsamości ........................................................................ 367
Wykorzystanie uwierzytelniania przy użyciu formularzy .......................................... 368
Kontekst zabezpieczeń WSS kontra kontekst zabezpieczeń Windows................. 369
Użytkownicy i grupy ........................................................................................................... 370
Tożsamości puli aplikacji .................................................................................................... 372
Konto systemowe SharePoint ........................................................................................... 373
Delegowanie danych uwierzytelniających użytkownika ........................................... 377
Personifikacja użytkownika przy użyciu tokenów użytkownika ................................... 378
Zabezpieczanie obiektów w usługach WSS.................................................................. 379
Prawa i poziomy uprawnień ............................................................................................. 381
Obsługa niepowodzeń autoryzacji za pomocą SPUtility .......................................... 384
Podsumowanie ........................................................................................................................... 385
Indeks ......................................................................................................................................... 387
Rozdział 1
Wprowadzenie
■ Poznaj podstawowe zagadnienia i terminy dotyczące usług Windows SharePoint
Services (WSS).
■ Poznaj podstawy inicjowania obsługi administracyjnej witryn.
■ Poznaj możliwości dostosowywania usług WSS do własnych potrzeb.
■ Zbadaj funkcje współpracy wbudowane w usługi WSS.
■ Poznaj możliwości rozwijania i rozszerzania usług WSS.
Inicjowanie obsługi administracyjnej witryn
Jeszcze dziesięć lat temu duża część firm dopiero poznawała sieć WWW i odkrywała możliwość dotarcia do konsumentów za pośrednictwem treści prezentowanej w postaci stron
HTML. Większość firm stworzyła pojedynczą witrynę udostępnianą w Internecie, która
spełniała wszystkie potrzeby związane z reklamowaniem produktów i usług.
Od tamtej pory wiele się zmieniło. W dzisiejszych czasach firmy wykorzystują witryny sieci
Web nie tylko jako metodę dotarcia do klientów, ale również w celu zapewniania dostawcom,
pracownikom i zarządowi dostępu do aplikacji. Nierzadko duże korporacje tworzą setki lub
nawet tysiące witryn sieci Web. Niektóre z nich wymagają na przykład stworzenia nowej witryny
na potrzeby każdej nowej kampanii marketingowej lub nowo zatrudnionego pracownika.
W świecie bez produktów i technologii SharePoint utrzymywanie i zarządzanie nieustannie tworzonymi witrynami sieci Web firmy może być drogie i pracochłonne. Przyjrzyjmy
się na przykład, z czym wiąże się proces tworzenia witryny sieci Web zaprojektowanej
z myślą o śledzeniu źródeł kontaktów i kontrahentów handlowych.
Po pierwsze, proces ten wymaga, aby administrator baz danych stworzył na serwerze
SQL Server lub w innym systemie zarządzania bazą danych nową bazę danych i tabele
konieczne do przechowywania danych handlowych. Następnie, programista musi stworzyć
witrynę ASP.NET wraz ze stronami sieci Web i wymaganym kodem służącym do wyświetlania i edycji tychże danych. Po przygotowaniu witryny ASP.NET do publikacji, administrator
systemu musi skopiować pliki aplikacji ASP.NET na docelowy serwer sieci Web i skonfigurować Internetowe Usługi Informacyjne 6.0 (IIS) poprzez stworzenie nowego katalogu
wirtualnego. Jeśli środowiskiem, w którym ma zostać zainstalowana aplikacja ASP.NET,
jest farma sieci Web, wymagania wzrastają, ponieważ powyższe procedury administracyjne
muszą zostać powielone na wszystkich serwerach frontonu sieci Web w farmie.
Jak łatwo sobie wyobrazić, proces przygotowywania i uruchamiania nowej witryny sieci
Web przy użyciu powyższego rozwiązania może ciągnąć się tygodniami, a nawet miesiącami
– ze względu na konieczność skoordynowania działań administratora baz danych, programisty Web oraz administratora systemu. Usługi WSS zostały zaprojektowane tak, aby zwiększyć
efektywność i przyspieszyć proces tworzenia witryn sieci Web. Programista WSS może tworzyć
komponenty, które są następnie wykorzystywane do tworzenia witryn i obszarów roboczych.
1
2
Microsoft® Windows® SharePoint® Services 3.0 od środka
Jądro usług WSS stanowi silnik służący do tworzenia i obsługi witryn. Architektura
usług WSS została zaprojektowana w szczególności z myślą o środowisku farmy sieci Web.
Dzięki usługom WSS dowolny członek działu IT może zainicjować obsługę administracyjną
witryny (w uproszczeniu stworzyć witrynę) w czasie mniejszym niż jedna minuta, wprowadzając wymagane informacje za pomocą formularza z poziomu przeglądarki. Administrator
baz danych nie musi tworzyć nowej bazy danych ani żadnych tabel. Programista ASP.NET
nie musi tworzyć nowej witryny sieci Web. Administrator systemu nie musi kopiować
żadnych plików ani konfigurować ustawień usług IIS na serwerze frontonu sieci Web.
Silnik WSS do inicjowania obsługi administracyjnej witryn bazuje na zintegrowanym
modelu składowania, który obejmuje wiele baz danych SQL Server służących do przechowywania zawartości i danych konfiguracyjnych. Instalując usługi WSS, można wybrać
opcję wykorzystania serwera SQL Server 2005 lub SQL Server 2000. W przypadku prostych scenariuszy rozwoju i wdrożenia można wykorzystać również serwer SQL Express,
co eliminuje konieczność wykupienia licencji na oprogramowanie SQL Server.
Microsoft Office SharePoint Server 2007
Istotne jest zrozumienie różnicy pomiędzy usługami Windows SharePoint Services
(WSS) a programem Microsoft Office SharePoint Server 2007 (MOSS). Zarówno WSS,
jak i MOSS stanowią fragmenty oprogramowania stworzone przez zespół Microsoft
Office. Jednak usługi WSS stanowią element systemu operacyjnego Windows Server
2003, natomiast MOSS to osobny produkt ze swoją własną licencją SKU. Usługi
WSS należy postrzegać jako platformę wewnętrzną, a MOSS jako dodatkowy zestaw
komponentów i usług, które wzbogacają tę platformę.
Usługi WSS nie zawierają własnego modelu licencjonowania, ich wykorzystanie
obejmuje licencja systemu Windows Server 2003. To sprawia, że zastosowanie aplikacji zaprojektowanych i zbudowanych w oparciu o platformę WSS może być dla
firm bardzo opłacalne. Natomiast program MOSS ma swój własny model licencjonowania, który obejmuje licencje po stronie serwera i licencje dostępowe (CAL). Model
licencjonowania MOSS jest dodatkowo podzielony na edycję Standard i Enterprise.
Każde wdrożenie WSS opiera się na koncepcji farmy. Farma stanowi w uproszczeniu zbiór
jednego lub więcej komputerów współpracujących ze sobą w celu dostarczenia funkcjonalności WSS do klientów. W najprostszym scenariuszu wdrożenia farma WSS składa się z pojedynczego serwera, który pełni rolę zarówno serwera frontonu sieci Web, jak i serwera baz
danych SQL Server. Bardziej skompilowana farma WSS składać się może z kilku serwerów
frontonu sieci Web i dedykowanego serwera baz danych, jak pokazano na Rysunku 1-1.
Każda farma WSS obejmuje jedną bazę danych SQL Server zwaną bazą danych konfiguracji. Baza danych konfiguracji śledzi ważne informacje dotyczące całej farmy. Na przykład
informacje, które serwery frontonu sieci Web są powiązane z farmą oraz którym użytkownikom nadane zostały uprawnienia administratora usług WSS na poziomie farmy.
Rozdział 1: Wprowadzenie
3
Serwer sieci Web 1
Router
http://www.litwareinc.com
Serwer sieci Web 2
Serwer
bazy danych
Serwer sieci Web 3
Rysunek 1-1
Farma WSS dostarcza aplikacje sieci Web.
Usługi WSS są zbudowane w oparciu o platformę Internetowych Usług Informacyjnych
6.0 (IIS). A w szczególności powierzają witrynom sieci Web obsługę przychodzących żądań
HTTP. W związku z tym trzeba zrozumieć, czym tak naprawdę jest witryna sieci Web usług
IIS. Witryna sieci Web usług IIS stanowi punkt wejścia w infrastrukturze serwera IIS. Na
przykład, Domyślna Witryna Sieci Web tworzona automatycznie przez serwer IIS nasłuchuje przychodzących żądań HTTP na porcie 80. Można tworzyć kolejne witryny sieci Web
usług IIS, aby zapewnić dodatkowe punkty wejścia wykorzystujące inne numery portów,
inne adresy IP lub inne nagłówki hosta.
Istotną cechą charakterystyczną witryn sieci Web usług IIS jest to, że ich ustawienia
zabezpieczeń są konfigurowane niezależnie od pozostałych witryn sieci Web usług IIS. Na
przykład można skonfigurować Domyślną Witrynę Sieci Web jako upublicznioną witrynę,
która dopuszcza wykorzystanie uwierzytelniania podstawowego i zezwala na anonimowy
dostęp i równocześnie stworzyć drugą witrynę sieci Web wykorzystywaną w obrębie korporacyjnej sieci LAN na innym porcie np. 1000. Po stworzeniu na serwerze IIS witryny
intranetowej można skonfigurować ją tak, aby wymagała ona zintegrowanego uwierzytelniania systemu Windows i nie zezwalała na dostęp anonimowy.
Jeśli witryna sieci Web usług IIS ma być wykorzystywana do obsługi witryn WSS, musi
zostać specjalnie skonfigurowana. Z omówieniem technicznych szczegółów tej konfiguracji
wstrzymamy się do kolejnego rozdziału. Teraz chcemy wprowadzić jedynie pewne najistotniejsze pojęcia i terminy.
Witryna sieci Web usług IIS, która została skonfigurowana specjalnie z myślą o uruchamianiu witryn WSS, nazywana jest aplikacją sieci Web. Każda witryna WSS działa w kontekście określonej aplikacji sieci Web. Jest to istotne, ponieważ aplikacja sieci Web pełniąca
rolę hosta dla witryny WSS odpowiada za pewne ważne aspekty środowiska WSS m.in.
konfigurację zabezpieczeń uwierzytelniania użytkowników.
Proces instalacji usług WSS obejmuje stworzenie i konfigurację aplikacji sieci Web
o nazwie Administracja centralna programu SharePoint 3.0. Aplikacja Administracja Centralna
Programu SharePoint 3.0 dostarcza strony, które pozwalają na realizowanie podstawowych
zadań administratorskich, takich jak konwertowanie standardowej witryny sieci Web usług
4
IIS na aplikację sieci Web usług WSS. Administracja Centralna Programu SharePoint umożliwia również stworzenie nowej witryny sieci Web usług IIS i zapewnia jej automatyczną
konfigurację na potrzeby aplikacji sieci Web usług WSS, bez konieczności bezpośredniego
wykorzystywania żadnego z narzędzi administracyjnych usług IIS.
Aplikacje sieci Web kontra Serwery wirtualne
W ostatniej wersji usług WSS zespół ds. produktu wykorzystywał termin serwer
wirtualny (ang. virtual server) do opisania witryny sieci Web usług IIS, która została
wzbogacona o funkcjonalność WSS. W aktualnej wersji usług WSS i jej dokumentacji pomocniczej termin serwer wirtualny został zastąpiony terminem aplikacja sieci
Web – głównie po to, aby uniknąć nieprawidłowych skojarzeń z innym produktem firmy Microsoft o tej samej nazwie. Jednak programiści WSS powinni pamiętać,
że nowy termin aplikacja sieci Web oraz poprzedni termin serwer wirtualny mogą
być często używane zamiennie. Na przykład model obiektowy WSS zawiera klasę
SPVirtualServer służącą do programowania obiektów aplikacji sieci Web.
W typowej farmie WSS istnieje zazwyczaj kilka różnych aplikacji sieci Web. Administracja
Centralna Programu SharePoint jest konfigurowana podczas instalacji jako osobna aplikacja
sieci Web wykorzystywana przez usługi WSS. Potrzebna jest jedna lub więcej innych aplikacji sieci Web do tworzenia i zarządzania witrynami, które będą dostępne dla użytkowników
końcowych. Można, na przykład, skonfigurować Domyślną Witrynę Sieci Web jako aplikację
sieci Web usług WSS, tak aby witryny WSS były udostępnianie za pośrednictwem standardowego portu 80 protokołu HTTP. Można również stworzyć w farmie dodatkowe aplikacje
sieci Web, jak np. intranetową aplikację sieci Web na porcie 1000. Dane konfiguracyjne
usług WSS dla całej farmy są przechowywane w bazie danych konfiguracji, a dane powiązane z witrynami WSS są umieszczane w innego typu bazie danych, zwanej bazą danych
zawartości. Podczas tworzenia nowej aplikacji sieci Web za pośrednictwem Administracji
Centralnej Programu SharePoint 3.0, usługi WSS tworzą nową bazę danych zawartości.
W prostym modelu wdrażania farma zawiera tylko jedną bazę danych zawartości dla każdej
aplikacji sieci Web, jak pokazano na Rysunku 1-2. W scenariuszach wymagających wyższego poziomu zabezpieczeń lub bardziej szczegółowego planowania składowania można
wykorzystywać bardziej zaawansowane procedury administracyjne w celu umieszczenia
witryn znajdujących się w aplikacji sieci Web w wielu bazach danych zawartości.
5
Żądanie do aplikacji sieci Web #1
http://www.litwareinc.com
http://www.litwareinc.com/sites/Vendors
Baza danych
zawartości #1
http://www.litwareinc.com:1000/sites/Sales
http://www.litwareinc.com:1000/sites/Accounting
Rysunek 1-2
Baza danych
zawartości #2
Farma WSS dostarcza aplikacje sieci Web przechowujące
dane w bazach danych zawartości.
Wskazówka Tworzone przez programistów oprogramowanie dla usług WSS nie może uzyskiwać bezpośredniego dostępu do bazy danych konfiguracji ani baz danych zawartości. Dlatego
trzeba oprzeć się pokusie napisania na przykład kodu ADO.NET, który odczytuje lub zapisuje
dane w tabelach wewnątrz tych baz danych. Zamiast tego należy wykorzystać w kodzie interfejsy
programistyczne API usług WSS. Dzięki temu usługi WSS uruchomią kod systemowy, który będzie
pośredniczył w uzyskaniu dostępu do bazy danych konfiguracji i/lub bazy danych zawartości.
Witryny i zbiory witryn
Warto zatrzymać się na chwilę, aby doprecyzować termin witryna WSS, który wykorzystywany był w przedstawionym do tej pory omówieniu. Po pierwsze, witryna WSS to pojemnik
do przechowywania zawartości. Zawartość witryny jest przechowywana głównie w postaci
list, bibliotek dokumentów i witryn podrzędnych. Po drugie, witryna stanowi jednostkę
zabezpieczeń, której zawartość jest dostępna dla konfigurowalnego zbioru użytkowników.
Witryna może definiować swój własny zbiór użytkowników lub dziedziczyć ustawienia
z witryny nadrzędnej. Witryna może także zawierać konfigurowalny zestaw grup i uprawnień, które definiują poziom dostępności poszczególnych użytkowników dla list i bibliotek
dokumentów znajdujących się w witrynie.
Należy zauważyć, że usługi WSS w rzeczywistości nie dokonują uwierzytelniania użytkowników, pozostawiają to serwerowi IIS i infrastrukturze dostawcy uwierzytelniania ASP.
NET. Jednak przejmują przywództwo, gdy do głosu dochodzi autoryzacja. Usługi WSS
dostarczają elementy interfejsu użytkownika oraz kod pomocniczy umożliwiający uprzywilejowanym użytkownikom konfigurowanie autoryzacji w odniesieniu do różnych elementów witryn. Usługi WSS 3.0 wprowadzają także mechanizmy stosowania zabezpieczeń,
które sprawiają, że polecenia i łącza do elementów witryny są pokazywane wyłącznie użytkownikom, którzy mają do nich autoryzowany dostęp.
6
Po trzecie, witryna stanowi aplikację z rozszerzalnym, w pełni dostosowywalnym interfejsem użytkownika. Administrator witryny może tworzyć strony i dostosowywać ich
układ oraz wygląd. Administrator witryny może także modyfikować strukturę nawigacyjną
witryny przy użyciu przeglądarki.
Witryna stanowi fundament dla wykorzystania technologii stron i składników Web Part
firmy Microsoft. Administratorzy witryn mogą dostosowywać strony składników Web Part,
dodając i konfigurując poszczególne składniki. Użytkownik może personalizować stronę
składników Web Part, modyfikując, dodając i/lub usuwając składniki Web Part. Wszystkie
dane dostosowań i personalizacji powiązane ze składnikami Web Part na stronie składników Web Part są automatycznie składowane w bazie danych zawartości.
Dla każdej witryny WSS musi zostać zainicjowana obsługa administracyjna w zakresie istniejącej aplikacji sieci Web. Jednak witryna nie może istnieć jako niezależna jednostka w aplikacji sieci Web, każda witryna WSS musi być stworzona w zakresie zbioru witryn. Zbiór witryn
stanowi pojemnik dla witryn WSS. Każdy zbiór witryn wymaga obecności witryny najwyższego poziomu. Poza wymaganą witryną najwyższego poziomu zbiór witryn może zawierać
hierarchię witryn podrzędnych. Na Rysunku 1-3 zaprezentowane zostały różne, dozwolone
zbiory witryn. Pierwszy zbiór witryn zawiera jedynie witrynę najwyższego poziomu. Drugi
zbiór witryn zawiera jeden poziom witryn podrzędnych pod witryną najwyższego poziomu.
Trzeci zbiór witryn zawiera bardziej złożoną hierarchię witryn podrzędnych.
Aplikacja sieci Web
http://www.litwareinc.com:1000
Zbiór witryn
/sites/Operations
Zbiór witryn
/sites/Sales
Zbiór witryn
/sites/Accounting
Witryna
najwyższego
poziomu
Witryna
najwyższego
poziomu
Witryna
najwyższego
poziomu
Witryna
podrzędna
/East
Witryna
podrzędna
/West
Witryna
podrzędna
/Reports
Witryna
podrzędna
/2006_Q1
Rysunek 1-3
Witryna
podrzędna
/IRS_Forms
Witryna
podrzędna
/2006_Q2
Witryny znajdują się w zbiorze witryn. Każdy zbiór witryn musi zawierać
witrynę najwyższego poziomu i może zawierać hierarchię witryn podrzędnych.
Jedną z pierwszych wątpliwości, które pojawiają się, gdy firma rozpoczyna wykorzystywanie technologii WSS lub MOSS, jest sposób rozmieszczenia witryn w zbiorach witryn. Czy
należy na przykład stworzyć jeden duży zbiór witryn z wieloma witrynami podrzędnymi,
czy może lepiej stworzyć osobne zbiory witryn? Aby podjąć najtrafniejszą decyzję, należy
rozważyć wszystkie związane z nią kwestie, które zostaną omówione w kilku kolejnych
7
akapitach. Trzeba zrozumieć wpływ rozmieszczenia witryn w zbiorach witryn na zakres
przywilejów administracyjnych, granice zabezpieczeń, operacje tworzenia i przywracania
kopii zapasowych oraz projekt witryny.
Być może niektórzy czytelnicy zadają sobie pytanie, dlaczego architektura WSS wymaga
istnienia specjalnego pojemnika do przechowywania witryn. Przede wszystkim zbiory
witryn reprezentują zakres przywilejów administracyjnych. Użytkownik, któremu przypisana została rola administratora zbioru witryn, ma pełne administracyjne uprawnienia we
wszystkich witrynach istniejących i tworzonych w przyszłości w tym zbiorze witryn.
Łatwo sobie wyobrazić ciężar zarządzania witrynami w dużej korporacji, która obsługuje
tysiące witryn rocznie. Obowiązek administrowania tymi wszystkimi stronami w rozsądnym czasie przekracza możliwości większości działów IT. Koncepcja zbioru witryn jest tak
ważna, ponieważ umożliwia działowi IT przeniesienie tego obciążenia na działy biznesowe
stanowiące właścicieli poszczególnych witryn.
Weźmy pod uwagę następujący przykład. W wielu firmach wykorzystujących usługi
WSS w dziale IT istnieje osoba odpowiedzialna za obsługę zbiorów witryn na żądanie jednego z działów biznesowych. W procesie tworzenia dział IT przypisuje jednemu lub kilku
użytkownikom z działu biznesowego uprawnienia administratorskie na poziomie nowego
zbioru witryn. Od tego momentu użytkownicy-administratorzy z działu biznesowego mogą
dodawać użytkowników oraz tworzyć elementy witryny, takie jak listy czy biblioteki dokumentów bez jakiejkolwiek pomocy działu IT. Mogą także dodawać witryny podrzędne do
witryny najwyższego poziomu. To umożliwia im rozbudowywanie hierarchii witryn podrzędnych i konfigurowanie zabezpieczeń w sposób odpowiadający ich potrzebom.
Klucz deszyfrujący WSS
Programiści, którzy rozpoczynają pracę z usługami WSS, często czują się nieco zdezorientowani w związku z inną terminologią wykorzystywaną w usługach WSS oraz
w ich prekursorze – usługach SharePoint Team Services (STS) w wersji 1.0. Na przykład występujący w usługach WSS termin zbiór witryn (ang. site collection) stanowi
odpowiednik znanego z STS terminu witryna (ang. site). Nowy termin WSS witryna
(ang. site) stanowi odpowiednik starego terminu STS sieć Web (ang. Web). Nowy termin WSS witryna najwyższego poziomu (ang. top-level site) stanowi odpowiednik starego terminu STS główna sieć Web (ang. root Web).
Chociaż zespół WSS konsekwentnie wykorzystywał nową terminologię WSS
w dokumentacji produktu, nadal istnieje sporo wystąpień terminu sieć Web zamiast
oczekiwanego terminu witryna oraz terminu witryna zamiast oczekiwanego terminu
zbiór witryn.
Na starej terminologii STS bazują na przykład nazwy klas w modelu obiektowym
WSS. W efekcie programując zbiór witryn, wykorzystuje się obiekt SPSite, a programując witrynę obiekt SPWeb. Obiekt SPSite zawiera publiczną właściwość o nazwie
RootWeb, która zwraca obiekt SPWeb reprezentujący witrynę najwyższego poziomu
w zbiorze witryn. Gdy już rozpozna się potencjalne źródło rozbieżności, opanowanie
różnych aspektów usług WSS staje się łatwiejsze.
8
Drugim argumentem przemawiającym za wykorzystywaniem zbiorów witryn jest to, że
stanowią one zakres dla członkostw i uwierzytelnień. Z założenia każdy zbiór witryn jest
niezależny od innych zbiorów witryn pod względem zdefiniowanych grup zabezpieczeń,
użytkowników dodanych w roli członków oraz autoryzacji wybranych użytkowników do
wybranych operacji.
Wyobraźmy sobie na przykład, że dział IT w firmie Litware posiada jeden zbiór witryn
dla działu Sprzedaży i jeden dla działu Księgowości. Mimo iż użytkownicy w dziale
Księgowości mają uprawnienia administratorskie w swoim zbiorze witryn, nie mogą oni
w żaden sposób wpływać na konfigurację zabezpieczeń zbioru witryn Sprzedaży. Jest tak,
ponieważ architektura WSS widzi każdy zbiór witryn jako jednostkę niezależną pod względem konfiguracji zabezpieczeń.
Trzecim powodem wykorzystania zbiorów witryn jest to, że zapewniają one wygodny
zakres dla operacji wykonywania i przywracania kopii zapasowych. Można wykonać kopię
zapasową zbioru witryn i w późniejszym czasie przywrócić ją z zachowaniem pełnej wierności. Przywracanie zbioru witryn może odbywać się w tej samej lokalizacji, w której
wykonana została kopia zapasowa. Ewentualnie zbiór witryn może zostać przywrócony
w innej lokalizacji, a nawet na innej farmie. Technika wykonywania kopii zapasowej zbioru
witryn i przywracania jej w innej lokalizacji stanowi wsparcie dla strategii przenoszenia
witryn WSS ze środowiska programistycznego do środowiska publikującego, a następnie
do środowiska produkcyjnego.
Narzędzie wiersza polecenia STSADM.EXE
Usługi WSS są dostarczane wraz z przydatnym narzędziem wiersza poleceń o nazwie
STSADM.EXE. To narzędzie umożliwia wydawanie komend z poziomu wiersza poleceń systemu Windows i tworzenie plików wsadowych realizujących zadania administracyjne, takie jak tworzenie zbiorów witryn oraz wykonywanie i przywracanie
ich kopii zapasowych. Po uruchomieniu narzędzia z wiersza polecenia lub pliku
wsadowego należy przekazać parametr –o wraz z jedną ze wspieranych operacji. Oto
przykład instrukcji wiersza polecenia służącej do stworzenia nowego zbioru witryn
pod określonym adresem URL.
STSADM.EXE -o CreateSite -url http://localhost/sites/Sales
-ownerlogin LitwareServer\BrianC
-owneremail [email protected]
-sitetemplate STS#0
W zaprezentowanym przykładzie w celu poprawienia czytelności wprowadzone
zostały załamania linii między parametrami. Jednak w rzeczywistości uruchamiając
narzędzie STSADM z wiersza polecenia lub pliku wsadowego, nie można wykorzystywać znaków końca linii.
Należy pamiętać, że instalacja usług WSS powoduje dodanie narzędzia STSADM.
EXE do katalogu systemowego WSS wewnątrz katalogu Windows Program Files. Aby
móc wywoływać to narzędzie bezpośrednio z wiersza polecenia na stacji roboczej,
należy dodać następującą ścieżkę do zmiennej systemowej Path.
c:\program files\common files\microsoft shared\web server extensions\12\bin\
9
Pisząc plik wsadowy, należy również przyjąć założenie, że może być on uruchamiany
na maszynie, na której nie zostały odpowiednio skonfigurowane zmienne środowiskowe. Z tego względu należy pisać pliki wsadowe, które w sposób jawny określają
lokalizację narzędzia STSADM.EXE.
@SET STSADM="c:\program files\common files\microsoft shared\
web server extensions\12\bin\stsadm"
%STSADM% -o CreateSite -url http://localhost/sites/Sales
-ownerlogin LitwareServer\BrianC
-owneremail [email protected]
-sitetemplate STS#0
Kolejny raz dla poprawy czytelności wprowadzone zostały załamania linii. Tworząc
rzeczywisty plik wsadowy, należy je usunąć.
Ostatnim aspektem, który warto wziąć pod uwagę, rozważając wykorzystanie zbiorów
witryn, jest to, że stanowią one zakres dla różnego typu elementów witryny i niestandardowych kwerend. Na przykład model obiektowy WSS pozwala na uruchamianie kwerend, które obejmują wszystkie listy w zbiorze witryn. Jednak ten wygodny mechanizm
wykorzystywania kwerend nie może obejmować zakresem wielu różnych zbiorów witryn.
Dlatego jeśli projekt aplikacji zakłada potrzebę wywoływania kwerend agregujących dane
pochodzące z list znajdujących się w różnych witrynach, jest to argument przemawiający
za umieszczeniem tych witryn w roli witryn podrzędnych w tym samym zbiorze witryn.
Użytkownicy mogą również tworzyć różnego typu niestandardowe elementy witryny
służące do wielokrotnego wykorzystania we wszystkich stronach w zbiorze witryn.
Przykładowo, gdy stworzymy kolumnę witryny w witrynie najwyższego poziomu, kolumna
ta będzie mogła zostać wykorzystana we wszystkich jej witrynach podrzędnych. Dzięki
temu po jednokrotnym zdefiniowaniu cech charakterystycznych kolumny, takich jak formatowanie, sprawdzanie poprawności lub lista wyboru, taki typ kolumny może być wielokrotnie wykorzystywany przez wiele list w zbiorze witryn. Następnie wystarczy uaktualnić
kolumnę witryny, aby modyfikacja ta wpłynęła na wszystkie listy, w których kolumna ta
została zastosowana. Kolumny witryny zostały wykorzystane po raz pierwszy w wersji
WSS 3.0 i zostaną omówione w sposób bardziej szczegółowy w Rozdziale 6 „Listy i typy
zawartości”.
Tworzenie zbioru witryn
Nie można w pełni docenić prostoty usług WSS, dopóki nie stworzy się swojego pierwszego zbioru witryn. Teraz krok po kroku omówimy czynności zmierzające do tego celu.
Czytelnik będzie pełnił rolę administratora farmy SharePoint, dlatego niezbędne są odpowiednie uprawnienia.
■
W menu Start systemu Windows należy zlokalizować grupę Narzędzia Administracyjne,
a następnie kliknąć opcję menu Administracja Centralna Programu SharePoint 3.0, aby
10
■
■
■
uruchomić aplikację Administracja Centralna Programu SharePoint. W kilku kolejnych
krokach procedury aplikacja ta będzie wykorzystywana do tworzenia nowej witryny.
W górnej części strony głównej aplikacji Administracja Centralna znajdują się trzy
karty: Strona Główna, Operacje oraz Zarządzanie Aplikacjami. Należy wybrać kartę
Zarządzanie Aplikacjami.
Na stronie Zarządzanie Aplikacjami należy zlokalizować i kliknąć łącze zatytułowane
Tworzenie Zbioru Witryn w sekcji Zarządzanie Witrynami Programu SharePoint. Dzięki
temu zostaniemy przeniesieni do strony, na której można wpisać szczegółowe informacje, jakich usług WSS wymagają w celu stworzenia nowego zbioru witryn.
Spójrzmy na Rysunek 1-4, który prezentuje górną część strony Tworzenie Zbioru Witryn.
Rysunek ten ilustruje przykład wypełnienia pól Tytuł, Opis, Adres URL w procesie tworzenia nowego zbioru witryn.
Rysunek 1-4 Podczas tworzenia nowego zbioru witryn trzeba określić nazwę,
docelowy adres URL oraz informacje o koncie użytkownika
dla jednego lub dwóch administratorów zbioru witryn.
■
Rysunek 1-5 prezentuje dolną część strony Tworzenie Zbioru Witryn. Jak widać, strona
ta umożliwia użytkownikowi wybranie szablonu witryny, który ma zostać wykorzystany
do stworzenia witryny najwyższego poziomu. Można wybrać jeden z kilku różnych
szablonów, takich jak np. Witryna Zespołu czy Pusta Witryna. W tym przykładzie należy
wybrać szablon Pusta Witryna.
11
Rysunek 1-5 Usługi WSS umożliwiają wybranie szablonu witryny
dla witryny najwyższego poziomu.
■
Po wprowadzeniu wszystkich wymaganych informacji, można kliknąć przycisk OK, aby
rozpocząć proces tworzenia. Usługi WSS stworzą nowy zbiór witryn zawierający witrynę
najwyższego poziomu. Witryna najwyższego poziomu zostanie wygenerowana przy użyciu wybranego szablonu witryny. Po pomyślnym zakończeniu procesu tworzenia usługi
WSS wyświetlą stronę zaprezentowaną na Rysunku 1-6.
Rysunek 1-6 Usługi WSS wyświetlają komunikat o pomyślnym
utworzeniu nowego zbioru witryn.
■
Nowy zbiór witryn WSS zawierający witrynę najwyższego poziomu wygenerowaną na
podstawie szablonu witryny Pusta Witryna został pomyślnie utworzony. Teraz wystarczy
kliknąć łącze np. http://<nazwa_serwera>/sites/Sprzedaz, aby przejść do strony głównej
tej witryny najwyższego poziomu, jak pokazano na Rysunku 1-7. Witryna nie zawiera
jeszcze żadnych list, ponieważ została utworzona na podstawie szablonu Pusta Witryna.
Jednak można z łatwością dodać do niej nowe listy i biblioteki dokumentów.
12
Rysunek 1-7
Nowa witryna utworzona na podstawie szablonu Pusta Witryna
Dostosowywanie witryn
Po stworzeniu pierwszego zbioru witryn musimy zadecydować, w jaki sposób chcemy go
skonfigurować i dostosować witrynę najwyższego poziomu. Usługi WSS dostarczają wiele
opcji konfigurowania i dostosowywania witryn. Rozpoczniemy od zbadania różnych opcji
dostępnych dla użytkowników, którym przypisane zostały uprawnienia administratora na
poziomie zbioru witryn.
W prawym górnym rogu strony znajduje się menu Akcje Witryny. Zawiera ono polecenia,
które umożliwiają tworzenie nowych elementów witryny, dostosowywanie aktualnej strony
oraz nawigację do strony Ustawienia Witryny. Warto zauważyć, że to menu wspiera stosowanie zabezpieczeń. Oznacza to, że osoba o uprawnieniu administratora zobaczy wszystkie
polecenia menu Akcje Witryny, podczas gdy mniej uprzywilejowany użytkownik zobaczy
jedynie ograniczony zestaw poleceń. Odwiedzający tę stronę użytkownicy, którzy mają
dostęp uprawniający wyłącznie do odczytu, w ogóle nie zobaczą menu Akcje Witryny.
Strona Ustawienia Witryny
Strona Ustawienia Witryny zawiera łącza do stron, które umożliwiają wykonywanie różnych zadań administracyjnych i dostosowujących. Standardowa strona Ustawienia Witryny
dla witryny najwyższego poziomu została zaprezentowana na Rysunku 1-8.
Czytelnikom, którzy nie mieli wcześniej styczności z usługami WSS, zaleca się zapoznanie ze wszystkimi stronami administracyjnymi dostępnymi za pośrednictwem strony
Ustawienia Witryny. Warto zauważyć, że strona Ustawienia Witryny dla witryny najwyższego poziomu zawiera sekcję Administracja witryną oraz dodatkową sekcję Administracja
zbioru witryn, której nie zawierają strony Ustawienia Witryny dla witryn podrzędnych.
Rysunek 1-8
13
Każda witryna zawiera stronę Ustawienia Witryny, która
udostępnia różne opcje konfiguracyjne i dostosowujące.
Jak widać, istnieje także sekcja Użytkownicy i Uprawnienia służąca do konfiguracji zabezpieczeń oraz sekcja Wygląd i Działanie służąca do modyfikowania wyglądu interfejsu użytkownika oraz opcji nawigacji. Istnieje również sekcja Galerie, która pozwala na przeglądanie i konfigurowanie różnych elementów aktualnej witryny, takich jak strony wzorcowe,
kolumny witryny i typy zawartości. Wszystkie te galerie zostaną szczegółowo omówione
w kilku kolejnych rozdziałach.
Strona Utwórz
Menu Akcje Witryny zawiera polecenie Utwórz, które prowadzi do strony Utwórz zaprezentowanej na Rysunku 1-9. Funkcjonalność, którą gwarantuje użytkownikom strona
Utwórz, stanowi jeden z aspektów WSS o największych możliwościach. A to dlatego, że
strona Utwórz umożliwia użytkownikom dostosowywanie aktualnej witryny poprzez tworzenie na żądanie nowych elementów witryny, takich jak listy, biblioteki dokumentów,
strony składników Web Part oraz witryny podrzędne.
Strona Utwórz, zaprezentowana na Rysunku 1-9, zawiera łącza dla standardowych
typów elementów, które są domyślnie dostępne w środowisku WSS. Te standardowe typy
elementów zostały zaprojektowane tak, aby ułatwiać współpracę na poziomie zespołu.
Zaliczają się do nich typy listowe służące do współpracowania przy użyciu elementów list
m.in. anonsów, kontaktów, łącz, zdarzeń kalendarzowych, zadań i śledzenia problemów.
Standardowe funkcje współpracy w WSS zapewniają również wsparcie dla tworzenia różnego typu bibliotek dokumentów. Poza standardowymi typami bibliotek dokumentów istnieją
również bardziej specjalistyczne typy, takie jak biblioteka obrazów czy stron typu wiki.
14
Rysunek 1-9
Strona Utwórz umożliwia użytkownikom tworzenie
na żądanie nowych elementów witryny.
Strona Utwórz jest interesująca nie tylko z punktu widzenia użytkowników z uprawnieniami
administratora, ale i programistów. Wyświetlany na stronie Utwórz zestaw typów elementów, które mogą zostać utworzone, może być swobodnie rozszerzany. W niniejszej książce
zaprezentowanych zostanie wiele różnych technik dodawania niestandardowych typów
elementów, np. własnych typów list i bibliotek dokumentów, zaprojektowanych z myślą
o konkretnym zastosowaniu biznesowym. Dodatkową zaletą jest to, że niestandardowe typy
elementów pojawiają się obok standardowych typów elementów WSS. Dzięki temu użytkownicy mogą w spójny sposób wzbogacać swoje witryny o różne, nowe elementy.
Tworzenie list i bibliotek dokumentów
Usługi WSS znacznie ułatwiają użytkownikom z odpowiednimi uprawnieniami dostosowywanie witryn poprzez tworzenie list i bibliotek dokumentów. Użytkownik po prostu klika
łącze dla określonego typu listy na stronie Utwórz, a następnie zostaje przeniesiony na inną
stronę i monitowany o nazwę oraz opis tworzonej listy. Należy mieć na uwadze, że nazwy
list i bibliotek dokumentów w witrynie muszą być unikalne.
Po stworzeniu lista lub biblioteka dokumentów jest gotowa do użycia. Każda lista
i biblioteka dokumentów oferuje zestaw stron, które umożliwiają użytkownikom dodawanie, wyświetlanie i usuwanie elementów oraz dokumentów. Aby móc aktywnie śledzić
zagadnienia omawiane w kolejnej sekcji, należy teraz stworzyć w nowej, pustej witrynie
przynajmniej jedną listę.
Dostosowywanie list przy użyciu polecenia Ustawienia Listy
Usługi WSS są bardzo elastyczne i pozwalają użytkownikom dostosowywać wiele aspektów
istniejących list oraz bibliotek dokumentów. Każda lista zawiera pasek narzędziowy z menu
Ustawienia. Menu Ustawienia zawiera polecenie Ustawienia Listy, które powoduje przeniesienie użytkownika do specjalnej strony, zaprezentowanej na Rysunku 1-10. Wyświetlana strona
zawiera tytuł, który składa się z wyrażenia Dostosowywanie listy oraz nazwy określonej listy. Na
przykład tytuł wygenerowany dla ustawień listy Anonsy brzmi Dostosowywanie listy Anonsy.
Rysunek 1-10
15
Polecenie Ustawienia Listy powoduje wyświetlenie strony
umożliwiającej użytkownikom dostosowywanie listy.
Polecenie Ustawienia Listy umożliwia użytkownikom dostosowywanie właściwości listy,
takich jak nazwa oraz wyświetlanie listy w postaci łącza w pasku Szybkie Uruchamianie.
Przy użyciu tej strony ustawień użytkownik może skonfigurować inne, istotne aspekty
dotyczące listy m.in. ustawień zabezpieczeń i przechowywania wersji. Strona Ustawienia
Listy zwiększa również elastyczność dostosowywania list lub bibliotek dokumentów, dzięki
możliwości dodawania, usuwania i modyfikowania kolumn i widoków.
Dostosowywanie i personalizacja witryn
przy użyciu składników Web Part
Wsparcie dla technologii Web Part stanowi jeden z aspektów usług WSS stwarzających największe możliwości. Strona składników Web Part wzbogaca witrynę o bazujący na języku
HTML, rozszerzalny interfejs użytkownika.
Zatrzymajmy się na chwilę i przyjrzyjmy się stronie składników Web Part z perspektywy
osoby wykorzystującej technologię Web Part. Na stronie głównej administrator witryny
może wybrać z menu Akcje Witryny polecenie Edytuj Stronę, aby wejść w tryb edytowania, w którym można dodawać, modyfikować i usuwać składniki Web Part. Modyfikacje
składników Web Part dokonane w tym trybie nazywane są dostosowaniami, ponieważ są
widoczne dla wszystkich użytkowników witryny.
Ponadto usługi WSS zapewniają użytkownikom o mniejszych uprawnieniach możliwość personalizowania stron składników Web Part poprzez dodawanie i modyfikowanie
składników Web Part. Należy mieć na uwadze, że wykorzystywane w technologii WSS
terminy dostosowywanie i personalizacja mają inne znaczenia. Dostosowywanie niesie za
sobą zmiany widoczne dla wszystkich użytkowników. Natomiast w przypadku personalizacji modyfikacje są widoczne tylko dla użytkownika, który ich dokonana. Usługi WSS
16
potrafią w sposób inteligentny przechowywać wspólne dane dostosowań i prywatne dane
personalizacji osobno w bazie danych zawartości. W kodzie mechanizm ten będzie nazywany składowaniem wspólnym (ang. shared storage) oraz składowaniem osobistym (ang.
personal storage). Układ strony składników Web Part tworzą strefy składników Web Part.
Składnik Web Part jest dodawany do strony składników Web Part poprzez umieszczenie go
w strefie składników Web Part. Usługi WSS umożliwiają użytkownikom tworzenie nowych
stron składników Web Part przy użyciu wbudowanego zestawu szablonów. W przeglądarce
można użyć jednego z tych szablonów stron składników Web Part do stworzenia nowej
strony o predefiniowanym układzie stref. Gdy użytkownik za pośrednictwem przeglądarki
tworzy nową stronę składników Web Part, wynikowa strona składników Web Part musi
być tworzona w kontekście biblioteki dokumentów.
WSS jako platforma programistyczna
W pewnym sensie usługi WSS działają na niekorzyść profesjonalnych twórców oprogramowania, ponieważ umożliwiają użytkownikom samodzielne tworzenie i dostosowywanie
witryn. W ciągu zaledwie kilkunastu minut użytkownik może stworzyć witrynę WSS,
dodać kilka list i bibliotek dokumentów czy dostosować wygląd witryny tak, aby odpowiadał on wymogom określonej sytuacji biznesowej. Stworzenie identycznego rozwiązania za
pomocą technologii ASP.NET zajęłoby programistom kilka tygodni a nawet miesięcy.
Jednak patrząc z innej strony, usługi WSS otwierają przed profesjonalnymi programistami nowe, atrakcyjne możliwości. Podobnie jak każda inna struktura (ang. framework),
domyślna funkcjonalność usług WSS wystarcza tylko do pewnego momentu. Później zwykle okazuje się, że konieczne jest stworzenie niestandardowych typów list i napisanie kodu
dla niestandardowych składników WSS, takich jak składniki Web Part, obsługa zdarzeń
i przepływy pracy. A ogromną zaletą usług WSS jako platformy programistycznej jest to,
że zostały one od początku zaprojektowane z myślą o rozszerzaniu programistycznym.
Platforma programistyczna WSS zawiera model obiektowy, strukturę Web Part Framework,
usługi sieci Web i model inicjowania obsługi administracyjnej witryn, co czyni ją uniwersalnym szkieletem dla skalowalnych aplikacji pełniących rolę portali.
Dostosowywanie konta programowanie
Przed przystąpieniem do projektowania oprogramowania dla platformy WSS trzeba poznać
granicę pomiędzy mechanizmem dostosowywania a programowaniem. Usługi WSS są bardzo elastyczne i zostały zaprojektowane tak, aby wspierać wysokopoziomowe dostosowania. Jak już wspominaliśmy, aby budować złożone witryny o bogatej funkcjonalności, wcale
nie trzeba być programistą.
Zaawansowany użytkownik może tworzyć i dostosowywać listy i biblioteki dokumentów. Użytkownicy mogą również dostosowywać i personalizować wygląd stron przy użyciu
składników Web Part. Doświadczeni użytkownicy mogą nawet tworzyć efektywny mechanizm stosowania znaków firmowych, dostosowując powiązane z witrynami strony wzorcowe oraz kaskadowe arkusze stylów przy użyciu programu SharePoint Designer.
Należy pamiętać, że usługi WSS zapisują wszystkie dostosowania witryny, modyfikując
dane w bazie danych zawartości. Ma to miejsce za każdym razem, gdy tworzona jest nowa
lista lub istniejąca lista jest dostosowywana poprzez dodawanie nowych kolumn i widoków.
17
Zasada ta ma zastosowanie również w przypadku wszelkiego typu dostosowań witryny
dokonywanych przy użyciu programu Microsoft Office SharePoint Designer.
Fakt, że wszystkie dostosowania są zapisywane jako modyfikacje w bazie danych zawartości, stanowi zarówno zaletę, jak i wadę usług WSS. Zaletą jest duża elastyczność, jaką ten
mechanizm gwarantuje użytkownikom i administratorom witryn w zakresie dokonywania
dostosowań ad hoc. Mechanizm ten stanowi natomiast wadę z punktu widzenia profesjonalnych programistów, ponieważ utrudnia kontrolowanie wersji modyfikacji i replikowanie
ich w wielu witrynach.
Wyobraźmy sobie standardowy projekt programistyczny ASP.NET, w którym wszystkie
wykorzystywane pliki źródłowe znajdują się w jednym katalogu na naszej maszynie. Po
zakończeniu fazy wstępnego projektowania i implementacji witryny można dodać wszystkie
pliki źródłowe witryny do systemu zarządzania kodem źródłowym, takiego jak Microsoft
Visual SourceSafe. Rozwiązanie takie umożliwia zastosowanie bardzo zdyscyplinowanego
podejścia do problemu instalacji i aktualizacji witryny po przeniesieniu jej do środowiska
produkcyjnego. Można także zdecydować się na przeniesienie zmian do środowiska publikowania, gdzie strony i kod witryny mogą zostać wnikliwie przetestowane przed umieszczeniem ich w środowisku produkcyjnym.
Jako programiści powinniśmy zadać sobie następujące pytania. W jaki sposób realizować będziemy zarządzanie kodem źródłowym zmian dostosowań? W jaki sposób dokonywać będziemy zmian dostosowań w definicjach list lub instancjach stron, a następnie
jak będziemy przenosić te zmiany ze środowiska rozwoju do środowiska publikowania,
a w końcu do środowiska produkcyjnego? W jaki sposób dokonywać będziemy modyfikacji dostosowań w witrynie, a następnie zastosujemy tę modyfikację w stu innych witrynach?
Niestety, niełatwo jest odpowiedzieć na te pytania i zazwyczaj okazuje się, że możliwe
rozwiązania są zbyt kosztowne w realizacji.
Na szczęście programiści mogą pracować na poziomie niższym niż infrastruktura dostosowań WSS. A dokładniej, programista może wykorzystywać niskopoziomowe pliki źródłowe do tworzenia wewnętrznych definicji obiektów, takich jak listy i szablony stron. Te
niskopoziomowe pliki źródłowe nie są przechowywane w bazie danych zawartości, a znajdują się w systemie plików na serwerze frontonu sieci Web. Praca na tym poziomie jest
bardziej skomplikowana i wymaga bardziej zaawansowanych umiejętności. Jednocześnie
jednak pozwala na scentralizowanie zarządzania kodem źródłowym i stanowi bardziej
metodologiczne rozwiązanie, zapewniające mechanizm podpisywania podczas przenoszenia stron i kodu ze środowiska programistycznego do środowiska publikowania, a stamtąd
do środowiska produkcyjnego. Takie podejście zwiększa również możliwości zarządzania
przechowywaniem wersji i ponownym wykorzystywaniem kodu w obrębie wielu witryn,
aplikacji sieci Web oraz farm.
W pozostałej części tej książki wprowadzone zostało rozróżnienie pomiędzy dostosowywaniem a programowaniem zgodne z następującymi kryteriami. Dostosowania WSS stanowią modyfikacje witryny osiągane poprzez dokonywanie zmian w bazie danych zawartości,
z reguły za pośrednictwem przeglądarki sieci Web lub programu SharePoint Designer.
Dostosowanie witryny nigdy nie odnosi się bezpośrednio do serwera frontonu sieci Web.
Natomiast programowanie WSS wiąże się z przetwarzaniem plików, które muszą zostać
umieszczone w systemie plików serwera frontonu sieci Web. Programowanie WSS polega
na tworzeniu szablonów stron i definicji list, jak również komponentów instalowanych
w skompilowanych zestawach, takich jak niestandardowe składniki Web Part, programy
18
obsługi zdarzeń i szablony przepływów pracy. Programowanie WSS na tym poziomie nazywane jest również rozwijaniem składników obsługi administracyjnej.
Należy pamiętać, że programowanie wymaga pewnego stopnia kontroli nad serwerem
frontonu sieci Web, ponieważ wiąże się w umieszczeniem na nim plików, takich jak szablony stron i zestawy. Programista pracujący w środowisku WSS, w którym nie ma uprawnień do dokonywania żadnych zmian na serwerach frontonu sieci Web, nie będzie mógł
zainstalować owoców swojej pracy. W takim środowisku można zastosować jedynie techniki dostosowywania, które są realizowane poprzez dokonywanie zmian w bazie danych
zawartości.
Chociaż mechanizm dostosowywania zapewnia użytkownikom sporą elastyczność, programowanie stwarza dużo większe możliwości. Stanowi ono dużo lepszą metodę w przypadku tworzenia rozwiązań WSS wielokrotnego użytku, jak również najlepszą metodę
optymalizowania czasów odpowiedzi i przepustowości w witrynach o wysokim natężeniu
ruchu. Programowanie składników obsługi administracyjnej przy użyciu usług WSS stanowi podstawowy temat niniejszej książki, natomiast omówienie dostosowań i związanych
z nimi narzędzi, takich jak program SharePoint Designer, to temat drugorzędny.
Możliwości rozwoju
Programista może rozszerzać usługi WSS w wielu różnych obszarach. W kolejnych dwóch
rozdziałach omówimy metody tworzenia niestandardowych stron aplikacji i szablonów
stron w celu zwiększenia funkcjonalności rozwiązań biznesowych. Jak będzie się można
przekonać, pewne typy stron w witrynie WSS pozwalają na pisanie schowanego bezpośrednio za nimi kodu zarządzanego, a inne nie. Jednak nawet, gdy typy stron nie wspierają
kodu w sposób bezpośredni, nadal można pisać kod w składnikach Web Part i formantach
użytkownika ASP.NET, a następnie wykorzystywać te komponenty na stronach.
Rozszerzenia wprowadzone w wersji WSS 3.0 wiążą się z dodaniem integracji ze stronami wzorcowymi ASP.NET i kaskadowymi arkuszami stylów (CSS). Integracja ta pozwala
lepiej kontrolować mechanizm stosowania w witrynie znaków firmowych, które będą
widoczne dla klientów oraz zarządu. Zapewniona została również ścisła integracja ze strukturą dostawcy nawigacji ASP.NET, dzięki której można tworzyć wszelkiego typu niestandardowe struktury nawigacyjne, znane ze standardowych aplikacji ASP.NET 2.0.
Możliwe jest również rozwijanie różnego typu niestandardowych komponentów wykorzystywanych w witrynach WSS. Do komponentów tych zaliczają się standardowe formanty serwerów ASP.NET, składniki Web Part, programy obsługi zdarzeń, niestandardowe
typy pól i niestandardowe zasady. Przyczyny i metody rozwijania tego typu komponentów
będą stopniowo omawiane w dalszej części książki.
Programista może również kontrolować sposób przechowywania zawartości w niestandardowej witrynie. Usługi WSS pozwalają na definiowanie niestandardowych typów na
potrzeby list i bibliotek dokumentów. Dzięki temu można kontrolować, jakie kolumny
i jakie widoki są dostępne dla użytkowników.
Usługi WSS 3.0 wprowadziły pewną użyteczną innowację, zwaną kolumną witryny.
Kolumna witryny stanowi definicję kolumny wielokrotnego użytku, która może zostać
zastosowana w wielu listach. Kolumna witryny definiuje nazwę kolumny, typ pola i inne
cechy charakterystyczne, takie jak wartość domyślna, formatowanie i sprawdzanie poprawności. Po zdefiniowaniu kolumny witryny można wykorzystywać ją podczas definiowania
19
schematu niestandardowych list i bibliotek dokumentów. Płynie z tego oczywista korzyść
polegająca na tym, że wystarczy zaktualizować kolumnę witryny w jednym miejscu,
a zmiana ta zostanie odzwierciedlona we wszystkich listach, w których wykorzystana
została ta kolumna witryny.
W usługach WSS 3.0 wprowadzono również inną, funkcjonalną innowację związaną
z przechowywaniem zawartości. Nosi ona nazwę typ zawartości. Typ zawartości stanowi
elastyczną definicję typu WSS wielokrotnego użytku, który opisuje kolumnę i zachowanie elementów list lub dokumentów w bibliotekach dokumentów. Przykładowo, można
stworzyć na potrzeby dokumentów zawierających prezentacje typ zawartości z unikalnym zestawem kolumn, programem obsługi zdarzeń i własnym szablonem dokumentu.
Następnie można stworzyć dla dokumentów ofert drugi typ zawartości z innym zestawem
kolumn, przepływem pracy i innym szablonem. W kolejnym kroku można zdefiniować
nową bibliotekę dokumentów i skonfigurować ją tak, aby wspierała ona oba typy zawartości. Wprowadzenie w wersji WSS 3.0 typów zawartości jest bardzo znaczącą zmianą,
ponieważ umożliwia obsługę różnych typów zawartości w tej samej liście lub bibliotece
dokumentów, co w wersji WSS 2.0 było niemożliwe.
Kolejny obszar, który może być programistycznie rozwijany, wiąże się z wykorzystaniem
nowego formatu plików Office – Open XML. Ta nowa technologia wprowadzona wraz
z wersją Microsoft Office 2007 pozwala na generowanie i/lub przetwarzanie dokumentów
Microsoft Office Word oraz Microsoft Office Excel za pośrednictwem kodu po stronie serwera
umieszczonego w niestandardowych komponentach, takich jak programy obsługi zdarzeń czy
przepływy pracy. Zaletą tej technologii jest to, że format plików Office Open XML eliminuje
konieczność instalowania i uruchamiania na serwerze wersji stacjonarnej aplikacji Microsoft
Office, takiej jak Office Word czy Office Excel. Wszystko można osiągnąć poprzez programowanie przy użyciu serwerowych bibliotek, co zapewnia wysoką skalowalność i stabilność.
Jednym z najciekawszych obszarów WSS 3.0 podlegających rozszerzaniu są przepływy pracy. Usługi WSS wykorzystują możliwości nowej platformy Microsoft Windows
Workflow Foundation, która stanowi część .NET Framework 3.0 i wzbogacają platformę
o dodatkowe elementy, które umożliwiają dołączanie logiki biznesowej do elementów list
i dokumentów w witrynie WSS. Usługi WSS rozszerzają podstawowy model Windows
Workflow Foundation, powiązując listy zadań i historii z każdym przepływem pracy. To
powoduje odwzorowanie pewnego zakresu odpowiedzialności w przepływach pracy, które
są z natury zorientowane na symulacje rzeczywistych procesów biznesowych realizowanych
przez człowieka, takich jak recenzowanie lub zatwierdzanie dokumentów.
Zarówno usługi WSS, jak i program MOSS zawierają wbudowane przepływy pracy, które
są domyślnie instalowane i gotowe do użycia. Usługi WSS zawierają prosty przepływ pracy
obiegu wspierający takie aspekty jak filtrowanie i zarządzenie treścią oraz jej zatwierdzanie.
Program MOSS wspiera bardziej złożone przepływy pracy wykorzystywane w takich operacjach, jak proces zatwierdzania realizowany na poziomie zarządzania zawartością sieci Web.
Dodawanie niestandardowych przepływów pracy to jeden z typowych mechanizmów
wykorzystywanych przez programistów tworzących rozwiązania biznesowe przy użyciu usług
WSS oraz programu MOSS. Poza standardowym wsparciem dla rozszerzeń Visual Studio
Extensions for Windows Workflow Foundation, zespół Office stworzył specjalnie z myślą
o usługach WSS pakiet Workflow Software Development Kit (SDK) wraz z pakietem pomocniczym Workflow Developer Starter Kit zawierającym szablony projektów Visual Studio do
tworzenia niestandardowych przepływów pracy dla witryn WSS.
20
Zabezpieczenia i członkostwo w witrynach to kolejne dwa obszary, które pozwalają programistom na rozszerzanie standardowej infrastruktury WSS. Poprzednie wersje usług WSS były
ściśle powiązane z kontami Windows i Microsoft Active Directory, co utrudniało wykorzystanie technologii SharePoint w witrynach udostępnianych w Internecie. W wersji WSS 3.0 jest
inaczej. Nowa struktura uwierzytelniania użytkowników została zaprojektowana ponownie na
bazie infrastruktury dostawcy uwierzytelniania wprowadzonej w ASP.NET 2.0.
Gdy nie chce się utrzymywać kont dla użytkowników WSS w katalogu Active Directory,
wystarczy po prostu zbudować lub nabyć dostawcę uwierzytelniania ASP.NET, który został
zaprojektowany tak, aby przechowywać i zarządzać kontami użytkowników w alternatywnym repozytorium tożsamości, takim jak np. baza danych SQL Server. Dzięki takiemu
rozwiązaniu architektonicznemu, usługi WSS 3.0 zyskały dużo szersze możliwości zastosowania w roli platformy służącej do budowania witryn internetowych.
Technologia ASP.NET 2.0 zawiera dostawcę uwierzytelniania, dzięki któremu można
wykorzystać konta użytkowników przechowywane w bazie danych SQL Server i uwierzytelnianie wykorzystujące formularze. Można skonfigurować ten typ dostawcy tak, aby
dostarczał usługi uwierzytelniania na potrzeby witryny WSS 3.0. Już niewielka ilość pracy
wystarczy, aby umieścić w Internecie witrynę WSS, która umożliwia nieznanym użytkownikom rejestrowanie się w roli członków. Technologia ASP.NET 2.0 oferuje wygodne w użyciu
wsparcie dla tworzenia i przechowywania kont użytkowników, a nawet umożliwia użytkownikom modyfikowanie swoich haseł. Wykorzystując uwierzytelnianie przy użyciu formularzy w WSS, można zastosować te same techniki zarządzania kontami użytkowników
co w rozwiązaniach ASP.NET 2.0.
Wprowadzenie do funkcji
Chociaż niestandardowemu rozszerzaniu podlega wiele obszarów usług WSS, warto rozpocząć naukę od funkcji. Funkcje stanowią innowację wprowadzoną w wersji WSS 3.0
specjalnie z myślą o programistach. Funkcje dostarczają mechanizm definiowania elementów witryny i dodawania ich do docelowej witryny lub zbioru witryn przy użyciu procesu
nazywanego aktywowaniem funkcji. Do typów elementów, które mogą być definiowane za
pomocą funkcji, zaliczają się: polecenia menu, łącza, szablony stron, wystąpienia stron,
definicje list, wystąpienia list, programy obsługi zdarzeń i przepływy pracy.
Pod względem fizycznym funkcja składa się z podkatalogu stworzonego w specjalnym
folderze WSS znajdującym się w systemie plików na każdym serwerze frontonu sieci Web.
Katalog odpowiadający funkcji składa się z jednego lub więcej bazujących na technologii
XML plików, które zawierają kod w języku Collaborative Application Markup Language
(CAML). Zgodnie z narzuconą konwencją, każdy katalog funkcji zawiera plik manifestu
o nazwie feature.xml, który definiuje wysokopoziomowe atrybuty funkcji, takie jak unikalny identyfikator i przyjazny dla użytkownika tytuł.
Poza plikiem feature.xml funkcję opisuje zazwyczaj jeden lub więcej dodatkowych plików XML (np. elements.xml), które definiują jej poszczególne elementy. Katalog danej
funkcji może także zawierać kilka innych typów plików zawierających takie elementy jak
definicje list czy szablony stron, jak również inne rodzaje zasobów, takie jak pliki graficzne,
kaskadowe arkusze stylów czy pliki JavaScript.
Jedną z metod pomocnych w zrozumieniu funkcji, jest zapoznanie się ze standardowym zestawem funkcji dostępnych w podstawowej instalacji WSS. Wygląd przykładowego
21
katalogu FEATURES tuż po instalacji usług WSS został zaprezentowany na Rysunku 1-11.
Jak widać, każda funkcja ma swój własny katalog. Warto także zauważyć, że strona Funkcje
Witryny będzie wyglądała zupełnie inaczej, gdy zainstalowany jest program MOSS, ponieważ dostępnych będzie ponad 100 funkcji.
W końcowej części rozdziału będzie można dowiedzieć się, jak stworzyć i zainstalować swoją pierwszą niestandardową funkcję. Po stworzeniu funkcji trzeba zainstalować ją
w usługach WSS na poziomie farmy. Po zainstalowaniu funkcja może zostać aktywowana
w kontekście witryny lub zbioru witryn przy użyciu strony administracyjnej dostępnej za
pośrednictwem strony Ustawienia Witryny.
Rysunek 1-11
Wiele szablonowych elementów WSS, jak np. listy współpracy,
jest zaimplementowanych w formie funkcji.
W dalszej części książki wprowadzane będą nowe funkcje służące do rozwiązywania określonych problemów, takich jak stosowanie w witrynie znaków firmowych przy użyciu
niestandardowej strony wzorcowej i kaskadowych arkuszy stylów. Inne funkcje pozwolą
zademonstrować tworzenie nowych instancji stron i udostępnianie w witrynie komponentów, takich jak składniki Web Part bądź niestandardowe przepływy pracy.
Niestandardowa funkcja umożliwia programiście definiowanie jednego lub kilku elementów, które mogą być aktywowane w kontekście witryny lub zbioru witryn. Silnik WSS
pozwala również na definiowanie całego projektu witryny poprzez stworzenie niestandardowej definicji witryny. Mechanizm rozwijania niestandardowych definicji witryn daje
programistom kontrolę nad prawie każdym aspektem nowej witryny, m.in. nad zastosowanymi znakami firmowymi, wstępnym zestawem list i wykorzystywanych funkcji. Rozdział
9 „Rozwiązania i instalacja” poświęcony jest pracy z definicjami witryn.
Programowanie przy użyciu modelu obiektowego WSS
Innym istotnym aspektem rozszerzania usług WSS jest programowanie przy użyciu modelu
obiektowego WSS. Podstawowe typy dostarczane przez model programistyczny WSS są
udostępniane poprzez standardowy zestaw WSS o nazwie Microsoft.SharePoint.dll.
Przyjrzyjmy się prostemu przykładowi. Wyobraźmy sobie, że stworzyliśmy aplikację konsolową i że dodaliśmy do niej odwołanie do Microsoft.SharePoint.dll. Model obiektowy WSS udostępnia klasę SPSite, która służy jako punkt wejścia do modelu obiektowego WSS na poziomie
zbioru witryn. Każda witryna w zbiorze witryn jest reprezentowana jako obiekt SPWeb. Każda
lista w witrynie jest reprezentowana jako obiekt SPList. Oto prosty przykład wykorzystujący
model obiektowy WSS do uzyskania dostępu do witryny najwyższego poziomu w docelowym
zbiorze witryn i sprawdzenia wszystkich znajdujących się w niej list.
22
using Microsoft.SharePoint;
namespace Hello_WSS_OM {
class Program {
static void Main() {
string sitePath = "http://litwareinc.com";
// wejście do modelu obiektowego poprzez zbiór witryn.
SPSite siteCollection = new SPSite(sitePath);
// pobranie referencji do witryny najwyższego poziomu.
SPWeb site = siteCollection.RootWeb;
// enumeracja po listach w witrynie
foreach (SPList list in site.Lists) {
Console.WriteLine(list.Title);
}
// sprzątanie zasobów poprzez wywołanie funkcji Dispose.
site.Dispose();
siteCollection.Dispose();
}
}
}
Na końcu tego przykładowego kodu powinny pojawić się dwa wywołania metody Dispose.
Część typów obiektowych w modelu obiektowym WSS (m.in. SPSite i SPWeb) wykorzystuje niezarządzane zasoby i musi zostać szybko zutylizowana. W przeciwnym wypadku,
gdy w zakresie zarządzania pamięcią polegać będziemy jedynie na mechanizmie Garbage
Collector platformy .NET, kod może stać się źródłem problemów, wykorzystując więcej
pamięci niż to konieczne. Ogólna zasada jest taka, że gdy tworzymy utylizowalny obiekt,
odpowiadamy również za wywołanie na nim metody Dispose. Jednakże referencje do
obiektów pozyskane za pośrednictwem obiektu SPContext aplikacji sieci Web WSS nie
powinny być utylizowane.
Tworzenie pierwszej funkcji
Nie ma lepszego zakończenia dla pierwszego rozdziału niż skok na głęboką wodę i stworzenie od podstaw prostej funkcji Hello World. Ćwiczenie to przeprowadzi nas przez podstawowe aspekty tworzenia, instalowania i testowania funkcji. Aby dodatkowo uatrakcyjnić
ćwiczenie, na zakończenie dodamy programy obsługi zdarzeń wywoływane w związku
z aktywowaniem lub dezaktywowaniem funkcji. Kod znajdujący się w programach obsługi
zdarzeń wykorzystywać będzie model obiektowy WSS do zmiany pewnych cech charakterystycznych docelowej witryny.
W przykładzie wykorzystamy Microsoft Visual Studio 2005 do stworzenia nowego projektu programistycznego dla funkcji. Visual Studio 2005 zapewni odpowiednie formatowanie znaczników XML i ASP.NET oraz poprzez mechanizm IntelliSense zwiększy wygodę
pracy z plikami XML koniecznymi do zdefiniowania funkcji.
Rozpocznijmy od stworzenia nowego projektu Class Library o nazwie HelloWorld.
W tym przykładzie stworzymy projekt C#, ale nic nie stoi na przeszkodzie, aby czytelnik
stworzył projekt Visual Basic .NET. Na końcu dodamy kod, który będzie kompilowany do
wyjściowej biblioteki DLL wykorzystywanej przez programy obsługi zdarzeń danej funkcji.
Jednak wcześniej stworzymy plik feature.xml.
23
Przed rozpoczęciem procesu tworzenia pliku feature.xml należy rozważyć fakt, że
funkcja musi zostać umieszczona w dedykowanym katalogu w folderze systemowym WSS
o nazwie FEATURES. Katalog FEATURES znajduje się w innym katalogu systemowym WSS
o nazwie TEMPLATE.
c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\
FEATURES
Biorąc pod uwagę wymagania stawiane przez instalację funkcji, dobrym rozwiązaniem
może okazać się stworzenie jednakowej hierarchii folderów w projekcie Visual Studio
wykorzystywanym do rozwijania funkcji WSS. To ułatwi kopiowanie plików funkcji do
odpowiednich lokalizacji i testowanie ich podczas prac programistycznych.
Na początku należy dodać folder o nazwie TEMPLATE do katalogu głównego aktualnego projektu. Po stworzeniu katalogu TEMPLATE należy stworzyć podkatalog o nazwie
FEATURES. Na zakończenie należy stworzyć w katalogu FEATURES kolejny katalog
o nazwie takiej samej jak nazwa projektu funkcji. W tym przypadku nazwa tego katalogu
to HelloWorld, jak pokazano na Rysunku 1-12.
Rysunek 1-12
Projekt Visual Studio służący do rozwijania funkcji WSS.
Następnie należy stworzyć plik XML o nazwie feature.xml wewnątrz katalogu HelloWorld.
Do tego katalogu dodamy informacje XML, które definiują wysokopoziomowe atrybuty
funkcji. Należy wstawić następujący kod XML do pliku feature.xml, aby dodać element
Feature najwyższego poziomu wraz z atrybutami opisującymi samą funkcję.
<Feature
Id="B2CB42E2-4F0A-4380-AABA-1EF9CD526F20"
Title="Rozdział 1: Funkcja Hello World "
Description="To jest pierwsza niestandardowa funkcja "
Scope="Web"
Hidden="FALSE"
ImageUrl="menuprofile.gif"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="elements.xml" />
</ElementManifests>
</Feature>
Jak widać, funkcja jest definiowana przy użyciu elementu Feature zawierającego atrybuty,
takie jak Id (Unikalny identyfikator), Title (Tytuł), Description (Opis), Version (Wersja),
Scope (Zakres), Hidden (Ukryta) i ImageUrl (Adres URL obrazu). Trzeba stworzyć nowy
identyfikator GUID dla atrybutu Id, aby funkcja mogła być unikalnie identyfikowana.
24
Atrybuty funkcji Title oraz Description powinny być przyjaznym dla użytkownika opisem
tekstowym nowej funkcji. Atrybuty te będą widoczne dla użytkowników za pośrednictwem
stron administracyjnych WSS służących do aktywowania i dezaktywowania funkcji.
Atrybut Scope definiuje kontekst, w którym funkcja może być aktywowana i dezaktywowana. Tworzona funkcja ma zakres o wartości Web, co oznacza, że może ona zostać aktywowana i dezaktywowana w kontekście witryny. Gdybyśmy przypisali atrybutowi Scope wartość
Site, funkcja byłaby aktywowana i dezaktywowana w zakresie zbioru witryn. Dwie inne możliwe wartości, które można nadać atrybutowi zakresu, to zakres WebApplication i Farm.
Jak widać, w powyższym kodzie atrybut Hidden zawiera wartość FALSE. Oznacza to,
że po zainstalowaniu w farmie funkcja będzie widoczna dla użytkowników, którzy mogą
chcieć ją aktywować. Można także stworzyć funkcję z atrybutem Hidden o wartości TRUE.
Skutkiem będzie ukrycie funkcji na liście dostępnych funkcji prezentowanej użytkownikom. Ukryte funkcje muszą być aktywowane za pośrednictwem wiersza polecenia, kodu
niestandardowego lub poprzez zależności z aktywacją innej funkcji. Zależności aktywacji
zostaną omówione w sposób bardziej szczegółowy w Rozdziale 9.
Można również zauważyć, że atrybut ImageUrl ma wartość, która wskazuje jeden z graficznych obrazów stanowiących część podstawowej instalacji WSS. Obraz ten zostanie
wyświetlony na stronach interfejsu użytkownika obok nazwy funkcji.
Ostatnią część zaprezentowanego pliku feature.xml stanowi element ElementManifests.
Element ten zawiera wewnętrzne elementy ElementManifest, które odwołują się do innych
plików XML, w których definiowane są elementy składające się na funkcję. W naszym przypadku istnieje tylko jeden element ElementManifest, który wykorzystuje atrybut Location
do wskazania pliku o nazwie element.xml.
Włączanie mechanizmu IntelliSense w Visual Studio
Wewnątrz katalogu TEMPLATE znajduje się katalog o nazwie XML, który zawiera
różne pliki XML Schema, w tym jeden o nazwie wss.xsd. Po powiązaniu pliku XML
Schema z plikami funkcji, takimi jak feature.xml i elements.xml, Visual Studio będzie
oferowało wsparcie IntelliSense podczas ich edycji, co znacznie ułatwi tworzenie niestandardowych funkcji. Można również skopiować pliki XSD do katalogu C:\Program
Files\Microsoft Visual Studio 8\Xml\Schemas\.
Teraz nadszedł czas, aby stworzyć plik element.xml i zdefiniować pojedynczy element
CustomAction, który zostanie wykorzystany do dodania prostego polecenia do menu Akcje
Witryny. Należy dodać do pliku elements.xml następujący kod XML, który definiuje element CustomAction.
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction
Id="SiteActionsToolbar"
GroupId="SiteActions"
Location="Microsoft.SharePoint.StandardMenu"
Sequence="100"
Title="Hello World"
Description="Wartość menu dodana przez użytkownika za pomocą funkcji"
25
ImageUrl="_layouts/images/menuprofile.gif" >
<UrlAction Url="http://msdn.microsoft.com"/>
</CustomAction>
</Elements>
Ten element CustomAction został zaprojektowany tak, aby spowodować dodanie polecenia
do menu Akcje Witryny. Dostarcza on przyjazny dla użytkownika tytuł (Title) oraz opis
(Description) oraz adres URL, który będzie wykorzystywany do przekierowania użytkownika, gdy wybierze on to polecenie menu. Przedstawiona przykładowa funkcja prezentuje zaledwie niewielki zakres dostępnych możliwości, niemniej stanowi prosty wstęp do
podróży po procesie instalacji i testowania funkcji.
Teraz, gdy już stworzyliśmy pliki feature.xml oraz elements.xml definiujące funkcję
HelloWorld, pozostało nam jeszcze do wykonania kilka czynności związanych z jej zainstalowaniem i przetestowaniem. Po pierwsze, należy skopiować katalog funkcji HelloWorld
do systemowego katalogu WSS o nazwie FEATURES. Po drugie, należy wywołać komendę
STSADM.EXE, w celu zainstalowania funkcji w usługach WSS. A w końcu należy aktywować funkcję w kontekście witryny WSS. Dwa pierwsze kroki można zautomatyzować, tworząc plik wsadowy o nazwie install.bat w katalogu głównym projektu HelloWorld i dodając
następujące instrukcje wiersza polecenia.
REM – Pamiętaj aby usunąć znaki końca wiersza z dwóch pierwszych linii
@SET TEMPLATEDIR="c:\program files\common files\microsoft shared\
web server extensions\12\Template"
@SET STSADM="c:\program files\common files\microsoft shared\
web server extensions\12\bin\stsadm"
Echo Kopiowanie plików
xcopy /e /y TEMPLATE\* %TEMPLATEDIR%
Echo Instalowanie funkcji
%STSADM% -o InstallFeature -filename
HelloWorld\feature.xml -force
Echo Ponowne uruchomienie procesu roboczego IIS
IISRESET
Zasadniczo można również zautomatyzować ostatnią czynność aktywowania funkcji w określonej witrynie, uruchamiając operację ActivateFeature za pomocą narzędzia STSADM.
Jednak w prezentowanym przykładzie technika ta nie została wykorzystana, aby czytelnik
samodzielnie przeszedł przez proces aktywowania funkcji podobnie jak to czynią inni
użytkownicy – za pośrednictwem interfejsu użytkownika WSS.
Po dodaniu pliku install.bat można skonfigurować Visual Studio tak, aby plik ten był
uruchamiany za każdym razem, gdy budowany jest projekt HelloWorld. W tym celu należy
przejść do karty Build Events we właściwościach projektu i dodać następujące instrukcje
w polu Post-build Event Command Line.
cd $(ProjectDir)
Install.bat
26
Pierwsza linia cd $(ProjectDir) jest konieczna do zmiany aktualnego katalogu na katalog
projektu. W drugiej linii uruchamiany jest plik wsadowy, który kopiuje pliki funkcji do
odpowiednich lokalizacji i instaluje funkcję przy użyciu operacji InstallFeature, wykorzystując narzędzie wiersza polecenia STSADM.EXE.
Po prawidłowym zainstalowaniu funkcja może zostać aktywowana w kontekście witryny.
W witrynie najwyższego poziomu w stworzonym we wcześniejszej części niniejszego rozdziału zbiorze witryn należy przejść do strony Ustawienia Witryny. W sekcji Administracja
Witryną należy kliknąć łącze zatytułowane Funkcje Witryny. To powinno spowodować
pojawienie się strony podobnej do zaprezentowanej na Rysunku 1-13. Warto mieć na
uwadze, że w farmie, w której zainstalowany został program MOSS, zaprezentowanych
zostanie dużo więcej funkcji niż w farmie z samymi usługami WSS.
Rysunek 1-13
Po zainstalowaniu funkcja może być aktywowana
i dezaktywowana przez użytkowników.
Strona Funkcje Witryny powinna zawierać funkcję HelloWorld. Po jej odnalezieniu można
kliknąć przycisk Uaktywnij, aby aktywować funkcję. Po wykonaniu tej czynności w rozwijanym menu Akcje Witryny powinien pojawić się niestandardowy element, co zaprezentowano na Rysunku 1-14. Po wybraniu tego niestandardowego elementu menu, użytkownik
zostanie przekierowany pod adres URL, który został zdefiniowany w atrybucie Url elementu UrlAction w pliku elements.xml.
Rysunek 1-14
Element CustomAction może być wykorzystywany do dodawania
niestandardowych poleceń do menu akcji witryny.
Po pomyślnym aktywowaniu funkcji i przetestowaniu niestandardowego polecenia
menu, warto dodatkowo poeksperymentować, powracając do strony Funkcje Witryny
i dezaktywując funkcję. Po dezaktywowaniu funkcji HelloWorld powinno się okazać, że
niestandardowy element został usunięty z menu Akcje Witryny.
Poznaliśmy fundamentalną zasadę dotyczącą funkcji. Programiści tworzą różnego typu
elementy witryn, które mogą być dodawane lub usuwane z witryny za pośrednictwem
procesu aktywacji i dezaktywacji.
27
Dodawanie do funkcji procedury obsługi zdarzenia
Teraz nadszedł czas, aby dodatkowo rozbudować przykład funkcji HelloWorld, dodając procedury obsługi zdarzeń i wykorzystując w kodzie model obiektowy WSS. Należy rozpocząć
od dodania do projektu referencji do biblioteki Microsoft.SharePoint.dll. Następnie należy
zlokalizować plik źródłowy nazwany Class1.cs i zmienić jego nazwę na FeatureReceiver.
cs. Później należy dodać następujący kod.
using System;
using Microsoft.SharePoint;
namespace HelloWorld{
public class FeatureReceiver : SPFeatureReceiver {
public override void FeatureInstalled(
SPFeatureReceiverProperties properties){}
public override void FeatureUninstalling(
SPFeatureReceiverProperties properties) { }
public override void FeatureActivated(
SPFeatureReceiverProperties properties){
SPWeb site = (SPWeb)properties.Feature.Parent;
// zapisujemy oryginalną wartość parametru Title danej witryny,
// używając zbioru właściwości SPWeb
site.Properties["OriginalTitle"] = site.Title;
site.Properties.Update();
// zmieniamy tytuł witryny
site.Title = "Hello World";
site.Update();
}
public override void FeatureDeactivating(
SPFeatureReceiverProperties properties) {
// przywracamy oryginalny tytuł danej witryny
SPWeb site = (SPWeb)properties.Feature.Parent;
site.Title = site.Properties["OriginalTitle"];
site.Update();
}
}
}
Pierwszą rzeczą, na którą należy zwrócić uwagę, jest sposób tworzenia procedury obsługi
zdarzenia, która jest uruchamiana, gdy funkcja jest aktywowana lub dezaktywowana.
Sposób ten polega na stworzeniu klasy, która dziedziczy z klasy SPFeatureReceiver. Jak
widać, można obsługiwać zdarzenia poprzez nadpisywanie wirtualnych metod klasy bazowej, takich jak FeatureActivated i FeatureDeactivating. Istnieją także dwie dodatkowe
metody obsługi zdarzeń, które będą uruchamiane podczas instalowania i odinstalowywania
funkcji, ale w tym podstawowym przykładzie nie będą one wykorzystywane.
Metoda FeatureActivated została napisana tak, aby modyfikować tytuł aktualnej witryny
przy użyciu modelu obiektowego WSS. Warto zwrócić uwagę na technikę pozyskiwania
referencji do bieżącej witryny – parametr Properties (Właściwości) służy do pobrania referencji do obiektu SPWeb. Parametr Properties wywodzi się z klasy SPFeatureReceiverPro
perties, która udostępnia właściwość Feature, która z kolei udostępnia właściwość Parent
28
z referencją do aktualnej witryny. Tytuł witryny zostaje zmieniony poprzez przypisanie
nowej wartości właściwości Title obiektu SPWeb, a następnie wywołanie metody Update.
Warto zauważyć także, że funkcja została zaprojektowana tak, aby przechowywać pierwotną wartość Title. Dzięki temu po dezaktywacji funkcji może zostać przywrócony oryginalny tytuł witryny. Cel ten osiągnięto przy użyciu trwałego zbioru właściwości danego
zakresu witryny, który jest dostępny za pośrednictwem kolekcji Properties obiektu SPWeb.
Co ważne, wiele innych obiektów w modelu obiektowym WSS ma podobną właściwość
Properties, którą można wykorzystać do śledzenia par nazwa-wartość przy użyciu trwałego
zbioru właściwości. Usługi WSS obsługują utrwalanie tych nazwanych wartości w bazie
danych zawartości oraz pobieranie ich na żądanie.
Po napisaniu kodu dwóch metod obsługi zdarzeń nadszedł czas na rozpatrzenie wymagań
związanych z instalacją zestawu HelloWorld.dll. Pierwszą sprawą, którą należy wziąć pod
uwagę, jest to, że ten zestaw DLL musi zostać zainstalowany w folderze Global Assembly
Cache (GAC). A to oznacza, że trzeba dodać do projektu plik z kluczem, aby podczas
kompilacji podpisać wynikową bibliotekę DLL i otrzymać zestaw z tzw. silną nazwą.
Po dodaniu pliku z kluczem i skonfigurowaniu projektu HelloWorld w celu zbudowania biblioteki HelloWorld.dll o silnej nazwie, można wstawić dodatkową linię instrukcji
do pola Post-event Build Command Line, aby odpowiednio instalować (lub nadpisywać)
zestaw w pamięci GAC za każdym razem, gdy budowany jest aktualny projekt. Wstawiane
instrukcje wiersza polecenia powinny wyglądać następująco:
"%programfiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" if $(TargetPath)
cd $(ProjectDir)
Install.bat
Kolejnym krokiem jest uaktualnienie pliku feature.xml przy użyciu dwóch nowych atrybutów, tak aby silnik WSS został poinformowany, że istnieją programy obsługi zdarzeń, które
powinny być uruchomiane za każdym razem, gdy funkcja jest aktywowana lub dezaktywowana. Cel ten można osiągnąć, dodając atrybuty ReceiverAssembly oraz ReceiverClass,
jak pokazano poniżej.
<Feature
Id="B2CB42E2-4F0A-4380-AABA-1EF9CD526F20"
Title="Rozdział 1: Funkcja Hello World "
Description="To jest pierwsza niestandardowa funkcja "
Version="1.0.0.0"
Scope="Web"
Hidden="FALSE"
ImageUrl="menuprofile.gif"
ReceiverAssembly="HelloWorld, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=b59ad8f489c4a334"
ReceiverClass="HelloWorld.FeatureReciever"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="elements.xml" />
</ElementManifests>
</Feature>
29
Atrybut ReceiverAssembly powinien zawierać czteroczęściową nazwę zestawu, który
został wcześniej zainstalowany w pamięci GAC. Natomiast atrybut ReceiverClass powinien zawierać nazwę (wraz z przestrzenią nazw) klasy publicznej dziedziczącej z klasy
SPFeatureReceiver w zestawie odpowiedzialnym za obsługę zdarzeń.
Po dokonaniu wspomnianych zmian w pliku feature.xml, powinniśmy móc przetestować
efekt naszej pracy. Podczas ponownego budowania projektu HelloWorld, środowisko Visual
Studio uruchomi plik install.bat w celu przeniesienia uaktualnionej wersji pliku feature.xml
do katalogu WSS FEATURES i zainstalowania uaktualnionej wersji naszej funkcji w usłudze
WSS. Proces budowania projektu powinien również skompilować zestaw HelloWorld.dll,
który ma silną nazwę i zainstalować go w folderze GAC. Prawdopodobnie pojawi się konieczność uruchomienia polecenia IISRESET w celu zrestartowania procesu roboczego IIS. Wynika
ona z tego, że funkcje i zestawy pobierane z pamięci GAC są przechowywane przez usługi
WSS w pamięci podręcznej w ramach procesu roboczego IIS.
Teraz możemy już przetestować efekty naszych działań, aktywując i dezaktywując funkcję w kontekście witryny WSS. Po aktywacji tytuł witryny powinien zmienić się na „Hello
World”. Natomiast po dezaktywowaniu funkcji powinna zostać przywrócona pierwotna
wartość tytułu witryny.
Pomyślne ukończenie powyżej opisanych zadań stanowi pierwszy krok na drodze ku
zostaniu znakomitym programistą WSS, gdyż tworzenie funkcji i programowanie przy
użyciu modelu obiektowego WSS to dwie, podstawowe umiejętności, które koniecznie
trzeba opanować.
Podsumowanie
Usługi WSS mają różne znaczenie dla różnych osób. Dla użytkowników usługi WSS stanowią fundament, na którym mogą oni oprzeć biznesowe rozwiązania Web, których skala
waha się od prostych witryn współpracy do korporacyjnych aplikacji. Dla administratorów zbiorów witryn usługi WSS oznaczają czystą przyjemność płynącą z możliwości
dostosowywania witryn poprzez dodawanie list i bibliotek dokumentów oraz poprzez
dostosowywanie wielu aspektów wyglądu witryny za pośrednictwem przeglądarki lub
narzędzi do dostosowywania, takich jak SharePoint Designer.
Dla działu IT usługi WSS stanowią skalowalne i rentowne rozwiązanie służące do tworzenia i zarządzania wieloma witrynami w środowisku farmy Web. Zapewniają one również
niezawodny mechanizm wdrażania i wersjonowania aplikacji.
Dla programisty usługi WSS reprezentują bogatą w funkcjonalność platformę programistyczną, która znacznie wzbogaca bazową platformę ASP.NET. Programiści budują rozwiązania programistyczne bazujące na usługach WSS przy użyciu funkcji, definicji witryn oraz
innych komponentów, takich jak składniki Web Part, programy obsługi zdarzeń, przepływy
pracy i niestandardowe zasady. Z pewnością o programowaniu WSS można mówić wiele,
co też czynimy w tej książce, prezentując jak najbardziej optymalnie wykorzystać poszczególne elementy platformy.
Rozdział 2
Architektura SharePoint
■ Poznaj najważniejsze pojęcia i terminy związane z technologiami IIS i ASP.NET.
■ Dowiedz się, w jaki sposób usługi Windows SharePoint Services (WSS) rozszerzają
infrastrukturę ASP.NET.
■ Zrozum różnice pomiędzy stronami witryny a stronami aplikacji.
■ Naucz się tworzenia niestandardowych stron aplikacji.
Podstawy IIS i ASP.NET 2.0
Niniejszy rozdział zajmuje się omówieniem podstawowych, architektonicznych szczegółów integracji WSS z Internetowymi Usługami Informacyjnymi firmy Microsoft (IIS) oraz
platformą ASP.NET. Na początku zaprezentowane zostaną najważniejsze, fundamentalne
pojęcia i terminy wykorzystywane w IIS i ASP.NET. Następnie będzie można się dowiedzieć, w jaki sposób zespół tworzący usługi WSS zaprojektował i zaimplementował wersję
WSS 3.0, bazującą na usługach IIS i rozszerzającą platformę ASP.NET.
Niniejszy rozdział ma za zadanie przede wszystkim przybliżyć czytelnikowi wewnętrzne
mechanizmy działania aplikacji sieci Web oraz proces inicjalizacji środowiska uruchomieniowego WSS. Jak będzie się można przekonać, zespół WSS rozszerzył technologię ASP.
NET, zastępując wiele standardowych komponentów własnymi komponentami.
Na zakończenie rozdziału zaprezentowane zostaną strony aplikacji oraz oferowane przez
nie funkcjonalności, które sprawiły, iż stały się one fundamentalnym aspektem architektury
WSS. Krok po kroku przedstawiony zostanie proces tworzenia własnych stron aplikacji
pewnego niestandardowego rozwiązania oraz dołączania do tych stron kodu, który operuje
modelem obiektowym WSS.
Witryny sieci Web usług IIS a katalogi wirtualne
Zarówno ASP.NET, jak i usługi WSS wykorzystują usługi IIS 6.0, które dostarczają mechanizmu oczekiwania na nadchodzące żądania HTTP oraz infrastrukturę administracyjną służącą do uruchamiania procesów roboczych na serwerze sieci Web. Aby zrozumieć, w jaki
sposób elementy te współgrają ze sobą, trzeba najpierw poznać podstawowe pojęcia dotyczące witryn sieci Web usług IIS oraz katalogów wirtualnych.
Witryna sieci Web usług IIS stanowi punkt wyjściowy w infrastrukturze serwera sieci Web
usług IIS. Każda witryna sieci Web usług IIS jest skonfigurowana tak, aby nasłuchiwać
i przetwarzać nadchodzące żądania HTTP spełniające określone kryteria. Witryna sieci Web
usług IIS może zostać skonfigurowana na przykład tak, aby obsługiwać żądania nadsyłane
pod określony adres IP, numer portu lub przekierowywane na określony serwer sieci Web
przy użyciu specjalnego nagłówka hosta, takiego jak np.http://Extranet.Litwareinc.com.
Usługi IIS automatycznie tworzą i konfigurują witrynę sieci Web usług IIS o nazwie
Domyślna witryna sieci Web, która nasłuchuje żądań HTTP przesyłanych na port o numerze
31
32
80 i dowolny adres IP wskazujący lokalny serwer sieci Web. Można również stworzyć i skonfigurować dowolną, dodatkową witrynę sieci Web usług IIS przy użyciu narzędzia administracyjnego usług IIS.
Każda witryna sieci Web usług IIS definiuje określoną przestrzeń adresów URL. Na przykład, standardowa Domyślna witryna sieci Web definiuje przestrzeń adresów URL, która
powoduje obsługiwanie wszystkich nadchodzących żądań o adresie URL odpowiadającym
wzorcowi: http://www.Litwareinc.com/*. Jak łatwo sobie wyobrazić, w zdefiniowanej przestrzeni adresów URL może zostać utworzona nieograniczona liczba adresów URL. Serwer
IIS przetwarza nadchodzące żądania skierowane do dowolnego z tych adresów URL, przekierowując je do Domyślnej witryny sieci Web.
Każda witryna sieci Web usług IIS jest skonfigurowana tak, aby mogła być mapowana do
katalogu głównego, który stanowi fizyczny katalog w systemie plików pełniącego rolę hosta
serwera sieci Web. Na przykład, standardowa konfiguracja IIS mapuje Domyślną witrynę
sieci Web do katalogu głównego o lokalizacji C:\Inetpub\wwwroot. W większości scenariuszy prostych przekierowań usługi IIS mapują nadchodzące żądania HTTP do fizycznych
plików wewnątrz katalogu głównego. Na przykład, usługi IIS odpowiedzą na żądanie strony
http://www.Litwareinc.com/page1.htm, po prostu pobierając zawartość pliku z lokalizacji c:\
Inetpub\wwwroot\page1.htm do pamięci i kierując strumień danych do klienta.
Jednym z istotnych aspektów dotyczących witryn sieci Web usług IIS jest to, że kontrolują one, czy nadsyłane żądania wymagają uwierzytelniania i w przypadku gdy tak jest,
określają, który protokół uwierzytelniania ma zostać wykorzystany. Na przykład, Domyślna
witryna sieci Web może być publiczną witryną dostępną dla użytkowników internetowych
i jako taka, może zostać skonfigurowana tak, aby zezwalać na odstęp anonimowy i wspierać Podstawowe uwierzytelnianie. Inna witryna sieci Web usług IIS może być skonfigurowana wyłącznie z myślą o wykorzystaniu przez pracowników w obrębie korporacyjnej sieci
LAN i nie zezwalać na dostęp anonimowy, a także wspierać zintegrowane uwierzytelnianie
systemu Windows zamiast uwierzytelniania podstawowego.
Poza witrynami sieci Web, usługi IIS wspierają tworzenie i konfigurację katalogów wirtualnych. Katalog wirtualny to jednostka, która definiuje podrzędną przestrzeń adresów
URL zagnieżdżoną w przestrzeni adresów URL nadrzędnej witryny sieci Web usług IIS.
Podobnie jak witryna sieci Web usług IIS, katalog wirtualny jest skonfigurowany przy
użyciu katalogu głównego w systemie plików na serwerze sieci Web pełniącym rolę hosta.
Usługi IIS gwarantują elastyczność definiowania katalogu głównego dla katalogu wirtualnego w dowolnej lokalizacji. Można na przykład stworzyć katalog wirtualny w Domyślnej
witrynie sieci Web w przestrzeni adresów URL, takiej jak http://www.Litwareinc.com/Sales.
Tworząc ten katalog wirtualny, można skonfigurować jego katalog główny jako np. folder
C:\WebApps\Site1 w systemie plików.
Usługi IIS zapewniają narzędzie administratorskie o nazwie Menedżer Internetowych
Usług Informacyjnych (IIS), zaprezentowane na Rysunku 2-1. Narzędzie to pozwala na
kontrolowanie, tworzenie i konfigurowanie witryn sieci Web usług IIS oraz katalogów wirtualnych na aktualnej maszynie. Można je uruchomić, wykorzystując skrót Start | Narzędzia
Administracyjne | Menedżer Internetowych Usług Informacyjnych (IIS). Czytelnikom, którzy nie znają jeszcze tego narzędzia, zaleca się uruchomienie go i naukę podstawowych
opcji związanych ze sprawdzaniem i konfiguracją właściwości witryn sieci Web usług IIS
oraz katalogów wirtualnych.
Rozdział 2: Architektura SharePoint
33
Warto zauważyć, że usługi IIS przechowują informacje konfiguracyjne dotyczące własnych witryn sieci Web usług IIS i katalogów wirtualnych w repozytorium zwanym metabazą
IIS. Metabaza IIS znajduje się w systemie plików każdego serwera frontonu sieci Web, na
którym uruchomione są usługi IIS. Na przykład, gdy tworzymy i konfigurujemy witrynę
sieci Web usług IIS przy użyciu narzędzia administratorskiego usług IIS, usługi śledzą te
zmiany, dokonując wpisów w lokalnej metabazie IIS.
Rysunek 2-1 Usługi IIS oferują narzędzie administratorskie służące do kontrolowania
i konfigurowania witryn sieci Web usług IIS oraz katalogów wirtualnych.
Zamiast wykorzystywać narzędzie administratorskie IIS, można również zautomatyzować
proces tworzenia i konfigurowania witryn sieci Web usług IIS i katalogów wirtualnych,
budując skrypty lub pisząc kod zarządzany wykorzystujący model obiektowy IIS. Proces ten
jest zazwyczaj dokonywany w środowiskach farmy sieci Web podczas wdrażania nowych
witryn sieci Web, ponieważ na każdym serwerze frontonu sieci Web w farmie musiałyby
zostać dokonane identyczne modyfikacje stanu metabazy IIS.
Rozszerzenia ISAPI i filtry ISAPI
W najprostszych scenariuszach przekierowań, usługi IIS po prostu mapują nadchodzące
żądania do fizycznych plików w katalogu głównym witryny sieci Web usług IIS lub w katalogu wirtualnym. Jednak usługi IIS wspierają także model programowania Internet Server
Application Programming Interface (ISAPI), który umożliwia realizowanie bardziej zaawansowanych scenariuszy. Model programowania ISAPI umożliwia w szczególności konfigurowanie witryny sieci Web usług IIS lub katalogu wirtualnego w taki sposób, aby nadchodzące
żądania wyzwalały wykonanie dodatkowego kodu po stronie serwera sieci Web.
Model programowania ISAPI został wprowadzony w pierwotnej wersji IIS i nadal zapewnia najniższy poziom tworzenia niestandardowych komponentów IIS. Model ten składa się
z dwóch podstawowych typów komponentów: rozszerzeń ISAPI i filtrów ISAPI.
Rozszerzenie ISAPI stanowi składnik DLL, który gra rolę punktu końcowego dla nadsyłanych żądań. Podstawowe założenie jest takie, że usługi IIS mogą mapować nadsyłane
żądania do zestawu punktów końcowych, które wyzwalają wykonanie kodu w rozszerzeniach ISAPI DLL. Rozszerzenie ISAPI DLL musi zostać zainstalowane na serwerze sieci
Web i skonfigurowane na poziomie witryny sieci Web usług IIS lub katalogu wirtualnego.
Konfiguracja zazwyczaj wiąże się z powiązaniem określonych rozszerzeń plików z rozszerzeniami ISAPI przy użyciu mapowania aplikacji IIS.
Podczas gdy rozszerzenie ISAPI służy jako punkt końcowy, filtr ISAPI pełni rolę obiektu
przechwytującego. Filtr ISAPI jest instalowany i konfigurowany na poziomie witryny sieci Web
usług IIS. Po zainstalowaniu filtr ISAPI przechwytuje wszystkie nadsyłane żądania skierowane
34
do tej witryny sieci Web usług IIS. Podstawowe założenie jest takie, że filtr ISAPI może zapewnić
przetwarzanie wstępne i końcowe dla każdego nasyłanego żądania. Filtry ISAPI są zazwyczaj
tworzone w celu zapewnienia niskopoziomowej funkcjonalności dla witryn sieci Web usług IIS,
takiej jak niestandardowe uwierzytelnianie czy rejestrowanie żądań.
Niestandardowe rozwijanie komponentów ISAPI nie jest w dzisiejszych czasach zbyt
popularne z kilku powodów. Po pierwsze, niestandardowe składniki ISAPI są trudne
w projektowaniu, rozwijaniu i debugowaniu, ponieważ muszą być pisane w niezarządzanym kodzie C++ i wymagają zastosowania skomplikowanych technik, takich jak np. synchronizacje wątków. Większość programistów pracuje na poziomie wyższym niż ISAPI
i wykorzystuje technologie takie jak ASP i/lub ASP.NET. Mimo iż większość czytelników
prawdopodobnie nigdy nie zostanie zmuszona do napisania własnego komponentu ISAPI,
warto znać ich zastosowanie.
Pule aplikacji a proces roboczy IIS
Usługi IIS zapewniają elastyczną infrastrukturę do zarządzania procesami roboczymi przy
użyciu pul aplikacji. Pula aplikacji stanowi konfigurowalną jednostkę, która pozwala na
kontrolowanie sposobu, w jaki usługi IIS mapują witryny sieci Web usług IIS i katalogi
wirtualne do instancji procesu roboczego IIS. Należy zauważyć, że instancje procesu roboczego IIS są uruchamiane przy użyciu programów wykonywalnych o nazwie w3wp.exe,
jak zaprezentowano na Rysunku 2-2.
W3WP.EXE
DefaultAppPool
uruchomiona jako USŁUGA SIECIOWA
HTTP.SYS
W3WP.EXE
IntranetAppPool
uruchomiona jako
LITWAREINC\MyCustomAccount
Rysunek 2-2 Usługi IIS wykorzystują sterownik o nazwie HTTP.SYS do przekierowywania
nadsyłanych żądań do odpowiedniej puli aplikacji.
Architektura przekierowań IIS jest kontrolowana przez sterownik trybu jądra o nazwie
http.sys. Sterownik ten nasłuchuje nadchodzących żądań HTTP i wykorzystuje informacje pochodzące z metabazy IIS do odpowiedniego przekierowywania żądań do dowolnej
instancji w3wp.exe powiązanej z docelową pulą aplikacji. Gdy sterownik http.sys stwierdza, że z docelową pulą aplikacji nie jest powiązana działająca instancja w3wp.exe, uruchamia nową instancję w celu zapewnienia obsługi żądania.
Każda witryna sieci Web usług IIS i katalog wirtualny mogą być skonfigurowane tak,
aby uruchamiać swoją własną, osobną pulę aplikacji. Z drugiej strony w celu podniesienia
wydajności można skonfigurować wiele różnych witryn sieci Web usług IIS i katalogów
wirtualnych tak, aby działały one w tej samej puli aplikacji. Przede wszystkim należy mieć
na uwadze, że konieczne jest określenie kompromisu między izolacją a wydajnością. Aby
osiągnąć wyższą izolację, trzeba uruchomić więcej instancji programu w3wp.exe, co ma
35
negatywny wpływ na wydajność. Aby osiągnąć większą wydajność, trzeba zmapować wiele
witryn sieci Web usług IIS i katalogów wirtualnych do mniejszej liczby instancji procesu
roboczego IIS, co ma negatywny wpływ na izolację.
Każda pula aplikacji ma ważne ustawienie zwane tożsamością puli aplikacji. Tożsamość
puli aplikacji jest konfigurowana przy użyciu specjalnego konta użytkownika Windows,
które stanowi lokalne konto na serwerze sieci Web lub domenowe konto w domenie usługi
Active Directory. Gdy sterownik http.sys uruchamia nową instancję w3wp.exe na potrzeby
określonej puli aplikacji, wykorzystuje tożsamość tejże puli aplikacji do zainicjalizowania
tokenu zabezpieczeń Windows, który służy następnie jako token danego procesu. Jest to
istotne, ponieważ wiąże się z ustaleniem tożsamości uruchomienia dla kodu działającego
w ramach procesu roboczego IIS.
Domyślnie, gdy tworzona jest nowa pula aplikacji, usługi IIS wykorzystują tożsamość
lokalnego konta o nazwie Usługa sieciowa. Można skonfigurować tożsamość puli aplikacji,
wykorzystując inne, wybrane konto użytkownika. Zaleca się, aby wdrażając witryny sieci
Web bazujące na ASP.NET i WSS, konfigurować tożsamość puli aplikacji przy użyciu konta
domenowego, a nie lokalnego konta o nazwie Usługa sieciowa. Zalecenie to odnosi się
w szczególności do środowisk farmy sieci Web, w których zachodzi potrzeba synchronizowania tożsamości puli aplikacji na wielu serwerach frontonu sieci Web w farmie.
Restartowanie puli aplikacji
Programowanie w ASP.NET i WSS wiąże się czasem z potrzebą restartowania puli
aplikacji, które wykorzystuje się do testowania kodu. Potrzeba taka może pojawić się,
gdy trzeba odświeżyć plik XML w rozwijanej definicji funkcji lub gdy trzeba załadować nową wersję zestawu DLL z pamięci GAC. Można zrestartować wszystkie procesy
powiązane z usługami IIS, wykonując następujące polecenie z wiersza poleceń:
IISRESET
Można także zrestartować tylko proces powiązany z określoną pulą aplikacji, wykonując makro VB Script o nazwie iisapp.vbs, które jest standardowym elementem
instalacji usług IIS 6.0 począwszy od Windows Server 2003 SP 1. Trzeba uruchomić ten skrypt przy użyciu hosta uruchamiania skryptów, takiego jak cscript.exe.
Wywołując polecenie cscript.exe, wraz z wskazaniem ścieżki do pliku iisapp.vbs,
można zrestartować określoną pulę aplikacji, przekazując parametr /a wraz z nazwą
puli aplikacji IIS.
cscript.exe c:\windows\system32\iisapp.vbs /a "DefaultAppPool"
Główną zaletą tej metody jest to, że jest ona szybsza niż pełne polecenie IISRESET, które
restartuje wszystkie procesy powiązane z usługami IIS. Wykorzystując to polecenie
zamiast polecenia IISRESET, można zyskać parę sekund.
36
ASP.NET 2.0 Framework
ASP.NET Framework to warstwa wykorzystująca usługi IIS oraz model programowania
ISAPI oferująca szerokie możliwości. Czytelnicy, którzy mieli okazję programować w ASP.
NET, wiedzą, że technologia ta zapewnia wygodę pisania logiki aplikacji w języku platformy .NET, takim jak C# lub Visual Basic .NET i pracy z wszystkimi zorientowanymi na
produktywność programami do projektowania wchodzącymi w skład środowiska Microsoft
Visual Studio. ASP.NET Framework dostarcza również wiele innych, wartościowych elementów, wspomagających programistę w obszarach, takich jak zarządzanie stanem, wiązaniem danych, nawigacją i przechowywaniem danych w pamięci cache.
ASP.NET Framework został zaimplementowany jako rozszerzenie ISAPI o nazwie
aspnet_isapi.dll. Podstawowa konfiguracja ASP.NET obejmuje zarejestrowanie mapowania
aplikacji do typowych rozszerzeń plików ASP.NET m.in. .aspx, .ascx, .ashx oraz .asmx na
poziomie witryny sieci Web usług IIS lub katalogu wirtualnego. Gdy usługi IIS napotykają nadchodzące żądanie dotyczące pliku z jednym z tych rozszerzeń, żądanie to zostaje
przekierowane do rozszerzenia aspnet_isapi.dll, które przekazuje kontrolę do ASP.NET
Framework. Sposób, w jaki ASP.NET Framework przetwarza żądanie, zależy w dużym
stopniu od rozszerzenia docelowego pliku.
ASP.NET Framework wykonuje żądania dotyczące każdej z witryn sieci Web usług IIS
i każdego katalogu wirtualnego we własnej, odrębnej aplikacji ASP.NET. Za każdą aplikacją
ASP.NET kryje się katalog główny zawierający zestaw plików. Taka architektura umożliwia
wdrażanie aplikacji ASP.NET w prostym stylu x-copy. Wystarczy stworzyć nowy katalog
wirtualny na komputerze serwera sieci Web i skopiować pliki aplikacji ASP.NET do katalogu głównego. Oczywiście jest to trochę bardziej kłopotliwe w środowisku farmy sieci
Web, ponieważ tworzenie katalogu wirtualnego i kopiowanie plików trzeba powtórzyć na
każdym serwerze frontonu sieci Web w farmie.
Każda aplikacja ASP.NET może być konfigurowana niezależnie poprzez dodanie pliku
web.config w katalogu głównym. Plik web.config to bazujący na języku XML plik z elementami konfiguracyjnymi, które kontrolują działanie różnych funkcji ASP.NET Framework,
takich jak kompilacja, renderowanie stron i zarządzanie stanem. Prosty plik web.config
może wyglądać następująco:
<configuration>
<system.web>
<customErrors mode="On" />
<httpRuntime maxRequestLength="51200" />
<authentication mode="Windows" />
<identity impersonate="true" />
<authorization>
<allow users="*" />
</authorization>
</system.web>
</configuration>
Warto zauważyć, że ASP.NET Framework uruchamia każdą aplikację ASP.NET z zachowaniem określonego poziomu izolacji. Także w sytuacji, gdy konfiguracja zakłada uruchamianie wielu aplikacji ASP.NET w tej samej puli aplikacji IIS. ASP.NET Framework zapewnia
37
izolację między aplikacjami ASP.NET działającymi w obrębie tej samej instancji procesu
roboczego IIS, umieszczając każdą z nich w osobnej domenie aplikacji .NET Framework.
Strony ASP.NET
Strona stanowi jeden z najbardziej wartościowych obiektów w ASP.NET Framework.
Programiści budujący aplikacje ASP.NET zazwyczaj konstruują strony, przeciągając i upuszczając formanty serwera w obszarze projektowym w Visual Studio i modyfikując właściwości stron i formantów przy użyciu standardowych arkuszy właściwości. ASP.NET
Framework i Visual Studio w dużym stopniu ułatwiają także dodawanie logiki do stron
poprzez pisanie kodu zarządzanego, który jest wykonywany w odpowiedzi na zdarzenia
zachodzące na poziomie strony i formantu.
Na poziomie fizycznym strona w aplikacji ASP.NET stanowi plik z rozszerzeniem .aspx,
które znajduje się na serwerze sieci Web i jest na żądanie kompilowany do postaci DLL
przez środowisko uruchomieniowe ASP.NET. Przyjrzyjmy się następującej definicji strony
.aspx, która zawiera formant po stronie serwera oraz prostą procedurę obsługi zdarzenia.
<%@ Page Language="C#" %>
<script runat="server">
protected override void OnLoad(EventArgs e)
lblDisplay.Text = "Hello, ASP.NET";
}
</script>
{
<html>
<body>
<form id="frmMain" runat="server">
<asp:Label runat="server" ID="lblDisplay" />
</form>
</body>
</html>
Za sceną ASP.NET Framework wykonuje całkiem sporo pracy, aby skompilować plik .aspx
do postaci DLL. Po pierwsze, musi przeanalizować plik .aspx, aby wygenerować plik źródła
C# (lub Visual Basic .NET) zawierający publiczną klasę, która dziedziczy po klasie Page
zdefiniowanej w przestrzeni nazw System.Web.UI w zestawie system.web.dll. Gdy analizator stron ASP.NET generuje tę klasę wywodzącą się z klasy Page, buduje drzewo formantów zawierające wszystkie formanty serwera zdefiniowane w pliku strony. Analizator stron
dodaje również wymagany kod dla programów obsługi zdarzeń zdefiniowanych w stronie.
Gdy analizator stron ASP.NET skończy budowanie pliku źródłowego strony .aspx, może
przejść do kompilowania go do biblioteki DLL. Kompilacja ta następuje automatycznie podczas
pierwszego żądania pliku .aspx. Po skompilowaniu pliku .aspx do biblioteki DLL przez środowisko uruchomieniowe ASP.NET, kopia biblioteki DLL może być wykorzystywana podczas
wszystkich kolejnych żądań, które dotyczą tego samego pliku .aspx. Jednak środowisko ASP.
NET monitoruje znacznik czasu w pliku .aspx i gdy powiązany plik .aspx zostanie uaktualniony,
powtórnie uruchomi proces kompilacji w celu ponownego zbudowania biblioteki DLL.
Jeden z powodów, dla jakich ASP.NET Framework jest tak popularny, wiąże się z wygodą
zastosowania formantów serwera. Można bardzo łatwo konstruować strony, korzystając ze
standardowych formantów dostarczanych wraz z ASP.NET Framework, takich jak formanty
38
sprawdzania poprawności, formant kalendarza i formanty wspierające wiązanie danych,
takie jak GridView czy Repeater. Co więcej, programista może w stosunkowo prosty sposób
tworzyć niestandardowe formanty i wykorzystywać je na stronach.
Strony wzorcowe
Nowością w ASP.NET 2.0 są strony wzorcowe, które stanowią bardzo efektywne podejście
do określania szablonów stron. Zasadniczo, strona wzorcowa definiuje wspólne elementy,
które mają zostać umieszczone na wielu różnych stronach (np. górny transparent oraz
formanty nawigacji po witrynie). Układ zdefiniowany na stronie wzorcowej może zostać
zastosowany na wielu różnych powiązanych z nią stronach. W terminologii ASP.NET strona
powiązana ze stroną wzorcową nazywana jest stroną zawartości. Podstawowa relacja między stroną wzorcową a powiązanymi z nią stronami zawartości została zaprezentowana na
Rysunku 2-3.
Strona zawartości 1
default.master
nawigacja
Transparent
zawartość dla
zastępczy2
Transparent
zastępczy1
zastępczy2
Strona zawartości 2
Transparent
nawigacja
nawigacja
zawartość dla
zastępczy1
zawartość dla
zastępczy1
zawartość dla
zastępczy2
Rysunek 2-3 Strona wzorcowa definiuje wspólny układ i nazwane symbole zastępcze, które
można zastąpić na stronach zawartości powiązanych ze stroną wzorcową.
Załóżmy na przykład, że tworzymy stronę wzorcową definiującą układ HTML z elementem
graficznym (transparentem) w górnej części strony. Na początku tworzymy plik z rozszerzeniem .master np. default.master. Następnie, dodajemy dyrektywę @Master w nagłówku
strony. Poniżej definiujemy układ HTML strony i dodajemy nazwane symbole zastępcze
(contentplaceholder), jak w następującym przykładzie.
<%@ Master %>
<html>
<body>
<form id="frmMain" runat="server">
<table width="100%">
39
<tr>
<td> <! – - Wyświetla banner firmy Litware -->
<h1>Litware Inc.</h1><hr />
</td>
</tr>
<tr>
<td> <! – - Wyświetla główną zawartość danej strony -->
<asp:contentplaceholder id="PlaceHolderMain" runat="server" />
</td>
</tr>
</table>
</form>
</body>
</html>
Gdy chcemy stworzyć stronę zawartości, tworzymy plik .aspx i dodajemy dyrektywę
@Page, która zawiera atrybut MasterPageFile. Gdy już zadecydujemy, który z nazwanych
symboli zastępczych zdefiniowanych na stronie wzorcowej chcemy zastąpić, definiujemy
elementy Content dla każdego z nich. Poniżej zaprezentowany został prosty przykład
strony zawartości powiązanej ze stroną default.master zaprezentowaną w poprzednim
przykładzie. W kodzie tym zawartość jest umieszczana w symbolu zastępczym o nazwie
PlaceHolderMain.
<%@ Page Language="C#" MasterPageFile="~/default.master" %>
protected override void OnLoad(EventArgs e)
lblDisplay.Text = "Hello World";
}
</script>
{
<asp:Content ID="main" Runat="Server"
ContentPlaceHolderID="PlaceHolderMain" >
<asp:Label ID="lblDisplay" runat="server" />
</asp:Content>
Trzeba zapamiętać, że gdy tworzymy stronę zawartości powiązaną ze stroną wzorcową, cały
kod HTML, który chcemy dodać, musi zostać umieszczony wewnątrz elementu Content
wskazującego określony nazwany symbol zastępczy. Strona nie będzie mogła zostać skompilowana, gdy zawiera formanty HTML lub serwerowe dodane poza elementem Content.
Jednak, jak widać na podstawie poprzedniego przykładu, poza elementem Content można
umieścić blok skryptu i dodać do niego dowolny kod.
Gdy strona wzorcowa definiuje nazwany symbol zastępczy, nie trzeba umieszczać go
na stronie zawartości, strona wzorcowa może definiować symbol wraz ze znajdującą się
w nim zawartością domyślną. Zawartość ta pojawi się na każdej stronie zawartości, która
jest powiązana z tą stroną wzorcową i nie zawiera określonego nazwanego symbolu zastępczego. Pozostałe strony zawartości, które są powiązane z tą samą stroną wzorcową, ale
zawierają dany nazwany symbol zastępczy, nadpiszą zawartość domyślną, zastępując ją
swoją własną zawartością niestandardową.
Na zakończenie, zwróćmy uwagę, że to osoby tworzące stronę wzorcową decydują,
jakie zawiera ona nazwane symbole zastępcze oraz zawartość domyślną. Jest to szczególnie istotne w przypadku projektowania stron dla witryny WSS, kiedy programista tworzy
40
strony zawartości powiązane ze stronami wzorcowymi stworzonymi przez zespół WSS.
W takiej sytuacji, trzeba poznać symbole zastępcze zdefiniowane przez zespół WSS oraz
typy zawartości, które można zastępować.
Potok Żądań HTTP
Pod zorientowaną na produktywność architekturą stron i formatów serwera, ASP.NET
Framework udostępnia Potok Żądań HTTP z myślą o programistach, którzy wolą pracować
na niższym poziomie. Dzięki temu programista uzyskuje poziom kontroli porównywalny
z zapewnianym przez model programowania ISAPI. Z tą przewagą, że tworząc komponenty
dla Potoku Żądań HTTP, można pisać kod w języku zarządzanym, takim jak C# czy Visual
Basic .NET. Można również użyć interfejsów API dostarczanych przez ASP.NET Framework,
co jest dużo łatwiejsze od wykorzystywania modelu programowania ISAPI.
Rysunek 2-4 prezentuje Potok Żądań HTTP wraz z trzema typami komponentów, które
można zastępować: HttpHandler, HttpApplication oraz HttpModule. Nadchodzące żądania
są ustawiane w kolejce i przypisywane do wątku roboczego, który następnie przetwarza
żądanie poprzez interakcję z każdym z tych typów komponentów.
HttpContext
wątek
roboczy
HttpApplication
HttpModule1
HttpHandler
HttpModule2
HttpModule3
Rysunek 2-4 Potok Żądań HTTP umożliwia programistom zastępowanie komponentów,
takich jak HttpHandler, HttpApplication oraz HttpModule.
Ostatecznym celem każdego żądania jest punkt końcowy, który został zamodelowany
w Potoku Żądań HTTP przy użyciu klasy HttpHandler, która implementuje interfejs
IHttpHandler. Programista może stworzyć niestandardowy komponent HttpHandler
i uwzględnić go w Potoku Żądań HTTP, dodając elementy konfiguracyjne do pliku web.
config.
W Potoku Żądań HTTP komponent HttpApplication znajduje się przed komponentem
HttpHandler. Nadsyłane do całej aplikacji żądania są zawsze przekierowywane przez komponent HttpApplication, zanim dotrą do odpowiednich komponentów HttpHandler, co
umożliwia komponentowi HttpApplication wstępne przetwarzanie wszystkich żądań niezależnie od tego, do którego komponentu HttpHandler są one kierowane. Etap wstępnego
przetwarzania obejmuje serię zdarzeń zdefiniowanych w klasie HttpApplication, takich jak
BeginRequest, AuthenticateRequest i AuthorizeRequest.
W sytuacji, gdy nie chce się wykorzystywać niestandardowego komponentu
HttpApplication, ASP.NET Framework inicjalizuje Potok Żądań HTTP przy użyciu standardowego obiektu HttpApplication, który zapewnia domyślny mechanizm obsługi
41
nadchodzących komunikatów. Jednak można zastąpić ten standardowy komponent, tworząc plik o nazwie global.asax i umieszczając go w katalogu głównym aplikacji ASP.NET
pełniącej rolę hosta. Plik global.asax może być podobny do następującego:
<%@ Application Language="C#" %>
protected void Application_AuthenticateRequest(object sender, EventArgs e) {
// kod obsługujący żądania uwierzytelniania znalazłby się tutaj
}
protected void Application_AuthorizeRequest(object sender, EventArgs e)
// kod obsługujący żądania autoryzacji znalazłby się tutaj
}
{
</script>
Trzeci z typów obiektów w Potoku Żądań HTTP, który można podmieniać własną implementacją, to HttpModule. Komponent HttpModule, podobnie jak komponent HttpApplication,
został zaprojektowany z myślą o obsłudze zdarzeń zdefiniowanych przez klasę HttpApplication
i jest przetwarzany przed przekazaniem kontroli do jakiejkolwiek klasy HttpHandler. Można
na przykład stworzyć niestandardowy komponent HttpModule do obsługi zdarzeń na poziomie żądań, takich jak BeginRequest, AuthenticateRequest czy AuthorizeRequest. Tak jak
w przypadku klasy HttpHandler, klasa HttpModule jest zdefiniowana wraz z interfejsem.
Można stworzyć klasę implementującą interfejs IHttpModule i uwzględnić ją w Potoku Żądań
HTTP, dodając elementy konfiguracyjne do pliku web.config.
Podczas gdy niestandardowe komponenty HttpApplication mogą być definiowane jako
zwykłe pliki tekstowe z rozszerzeniem .asax, niestandardowe komponenty HttpModule
są zawsze kompilowane jako klasy w zestawach DLL. Aby dodać niestandardowy komponent HttpModule do Potoku Żądań HTTP, należy dodać odpowiednie wpisy do pliku
web.config.
Funkcjonalność komponentów HttpApplication i HttpModule jest podobna, jednak istnieje kilka różnic wartych podkreślenia. Po pierwsze, nie trzeba ograniczać się do jednego
komponentu HttpModule dla aplikacji, jak w przypadku komponentów HttpApplication.
Plik web.config dla aplikacji ASP.NET może definiować kilka różnych komponentów
HttpModule. Po drugie, komponenty HttpModule mogą być konfigurowane na poziomie
maszyny. W rzeczywistości, ASP.NET Framework oferuje kilka różnych komponentów
HttpModule, które są automatycznie konfigurowane na poziomie maszyny, aby dostarczać funkcjonalność ASP.NET w obszarach, takich jak uwierzytelnianie systemu Windows,
uwierzytelnianie przy użyciu formularzy oraz pamięć podręczna stron wyjściowych.
Ostatni komponent, który zostanie zaprezentowany w ramach omawiania Potoku Żądań
HTTP, to HttpContext. Gdy ASP.NET inicjalizuje żądanie wysyłane do Potoku Żądań HTTP,
tworzy obiekt klasy HttpContext i inicjalizuje go przy użyciu istotnych informacji kontekstowych.
Uwzględniając następstwo czasowe, warto zauważyć, że ASP.NET tworzy ten obiekt,
zanim jakikolwiek niestandardowy kod wewnątrz Potoku Żądań HTTP ma możliwość rozpoczęcia pracy. Oznacza to, że zawsze można użyć w kodzie obiektu HttpContext oraz
42
jego obiektów podrzędnych, takich jak Request, User oraz Response. Gdy tworzy się komponent, który ma być wykonywany w ramach potoku obsługi żądania HTTP, można użyć
następującego kodu:
HttpContext currentContext = HttpContext.Current;
string incomingUrl = currentContext.Request.Url;
string currentUser = currentContext.User.Identity.Name;
currentContext.Response.Write("Hello world");
Dodatkowa bibliografia dotycząca technologii ASP.NET
Zachęcamy czytelników do pogłębiania wiedzy o ASP.NET 2.0, ponieważ dzięki temu
podnosi się swoje kwalifikacje jako programisty WSS 3.0. Podczas tworzenia rozwiązań WSS 3.0 można wykorzystać wiele zaawansowanych technik ASP.NET. Poniżej
zaprezentowana została lista kilku tytułów, które szczególnie przypadły do gustu
autorom niniejszej książki.
■ Programming ASP.NET 2.0: Core Reference, Dino Esposito (Microsoft Press, 2006)
■ Programming ASP.NET 2.0 Applications: Advanced Topics, Dino Esposito (Microsoft
Press, 2006)
■ Essential ASP.NET 2.0, 2nd Edition, Fritz Onion oraz Keith Brown (Addison-Wesley
Professional, 2007)
Integracja technologii WSS z ASP.NET
Poznawanie zagadnienia integracji technologii WSS z ASP.NET warto rozpocząć od zrozumienia wysokopoziomowych celów projektowych usług WSS, które zostały opracowane
w celu wzbogacenia ASP.NET Framework. Usługi WSS zwiększają funkcjonalność ASP.NET
w środowiskach, które wymagają stałego tworzenia, aktualizowania i usuwania witryn.
Ponadto usługi WSS dodają do ASP.NET zestaw elementów witryn, które pozwalają administratorom witryn w szybki sposób tworzyć strony, listy i biblioteki dokumentów w kontekście witryny.
Usługi WSS integrują się z platformą ASP.NET na poziomie witryny sieci Web usług IIS.
Każda witryna sieci Web usług IIS, która ma pełnić rolę hosta dla witryn WSS, musi przejść
przez jednorazowy proces transformacji, w którym zostaje ona skonfigurowana do postaci
nazywanej w terminologii WSS aplikacją sieci Web. Proces transformacji obejmuje dodanie
wpisów do metabazy IIS i pliku web.config usług WSS w katalogu głównym pełniącej rolę
hosta witryny sieci Web usług IIS. Po zakończeniu transformacji, usługi WSS rozszerzają
architekturę przekierowań usług IIS i ASP.NET w celu odpowiedniego przesyłania wszystkich nadsyłanych żądań za pośrednictwem środowiska uruchomieniowego WSS.
W kolejnej części niniejszego rozdziału omówione zostaną praktyczne aspekty dotyczące
konfiguracji aplikacji sieci Web. Jednak przed zagłębieniem się w szczegóły warto dokonać
pewnego, istotnego spostrzeżenia. A mianowicie rozważyć rolę, jaką aplikacja sieci Web
jako całość pełni w ogólnym obrazie architektury usług WSS ze szczególnym uwzględnieniem funkcjonalności zarządzania i skalowalności.
43
Tworzenie aplikacji sieci Web usług WSS stanowi ważne administracyjne zadanie, które
wymaga uprawnień administratora na poziomie farmy. Stworzenie aplikacji sieci Web
wymaga dokonania wielu zmian w systemie plików i metabazie IIS na każdym serwerze
frontonu sieci Web. W środowisku farmy sieci Web zmiany te są automatycznie odzwierciedlane przez środowisko uruchomieniowe WSS na każdym serwerze frontonu sieci Web
w farmie. Etap tworzenia aplikacji sieci Web jest konieczny tylko w przypadku wstępnego
instalowania i konfigurowania usług WSS.
Po stworzeniu aplikacji sieci Web nie trzeba już ingerować w system plików lub metabazę IIS na serwerze frontonu sieci Web podczas tworzenia, aktualizowania i usuwania
witryn lub zbiorów witryn. Architektura WSS umożliwia dostarczanie nowych witryn
i zbiorów witryn po prostu poprzez dodawanie wpisów do bazy danych konfiguracji i bazy
danych zawartości. Ten aspekt architektury WSS daje jej znaczącą przewagę nad platformą
ASP.NET w zakresie zarządzania i udostępniania. Zwiększone możliwości zarządzania są
jeszcze wyraźniej zauważalne w środowisku farmy sieci Web.
Aplikacje sieci Web
Istnieją dwa podstawowe sposoby tworzenia aplikacji sieci Web przy użyciu aplikacji
Administracji Centralnej WSS lub narzędzia wiersza poleceń – stsadm.exe. Pierwszy z nich
polega na stworzeniu aplikacji sieci Web poprzez przekonwertowanie istniejącej witryny
sieci Web usług IIS. Drugim sposobem jest stworzenie nowej aplikacji sieci Web od podstaw i zlecenie usługom WSS stworzenia witryny sieci Web usług IIS w tle. W obu przypadkach usługi WSS konfigurują wynikową witrynę sieci Web usług IIS poprzez dodanie
mapowania aplikacji IIS i stworzenie kilku katalogów wirtualnych. Ponadto usługi WSS
kopiują plik global.asax i plik web.config do katalogu głównego witryny sieci Web usług
IIS pełniącej role hosta.
Usługi WSS muszą dodać mapowanie aplikacji IIS dla każdej aplikacji sieci Web, aby
zagwarantować, że każde nadchodzące żądanie będzie wstępnie przekierowywane do środowiska ASP.NET. Należy pamiętać, że domyślna konfiguracja dla ASP.NET rejestruje tylko
mapowania aplikacji dla żądań z typowymi rozszerzeniami plików ASP.NET, takimi jak
.aspx, ascx, .ashx oraz .asmx. A usługi WSS konfigurują pełniącą role hosta witrynę sieci
Web usług IIS przy użyciu wieloznacznych mapowań aplikacji w celu przekierowywania do
aspnet_isapi.dll wszystkich nadsyłanych żądań, w tym także żądań z rozszerzeniami, które
nie są charakterystyczne dla ASP.NET, takimi jak .doc, .docx oraz .pdf.
Ponieważ każde żądanie skierowane do aplikacji sieci Web jest przesyłane poprzez
aspnet_isapi.dll, automatycznie zostaje ono w pełni zainicjalizowane w kontekście ASP.NET.
Co więcej, mechanizm przetwarzania można kontrolować poprzez użycie niestandardowego
obiektu HttpApplication i dodanie elementów konfiguracyjnych do pliku web.config. Zespół
WSS wykorzystuje standardowe techniki ASP.NET do rozszerzania potoku żądań HTTP za
pomocą kilku niestandardowych komponentów, jak pokazano na Rysunku 2-5.
Jak widać na Rysunku, usługi WSS konfigurują każdą aplikację sieci Web z niestandardowym obiektem HttpApplication przy użyciu klasy SPHttpApplication. Należy zauważyć, że klasa ta jest instalowana wraz z systemowym zestawem WSS o nazwie Microsoft.
SharePoint.dll. Usługi WSS integrują niestandardową klasę poprzez stworzenie niestandardowego pliku global.asax na najwyższym poziomie aplikacji sieci Web dziedziczącej
po SPHttpApplication.
44
HttpContext
wątek
roboczy
SPHttpApplication
SPRequestModule
SPHttpHandler
Moduł ASP.NET 1
Moduł ASP.NET 2
Rysunek 2-5 Usługi WSS rozszerzają standardowy potok żądań HTTP ASP.
NET przy użyciu niestandardowych komponentów.
<@Application Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" >
Poza wykorzystaniem niestandardowego obiektu HttpApplication architektura WSS wykorzystuje niestandardową implementację klasy HttpHandler i niestandardowy HttpModule.
Te dwa komponenty charakterystyczne dla usług WSS są integrowane z potokiem żądań
HTTP dla aplikacji sieci Web za pomocą standardowych wpisów w pliku web.config.
Warto przyjrzeć się zaprezentowanemu poniżej fragmentowi kodu XML, który stanowi
część standardowego pliku web.config wykorzystywanego przez aplikację sieci Web usług
WSS 3.0.
<configuration>
<system.web>
<httpHandlers>
<remove verb="GET,HEAD,POST" path="*" />
<add verb="GET,HEAD,POST" path="*"
type="Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, ..." />
</httpHandlers>
<httpModules>
<clear />
<add name="SPRequest"
type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, ..." />
<! – - pozostałe standardowe wpisy definiujące biblioteki httpModules ASP.
NET -->
</httpModules>
</system.web>
</configuration>
Członkowie zespołu WSS stworzyli swój własny obiekt HttpModule o nazwie
SPRequestModule służący do inicjalizowania różnych aspektów środowiska uruchomieniowego WSS. Jak widać, standardowy plik WSS web.config konfiguruje SPRequestModule tak,
aby był to pierwszy obiekt HttpModule odpowiadający na zdarzenia na poziomie aplikacji
w potoku żądań HTTP w ASP.NET. Sprawdzając plik web.config dla aplikacji sieci Web
WSS, można się przekonać, że usługi WSS dodają wsparcie dla kilku standardowych dla
ASP.NET Framework komponentów HttpModule, które obsługują takie aspekty jak przechowywanie danych wyjściowych w pamięci cache czy różnego typu uwierzytelnienia.
45
Standardowy plik WSS web.config rejestruje również obiekt HttpHandler o nazwie
SPHttpHandler i konfiguruje go przy użyciu ścieżki "*". Umożliwia to usługom WSS
dostarczanie klasy SPHttpHandler jako pojedynczego punktu końcowego dla wszystkich
nadsyłanych żądań.
Podsumowując, architekturę WSS można było zrealizować dzięki rozszerzeniom potoku
żądań HTTP. To umożliwiło usługom WSS pełne wykorzystanie wbudowanych możliwości
platformy ASP.NET Framework przy jednoczesnym przejęciu kontroli nad każdym żądaniem skierowanym do aplikacji sieci Web.
Standardowy plik web.config dla aplikacji sieci Web
W poprzedniej części rozdziału można było przekonać się, że plik web.config dla aplikacji
sieci Web zawiera standardowe elementy konfiguracyjne ASP.NET. Jednak usługi WSS idą
o krok dalej, rozszerzając standardowy format pliku ASP.NET web.config o niestandardową sekcję SharePoint. Poniżej zaprezentowano fragment kodu XML, który zawiera sekcję
SharePoint pliku web.config i elementy w configSections, które dostarczają dodatkowych
informacji konfiguracyjnych wymaganych przez ASP.NET.
<configuration>
<configSections>
<sectionGroup name="SharePoint">
<section name="SafeControls" type="..." />
<section name="RuntimeFilter" type="..." />
<section name="WebPartLimits" type="..." />
<section name="WebPartCache" type="..." />
<section name="WebPartWorkItem" type="..." />
<section name="WebPartControls" type="..." />
<section name="SafeMode" type="..." />
<section name="MergedActions" type="..." />
<section name="PeoplePickerWildcards" type="..." />
</sectionGroup>
</configSections>
<SharePoint>
<SafeMode />
<WebPartLimits />
<WebPartCache />
<WebPartControls />
<SafeControls />
<PeoplePickerWildcards />
<MergedActions />
<BlobCache />
<RuntimeFilter />
</SharePoint>
</configuration>
Elementy konfiguracyjne, które są zagnieżdżone w sekcji SharePoint, są odczytywane przez
różne komponenty środowiska uruchomieniowego WSS. Dla każdego elementu zagnieżdżonego w sekcji SharePoint istnieje odpowiadający mu element sekcji w elemencie configSections,
który określa, jaka klasa konfiguracyjna jest wykorzystywana do odczytywania tej informacji
w czasie wykonania. To umożliwia różnym komponentom środowiska uruchomieniowego
46
WSS odczytywanie charakterystycznych dla usług WSS informacji konfiguracyjnych podczas
przetwarzania żądania. W niniejszej książce zaprezentowanych zostanie szereg technik programistycznych, które wymagają dodania lub modyfikowania elementów w sekcji SharePoint
w pliku web.config.
SPVirtualPathProvider
Jedną z przewag usług WSS nad platformą ASP.NET jest możliwość dostarczania i dostosowywania stron w witrynie, bez konieczności dokonywania jakichkolwiek zmian w lokalnym
systemie plików na serwerze frontonu sieci Web. Taki mechanizm dostarczania i dostosowywania stron w WSS stał się możliwi dzięki przechowywaniu dostosowanych wersji
plików .aspx i .master w bazie danych zawartości i pobieraniu ich na żądanie, gdy są one
niezbędne do obsłużenia żądania strony.
Przyjrzyjmy się prostemu przykładowi działania mechanizmu dostosowywania stron
w usługach WSS. Wyobraźmy sobie, że chcemy zmodyfikować układ HTML strony głównej (default.aspx) wybranej witryny przy użyciu programu Microsoft Office SharePoint
Designer. Gdy modyfikujemy i zapisujemy stronę przy użyciu tego programu, usługi WSS
zapisują całą zawartość dostosowanej definicji strony w bazie danych zawartości. Od tego
momentu, gdy nadsyłane jest żądanie dotyczące tej samej strony, usługi WSS pobierają
zawartość dostosowanej definicji strony z bazy danych zawartości i przekazują ją do środowiska ASP.NET celem przeanalizowania. Za chwilę omówione zostaną elementy architektury, dzięki którym jest to możliwe.
W wersji ASP.NET 2.0 wprowadzono nowy, dynamicznie podłączany typ komponentu
o nazwie dostawca ścieżek wirtualnych. Dostawca ścieżek wirtualnych ma w założeniu
zapewnić oderwanie szczegółowych danych dotyczących miejsca przechowywania plików
strony od środowiska ASP.NET. Tworząc niestandardowego dostawcę ścieżek wirtualnych,
programista może napisać niestandardowy składnik, który pobiera typy plików ASP.NET,
takie jak .aspx i .master z lokalizacji zdalnej, takiej jak baza danych Microsoft SQL Server.
Gdy dostawca ścieżek wirtualnych pobiera zawartość strony .aspx, może przekazać ją do
środowiska ASP.NET celem dalszego przetwarzania.
Zespół WSS stworzył dostawcę ścieżek wirtualnych o nazwie SPVirtualPathProvider,
który jest zintegrowany z każdą aplikacją sieci Web. Klasa SPVirtualPathProvider jest zintegrowana z infrastrukturą obsługi żądań ASP.NET poprzez komponent SPRequestModule.
A dokładniej, komponent SPRequestModule zawiera kod służący do rejestrowania klasy
SPVirtualPathProvider w ASP.NET Framework podczas dokonywania inicjalizacji aplikacji
sieci Web. Na Rysunku 2-6 zaprezentowany został diagram obrazujący rolę komponentu
SPVirtualPathProvider.
Jak widać na Rysunku, komponent SPVirtualPathProvider może pobrać plik strony
ASP.NET (np. default.aspx) z bazy danych zawartości, a następnie przekazać go do analizatora stron ASP.NET. Klasa SPVirtualPathProvider współpracuje z inną klasą o nazwie
SPPageParserFilter w celu dostarczenia instrukcji przetwarzania do analizatora stron ASP.
NET. Na przykład, komponent SPPageParserFilter kontroluje, czy analizator stron ASP.
NET kompiluje stronę ASP.NET do zestawu DLL czy też przetwarza stronę w trybie bez
kompilacji, który został wprowadzony w wersji ASP.NET 2.0. W kolejnym rozdziale
omówiony zostanie mechanizm dodawania wpisów do pliku web.config, z którego klasa
SPPageParserFilter czerpie informacje o sposobie przetwarzania pobieranych stron.
SPVirtualPathProvider
47
Analizator stron
ASP.NET.ASPX
SPPageParserFilter
default.aspx
Baza danych zawartości
Rysunek 2-6 Usługi WSS wykorzystują niestandardowego dostawcę ścieżek wirtualnych do
zaangażowania analizatora stron .aspx dostarczanego przez ASP.NET 2.0.
Komponent SPVirtualPathProvider odgrywa bardzo istotną rolę w ogólnej architekturze
WSS, ponieważ stanowi fundament mechanizmu wspierania dostosowań stron. Wspiera
on także ważną, z punktu widzenia wydajności, funkcjonalność o nazwie widmowość stron
(ang. page ghosting), która stanowi kluczowy element zapewniający skalowanie farmy WSS
na dziesiątki tysięcy stron we wszystkich witrynach w farmie. Zaprezentujemy teraz krótki
przykład ilustrujący działanie tego mechanizmu.
Wyobraźmy sobie, że stworzyliśmy 100 nowych witryn WSS na podstawione szablonu
Pusta witryna. Jeśli żadna z tych witryn nie wymaga dostosowanej wersji strony głównej
(default.aspx), czy miałoby sens kopiowanie tego samego pliku definicji do bazy danych
zawartości 100 razy? Odpowiedź na to pytanie jest oczywista: nie. Na szczęście strony
w witrynie WSS, takie jak default.aspx, bazują na szablonach stron, które znajdują się
w systemie plików na serwerze frontonu sieci Web. Szablony stron są wykorzystywane do
obsługi wystąpień strony w kontekście witryn, jak np. strona dostępna przy użyciu określonego adresu URL http://litwareinc.com/default.aspx.
Gdy wystąpienie strony zostaje wstępnie stworzone na podstawie szablonu strony, usługi
WSS nie muszą zapisywać jego kopii w bazie danych zawartości, ponieważ mogą pobrać szablon
strony z systemu plików na serwerze sieci Web i wykorzystać go do przetwarzania wszystkich
żądań niedostosowanego wystąpienia strony. A zatem można powiedzieć, że termin widmowość
stron opisuje akt przetwarzania żądania niedostosowanego wystąpienia strony przy użyciu szablonu strony pobranego do pamięci z systemu plików na serwerze frontonu sieci Web.
Widmowość stron jest bardzo użyteczna, ponieważ eliminuje konieczność przesyłania
zawartości pliku definicji strony z komputera pełniącego rolę serwera SQL Server z bazą
danych zawartości do komputera pełniącego rolę serwera frontonu sieci Web. Widmowość
stron umożliwia także przetwarzanie stron głównych dla tysięcy różnych witryn przy użyciu
jednego szablonu strony, który jest kompilowany do zestawu DLL i pobierany do pamięci
w procesie roboczym IIS tylko jednokrotnie dla aplikacji sieci Web. Obie te funkcje stanowią kluczowe czynniki wpływające na skalowalność usług WSS w środowiskach o wysokim
natężeniu ruchu, w których uruchomione są tysiące lub nawet dziesiątki tysięcy witryn.
Zmodyfikowanie strony i zapisanie jej dostosowanej wersji w bazie danych zawartości przy użyciu programu SharePoint Designer uniemożliwia wykorzystanie widmowości
stron. Zamiast tego, dostarczony SPVirtualPathProvider musi pobrać dostosowaną wersję
48
strony z bazy danych zawartości, jak zaprezentowano na Rysunku 2-6. Z tego względu
dostosowane strony nazywane są niekiedy stronami niewidmowymi.
Rozumiejąc już sposób, w jaki usługi WSS przetwarzają żądania zarówno stron widmowych, jak i niewidmowych, można dostrzec, jak ważną rolę pełni SPVirtualPathProvider.
To SPVirtualPathProvider określa, czy żądana strona została dostosowana. To
SPVirtualPathProvider decyduje, czy strona ma być przetwarzana jako widmowa czy też
niewidmowa. Warto również zauważyć, że wszystkie aspekty widmowości i niewidmowości stron są niezależne od środowiska ASP.NET i stanowią funkcję oferowaną właśnie dzięki
wykorzystaniu usług WSS.
Analizowanie stron w wersji WSS 2.0
Poprzednia wersja usług WSS bazowała na platformie ASP.NET 1.1, która nie dostarczała
odpowiednika modelu dostawcy ścieżek wirtualnych wprowadzonego w wersji ASP.
NET 2.0. Z tego względu zespół WSS stworzył własny analizator stron .aspx analizujący
dostosowane pliki aspx po pobraniu ich z bazy danych zawartości. Niestety, analizator
stron .aspx stworzony przez zespół WSS dla wersji WSS 2.0 nie wspierał wielu bardziej
zaawansowanych funkcji oferowanych przez analizator stron ASP.NET, takich jak formanty użytkownika. Nowa architektura wprowadzona w wersji WSS 3.0, która zawiera
komponent SPVirtualPathProvider oraz analizator stron ASP.NET, stanowi jedno z najistotniejszych ulepszeń architekturalnych w stosunku do wersji WSS 2.0.
Katalogi wirtualne z aplikacji sieci Web
Gdy usługi WSS konwertują witrynę sieci Web usług IIS do aplikacji sieci Web, tworzą
kilka katalogów wirtualnych. Te katalogi wirtualne m.in. katalog _controltemplates, katalog _layouts, katalog _vti_bin oraz katalog _wpresources, są wykorzystywane przez środowisko uruchomieniowe WSS w różnych kontekstach. Można zobaczyć listę katalogów
wirtualnych, przeglądając aplikację sieci Web przy użyciu narzędzia Menedżer usług IIS,
jak zaprezentowano na Rysunku 2-7.
Rysunek 2-7 Witryna sieci Web usług IIS skonfigurowana jako aplikacja sieci Web
zawiera cztery standardowe katalogi wirtualne, w tym katalog _layouts.
Jak widać na Rysunku 2-7, każdy z katalogów wirtualnych w aplikacji sieci Web jest mapowany do katalogu fizycznego w systemie plików na serwerze frontonu sieci Web pod następującym adresem:
c:\program files\common files\microsoft shared\web server extensions
49
Każdy z tych katalogów wirtualnych pełni określoną rolę w ogólnej architekturze WSS.
Na przykład, katalog _vit_bin umożliwia usługom WSS udostępnianie bibliotek DLL oraz
plików usług sieci Web .asmx pod określoną ścieżką w przestrzeni adresów URL aplikacji
sieci Web. Katalog _controltemplates stanowi repozytorium dedykowane do umieszczania
w nim formantów użytkownika ASP.NET, które mogą zostać wykorzystane na stronach.
Katalog wirtualny _wpresources stanowi repozytorium plików zasobów, które są instalowane wraz ze składnikami Web Part.
Jeden z katalogów wirtualnych aplikacji sieci Web _layouts zostanie w niniejszym rozdziale omówiony bardziej szczegółowo, ponieważ stanowi podstawowe wsparcie dla specjalnego typu stron zwanych stronami aplikacji. Strony aplikacji są dostarczane z katalogu
_layouts i oferują szczególną funkcjonalność, która zostanie omówiona w kolejnej sekcji.
Strony witryn konta strony aplikacji
Niektóre strony w witrynie WSS np. strona główna (default.aspx), wspierają dostosowania dokonywane przez użytkowników za pomocą narzędzi, takich jak SharePoint Designer. Strony, które
wspierają dostosowywania użytkowników, nazywane są stronami witryn. Wsparcie dostosowań
stron witryn zapewnia wysoką elastyczność, jednakże ma również słabe punkty. Aby wspierać
dostosowywanie stron bez znaczącego obniżania skalowalności, usługi WSS muszą zastosować
schemat widmowości stron omówiony we wcześniejszej części niniejszego rozdziału. Mimo to
dostosowania stron mogą w sposób odczuwalny wpływać na skalowalność.
Wyobraźmy sobie duże środowisko WSS z aplikacją sieci Web, w której działają tysiące
witryn. Co stałoby się, gdyby administrator każdej z witryn zmodyfikował stronę główną
witryny przy użyciu programu SharePoint Designer? Każda z tych stron witryn stałaby
się stroną niewidmową, a to negatywnie wpłynęłoby na skalowalność, zmuszając serwer
frontonu sieci Web do pobierania z bazy danych zawartości każdej strony z osobna. Każda
strona musiałaby również być indywidualnie analizowana i pobierana do pamięci.
Warto również wziąć pod uwagę fakt, że po dostosowaniu strony jej kopia musi zostać
umieszczona w bazie danych zawartości. A to pociąga za sobą kwestie bezpieczeństwa.
Wyobraźmy sobie sytuację, w której złośliwy użytkownik o uprawnieniach administratora
witryny w zbiorze witryn próbuje dokonać ataku, dopisując kod wewnętrzny w dostosowanej wersji strony witryny. Usługi WSS łagodzą to zagrożenie poprzez domyślną zasadę,
która zakazuje wykorzystania wewnętrznych skryptów w stronach witryn. Ponadto
domyślna zasada uruchamia strony witryn w trybie bez kompilacji, co oznacza, że nie są
one kompilowane do bibliotek DLL.
Podsumowując, wsparcie dostosowywania stron witryn wiąże się z problemami w zakresie wydajności i bezpieczeństwa. Jak już wspomniano, architektura WSS wprowadza inny
typ stron zwany stronami aplikacji. Jedną z kluczowych cech stron aplikacji jest to, że nie
wspierają one dostosowywania. A zatem strony aplikacji pozwalają uniknąć problemów
związanych z wydajnością i bezpieczeństwem, które występują w przypadku stron witryn.
Standardowa strona Ustawienia witryny (settings.aspx) stanowi dobry przykład strony aplikacji. Można uzyskać do niej dostęp z dowolnej witryny, jednocześnie nie wspiera ona dostosowywania. Strony aplikacji, takie jak settings.aspx, są instalowane w postaci plików fizycznych
w systemie plików na serwerze frontonu sieci Web w katalogu o następującej ścieżce:
c:\program files\common files\microsoft shared
\web server extensions\12\TEMPLATE\LAYOUTS
50
Warto zauważyć, że fizyczny katalog \LAYOUTS jest mapowany do katalogu wirtualnego
_layouts za każdym razem, gdy usługi WSS tworzą nową aplikację sieci Web. Dzięki wykorzystaniu tego schematu mapowania wraz z pewną dodatkową logiką przetwarzania, środowisko uruchomieniowe WSS może uczynić każdą stronę aplikacji dostępną w kontekście
dowolnej witryny w farmie. Załóżmy na przykład, że w farmie istnieją trzy różne witryny
dostępne za pośrednictwem następujących adresów URL:
http://Litwareinc.com
http://Litwareinc.com/sites/Vendors
http://Litwareinc.com:1001/sites/Accounting
Można uzyskać dostęp do strony aplikacji, takiej jak settings.aspx, dodając jej relatywną
ścieżkę w katalogu _layouts na końcu adresu URL witryny. Na przykład do uzyskania
dostępu do strony Ustawienia Witryny posłużyć mogłyby następujące trzy adresy URL:
http://Litwareinc.com/_layouts/settings.aspx
http://Litwareinc.com/sites/Vendors/_layouts/settings.aspx
http://Litwareinc.com:1001/sites/Accounting/_layouts/settings.aspx
Ponieważ istnieje tylko jedna wersja strony aplikacji o zakresie farmy serwerów, może ona
zostać skompilowana do pojedynczego zestawu DLL i pobrana do pamięci jednokrotnie dla
każdej aplikacji sieci Web. Dzięki temu znika problem związany z istnieniem różnych wersji
stron aplikacji dla każdej z witryn. Co więcej, strony aplikacji nie są narażone na ataki ze strony
użytkowników, których uprawnienia pozwalają na dostosowywanie stron witryn. W związku
z tym usługi WSS nie zakazują im zawierania kodu wewnętrznego (ang. in-line).
Strony aplikacji są intensywnie wykorzystywane przez zespół WSS do dostarczania większości
standardowych funkcji związanych z tworzeniem i administrowaniem witrynami oraz ich podstawowymi elementami. Rysunek 2-8 prezentuje katalog fizyczny \LAYOUTS na serwerze frontonu
sieci Web, który jest mapowany do katalogu _layouts przez usługi WSS. Jak widać, standardowa
instalacja usług WSS 3.0 zawiera wiele różnych stron aplikacji, w tym settings.aspx.
Po otwarciu kodu źródłowego standardowej strony aplikacji WSS można zauważyć,
że jest ona powiązana ze znajdującą się w katalogu _layouts stroną wzorcową o nazwie
application.master. W kolejnej sekcji omówiony zostanie proces tworzenia niestandardowej strony aplikacji. Podczas tworzenia własnych niestandardowych stron aplikacji można
postępować zgodnie ze schematem i także powiązać je z plikiem application.master.
Rysunek 2-8 Katalog \LAYOUTS zawiera strony aplikacji, które są
dostępne z poziomu dowolnej witryny w farmie.
51
A teraz podsumujmy różnice pomiędzy stronami witryn a stronami aplikacji. Strony witryn
wspierają dostosowywanie stron. Przykładami stron witryn są między innymi strona główna
witryny (default.aspx) oraz strony powiązane z listami i bibliotekami dokumentów, takie jak
AllItems.aspx, NewForm.aspx oraz EditForm.aspx. Fakt, że strony witryn wspierają dostosowywanie, zwiększa ich elastyczność, ale ma również niekorzystny wpływ na wydajność
oraz skalowalność. Strony witryn nie wspierają kodu wewnętrznego zgodnie z domyślną
zasadą zabezpieczeń wymuszaną przez usługi WSS.
Strony aplikacji nie wspierają dostosowywania, co daje im dwa punkty przewagi nad
stronami witryn. Po pierwsze, każda aplikacja jest zawsze komplikowana od pojedynczego pliku DLL, a więc gwarantuje wyższą wydajność i skalowalność niż strona witryny.
Po drugie, strony aplikacji mogą zawierać kod wewnętrzny. Po poznaniu podstawowych
informacji dotyczących stron aplikacji, warto zobaczyć, z czym wiąże się proces tworzenia
własnej strony aplikacji w niestandardowym rozwiązaniu.
Tworzenie niestandardowych stron aplikacji
Do niniejszego rozdziału dołączony został przykładowy projekt Visual Studio o nazwie
CustomApplicationPages. Projekt ten zawiera kilka niestandardowych przykładów
stron aplikacji, m.in. Hello.aspx, ApplicationPage1.aspx, ApplicationPage2.aspx oraz
ApplicationPage3.aspx. Projekt Visual Studio obejmuje także zdarzenie post-build (wywoływane po zbudowaniu kodu) powodujące uruchomienie pliku wsadowego o nazwie
install.bat, który kopiuje strony aplikacji do odpowiednich miejsc w katalogu \LAYOUTS.
Plik install.bat instaluje również funkcję o nazwie CustomApplicationPages, co powoduje
dodanie elementów menu do menu Akcje witryny aktualnej witryny i umożliwia użytkownikom nawigowanie do stron aplikacji projektu.
Po otwarciu projektu CustomApplicationPages należy go zbudować. W efekcie uruchomiony zostanie plik install.bat. Od tego momentu będzie można przejść do dowolnej
witryny i aktywować na poziomie witryny funkcję o nazwie CustomApplicationPages, co
umożliwi śledzenie przykładów zaprezentowanych w dalszej części niniejszego rozdziału.
Warto zauważyć, że chociaż można umieścić strony aplikacji bezpośrednio w katalogu \LAYOUTS, mogłoby to stać się przyczyną problemów związanych z potencjalnym
konfliktem nazw plików między stronami aplikacji a innymi stronami stworzonymi przez
firmę Microsoft bądź inne firmy. Z tego względu zalecaną praktyką jest umieszczanie
stron aplikacji w charakterystycznym dla firmy lub projektu katalogu zagnieżdżonym
w katalogu \LAYOUTS. Strony aplikacji wchodzące w skład omawianego przykładowego
projektu będą umieszczane w charakterystycznym dla projektu podkatalogu o nazwie \
CustomApplicationPages znajdującym się w katalogu \LAYOUTS.
Strony aplikacji powinny wywodzić się z bazowej klasy zestawu Microsoft.SharePoint
o nazwie LayoutsPageBase. A zatem, tworząc niestandardową stronę aplikacji, która będzie
wyświetlać pewne informacje dotyczące aktualnej witryny, w pierwszym przykładzie wykorzystujemy stronę aplikacji o nazwie Hello.aspx, która wywodzi się właśnie z tej klasy bazowej.
Strony aplikacji są z reguły tworzone jako strony zawartości powiązane ze stroną wzorcową o nazwie application.master znajdującą się w katalogu \LAYOUTS. Do tego pliku
strony wzorcowej można odwołać się z poziomu niestandardowej strony aplikacji przy
użyciu ścieżki wirtualnej ~/_layouts/application.master. Definicja strony aplikacji o nazwie
52
Hello.aspx, która została zaprezentowana w Listingu 2-1, stanowi punkt przygotowawczy
do tworzenia własnych stron aplikacji.
Listing 2-1
Niestandardowa strona aplikacji może zawierać
kod układu HTML i kod wewnętrzny.
Niestandardowa strona aplikacji
<%@ Assembly Name="Microsoft.SharePoint, [full 4-part assembly name]"%>
<%@ Page Language="C#" MasterPageFile="~/_layouts/application.master"
Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
protected override void OnLoad(EventArgs e) {
SPWeb site = this.Web;
lblSiteTitle.Text = site.Title;
lblSiteID.Text = site.ID.ToString().ToUpper();
}
</script>
<asp:Content ID="Main" contentplaceholderid="PlaceHolderMain" runat="server">
<table border="1" cellpadding="4" cellspacing="0" style="font-size:12">
<tr>
<td>Site Title:</td>
<td><asp:Label ID="lblSiteTitle" runat="server" /></td>
</tr>
<tr>
<td>Site ID:</td>
<td><asp:Label ID="lblSiteID" runat="server" /></td>
</tr>
</table>
</asp:Content>
<asp:Content ID="PageTitle" runat="server"
contentplaceholderid="PlaceHolderPageTitle" >
Hello World
</asp:Content>
<asp:Content ID="PageTitleInTitleArea" runat="server"
contentplaceholderid="PlaceHolderPageTitleInTitleArea" >
Podstawowa strona aplikacji "Hello World"
</asp:Content>
Warto zauważyć, że przykładowa strona aplikacji zaprezentowana w Listingu 2-1 specyfikuje trzy znaczniki Content, które mają zostać dodane do zawartości HTML strony wynikowej. Strona ta zastępuje symbole zdefiniowane w pliku application.master o nazwach
PlaceHolderMain, PlaceHolderPageTitle oraz PlaceHolderPageTitleInTitleArea. Jednak są to
zaledwie trzy spośród wielu różnych zdefiniowanych w pliku application.master symboli
zastępczych, które można zastąpić.
Ponadto wersja Hello.aspx zaprezentowana w Listingu 2-1 zawiera w górnej części blok
skryptu, w którym znajduje się kod wykorzystujący model obiektowy WSS. Programując
tego typu stronę w Visual Studio 2005, można czerpać korzyści z ułatwień, takich jak
53
kolorowanie kodu czy IntelliSense, jednak najpierw trzeba dodać odpowiednią dyrektywę
@Assembly w górnej części strony. W tym celu należy zmodyfikować dyrektywę @Assembly
zaprezentowaną w Listingu 2-1, korzystając z informacji pochodzących z zestawu Microsoft.
SharePoint, jak pokazano poniżej:
Microsoft.SharePoint,
Version=12.0.0.0,
Culture=neutral,
PublicKeyToken=71E9BCE111E9429C
Dla poprawy czytelności w powyższym kodzie dodane zostały załamania linii, natomiast
podczas dodawania dyrektywy @Assembly do pliku .aspx należy wpisać wszystkie informacje dotyczące zestawu w jednej linii.
Strony aplikacji są pomocne, ponieważ zapewniają szybki i łatwy dostęp do obiektu
WSS. Po stworzeniu strony aplikacji i dostarczeniu nadpisanej implementacji metody
OnLoad, jak pokazano w Listingu 2-1, można uzyskać dostęp do modelu obiektowego
WSS w kontekście charakterystycznym dla witryny za pomocą następującego kodu, który
wykorzystuje właściwości klasy bazowej LayoutsPageBase:
SPSite siteCollection = this.Site;
Możliwość pobrania kontekstu witryny oraz zbioru witryn znacznie zwiększa możliwości
tworzenia stron aplikacji. Strona aplikacji może zachowywać się odmiennie w zależności
od witryny, za której pośrednictwem uzyskano do niej dostęp. Jeśli uzyskamy dostęp do
strony aplikacji z kontekstu jednej witryny, zazwyczaj będzie ona wyglądać i zachowywać
się inaczej, niż gdybyśmy uzyskali dostęp z kontekstu innej witryny.
Przykładowy plik Hello.aspx wykorzystuje kod modelu obiektowego WSS w metodzie
OnLoad w celu pozyskania informacji o bieżącej witrynie, a następnie wyświetla te informacje w etykiecie zdefiniowanej w nazwanym symbolu zastępczym PlaceHolderMain.
}
Gdy uzyskuje się dostęp do strony Hello.aspx za pośrednictwem określonej witryny, strona
prezentuje charakterystyczne dla niej informacje, jak pokazano na Rysunku 2-9.
Rysunek 2-9 Niestandardowa strona aplikacji może być z łatwością
programowana przy użyciu modelu obiektowego WSS.
54
Wykorzystywanie kodu schowanego na stronach aplikacji
Choć jak widać na podstawie zaprezentowanego przykładu, dodanie kodu wewnętrznego
w pliku .aspx niestandardowej strony aplikacji jest nie tylko możliwe, ale i całkiem proste, można także wykorzystać inne podejście, w którym kod jest utrzymywany w sposób
schowany, wspierany przez ASP.NET. Wszystkie przykładowe strony aplikacji w projekcie
CustomApplicationPages (z wyjątkiem zaprezentowanej już strony Hello.aspx) wykorzystują to podejście. Kod schowany ma wielu zwolenników, ponieważ umożliwia oddzielenie
kodu od danych definiujących układ interfejsu użytkownika. Odseparowanie kodu może
usprawnić pracę programisty w czasie pisania kodu stron aplikacji.
Na początku przyjrzyjmy się plikowi ApplicationPage1.aspx, który zawiera dwa
znaczniki formantów serwera oraz dane wyjściowe identyczne ze stroną Hello.
aspx. Znacząca różnica polega na tym, że kod ApplicationPage1.aspx znajduje się
w pliku źródłowym o nazwie ApplicationPage1.cs, który zostaje wkompilowany w zestaw
o nazwie CustomApplicationPages.dll instalowany w pamięci GAC. Analizując definicję
stronyApplicationPage1.aspx w Listingu 2-2, można zauważyć, że zawiera ona ten sam kod
HTML i znaczniki formantów co Hello.aspx, jednakże kod został usunięty.
Listing 2-2
Niestandardowa strona aplikacji może odwoływać
się do klasy bazowej kodu schowanego.
<%@ Assembly Name="Microsoft.SharePoint, [full 4-part assembly name]" %>
<%@ Assembly Name="CustomApplicationPages, [full 4-part assembly name]" %>
<%@ Page Language="C#" MasterPageFile="~/_layouts/application.master"
Inherits="CustomApplicationPages.ApplicationPage1"
EnableViewState="false" EnableViewStateMac="false" %>
<asp:Content ID="Main" contentplaceholderid="PlaceHolderMain" runat="server">
<table border="1" cellpadding="4" cellspacing="0" style="font-size:12">
<tr>
<td>Site Title:</td>
<td><asp:Label ID="lblSiteTitle" runat="server" /></td>
</tr>
<tr>
<td>Site ID:</td>
<td><asp:Label ID="lblSiteID" runat="server" /></td>
</tr>
</table>
</asp:Content>
<asp:Content ID="PageTitle" runat="server"
contentplaceholderid="PlaceHolderPageTitle" >
Hello World
</asp:Content>
<asp:Content ID="PageTitleInTitleArea" runat="server"
contentplaceholderid="PlaceHolderPageTitleInTitleArea" >
Strona aplikacji 1 'Hello World' z kodem schowanym
</asp:Content>
55
Istnieją dwie dodatkowe różnice między stronami Hello.aspx a ApplicationPage1.aspx.
Po pierwsze, ApplicationPage1.aspx zawiera drugą dyrektywę zestawu odwołującą się do
zestawu wyjściowego aktualnego projektu o nazwie CustomApplicationPages.dll. Po drugie, ApplicationPage1.aspx nie dziedziczy bezpośrednio po klasie LayoutsPageBase, lecz
dziedziczy po klasie kodu schowanego o nazwie ApplicationPage1, która została zdefiniowana w przestrzeni nazw CustomApplicationPages. Teraz możemy już przeanalizować
Listing 2-3 zawierający definicję klasy kodu schowanego znajdującego się w pliku źródłowym ApplicationPage1.cs, która dziedziczy po klasie LayoutsPageBase.
Listing 2-3
using
using
using
using
using
using
Klasa kodu schowanego strony aplikacji powinna
dziedziczyć po klasie LayoutsPageBase.
System;
System.Web;
System.Web.UI;
System.Web.UI.WebControls;
Microsoft.SharePoint;
Microsoft.SharePoint.WebControls;
namespace CustomApplicationPages {
public class ApplicationPage1 : LayoutsPageBase {
// dodanie formantów odpowiadających znacznikom na stronie .aspx
protected Label lblSiteTitle;
protected Label lblSiteID;
// pobranie aktualnej strony aplikacji oraz witryny
// oprogramowanie formantów, wykorzystywanych z poziomu strony .aspx
}
}
}
W programowaniu ASP.NET istnieje przydatny mechanizm, zgodnie z którym, gdy mamy
plik .aspx i klasę kodu schowanego, klasa kodu schowanego definiuje pole formantu przy
użyciu nazwy wykorzystywanej przez wystąpienie formantu na stronie .aspx. Gdy środowisko uruchomieniowe ASP.NET kompiluje plik .aspx, dodaje wsparcie dla tworzenia wystąpienia formantu oraz przypisuje odwołanie do pola formantu w klasie kodu schowanego.
To umożliwia metodom w klasie kodu schowanego uzyskiwanie dostępu do wystąpień
formantów wykorzystywanych w pliku .aspx. Na przykład klasa ApplicationPage1 definiuje
pola formantów o nazwach lblSiteTitle i lblSiteID, które odpowiadają znacznikom formantów zdefiniowanym w pliku ApplicationPage1.aspx. To sprawia, że kod w metodzie obsługi
56
zdarzenia OnLoad w pliku ApplicationPage1.cs może odwoływać się do tych formantów
za pośrednictwem pól o nazwie lblSiteTitle i lblSiteID.
Debugowanie komponentów WSS
Zasadniczo usługi WSS dostarczają komunikatów o błędach zaprojektowanych
z myślą o użytkownikach końcowych w środowisku produkcyjnym. To oznacza, że
domyślnie usługi WSS nie zapewniają wyczerpujących informacji diagnostycznych
lub komunikatów o błędzie, które ułatwiałyby debugowanie kodu. Rozwijając komponenty WSS, takie jak niestandardowe strony aplikacji, trzeba zmodyfikować plik
web.config aktualnej aplikacji sieci Web w celu włączenia wsparcia dla debugowania
i komunikatów o błędach zawierających śledzenie stosu. Oto fragment pliku web.
config prezentujący trzy istotne atrybuty, których wartości domyślne zostały zmodyfikowane w celu włączenia wsparcia dla debugowania.
<configuration>
<SharePoint>
<SafeMode CallStack="true" />
</SharePoint>
<system.web>
<customErrors mode="Off" />
<compilation debug="true" />
</system.web>
</configuration>
Choć dokonanie powyższej modyfikacji pliku web.config jest konieczne do włączenia
wsparcia dla debugowania, czasem warto również przywrócić pierwotną postać pliku
web.config. Na przykład gdybyśmy stworzyli stronę aplikacji, która wywołuje wyjątek lub program obsługi zdarzenia, który anuluje akcje podjęte przez użytkownika.
Przywrócenie pierwotnego stanu pliku web.config pozwala sprawdzić, w jaki sposób
kod zachowywać się będzie w środowisku produkcyjnym. Dlatego warto zapoznać
się procedurą modyfikowania pliku web.config z trybu debugowania do trybu użytkownika końcowego i na odwrót.
Wsparcie nawigacji z poziomu stron aplikacji
Gdy już wiemy, jak stworzyć stronę aplikacji, uzupełnijmy ją, dodając funkcję, która wstawia
element menu do menu Akcje Witryny. Ten element menu zostanie stworzony w celu umożliwienia użytkownikowi nawigacji do strony ApplicationPage1.aspx. W ostatnim rozdziale
zademonstrowaliśmy technikę tworzenia niestandardowej funkcji z elementem CustomAction.
Teraz stworzymy trochę inny element CustomAction, który wygląda następująco.
<! – - dodanie komendy do menu Akcje Witryny -->
<CustomAction Id="SiteActionsToolbar"
Sequence="2001"
57
Title="Strona aplikacji 1"
Description="Sprawdzenie typowych właściwości witryny "
ImageUrl="/_layouts/images/DECISION.GIF">
<UrlAction Url="~site/_layouts/CustomApplicationPages/ApplicationPage1.aspx"/>
</CustomAction>
Powinniśmy zauważyć, że element CustomAction jest prawie identyczny z elementem zaprezentowanym w poprzednim rozdziale. Różnica leży w łańcuchu wykorzystanym jako atrybut
URL wewnętrznego elementu UrlAction. Atrybut URL w niniejszym przykładzie rozpoczyna
się od ciągu ~site. Jest to dynamiczny token, który usługi WSS zastępuje właściwym adresem
URL bieżącej witryny. Wykorzystując tę technikę, można dodać do menu Akcje Witryny element (jak np. zaprezentowany na Rysunku 2-10), który umożliwia użytkownikowi przejście
do niestandardowej strony aplikacji w odpowiednim kontekście witryny.
Rysunek 2-10 Element menu stworzony przy użyciu elementu CustomAction ułatwia
użytkownikowi nawigację do niestandardowej strony aplikacji.
Tworząc element CustomAction, można skonfigurować atrybut URL wewnętrznego elementu UrlAction przy użyciu tokenu ~site w zademonstrowany sposób. Warto wiedzieć,
że usługi WSS wspierają również token ~sitecollection, w przypadku gdy strona aplikacji
powinna być zawsze wykonywana w kontekście adresu URL powiązanego z bieżącym
zbiorem witryn i witryną najwyższego poziomu.
Stworzenie strony aplikacji wykorzystującej
formant SPGridView
Przykład ApplicationPage2.aspx demonstruje technikę wykorzystywania podręcznego formantu serwera stworzonego przez zespół WSS o nazwie SPGridView. SPGridView stanowi
wzbogaconą wersję formantu ASP.NET GridView, który jest integrowany z plikami kaskadowych arkuszy stylów WSS (CSS), dzięki czemu przyjmuje ten sam wygląd i działanie co
otaczające go środowisko.
Formant SPGridView jest zdefiniowany wewnątrz zestawu Microsoft.SharePoint w przestrzeni nazw Microsoft.SharePoint.WebControls. Aby wykorzystać ten formant na stronie aplikacji, należy dodać dyrektywę @Assembly odwołującą się do zestawu Microsoft.
SharePoint. Ponadto należy dodać dyrektywę @Register, aby zaimportować przestrzeń nazw
formantu i zdefiniować atrybut Tagprefix, który zostanie wykorzystany podczas tworzenia
znacznika formantu. Oto przykład dyrektywy @Register, która jest wykorzystywana na
stronie ApplicationPage2.aspx.
<%@ Register Tagprefix="SharePoint"
Namespace="Microsoft.SharePoint.WebControls"
Assembly="Microsoft.SharePoint, [pełna czteroczłonowa nazwa zestawu ]" %>
58
Jak widać, ta dyrektywa @Register importuje przestrzeń nazw Microsoft.SharePoint.
WebControls z wartością Tagprefix równą SharePoint. To umożliwia stworzenie wystąpienia
formantu SPGridView przy użyciu znacznika formantu, który wygląda następująco:
<SharePoint:SPGridView runat="server"
ID="grdPropertyValues"
AutoGenerateColumns="false"
RowStyle-BackColor="#DDDDDD"
AlternatingRowStyle-BackColor="#EEEEEE" />
Zatrzymajmy się na chwilę i przyjrzyjmy pełnej definicji strony aplikacji w pliku źródłowym o nazwie ApplicationPage2.aspx. Następnie otwórzmy plik źródłowy o nazwie
ApplicationPage2.cs i sprawdźmy klasę kodu schowanego dla tej strony aplikacji. Jak łatwo
zauważyć, klasa o nazwie ApplicationPage2 współpracuje z niestandardową klasą pomocniczą o nazwie PropertyCollectionBinder w celu stworzenia obiektu ADO.NET DataTable
wypełnionego informacjami dotyczącymi bieżącej witryny oraz zbioru witryn. Obiekt
DataTable został wykorzystany w tym przykładzie, ponieważ jego zawartość może posłużyć do wypełnienia formantu SPGridView przy użyciu standardowych technik wiązania
danych znanych z ASP.NET.
Zastrzeganie dostępu do stron aplikacji
dla administratorów witryn
Prezentowane do tej pory strony aplikacji i wspierające je elementy w menu Akcje Witryny
były tworzone w taki sposób, aby były dostępne dla wszystkich użytkowników witryny.
Jednak nie zawsze jest to pożądane rozwiązanie. Strony aplikacji są często zaprojektowane
tak, aby dostarczać informacje i funkcjonalność, która powinna być dostępna wyłącznie
dla administratorów witryn. Jak osiągnąć ten cel, pokażemy na przykładzie kolejnej strony
aplikacji o nazwie ApplicationPage3.aspx.
Rozpocznijmy od ponownego przeanalizowania procedury tworzenia elementu
CustomAction w funkcji. Można dodać atrybut o nazwie RequireSiteAdministrator i przypisać mu wartość True, aby ten element menu był widoczny tylko dla użytkowników
będących administratorami witryny.

<CustomAction Id="SiteActionsToolbar"
Sequence="1003"
Title="Strona aplikacji 3"
Description="Strona aplikacji dostępna tylko dla Administratora "
RequireSiteAdministrator="True"
ImageUrl="/_layouts/images/DECISION.GIF">
<UrlAction Url="~site/_layouts/CustomApplicationPages/ApplicationPage3.aspx"/>
</CustomAction>
Choć ukrycie elementu menu przed użytkownikami, którzy nie są administratorami
witryny, stanowi dobry początek, nie zapewnia ono wystarczającego zabezpieczenia. Sama
strona aplikacji nadal będzie dostępna dla wszystkich użytkowników, którzy znają jej adres
URL. Aby zablokować stronę aplikacji w sposób bezpieczny, należy nadpisać właściwość
59
RequireSiteAdministrator klasy bazowej LayoutsPageBase, jak pokazano w poniższym
kodzie.
public class ApplicationPage3 : LayoutsPageBase {
protected override bool RequireSiteAdministrator {
get { return true; }
}
// tutaj znajdzie się Twój kod
}
}
Dodanie powyższego kodu do strony aplikacji sprawia, że jest ona faktycznie zabezpieczona. Gdy użytkownik, który nie jest administratorem witryny, spróbuje przejść do tej
strony aplikacji, zostanie przekierowany do standardowej strony WSS Odmowa dostępu.
Dodanie niestandardowego elementu
do menu kontekstowego
Teraz dodatkowo rozwiniemy umiejętność tworzenia niestandardowych stron aplikacji,
analizując stronę wyświetlającą informacje o określonym dokumencie w bibliotece dokumentów. W tym przykładzie przyjrzymy się stronie aplikacji o nazwie ApplicationPage4.
aspx. Rozpoczniemy od stworzenia nowego elementu CustomAction, który nie zostanie
jednak dodany do menu Akcje Witryny. Poniższy kod ma za zadanie dodać nowy element
do menu kontekstowego każdego dokumentu w bibliotece dokumentów. Przyjrzyjmy się
następującemu fragmentowi kodu XML, który definiuje element CustomAction.

<CustomAction Id="ApplicationPage4.ECBItemMenu"
RegistrationType="List"
RegistrationId="101"
ImageUrl="/_layouts/images/GORTL.GIF"
Location="EditControlBlock"
Sequence="105"
Title="Strona aplikacji 4" >
<UrlAction Url="~site/_layouts/CustomApplicationPages/ApplicationPage4.aspx
?ItemId={ItemId}&ListId={ListId}"
/>
</CustomAction>
Element CustomAction różni się od poprzednio prezentowanego tym, że jego atrybut
RegistrationType ma wartość List. Ponadto jest skonfigurowany przy użyciu atrybutu
RegistrationID, któremu przypisana została wartość 101. Wartość 101 stanowi identyfikator typu listy, który odnosi się do wszystkich bibliotek dokumentów. Warto również
zwrócić uwagę na atrybut Location o wartości EditControlBlock, który skutkuje dodaniem
elementu do menu kontekstowego dokumentów w bibliotece dokumentów, jak zaprezentowano na Rysunku 2-11.
60
Rysunek 2-11 Kod CustomAction może dodawać polecenia do menu
kontekstowego elementów listy lub biblioteki dokumentów.
Przyglądając się elementowi CustomAction zaprezentowanemu w tym przykładzie, możemy
zauważyć, że element ActionUrl jest skonfigurowany przy użyciu atrybutu URL, który
wskazuje stronę ApplicationPage4.aspx wraz z następującym ciągiem kwerendy.
../ApplicationPage4.aspx?ItemId={ItemId}&ListId={ListId}
Ciąg kwerendy, który został dodany na końcu adresu URL służącego do nawigacji do strony
ApplicationPage4.aspx, zawiera tokeny {ListId} oraz {ItemId}. Usługi WSS dynamicznie
zastępują token {ListId} identyfikatorem GUID bieżącej listy lub biblioteki dokumentów.
Natomiast token {ItemId}usługi WSS zastępują dynamicznie liczbowym identyfikatorem
aktualnego elementu listy lub dokumentu.
Kod znajdujący się wewnątrz strony ApplicationPage4.cs został napisany przy założeniu, że ciąg kwerendy zawiera informacje, które można wykorzystać do zidentyfikowania
określonego dokumentu i biblioteki dokumentów, w której się on znajduje. Przeanalizujmy
następujący kod, zwracając uwagę na sposób, w jaki wymagane informacje wyciągane są
z ciągu kwerendy i wykorzystywane do stworzenia obiektów SPList oraz SPListItem.
// pobierz aktualny zbiór witryn oraz witrynę
// dostęp do aktualnej listy lub biblioteki dokumentów
string ListId = Request.QueryString["ListId"];
SPList list = site.Lists[new Guid(ListId)];
// dostęp do pojedynczego elementu listy lub dokumentu
string ItemId = Request.QueryString["ItemId"];
SPListItem item = list.Items.GetItemById(Convert.ToInt32(ItemId));
W niektórych przypadkach (jak na przykład teraz) można przyjąć założenie, że ma się do
czynienia z biblioteką dokumentów, a nie standardowym typem listy. W takich sytuacjach
można dodać kod konwertujący obiekt SPList do obiektu SPDocumentLibrary. Można
także uzyskać bezpośredni dostęp do dokumentu w zapytaniu poprzez stworzenie obiektu
SPFile, jak w następującym przykładzie.
// pobierz aktualny zbiór witryn oraz witrynę
61
// dostęp do aktualnej listy lub biblioteki dokumentów
string ListId = Request.QueryString["ListId"];
SPList list = site.Lists[new Guid(ListId)];
lblListTile.Text = list.Title;
lblRootFolderUrl.Text = list.RootFolder.Url;
// jeżeli aktualna lista to biblioteka dokumentów...
SPDocumentLibrary documentLibrary = (SPDocumentLibrary)list;
lblDocumentTemplateUrl.Text = documentLibrary.DocumentTemplateUrl;
// dostęp do pojedynczego elementu listy lub dokumentu
string ItemId = Request.QueryString["ItemId"];
lblDocumentID.Text = ItemId;
SPListItem item = list.Items.GetItemById(Convert.ToInt32(ItemId));
lblDocumentName.Text = item.Name;
lblDocumentUrl.Text = item.Url;
// jeżeli aktualna lista to biblioteka dokumentów...
SPFile file = site.GetFile(item.Url);
lblFileAuthor.Text = file.Author.Name;
lblFileSize.Text = file.TotalLength.ToString("0,###") + " bits";
lblFileLastModified.Text = "By " + file.ModifiedBy.Name +
" on " + file.TimeLastModified.ToLocalTime().ToString();
lblFileCheckOutStatus.Text = file.CheckOutStatus.ToString();
Zaprezentowany w pliku ApplicationPage4.cs kod wykorzystuje model obiektowy WSS do
pozyskania informacji o określonym dokumencie i jego bibliotece dokumentów. Gdybyśmy
przeszli do tej strony, korzystając z menu kontekstowego dokumentu w bibliotece dokumentów, na stronie wyświetlone byłyby informacje podobne do zaprezentowanych na
Rysunku 2-12.
Rysunek 2-12 Strona aplikacji może wyświetlać informacje
o określonym elemencie listy lub dokumencie.
Na podstawie kilku zaprezentowanych przykładów można zauważyć, że tworzenie niestandardowych stron aplikacji może znacznie wzbogacić niestandardowe rozwiązania. Trzeba
62
mieć świadomość, że zaprezentowany został zaledwie wierzchołek góry lodowej możliwości
oferowanych przez rozszerzanie standardowej funkcjonalności. Można tworzyć niestandardowe strony aplikacji, aby dostarczać niestandardowe funkcje administracyjne na poziomie
zbioru witryn, witryn, list, elementów, bibliotek dokumentów bądź dokumentów. Można
także tworzyć niestandardowe strony aplikacji, aby zaoferować nietypowy interfejs użytkownika dla list, w których elementy interfejsu są zaprojektowane z myślą o uzyskiwaniu
dostępu do elementów, wyświetlaniu ich, aktualizowaniu bądź usuwaniu. Podsumowując,
niestandardowe strony aplikacji mogą stanowić fundament niestandardowego rozwiązania
opartego na platformie WSS.
Podsumowanie
Niniejszy rozdział rozpoczął się od omówienia najważniejszych pojęć i terminów związanych z technologiami IIS oraz ASP.NET. Gdy rozpoczyna się analizowanie wewnętrznego działania usług WSS, posiadanie podstawowej wiedzy w tym zakresie jest niezbędne.
Dowiedzieliśmy się, że usługi WSS konwertują witrynę sieci Web usług IIS do aplikacji sieci
Web, zastępując pewne komponenty w potoku żądań HTTP. Nauczyliśmy się również, że
komponent SPVirtualPathProvider pełni bardzo ważną rolę w ogólnej architekturze WSS,
ponieważ stanowi fundament mechanizmu dostosowywania stron.
W niniejszym rozdziale omówiona została również różnica między stronami witryn
a stronami aplikacji. Strony aplikacji nie wspierają dostosowywania, jednak mają kilka kluczowych przewag nad stronami witryn. Mianowicie gwarantują wyższą wydajność i mogą
zawierać kod wewnętrzny lub kod schowany. W tym rozdziale poznaliśmy techniki tworzenia niestandardowych stron aplikacji i integrowania ich z menu witryny przy użyciu
elementów CustomAction.
Teraz, gdy już znamy podstawowe możliwości niestandardowych stron aplikacji, nadszedł czas, aby powrócić do stron witryn. Kolejny rozdział zawiera bardziej szczegółowe
omówienie modelu przetwarzania stron witryn, a także procesu tworzenia niestandardowych szablonów stron oraz sposobów wykorzystywania ich w wystąpieniach stron wybranej witryny.

Microsoft® Windows® SharePoint® 3.0 od środka

Transkrypt

Podobne dokumenty