Microsoft® Windows® SharePoint® 3.0 od środka
Transkrypt
Microsoft® Windows® SharePoint® 3.0 od środka
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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. Rozdział 1: Wprowadzenie 5 Żądanie do aplikacji sieci Web #1 http://www.litwareinc.com Żądanie do aplikacji sieci Web #1 http://www.litwareinc.com/sites/Vendors Baza danych zawartości #1 Żądanie do aplikacji sieci Web #2 http://www.litwareinc.com:1000/sites/Sales Żądanie do aplikacji sieci Web #2 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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 Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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\ Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka ■ ■ ■ 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. Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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 Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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 Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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" Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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> Rozdział 1: Wprowadzenie 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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 Rozdział 2: Architektura SharePoint 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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 Rozdział 2: Architektura SharePoint 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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%"> Rozdział 2: Architektura SharePoint 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" %> <script runat="server"> 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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 Rozdział 2: Architektura SharePoint 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#" %> <script runat="server"> 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. Rozdział 2: Architektura SharePoint 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. Rozdział 2: Architektura SharePoint 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. Rozdział 2: Architektura SharePoint 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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 Rozdział 2: Architektura SharePoint 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. Rozdział 2: Architektura SharePoint 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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" %> <script runat="server"> 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 Rozdział 2: Architektura SharePoint 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; SPWeb site = this.Web; 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. protected override void OnLoad(EventArgs e) { SPWeb site = this.Web; lblSiteTitle.Text = site.Title; lblSiteID.Text = site.ID.ToString().ToUpper(); } 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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> Rozdział 2: Architektura SharePoint 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; protected override void OnLoad(EventArgs e) { // pobranie aktualnej strony aplikacji oraz witryny SPSite siteCollection = this.Site; SPWeb site = this.Web; // oprogramowanie formantów, wykorzystywanych z poziomu strony .aspx lblSiteTitle.Text = site.Title; lblSiteID.Text = site.ID.ToString().ToUpper(); } } } 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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" GroupId="SiteActions" Location="Microsoft.SharePoint.StandardMenu" Sequence="2001" Rozdział 2: Architektura SharePoint 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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. <!-- dodanie komendy do menu Akcje Witryny --> <CustomAction Id="SiteActionsToolbar" GroupId="SiteActions" Location="Microsoft.SharePoint.StandardMenu" 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ść Rozdział 2: Architektura SharePoint 59 RequireSiteAdministrator klasy bazowej LayoutsPageBase, jak pokazano w poniższym kodzie. public class ApplicationPage3 : LayoutsPageBase { protected override bool RequireSiteAdministrator { get { return true; } } protected override void OnLoad(EventArgs e) { // 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. <!-- Łącze dodane do menu kontekstowego każdego dokumentu biblioteki --> <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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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ę SPSite siteCollection = this.Site; SPWeb site = this.Web; // 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ę SPSite siteCollection = this.Site; SPWeb site = this.Web; Rozdział 2: Architektura SharePoint 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 Microsoft® Windows® SharePoint® Services 3.0 od środka 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.