Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00061 009078 11061253 na godz. na dobę w sumie
CSS i Ajax. Strony WWW zgodne ze standardami sieciowymi W3C - książka
CSS i Ajax. Strony WWW zgodne ze standardami sieciowymi W3C - książka
Autor: , , , , , Liczba stron: 304
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-1755-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> webmasterstwo >> css
Porównaj ceny (książka, ebook, audiobook).

Twórz serwisy internetowe zgodne z standardami!

Współczesne strony internetowe różnią się, a przynajmniej powinny, od tych sprzed kilku lat. Jeżeli różnic nie widać od strony graficznej, to z pewnością można je znaleźć w kodzie strony. Nowoczesne witryny WWW charakteryzują się zgodnością ze standardami, wykorzystaniem kaskadowych arkuszy stylów oraz udogodnieniami dla osób niepełnosprawnych. A dzięki zastosowaniu technologii AJAX współczesne witryny kuszą interaktywnością i dynamizmem.

Autorzy niniejszej książki wprowadzają Czytelnika w tajniki projektowania serwisów zgodnych z zasadami ustalonymi przez organizację W3C. Dzięki tej książce poznasz rodzaje i zastosowanie standardów sieciowych. Dowiesz się, w jaki sposób wybrać język znaczników, oraz poznasz zalety i wady języków HTML i XHTML. Nauczysz się korzystać z kaskadowych arkuszy stylów, a następnie odkryjesz sposób wykorzystania technologii AJAX w celu tworzenia interaktywnych stron WWW. Co najważniejsze, dostosujesz swoją stronę do współczesnych standardów, dzięki czemu zyska na dostępności i interaktywności, przyciągając rzesze użytkowników!

Dostosuj się do standardów -- zwiększ dostępność i popularność swojej strony internetowej!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

CSS i Ajax. Strony WWW zgodne ze standardami sieciowymi W3C Autor: Christopher Schmitt, Kimberly Blessing, Rob Cherny, Meryl K. Evans, Kevin Lawver, Mark Tramme T‡umaczenie: Robert G(cid:243)rczyæski ISBN: 978-83-246-1755-5 Tytu‡ orygina‡u: Adapting to Web Standards: CSS and Ajax for Big Sites (Voices That Matter) Format: 168x237, stron: 312 Tw(cid:243)rz serwisy internetowe zgodne z standardami! (cid:149) Jak projektowa(cid:230) serwisy WWW zgodne z standardami? (cid:149) Jak zaprojektowa(cid:230) interfejs u¿ytkownika? (cid:149) Jak zwiŒkszy(cid:230) wydajno(cid:156)(cid:230) strony WWW? Wsp(cid:243)‡czesne strony internetowe r(cid:243)¿ni„ siŒ, a przynajmniej powinny, od tych sprzed kilku lat. Je¿eli r(cid:243)¿nic nie wida(cid:230) od strony graficznej, to z pewno(cid:156)ci„ mo¿na je znale(cid:159)(cid:230) w kodzie strony. Nowoczesne witryny WWW charakteryzuj„ siŒ zgodno(cid:156)ci„ ze standardami, wykorzystaniem kaskadowych arkuszy styl(cid:243)w oraz udogodnieniami dla os(cid:243)b niepe‡nosprawnych. A dziŒki zastosowaniu technologii AJAX wsp(cid:243)‡czesne witryny kusz„ interaktywno(cid:156)ci„ i dynamizmem. Autorzy niniejszej ksi„¿ki wprowadzaj„ Czytelnika w tajniki projektowania serwis(cid:243)w zgodnych z zasadami ustalonymi przez organizacjŒ W3C. DziŒki tej ksi„¿ce poznasz rodzaje i zastosowanie standard(cid:243)w sieciowych. Dowiesz siŒ, w jaki spos(cid:243)b wybra(cid:230) jŒzyk znacznik(cid:243)w, oraz poznasz zalety i wady jŒzyk(cid:243)w HTML i XHTML. Nauczysz siŒ korzysta(cid:230) z kaskadowych arkuszy styl(cid:243)w, a nastŒpnie odkryjesz spos(cid:243)b wykorzystania technologii AJAX w celu tworzenia interaktywnych stron WWW. Co najwa¿niejsze, dostosujesz swoj„ stronŒ do wsp(cid:243)‡czesnych standard(cid:243)w, dziŒki czemu zyska na dostŒpno(cid:156)ci i interaktywno(cid:156)ci, przyci„gaj„c rzesze u¿ytkownik(cid:243)w! (cid:149) Zalety standard(cid:243)w sieciowych (cid:149) Przygotowanie interfejsu u¿ytkownika (cid:149) Wady i zalety jŒzyk(cid:243)w HTML oraz XHTML (cid:149) Wp‡yw deklaracji DOCTYPE na zachowanie przegl„darki (cid:149) Korzy(cid:156)ci p‡yn„ce z zastosowania kaskadowych arkuszy styl(cid:243)w (cid:149) Sposoby do‡„czania arkuszy styl(cid:243)w do strony (cid:149) Zasady wykorzystania technologii AJAX (cid:149) Wsp(cid:243)‡praca jŒzyka JavaScript z CSS (cid:149) Systemy zarz„dzania tre(cid:156)ci„ (cid:149) Programowanie aplikacji sieciowych (cid:149) Sposoby na zwiŒkszenie wydajno(cid:156)ci witryn internetowych Dostosuj siŒ do standard(cid:243)w (cid:151) zwiŒksz dostŒpno(cid:156)(cid:230) i popularno(cid:156)(cid:230) swojej strony internetowej! Wydawnictwo Helion ul. Ko(cid:156)ciuszki 1c 44-100 Gliwice tel. 032 230 98 63 e-mail: helion@helion.pl Spis treści Podziękowania ....................................................................................................................................... 7 O autorach ................................................................................................................................................ 9 Część I Tworzenie witryn internetowych bazujących na standardach sieciowych 13 WPROWADZENIE 15 Czym są standardy sieciowe? .............................................................................................16 Podstawowe zalety standardów sieciowych ........................................................17 Internetowe interfejsy użytkownika ................................................................................17 Planowanie interfejsu użytkownika .................................................................................18 Współczesne planowanie witryny internetowej .................................................20 Nowe podejście: plany architektury UI ...................................................................22 ROZDZIAŁ 1. TWORZENIE INTERFEJSU 25 Od czego rozpocząć? .............................................................................................................27 Struktura dokumentu: wybór języka znaczników ......................................................27 HTML kontra XHTML ......................................................................................................28 Przełączanie deklaracji DOCTYPE i jej wpływ na tryb pracy przeglądarki internetowej .....................................34 Weryfikować czy nie weryfikować poprawności kodu? ...................................44 Treść i struktura: od projektu do wykonania ........................................................47 ROZDZIAŁ 2. WPROWADZENIE DO KASKADOWYCH ARKUSZY STYLÓW 59 Ile plików CSS należy utworzyć? ........................................................................................60 Plik CSS i strategie jego dołączania ..........................................................................62 Mikroformaty w służbie konwencji i czytelnych nazw ..............................................68 Mikroformaty i POSH .....................................................................................................69 Zbyt wiele klas ..........................................................................................................................72 Classitis klas .......................................................................................................................72 Uzdrowienie classitis ......................................................................................................74 Struktura treści pliku CSS .....................................................................................................78 Media alternatywne w CSS ..................................................................................................81 Prezentacja zapewniająca swobodę działania .............................................................85 ROZDZIAŁ 3. INTEGRACJA Z WARSTWĄ OBSŁUGI ZDARZEŃ 87 Nowoczesne metody technologii Ajax ...........................................................................88 Nowoczesne, progresywne i dyskretne skrypty ..................................................90 Wymagania JavaScript: plik oraz spis funkcji ...............................................................92 Błędny skrypt, oj, błędny! .............................................................................................93 Dyskretne usprawnienia ...............................................................................................98 Wyskakujące okna ....................................................................................................... 100 Elementy dynamiczne i innerHTML ...................................................................... 104 4 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C Współpraca kodu JavaScript z arkuszami stylów CSS i warstwą prezentacyjną ................................................ 107 Ogromne witryny internetowe i obsługa wielu zdarzeń onload ............... 109 Własne skrypty kontra gotowe struktury .................................................................... 111 Przykład kodu struktury jQuery .............................................................................. 113 Struktury znacznie ułatwiają używanie technologii Ajax ............................. 117 Kilka słów odnośnie struktur .................................................................................... 119 ROZDZIAŁ 4. PROGRAMOWANIE APLIKACJI SIECIOWYCH 121 Aplikacje sieciowe obciążone jarzmem przeszłości ................................................ 122 Jakość oprogramowania i analiza jego elementów ....................................... 122 Wskazówki, reguły oraz standardy sieciowe .............................................................. 125 Reguły programowania ............................................................................................. 125 Lepsze formularze tworzone za pomocą nowoczesnego kodu znaczników .............................................. 126 Struktury działające po stronie serwera oraz narzędzia szablonów ......... 130 Platforma Microsoft ASP.NET ........................................................................................... 134 Dane wyjściowe ASP.NET .......................................................................................... 137 Kontrolki HTML ASP.NET, kontrolki Web Control i inne ................................ 144 Zarządzanie treścią .............................................................................................................. 149 Podstawy systemu zarządzania treścią ................................................................ 150 System zarządzania treścią i czysta treść ............................................................ 150 Dane wyjściowe systemu zarządzania treścią i moduły ................................ 151 Szablony systemu zarządzania treścią ................................................................. 152 Tryb WYSIWYG dla autorów treści ......................................................................... 156 Firmy trzecie ................................................................................................................... 158 W jaki sposób podejść do aplikacji sieciowych? ...................................................... 159 ROZDZIAŁ 5. KRĄG STANDARDÓW 161 Organizacyjna opieszałość ............................................................................................... 162 Wprowadzenie kręgu ......................................................................................................... 164 Menedżer standardów ............................................................................................... 164 Tworzenie i dokumentowanie standardów ....................................................... 165 Szkolenia i komunikacja ............................................................................................ 168 Proces przeglądu jakości ........................................................................................... 170 Wprawienie całości w ruch ............................................................................................... 172 Utrzymywanie impetu ................................................................................................ 172 Podsumowanie ..................................................................................................................... 173 Część II Studium przypadku 175 PRAKTYKA NIE OZNACZA DOSKONAŁOŚCI 177 Komunikacja ........................................................................................................................... 178 Zdolność do adaptacji ........................................................................................................ 178 Wytrwałość ............................................................................................................................. 179 Próby i cierpienia .................................................................................................................. 179 Spis treści 5 ROZDZIAŁ 6. EVERYTHINGTORI.COM 181 Kulisy ......................................................................................................................................... 182 Zagłębienie się w świat Tori Amos ........................................................................ 184 Rozpoczęcie właściwego procesu tworzenia projektu .................................. 184 Zbudowanie szkieletu ................................................................................................ 185 Budowanie witryny ..................................................................................................... 192 Kulisy arkuszy stylów CSS .......................................................................................... 196 Uruchomienie witryny ........................................................................................................ 205 Spotkanie z projektantem Philipem Fierlingerem ................................................... 206 Utwór końcowy ..................................................................................................................... 210 ROZDZIAŁ 7. AOL.COM 213 Utworzenie zespołu skazanego na sukces i unikanie porażek ........................... 215 Co poszło źle? ................................................................................................................ 215 Projektowanie z uwzględnieniem wydajności ......................................................... 237 Oszacowanie wydajności przed utworzeniem choćby jednego wiersza kodu ................................... 238 Obawy związane z wydajnością ............................................................................. 242 Wywiad: David Artz ..................................................................................................... 247 Powtarzalne kroki ........................................................................................................ 249 Projekt i architektura systemu ......................................................................................... 250 System wzajemnej pomocy ..................................................................................... 250 Wykonywanie procedur pośredniczących ......................................................... 251 Rozważania dotyczące organizacji pracy ............................................................ 252 Magia interfejsu .................................................................................................................... 254 Harmonizacja kodu znaczników z deklaracją DOCTYPE ............................... 254 Najlepsze rozwiązania w zakresie CSS ................................................................. 258 Arkusze stylów CSS ułatwiające dostępność treści ......................................... 261 Wydajność w rzeczywistym produkcie ................................................................ 267 Podsumowanie ..................................................................................................................... 269 Posłowie ............................................................................................................................................... 271 Dodatek A Docelowe przeglądarki internetowe .................................................................. 273 Dodatek B Dostępność treści ....................................................................................................... 279 Dodatek C Wskazówki dotyczące wydajności witryny internetowej ........................... 281 Dodatek D Przewodnik po selektorach CSS ........................................................................... 291 Skorowidz ............................................................................................................................................ 295 4 Programowanie aplikacjisieciowych ProfesjonalnezespoÏyprogramistówbuduj¦cewitrynyinternetowenieograniczaj¦ si¸dotworzeniatreäcistatycznych,aleoferuj¦takĂeaplikacjedynamiczneiwitryny wykorzystuj¦cesystemyzarz¦dzaniatreäci¦(CMS).WtakimprzypadkuuĂywany jestkodwarstwyinterfejsuuĂytkownika(UI),podzielonydalejnakodj¸zyka znaczników,arkuszestylówCSSorazskryptyJavaScript.ZnaczenieUIpowoduje, Ăegotowawitrynainternetowajestwi¸ksza,aponadtowydÏuĂaj¦si¸okresyczasu mi¸dzyznacz¦cymimodernizacjamiwitryny.Powstajewi¸cpytanie,dlaczegonie pokusi©si¸oograniczeniezaleĂnoäciodprogramistówtworz¦cychkodwewn¸trzny b¦dĀekspertówzzakresusystemówCMS,skoroprogramiäciUImoglibysamoǦ dzielniezarz¦dza©zmianamiprzeprowadzanymiwUI? JeĂelidoda©dotegowyzwaniawynikaj¦cezkoniecznoäciintegracjizelementami opracowanymiprzezfirmytrzecieorazstarszymiinowszymielementamisieciowymi organizacji,towyraĀniewida©nieskoÑczonepokÏadykorzyäcipÏyn¦cychzestosowania standardówsieciowych.Wrzeczywistoäciwszystko,cojesttworzonewramach koduinterfejsuuĂytkownikakoÑcowego,powinnozosta©zaimplementowane zuĂyciemtechnikzgodnychzestandardamisieciowymi. 122 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C Aplikacje sieciowe obciążone jarzmem przeszłości Wielu programistów aplikacji sieciowych nauczyło się języka HTML w latach dziewięć- dziesiątych ubiegłego stulecia i od tamtego okresu nie uaktualnili stosowanych technik programowania w celu wdrożenia nowych technologii. Przedstawienie nowych poziomów separacji i ścisłego używania standardów lub specyfikacji aplikacji programi- ście, który kształcił się w okresie powszechnego stosowania „zupy znaczników”, może być naprawdę ciekawym doświadczeniem. Nowoczesne podejście bazujące na standardach sieciowych jest znacznie czystsze, efektywniejsze i logiczniejsze. Zwykle zmierza również do postawienia programisty sieciowego przed sytuacją „albo to działa, albo nie działa” — często wskrzeszając w nim zainteresowanie programowaniem interfejsu. Z definicji witryny internetowe opierające się na standardach sieciowych dążą do ścisłego przestrzegania standardów, zawsze gdy tylko jest to możliwe. Kiedy oprogramowanie sieciowe umieszcza lub nawet tworzy kod warstwy UI, należy oczekiwać takiego samego poziomu dyscypliny. W dłuższej perspektywie czasu takie podejście przyniesie korzyści witrynie oraz aplikacji poprzez ograniczenie ryzyka, które nieuchronnie pojawia się wraz z kolejnymi modyfikacjami. Podejście wykorzy- stujące standardy sieciowe zwiększa poziom zgodności i dostępności treści witryny oraz redukuje poziom używanych zasobów i wysiłku, który trzeba włożyć w zmianę interfejsu użytkownika aplikacji lub statycznych fragmentów witryny. Problem polega jednak na tym, że wciąż istnieje ogromna ilość archaicznego, niespój- nego lub po prostu przestarzałego kodu, który został zaimplementowany w opro- gramowaniu sieciowym. Programiści muszą bardzo dokładnie przyjrzeć się zarówno własnym, jak i komercyjnym implementacjom oprogramowania w celu określenia jak i kiedy oprogramowanie witryny może zyskać na zastosowaniu standardów sieciowych. Jakość oprogramowania i analiza jego elementów W celu właściwego określenia natury sytuacji, absolutnie każdy element oprogramowania sieciowego w projekcie powinien zostać poddany ewidencji, odpowiednio skatalogo- wany i określony pod względem zgodności (bądź jej braku) ze standardami sieciowymi. Problemy związane z tworzeniem aplikacji sieciowej Z perspektywy standardów sieciowych, problemy zwykle pojawiają się tam, gdzie programiści aplikacji muszą utworzyć warstwę UI — w obszarach związanych z obsługą, przeprojektowywaniem, delikatnymi zmianami w projekcie oraz oczywiście w kwestiach dotyczących dostępności treści i możliwości przeglądarek internetowych. ROZDZIAŁ 4 Programowanie aplikacji sieciowych 123 Zazwyczaj programista sieciowy albo wrzuca kod do szablonów przygotowanych przez zespół projektantów, albo próbuje dopasować wygląd i działanie do przedstawionego w statycznej reprezentacji aplikacji. Istnieją również pakiety oprogramowania, które generują kod UI, pozwalając na różne poziomy dostosowania go do własnych potrzeb. Ponadto, ponieważ programiści sieciowi tworzą również własny kod interfejsu, skutkuje to otrzymaniem różnego stopnia zgodności ze standardami — czasami całkiem świetnego i wystarczającego, a w innych przypadkach wręcz przeciwnie. Oczywiście jest to dość złożony problem o wielu aspektach, ale kluczowy jest fakt, że struktury aplikacji, materiały edukacyjne, wygenerowany kod oraz narzędzia po- ważnie cierpią w wyniku braku demonstracji najlepszych praktyk i rozwiązań. Wielu programistów posługuje się różnymi formami zintegrowanego środowiska progra- mowania (ang. Integrated Development Environment — IDE), bibliotekami kodu lub kopiuje kod, który może, ale nie musi opierać się na najlepszych rozwiązaniach. W wyniku takiej sytuacji kod wewnętrzny jest tworzony z użyciem niewłaściwych znaczników wymieszanych wraz z warstwą prezentacyjną, w projektach stosuje się układy bazujące na tabelach, a ponadto dodatkowe i zupełnie zbędne znaczniki. Interfejsy często zawierają skrypty błędnie napisane lub utworzone pod kątem określonej przeglądarki internetowej, lub skrypty innych interfejsów w ogóle nie są brane pod uwagę. W takim przypadku zmiana projektu staje się prawdziwym problemem — a wcale nie musi nim być. Warstwa UI jest albo utworzona w wyniku pracy człowieka, albo może być wygene- rowana poprzez oprogramowanie (przy minimalnym poziomie wysiłku) i ślepo zaak- ceptowana przez użytkownika. Powstaje pytanie: jak dużo wysiłku trzeba włożyć w jej opracowanie? Ponieważ współcześni inżynierowie aplikacji, platformy serwerowe i narzędzia zwykle domyślnie nie tworzą kodu interfejsu zgodnego ze standardami sieciowymi, to zadanie zapew- nienia odpowiedniej jakości spadło na zespół. Osiągnięcie zgodności ze standardami sieciowymi interfejsu aplikacji i systemu zarządzania treścią wymaga włożenia dużego wysiłku. Ustanowienie zbioru najlepszych praktyk dotyczących kodu UI w oprogra- mowaniu działającym po stronie serwera może być punktem zwrotnym, od którego rozpocznie się usprawnianie oprogramowania. Trzeba zdawać sobie sprawę z istnienia prawdziwego kompromisu między rozwią- zaniem, które pozwoli na uniknięcie problemów w przyszłości, a po prostu naci- skiem na jak najszybsze wydanie produktu. Z perspektywy dłuższego okresu czasu dążenie do uzyskania UI zgodnego ze standardami sieciowymi powoduje ograniczenie ryzyka związanego z brakiem spójności warstw logiki aplikacji, prezentacji i UI. Jednakże implementacja standardów może czasami zabrać dużo czasu. 124 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C Kryteria wartościowania W przypadku oceny każdego dokumentu aplikacji należy wziąć pod uwagę kilka czynników: ™ Skąd pochodzi dana warstwa UI? ™ Jaka jest struktura kodu interfejsu? ™ Czy kod to poprawny HTML lub XHTML? ™ Czy w dokumencie znajduje się deklaracja DOCTYPE, a dokument jest genero- wany w „trybie standardów” czy „dziwactw”? ™ W jaki sposób zostały zdefiniowane aspekty prezentacyjne? ™ Czy programiści aplikacji zrozumieli kod UI? ™ Czy programiści UI zrozumieli kod wewnętrzny? ™ Ilu członków zespołu zrozumiało sposób integracji UI oraz kodu wewnętrznego? ™ W jaki sposób jest generowany kod znaczników? ™ Czy oprogramowanie odwołuje się do jakiegokolwiek bieżącego kodu prezen- tacyjnego, takiego jak pliki arkuszy stylów CSS? Jeżeli tak, to do jakich plików? Czy te pliki zmieniają się w projekcie? ™ Jak blisko kod interfejsu jest powiązany z wewnętrzną logiką biznesową (o ile w ogóle jest powiązany)? ™ Czy istnieje jakikolwiek sposób abstrakcji kodu UI od kodu aplikacji? ™ Jeśli aplikacja generuje kod interfejsu, czy istnieje jakikolwiek sposób kontroli tego procesu? ™ Jeżeli użytkownik ma możliwość generowania treści lub kodu, to czy istnieje jakikolwiek sposób zablokowania tego, co użytkownik może zrobić? ™ Jak duży wysiłek trzeba będzie włożyć w modyfikacje warstwy UI? ™ Jak duże jest ryzyko związane z modyfikacją warstwy UI aplikacji? ™ Jakie są potencjalne korzyści i wady wynikające z zaniechania przeprojektowania aplikacji? ™ Jakie są ograniczenia związane z tym, że oprogramowanie firm trzecich może wymagać dostosowania do własnych potrzeb? Szczerze mówiąc, to jest ogromna ilość informacji, które trzeba zebrać, przeanalizować, a następnie rozważyć. Czy aplikacja może zostać uaktualniona? Na koniec trzeba wspomnieć, że w przypadku części oprogramowania być może niewiele będzie można zdziałać. Taka sytuacja może wynikać z faktu, że po prostu nie będzie możliwości uaktualnienia kodu interfejsu do postaci zgodnej ze standardami sieciowymi. Powodem mogą być albo kwestie związane z architekturą aplikacji, ROZDZIAŁ 4 Programowanie aplikacji sieciowych 125 albo nieakceptowanym poziomem ryzyka związanego z uaktualnieniem. W takich przypadkach wysiłki stają się ćwiczeniem w zakresie kompromisów. Albo potrzeby staną się powodem utworzenia długoterminowego planem nastawionego na rozwiązanie problemów, albo zarówno użytkownicy, jak i biznes będą cierpieli z powodu bolesnego procesu uaktualnienia. Między krótkoterminowym wysiłkiem i ryzykiem oraz długoterminowym wysiłkiem i ryzykiem występują wyraźne kompromisy. Niektóre rozwiązania częściowe zakładają albo implementację części stylów (nawet wyodrębnionych z określonych plików CSS), albo powierzchowne ponowne opracowanie wyglądu i działania danej aplikacji. Jednak z perspektywy długiego okresu czasu organizacja będzie z tego powodu cierpiała, ponieważ coraz trudniejsze stanie się wprowadzanie zmian w aplikacji. Te zmiany staną się przypadkami szczególnymi i za każdym razem będą wymagały szczególnego podejścia. Punkt krytyczny będzie inny dla każdej organizacji. Wskazówki, reguły oraz standardy sieciowe Aplikacje sieciowe opracowane przez organizację mogą osiągać korzyści wynikające ze stosowania standardów sieciowych, wytycznych programowania, punktów wzajem- nego oddziaływania oraz wskazówek dotyczących sposobu pisania oraz stylu kodu UI. Reguły programowania Istnieją standardy dotyczące jakości i spójności programowania, podobne do często stosowanych przez programistów w kodzie wewnętrznym aplikacji. Jednak w chwili obecnej zostały rozszerzone na kod interfejsów, co może być zupełną nowością. ™ Każdy kod UI powinien spełniać podstawowe, najlepsze praktyki dotyczące standardów sieciowych, czyli między innymi stosować styl POSH, arkusze stylów CSS oraz dyskretny kod JavaScript (jak to opisano w rozdziałach — odpowiednio — 1., 2. i 3.). ™ Kluczowe znaczenie ma tworzenie kodu niezależnego od rodzaju przeglądarek internetowych, zapewniającego dostępność oraz umożliwiającego (w razie potrzeby) elegancką degradację funkcji. ™ Programy warstwy UI powinny odwoływać się do klas CSS i atrybutów ID poprzez wyciągnięcie ich z głębi logiki aplikacji do innych, łatwo dostępnych miejsc kodu. W ten sposób przeprowadzanie modyfikacji informacji prezentacyjnych niesie ze sobą minimalne ryzyko dla aplikacji. Wymienione klasy CSS i atrybuty ID mogą być powierzchownymi właściwościami klas obiektu, przechowywane w plikach konfiguracyjnych lub zmiennych o zasięgu aplikacji, co umożliwia ich łatwą zmianę w przyszłości. 126 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C ™ Należy za wszelką cenę unikać stosowania osadzonych w kodzie stylów bądź innych elementów prezentacyjnych. ™ W kwestii aplikacji JavaScript warto współpracować z programistami interfejsu, tak aby maksymalnie współdzielić skrypty i unikać związanych z nimi konfliktów. ™ Opracować najprostszy z możliwych i semantyczny kod znaczników aplikacji. ™ Utworzyć proste, standardowe reguły CSS formularzy, tak aby po dodaniu nowych formularzy zostały w nich zastosowane style CSS bez potrzeby włożenia większego wysiłku. Dzięki stosowaniu powyższych wskazówek oraz tworzeniu czystego, rozdzielonego kodu zgodnego ze standardami sieciowymi, programista zagwarantuje, że aplikacja i oprogramowanie o znaczeniu krytycznym dla biznesu nie będzie wymagało dużych bądź ryzykownych modyfikacji podczas kolejnego przeprojektowania. Niestety, wymienione powyżej wskazówki często odbiegają od tego, co znajduje się w pakietach oprogramowania, narzędziach oraz kodzie generowanym przez IDE lub edytory typu WYSIWYG. Te narzędzia zwykle pozwalają programistom jedynie na usunięcie z kodu ustawień prezentacyjnych, umieszczenie warstwy prezentacyjnej w klasach CSS, itp. Analiza alternatywnych ustawień lub eksperymenty z funkcjami narzędzia pozwalające na osiągnięcie pożądanych wyników mogą wymagać większej ilości czasu i wysiłku. Jednak bardzo często wystarczy powziąć proste kroki pozwalające na oddzielenie logiki aplikacji od kodu wewnętrznego. Lepsze formularze tworzone za pomocą nowoczesnego kodu znaczników Większość aplikacji sieciowych zawiera w sobie pewne rodzaje formularzy. Aby zapewnić tym formularzom elegancki układ, programiści najczęściej używają tabel HTML. Chociaż stosowanie tej techniki właściwie nie jest błędne, to trzeba przypomnieć, że tabele zostały opracowane z myślą o umieszczaniu w nich danych tabelarycznych. Ponieważ formularz nie zawiera tego rodzaju danych, to nie ma najmniejszego powodu do stosowania tabeli. Ponadto tabele często zawierają atrybuty prezentacyjne, takie jak bgcolor, align i width, oraz nie oferują takich korzyści w kwestii dostępności treści, jakie można uzyskać stosując podejście zgodne ze standardami sieciowymi. Formularze bardzo często używają także kodu po stronie serwera, którego zadaniem jest umieszczenie pewnych wartości w formularzu (więcej na ten temat zostanie przedstawione w dalszej części rozdziału). Przykładowo: poniżej przedstawiono kod wyświetlający prosty formularz, który został umieszczony w tabeli (zobacz rysunek 4.1): p ProszÚ wypeïniÊ poniĝszy formularz: /p p b Informacje o uĝytkowniku /b /p form action= submit.php method= post ROZDZIAŁ 4 Programowanie aplikacji sieciowych 127 RYSUNEK 4.1. Formularze są najczęściej umieszczane w tabelach HTML i używają znaczników prezentacyjnych table width= 300 border= 0 tr td bgcolor= #cccccc width= 30 align= right ImiÚ: /td td input type= text name= txtFName size= 30 / /td /tr tr td bgcolor= #cccccc align= right Nazwisko: /td td input type= text name= txtLName size= 30 / /td /tr tr td bgcolor= #cccccc align= right Tytuï: /td td input type= text name= txtTitle size= 30 / /td /tr tr td colspan= 2 input type= submit value= WyĂlij / /td /tr /table /form Dla porównania, poniżej znajduje się nowa wersja kodu powodującego wyświetlenie tego samego formularza (zobacz rysunek 4.2): p ProszÚ wypeïniÊ poniĝszy formularz: /p form action= submit.php method= post div id= formBlock fieldset legend Informacje o uĝytkowniku /legend p label for= txtFName ImiÚ: /label input type= text id= txtFName tabindex= 1 / /p p 128 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C RYSUNEK 4.2. Stosowanie nowoczesnego kodu znaczników powoduje, że tworzenie prostych formularzy jest zdumiewająco łatwe label for= txtLName Nazwisko: /label input type= text id= txtLName tabindex= 2 / /p p label for= txtFName Tytuï: /label input type= text id= txtTitle tabindex= 3 / /p p input type= submit value= WyĂlij tabindex= 4 / /p /fieldset /div /form Przedstawiony powyżej kod formularza może zostać połączony z poniższym arkuszem stylów CSS, który powinien być stosowany względem każdego formularza na witrynie, co zapewni im spójny wygląd. Wprawdzie takie rozwiązanie wymaga użycia dodatkowego kodu, ale zastosowanie spójnego sposobu tworzenia formularzy i nadawania im stylu będzie ogromną zaletą dla aplikacji. h1 { margin: 0; font-weight: normal; font-size: 15px; } #formBlock { width: 300px; } #formBlock p { margin: 0 0 3px; } p { width: 100 ; } ROZDZIAŁ 4 Programowanie aplikacji sieciowych 129 label { background-color: #ccc; display: block; float: left; width: 28 ; text-align: right; margin-right: 2px; padding: 2px 0; } input { float: left; width: 65 ; margin-bottom: 4px; margin-top: 1px; padding: 1px; } input[type=submit] { width: 10 ; } fieldset { border: none; padding: 0; margin: 0; } legend { font-weight: bold; margin-bottom: 12px; } Analiza nowego kodu XHTML napisanego z uwzględnieniem standardów sieciowych pokazuje zasadnicze usprawnienia w stosunku do formularzy utworzonych bez zastosowania podejścia semantycznego: ™ W kodzie nie ma już niepotrzebnej tabeli HTML służącej do nadania wyglądu formularzowi. ™ Formularz zawiera elementy label , które przypisują etykiety faktycznym kon- trolkom formularza — doskonałe rozwiązanie z punktu widzenia dostępności, funkcja opracowana z myślą o użytkowniku i obsługiwana przez większość przeglądarek internetowych. ™ Zastosowany został atrybut tabindex ułatwiający ustalenie kolejności przechodze- nia między polami oraz zwiększający dostępność strony za pomocą klawiatury. ™ Formularz został zgrupowany w znaczniku fieldset oraz oznaczony etykietą za pomocą znacznika legend , który grupuje i opisuje formularz w celu zwięk- szenia jego dostępności. 130 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C ™ Ponieważ kod formularza jest czystszy i czytelniejszy, to po dołączeniu do aplikacji programiści zajmujący się jej obsługują będą mogli łatwiej odczytywać i mody- fikować ten formularz. Struktury działające po stronie serwera oraz narzędzia szablonów Jeżeli chodzi o technologie skryptowe w Internecie, to dostępnych jest ich kilka, między innymi PHP (PHP: Hypertext Preprocessor), klasyczne ASP (ang. Active Server Pages), ColdFusion (opracowana przez firmę Macromedia, która kilka lat temu została przejęta przez Adobe). Wymienione platformy językowe służące do wykonywania zadań po stronie serwera posiadają modele, które umieszczają w tych samych plikach kod interfejsu oraz kod wewnętrzny aplikacji. W jednym wierszu kodu programiści natykają się na kod wewnętrzny umieszczony wewnątrz zdefiniowanych ograniczników (na przykład takich jak ... ), a następnie znajdują się standardowe znaczniki HTML. Ponadto kod działający po stronie serwera będzie używał poleceń print w celu wy- generowania kodu HTML, często wymieszanego wraz z danymi prezentacyjnymi. Dostępnych jest kilka platform oraz technik programowania — na przykład ColdFusion Fusebox (http://fusebox.org) oraz system szablonów PHP Smarty (http://smarty.php.net) — które zapewniają modularyzację warstw oraz próbują rozdzielić logikę biznesową od kodu interfejsu. W tym celu tworzą pliki szablonów zawierające kod interfejsu, podczas gdy kod wewnętrzny zostaje umieszczony w oddzielnych plikach. W rzeczywi- stości osiągnięte wyniki są z reguły bardzo zróżnicowane, ponieważ kod działający po stronie serwera nadal musi „wyprodukować” interfejs użytkownika. Pytanie, które można zadać pod koniec omawiania tego tematu, brzmi: jaka jest jakość kodu znaczników tworzącego UI nawet po jego oddzieleniu od logiki biznesowej? Wszelkie dostępne na świecie warstwy oprogramowania aplikacji nie zdadzą się na nic, jeżeli podstawowy kod HTML będzie łamał opracowane najlepsze rozwiązania lub zostanie umieszczony w plikach, których programiści tworzący UI nie będą mogli kontrolować lub przez które nie będą mogli przebrnąć. Proste kroki prowadzące do tworzenia lepszych skryptów działających po stronie serwera W przypadku wszystkich platform lub systemów wykorzystujących szablony można powziąć proste kroki, które mogą ograniczyć potencjalne szkody, nawet w przypadku podstawowego PHP lub podobnych środowiskach. W najbardziej podstawowym sensie wszelkie dane wyjściowe aplikacji lub generowany kod UI będą przedmiotem stosowania tych samych reguł, które odnoszą się do kodu UI nieużywającego bazy danych. Jedyna różnica polega na tym, że tego rodzaju kod jest po prostu generowany, a nie tworzony ręcznie przez programistów. ROZDZIAŁ 4 Programowanie aplikacji sieciowych 131 Warto zwrócić uwagę, że wyzwania związane z uzyskaniem czystego rozdziału logiki biznesowej po stronie serwera od warstwy prezentacyjnej nie są jedynie domeną języka PHP. Większość języków programowania działających po stronie serwera wykorzystuje dobre praktyki programowania i dyscyplinę. Cechą charakterystyczną, szczególnie w przypadku PHP, klasycznego ASP i ColdFusion, jest bardzo często osadzanie logiki aplikacji w tych samych plikach, które zawierają kod interfejsu, na przykład: ?php // WyĞwietlenie wyników. echo table border= 1 width= 400 ; while ($row = mysql_fetch_assoc($result)) { echo tr valign= top ; echo td bgcolor= #ffffcc b $row[ username ] /b /td ; echo td $row[ firstname ] /td ; echo td $row[ lastname ] /td ; echo td font color= grey $row[ notes ] /font /td ; echo /tr ; } echo /table ; ? Przedstawiony powyżej kod wykonuje w PHP proste zadanie — kolejno przechodzi przez wiersze zbioru wynikowego zwróconego przez bazę danych. Większość języków skryptowych, w celu wyświetlenia danych wyjściowych pobranych z bazy danych stosuje podobne techniki do przedstawionej powyżej, opierając się na strukturze pętli. Oczywiście, przedstawiony przykład jest mały i bardzo prosty, ale może on być umieszczony głęboko wewnątrz innej struktury pętli bądź skomplikowanej struktury pętli. Zaprezentowany powyżej kod (oraz inne, podobne kody działające po stronie serwera) ma kilka wad: ™ Elementy prezentacyjne zostały osadzone w kodzie pętli. ™ Zmiana projektu wizualnego będzie wymagała zmian w aplikacji. W tym celu trzeba będzie skorzystać z usług programisty, zamiast po prostu wprowadzić zmiany w zewnętrznym (z punktu widzenia aplikacji) pliku arkuszy stylów CSS. ™ Za każdym razem, gdy zajdzie potrzeba zmiany wyglądu tabeli, programista będzie musiał odszukać kod prezentacyjny i przeprowadzić modyfikacje bezpośrednio w kodzie logiki aplikacji. ™ W atrybutach prezentacyjnych zastosowano znaki sterujące, ponieważ atrybuty w języku HTML używają znaków cudzysłowów. Ten krok powoduje, że kod staje się mniej czytelny i trudniejszy w zarządzaniu. ™ W każdej tabeli znajdującej się na witrynie trzeba będzie ręcznie wprowadzić dane prezentacyjne. 132 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C Mimo że powyższy kod jest prosty, to demonstruje pomieszanie kodu wewnętrznego z warstwą prezentacyjną. Łatwo sobie wyobrazić, jak mógłby wyglądać kod wraz z zagnieżdżonymi tabelami służącymi do utworzenia krawędzi i menu oraz stosujący inne atrybuty prezentacyjne dla każdej z kolumn… Kod stałby się zupełnie nieczytelny. Elegancką alternatywą jest następujący kod: style type= text/css #results { border: 1px solid #000; width: 400px; } #results td { border: 1px inset #000; vertical-align: top; } td.username { background-color: #ffc; } td.notes { color: gray; } /style ?php echo table id= results ; while ($row = mysql_fetch_assoc($result)) { echo tr ; echo td class= username $row[ username ] /td ; echo td $row[ firstname ] /td ; echo td $row[ lastname ] /td ; echo td class= notes $row[ notes ] /td ; echo /tr ; } echo /table ; ? W celu zachowania zwięzłości, na powyższym fragmencie kodu przedstawiono tylko blok style zawierający definicję arkuszy stylów CSS. Można jednak dostrzec, że w celu zmiany wyglądu tabeli, czcionek lub sposobu wyrównania treści w komórce tabeli nie zachodzi potrzeba modyfikacji żadnego wiersza kodu PHP. Przykład jest dość szczątkowy, ale należy pamiętać o jednym — im bardziej skomplikowana logika biznesowa, tym większe korzyści płyną z wyrzucenia informacji prezentacyjnych z logiki biznesowej. ROZDZIAŁ 4 Programowanie aplikacji sieciowych 133 UWAGA W przedstawionej powyżej tabeli idealnym rozwiązaniem byłoby również użycie wiersza th w celu utworzenia nagłówków opisujących kolumny. W ten sposób można zwięk- szyć zarówno poziom dostępności treści strony, jak i semantyczność kodu. Jeżeli projekt graficzny nie zakłada wyświetlania nagłówków tabeli to zawsze można je ukryć za pomocą arkusza stylów CSS. Pozostaną one jednak dostępne dla urządzeń wspomagających. Problem Zaletą stosowania technologii, takich jak PHP lub nawet klasyczne ASP, jest fakt, że programista sieciowy zachowuje pełną kontrolę nad sposobem generowania kodu UI — zaleta, której nie należy lekceważyć. Koszty związane z utrzymaniem i obsługą interfejsu użytkownika aplikacji mogą stać się problemem w zespole, gdy zachodzi prawdopodobieństwo, że kod UI nie został napisany przez programistów tego zespołu. W takich przypadkach bardzo ważna jest przede wszystkim komunikacja oraz ponowna ocena. Oczywiście, są to przecież procedury biznesowe, a nie techniki programowania, ale bardzo często te podstawowe procesy po prostu nie zachodzą. Problem polega na tym, że we współczesnym świecie coraz więcej nowych produk- tów i technologii zyskuje szeroką akceptację, a więc proces oceny oraz programowania UI stał się znacznie trudniejszy niż wcześniej. W przypadku złożonych aplikacji bizneso- wych języki skryptowe — na przykład te omówione dotąd w książce — wypadły z obiegu, ponieważ sama platforma nie narzuca architektury warstwom aplikacji. Ciężarem spoczywającym na programistach jest stosowanie strukturalnych wzorców projektowych, które wymagają używania dobrych praktyk w zakresie programowania. Starsze narzędzia, takie jak PHP i ColdFusion, były często znacznie bardziej dostępne dla programistów lub projektantów UI niż niektóre nowsze technologie. Zasadniczy problem pozostał, a w przypadku większości nowych środowisk programo- wania działających po stronie serwera stał się nawet jeszcze poważniejszy. Problem dotyczy zwłaszcza sytuacji, gdy osadzony skrypt działający po stronie serwera, na przykład PHP lub klasyczne ASP (obecnie ASP.NET) stosujący podejście warstwowe, próbuje oddzielić logikę biznesową od kodu wewnętrznego. Problem może również wystąpić, gdy język XSLT jest używany do generowania kodu XHTML lub HTML z XML. Jaki jest więc ten zasadniczy problem? Kiedy inżynierowie oprogramowania budowali coraz dojrzalsze i działające na warstwach środowiska interfejsów, takie jak Java, ASP.NET lub XML/XSLT, to programiści interfejsów nie poznali elementów odpo- wiedzialnych za interfejs w tychże środowiskach programistycznych — i najczęściej nigdy nie poznają. 134 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C Zwykle elementy odpowiedzialne za interfejs w tych platformach oprogramowania generują dane wyjściowe, w postaci takiego samego, przestarzałego i niespełniającego standardów kod interfejsu, który już wcześniej był stosowany. Prawdziwym wyzwaniem jest więc implementacja standardów sieciowych w interfejsie tego rodzaju aplikacji. Ostrzeżenie przed kodem generowanym po stronie serwera Część nowoczesnych środowisk aplikacji posiada funkcje zaprojektowane w celu pomocy podczas usuwania „zbędnego” generowania kodu HTML lub innego kodu UI z aplikacji. Koncepcja polega na tym, aby kod HTML (lub XHTML) mógł zostać w łatwy sposób wyizolowany, a następnie dynamicznie wygenerowany za pomocą poleceń przekazanych do języka programowania pakietu narzędziowego. Zazwyczaj stosowane są właściwości przypisywane zbiorom danych zwracanych przez zapytania do bazy danych lub inne podobne struktury kontrolujące dynamiczne tworzenie danych wyjściowych. Problem związany z tego rodzaju podejściem to fakt, że zarówno projekt, jak i osta- tecznie generowany kod opierają się w dużym stopniu na decyzjach programistów tworzących oprogramowanie używane do abstrahowania i generowania kodu. Dlatego też sukces jest uzależniony również od wysiłków programisty mających na celu poznanie funkcji UI dostępnych w używanym oprogramowaniu. Różne platformy oferują zróżnicowane poziomy jakości. Programiści muszą więc „poznać kod źródłowy” i faktycznie obserwować strukturę kodu znaczników po jego wygenerowaniu, zamiast po prostu przyglądać mu się, gdyż kod znaczników jest generowany dynamicznie. W większości przypadków nic nie jest w stanie zastąpić czynnika ludzkiego. Przejrzenie rzeczywistych działaniach realizowanych przez kod i zorientowanie się w nich wymaga wykonania kilku dodatkowych kroków. Czasami trzeba będzie wprowadzić kilka poprawek, a innym razem nie będzie to konieczne. Skoro Czytelnik dotarł aż do tego miejsca książki, to powinno być dla niego oczywiste, że utworzenie interfejsu zgod- nego ze standardami sieciowymi może przynieść wymierne korzyści. Platforma Microsoft ASP.NET Jedną z platform, która została szeroko zastosowana zwłaszcza w dużych organizacjach, jest dość krytycznie przyjęta technologia firmy Microsoft o nazwie ASP.NET (następca „klasycznego” ASP). Klasy podstawowe .NET, obiekty oraz API mają ogromne możliwości. Technologia ASP.NET wymusza poprzez stosowany model używanie warstw kodu, które oddzielają do pewnego stopnia logikę programu oraz bazę danych od plików „interfejsu użytkownika” posiadających rozszerzenie .aspx. Wymienione pliki zawierają kod HTML oraz własne znaczniki ASP.NET, do których powrócimy w dalszej części rozdziału. Teoretycznie programiści UI uczą się wymienionych znaczników w celu uzyskania kontroli nad interfejsem i utworzenia punktów zaczepienia dla programistów kodu wewnętrznego. To jest faktycznie możliwe, ale w rzeczywistości rzadko osiągane. ROZDZIAŁ 4 Programowanie aplikacji sieciowych 135 Zespół programistów mógłby podjąć nieśmiałą decyzję dotyczącą edukacji zespołu programistów UI, a następnie współpracować z nimi podczas nauki, natomiast zespół UI mógłby wykazać motywację do nauki. Takie rzeczy się zdarzają. Zazwyczaj, aplikacje sieciowe ASP.NET są tworzone w środowisku IDE o nazwie Microsoft Visual Studio.NET. Wymienione środowisko IDE oferuje okno działające w trybie WYSIWYG uzupełniające widok kodu źródłowego oraz pozwalające programi- stom na szybkie przeciąganie obiektów na stronę, ustawianie właściwości, także tych dotyczących atrybutów prezentacyjnych bez konieczności napisania ani jednego wiersza kodu. Te ustawienia generują kod HTML. TO NIE TAK, ŻE CZEPIAMY SIĘ PLATFORMY ASP.NET W rzeczywistości jest wręcz na odwrót. Omówione w dalszej części rozdziału przykłady zaprezentują potężne możliwości i wszechstronność ASP.NET oraz podobnych platform w rękach osoby, która doskonale wie, w jaki sposób posługiwać się opro- gramowaniem w celu uzyskania kodu zgodnego ze standardami sieciowymi. Do- stępnych jest wiele podobnych platform, a większość z nich pozwala na modyfikację sposobu generowania danych wyjściowych. Wymaga to jednak włożenia wysiłku w celu odszukania i poznania funkcji, które pomagają w wygenerowaniu wysokiej jakości kodu interfejsu. Między poszczególnymi platformami koncepcje są niemal takie same. Konieczne jest włożenie pewnego wysiłku i poświęcenie czasu na zrozumienie, jakie dane zostaną wygenerowane, zamiast zwykłego stwierdzenia „to z grubsza wygląda dobrze”. W ten sposób zyskują wszyscy — użytkownicy witryny, firma i cała reszta. Podczas pracy nad aplikacją programiści bywają całkiem mocno spięci i często nie przejmują się ostatnimi krokami. Oczywiście, istnieją wyjątki, ale ta sekcja nie jest przeznaczona dla takich indywidualności. Z punktu widzenia standardów sieciowych istnieje kilka kwestii, na które trzeba zwrócić uwagę, używając Visual Studio.NET, zwłaszcza w wersji wcześniejszej niż 2005, oraz kodu ASP.NET generowanego przez serwer: ™ Większość przykładów i materiałów edukacyjnych ASP.NET zawiera nieprawi- dłowy kod. ™ Visual Studio.NET 2003 oraz wcześniejsze wersje maja złą sławę z powodu prze- pisywania i zmiany formatowania kodu HTML strony (kiedy programista przejdzie do trybu graficznego), nawet jeśli została utworzona i starannie dopracowana w innej aplikacji bądź zwykłym edytorze tekstowym przez programistę UI. ™ Formularze i kontrolki danych mogą być „znacznikami” ASP.NET, które bardzo czę- sto mają osadzone w nich atrybuty prezentacyjne. Wygenerowany kod źródłowy najczęściej nie jest zgodny z XHTML lub HTML, choć w wersji 2005 zanotowano 136 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C na tym polu ogromną poprawę. Jeżeli programista nie włoży dodatkowego wysiłku w nadzór generowanych danych wyjściowych, to wymienione atrybuty znaczników będą miały osadzoną olbrzymią ilość danych prezentacyjnych. ™ W wersjach 2003 i wcześniejszych, kiedy programista używał wbudowanych narzędzi do tworzenia strony, tak utworzona strona HTML była wyświetlana w „trybie dziwactw”, ponieważ deklaracja DOCTYPE dołączona do dokumentu nie zawierała URI. ™ ASP.NET zawiera funkcję „inteligentnego generowania”, która oznacza, że serwer podejmuje decyzje dotyczące rodzaju wysyłanej do przeglądarki internetowej warstwy kodu UI na podstawie ustawień dokonanych po stronie serwera. Serwer „zgaduje” poziom obsługi danej technologii przez przeglądarkę internetową. ™ Kod ASP.NET działający po stronie serwera używa dużych ilości atrybutów ID w kontrolkach osadzonych na stronie. Najczęściej, w zależności od kontekstu, wymienione atrybuty ID mają dynamicznie zmieniane nazwy na podstawie ich położenia w dokumencie. Dlatego też programiści CSS i JavaScript mają znacznie utrudnione zadanie w kwestii odwoływania się do obiektów strony poprzez ich wartości ID. I nie ma tutaj znaczenia, że taki sposób odwoływania jest otwarty, rozpoznawany wszędzie i zgodny ze standardami sieciowymi. W niektórych przypadkach zastosowanie klasy CSS może być odpowiednim rozwiązaniem. Można również spróbować zastosować wymagany atrybut ID elementowi nad- rzędnemu, a odwołać się do żądanego obiektu poprzez kontekst. Idealnym wyjściem jest, gdy projektanci interfejsu i programiści kodu wewnętrznego współpracują ze sobą podczas ustawiania atrybutów ID dla interfejsu użytkownika. Wówczas będzie to najlepszy sposób wykorzystania możliwości kodu zarówno interfejsu jak i wewnętrznego — ale takie rozwiązanie nie jest dostępne w każdym przypadku. Warto zwrócić uwagę na jeden interesujący fakt. Mianowicie, wymienione problemy można pokonać wkładając dodatkowy wysiłek oraz poświęcając więcej czasu i uwa- gi aspektom kodu interfejsu użytkownika. WSKAZÓWKA Jednym ze sposobów poradzenia sobie z funkcją „inteligentnego generowania” jest ustawienie opcji konfiguracyjnej ClientTarget wartości Uplevel. W ten sposób ASP.NET przestanie zakładać, że jedyna przeglądarka oferująca zaawansowane funkcje to Microsoft Internet Explorer, i zacznie wysyłać zaawansowany kod do wszystkich. Jednak takie rozwią- zanie powoduje powstanie problemów z niektórymi funkcjami, zwłaszcza dotyczącymi ASP.NET 1.1 i JavaScript. Będą one obsługiwane jedynie przez przeglądarkę IE, ponieważ Microsoft w pewnych miejscach zastosował kod obsługiwany tylko i wyłącznie przez tę przeglądarkę. Należy zachować szczególną ostrożność i dokładnie przetestować aplikację ASP.NET jeszcze przed jej wdrożeniem. Co więcej, wymienione funkcje zostały w pewnym stopniu zmienione w ASP.NET 2.0 — kolejny powód do wykonywania wczesnych i częstych testów. ROZDZIAŁ 4 Programowanie aplikacji sieciowych 137 DUŻE USPRAWNIENIA W ASP.NET 2.0 Zarówno w ASP.NET 2.0 jak i Visual Studio.NET 2005 firma Microsoft podjęła duże wysiłki, aby generowany kod był w jeszcze większym stopniu zgodny ze standardami siecio- wymi i zapewniał większą dostępność. Inne wprowadzone usprawnienie polega na tym, że nowa wersja środowiska IDE po przejściu do trybu graficznego przepisuje (modyfikuje) znacznie mniejszą ilość kodu. Kod kontrolek i formularzy generowany automatycznie przez platformy Visual Studio.NET i ASP.NET jest praktycznie zgodny z językiem XHTML w wersji Transitional, co jest pochodną ścisłej natury specyfikacji. Jednak programista nadal musi włożyć dodatkowy wysiłek, aby uniknąć generowania osadzonych atrybutów prezentacyjnych i zwiększyć poziom dostępności kodu. W pewnych sytuacjach lepiej użyć innych kontrolek, które pozwalają na większą elastyczność w zakresie generowanego kodu. Wymienione opcje zostały znacznie usprawnione w ASP.NET 2.0. Dane wyjściowe ASP.NET Podobnie jak w przypadku innych języków, także ASP.NET umożliwia wyświetlanie danych wyjściowych pochodzących z bazy danych. Jednak jedynym sposobem zaimplementowanym przez Microsoft jest wykorzystanie znaczników działających po stronie serwera. Wszystkie wymienione znaczniki mają atrybuty prezentacyjne, które w domyśle miały pomoc programiście w nadzorowaniu prezentacyjnych aspektów kodu XHTML danych wyjściowych. Poniżej przedstawiono typowy przykład kontrolek ASP.NET używających funkcji o nazwie DataGrid do utworzenia danych wyjściowych w postaci tabeli zawierającej elementy pochodzące z bazy danych. Kod został osadzony w pliku .aspx otoczonym pozostałą częścią dokumentu (X)HTML (zobacz rysunek 4.3). asp:DataGrid ID= catalog runat= server AutoGenerateColumns= false CellPadding= 2 Width= 600 BorderColor= black ItemStyle Font-Names= Arial Font-Size= 12px ForeColor= #800000 VerticalAlign= top / AlternatingItemStyle Font-Names= Arial Font-Size= 12px ForeColor= #400000 BackColor= #cccccc / HeaderStyle Font-Bold= true Font-Names= Arial Font-Size= 15px ForeColor= white BackColor= black VerticalAlign= top / Columns asp:BoundColumn DataField= Name HeaderText= Nazwa / asp:BoundColumn DataField= abbr HeaderText= Nazwa skrócona / asp:BoundColumn DataField= typeof HeaderText= Rodzaj / asp:BoundColumn DataField= notes HeaderText= Opis / /Columns /asp:DataGrid 138 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C RYSUNEK 4.3. Kontrolka DataGrid w ASP.NET wyświetlająca dane Powyższy kod powoduje zdefiniowanie tabeli danych wyjściowych oraz naprzemiennych kolorów jej wierszy. Atrybuty opisujące wygląd i sposób działania tabeli są po prostu niektórymi z dostępnych opcji. W rzeczywistości ilość tych opcji jest ogromna. Dane źródłowe tabeli są pobierane poprzez inną warstwę kodu. Wynika to z separacji danych od warstwy prezentacyjnej, która jest doskonałym rozwiązaniem choć w przypadku ASP.NET tylko teorią. Poniżej przedstawiono kod wygenerowany przez powyższy fragment kodu: table cellspacing= 0 cellpadding= 2 rules= all border= 1 id= catalog style= border-color:Black;width:600px;border-collapse: collapse; tr valign= top style= color:White;background-color:Black; font-family:Arial;font-size:15px;font-weight:bold; td Nazwa /td td Nazwa skrócona /td td Rodzaj /td td Opis /td /tr tr valign= top style= color:Maroon;font-family:Arial; font-size:12px; td HyperText Markup Language /td td HTML /td td Kod ´znaczników /td td Uĝywany do tworzenia dokumentów. Charakteryzuje siÚ luěnÈ ´skïadniÈ. /td /tr tr valign= top style= color:#400000;backgroundcolor:# CCCCCC;font-family:Arial;font-size:12px; td eXtensible HyperText Markup Language /td td XHTML /td td Kod znaczników /td td To HTML wraz ze skïadniÈ XML, a takĝe ´Ăcisïymi reguïami stosowanymi w XML. /td ROZDZIAŁ 4 Programowanie aplikacji sieciowych 139 /tr tr valign= top style= color:Maroon;font-family:Arial; font-size:12px; td Kaskadowe arkusze stylów /td td CSS /td td Warstwa ´prezentacyjna /td td Warstwa prezentacyjna witryny. Arkusze stylów sÈ oddzielnymi ´dokumentami i zawierajÈ informacje definiujÈce wyglÈd ´i dziaïanie witryny internetowej. /td /tr tr valign= top style= color:#400000;backgroundcolor:# CCCCCC;font-family:Arial;font-size:12px; td JavaScript /td td JS /td td Obsïuga zdarzeñ, interakcja, ´zdarzenia /td td Czasami nazywana warstwÈ obsïugi zdarzeñ, nadzoruje ´interakcjÚ z uĝytkownikiem, zdarzenia oraz sposób zachowania ´stron internetowych. /td /tr /table Przedstawiona tabela jest dość prosta, zawiera naprzemienne kolory wierszy, usta- wienia rodziny czcionek oraz elegancko stosuje arkusze stylów CSS zamiast znaczników font . Jednak powyższy fragment kodu pokazuje przykład rodzaju kodu, który jest powszechnie używany do demonstracji kontrolki DataGrid. Arkusze stylów CSS są osadzone w kodzie i wielokrotnie powtarzane, co wynika ze stosowania przez ASP.NET atrybutów takich jak ForeColor, BackColor i innych. Ponadto pierwszy wiersz tabeli, który z założenia ma być nagłówkiem, to po prostu element td wraz z pogrubioną czcionką. Zaprezentowany kod to powód do wstydu, ponieważ w rzeczywistości ASP.NET posiada funkcje pozwalające na przypisywanie klas CSS dla większości wartości. Ponadto w ASP.NET 2.0 jest obsługiwany znacznik th służący do generowania nagłówka w tabeli. Atrybut CssClass występuje w większości znaczników, a także istnieją inne, które pozwalają na przypisywanie klas znacznikom w wielu sytuacjach. Warto zwrócić uwagę na użycie w poniższym kodzie atrybutu UseAccessibleHeader kontrolki DataGrid. Źle się stało, że programiści muszą stosować wewnątrz kodu własne sposoby na zwiększenie poziomu jego dostępności, ale taka jest natura „bestii” — i na szczęście odpowiednie funkcje są dostępne w ASP.NET 2.0. W zaprezentowanym poniżej fragmencie kodu dokonano drobnych modyfikacji kodu ASP.NET, które pozwoliły na zwiększenie jakości generowanych danych wyjściowych: asp:DataGrid ID= catalog runat= server AutoGenerateColumns= false CssClass= grid-class UseAccessibleHeader= true ItemStyle CssClass= item / AlternatingItemStyle CssClass= item-alt / 140 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C HeaderStyle CssClass= item-header / Columns asp:BoundColumn DataField= Name HeaderText= Nazwa / asp:BoundColumn DataField= abbr HeaderText= Nazwa skrócona / asp:BoundColumn DataField= typeof HeaderText= Rodzaj / asp:BoundColumn DataField= notes HeaderText= Opis / /Columns /asp:DataGrid Do powyższego fragmentu kodu można dołączyć arkusz stylów CSS, na przykład taki: .grid-class { border: 1px solid black; width: 600px; border-collapse:collapse; } .grid-class td { vertical-align: top; padding: 2px; border: 1px solid black; } .item { font: 12px arial, sans-serif; color: #800; } th { font: bold 15px arial, sans-serif; background-color: black; color: white; vertical-align: top; text-align: left; padding: 2px; } .item-alt { font: normal 12px arial, sans-serif; background-color: #ccc; } W takim przypadku wygenerowana tabela HTML będzie sama jak poprzednia (zobacz rysunek 4.4). Jednak użyty do jej utworzenia kod jest lepszy i bardziej zgodny ze standardami sieciowymi. Dane wyjściowe XHTML zostały przedstawione poniżej: table class= grid-class cellspacing= 0 rules= all border= 1 id= catalog style= border-collapse:collapse; tr class= item-header th scope= col Nazwa /th th scope= col Nazwa skrócona /th th scope= col Rodzaj /th th scope= col Opis /th ROZDZIAŁ 4 Programowanie aplikacji sieciowych 141 RYSUNEK 4.4. Ta sama kontrolka DataGrid w ASP.NET, ale po zastosowaniu usprawnień zwiększających jej zgodność ze standardami sieciowymi /tr tr class= item td HyperText Markup Language /td td HTML /td td ´Kod znaczników /td td Uĝywany do tworzenia dokumentów. Charakteryzuje siÚ luěnÈ ´skïadniÈ. /td /tr tr class= item-alt td eXtensible HyperText Markup Language /td td XHTML /td td Kod znaczników /td td To HTML wraz ze skïadniÈ XML, a takĝe ´Ăcisïymi reguïami stosowanymi w XML. /td /tr tr class= item td Kaskadowe arkusze stylów /td td CSS /td td Warstwa ´prezentacyjna /td td Warstwa prezentacyjna witryny. Arkusze stylów sÈ oddzielnymi ´dokumentami i zawierajÈ informacje definiujÈce wyglÈd ´i dziaïanie witryny internetowej. /td /tr tr class= item-alt td JavaScript /td td JS /td td Obsïuga zdarzeñ, interakcja, ´zdarzenia /td td Czasami nazywana warstwÈ obsïugi zdarzeñ, nadzoruje ´interakcjÚ z uĝytkownikiem, zdarzenia oraz sposób zachowania ´stron internetowych. /td /tr /table 142 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C Warto zwrócić uwagę, że nowy kod zawiera znacznik th (kompletny wraz z atrybutem scope) klasy CSS dla większości elementów, łącznie z obsługą naprzemiennego koloru wierszy, oraz nie ma (w większości) osadzonych atrybutów prezentacyjnych. Mimo że powyższy kod na pewno nie jest doskonały, to jednak stanowi duże usprawnienie, a poprawienie danych wyjściowych wymagało drobnych korekt technicznych. Ten rodzaj modyfikacji wymaga pracy ze strony programistów interfejsu, którzy będą znali techniki pracy z kodem wewnętrznym. Albo programistów kodu wewnętrznego, którzy wiedzą, jak programować interfejs. Znaczniki ASP.NET generujące dane wyjściowe na podstawie danych pochodzących z bazy danych posiadają znacznie więcej opcji. W niektórych sytuacjach zastosowanie innego znacznika może być znacznie lepszym rozwiązaniem, ponieważ zapewni on większy poziom kontroli nad generowanym kodem UI. Przykładowo: kontrolka Repeater stanowi doskonały wybór podczas tworzenia prostych danych wyjściowych, gdyż definiuje ona pętlę danych wyjściowych i używa małych szablonów kodu, w których programista może określić to, co powinno być wyświetlone: asp:Repeater id= catalog runat= server HeaderTemplate table class= grid-class tr th Nazwa /th th Nazwa skrócona /th th Rodzaj /th th Opis /th /tr /HeaderTemplate ItemTemplate tr class= item td #Container.DataItem( name ) /td td #Container.DataItem( abbr ) /td td #Container.DataItem( typeof ) /td td #Container.DataItem( notes ) /td /tr /ItemTemplate AlternatingItemTemplate tr class= item-alt td #Container.DataItem( name ) /td td #Container.DataItem( abbr ) /td td #Container.DataItem( typeof ) /td td #Container.DataItem( notes ) /td /tr ROZDZIAŁ 4 Programowanie aplikacji sieciowych 143 /AlternatingItemTemplate FooterTemplate /table /FooterTemplate /asp:Repeater Przedstawiony powyżej kod generuje tabelę HTML, która jest połączona z przedsta- wionym wcześniej arkuszem stylów CSS. Powstały kod jest czysty i pozbawiony wszelkich niepotrzebnych atrybutów prezentacyjnych. Chociaż kontrolka Repeater wymaga użycia nieco większej ilości kodu, to jednak daje programiście większą kontrolę nad sposobem generowania danych wyjściowych (zobacz rysunek 4.5): table class= grid-class tr th Nazwa /th th Nazwa skrócona /th th Rodzaj /th th Opis /th /tr tr class= item td HyperText Markup Language /td td HTML /td td Kod znaczników /td td Uĝywany do tworzenia dokumentów. Charakteryzuje siÚ luěnÈ ´skïadniÈ. /td /tr tr class= item-alt td eXtensible HyperText Markup Language /td td XHTML /td td Kod znaczników /td td To HTML wraz ze skïadniÈ XML, a takĝe Ăcisïymi reguïami ´stosowanymi w XML. /td /tr tr class= item td Kaskadowe arkusze stylów /td td CSS /td td Warstwa prezentacyjna /td td Warstwa prezentacyjna witryny. Arkusze stylów sÈ oddzielnymi ´dokumentami i zawierajÈ informacje definiujÈce wyglÈd ´i dziaïanie witryny internetowej. /td /tr tr class= item-alt td JavaScript /td td JS /td td Obsïuga zdarzeñ, interakcja, zdarzenia /td 144 CSS I AJAX. STRONY WWW ZGODNE ZE STANDARDAMI SIECIOWYMI W3C RYSUNEK 4.5. Użycie kontrolki Repeater ASP.NET w celu wygenerowania tej samej tabeli, ale z czystszym kodem, przy zachowaniu takiego samego wyglądu td Czasami nazy
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

CSS i Ajax. Strony WWW zgodne ze standardami sieciowymi W3C
Autor:
, , , , ,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: