načítání...
nákupní košík
Košík

je prázdný
a
b

Kniha: Webové programování v ASP.NET 2.0 -- Problém, návrh, řešení - Marco Bellinaso

Webové programování v ASP.NET 2.0 -- Problém, návrh, řešení
-15%
sleva

Kniha: Webové programování v ASP.NET 2.0
Autor: Marco Bellinaso
Podtitul: Problém, návrh, řešení

Světový bestseller z legendární edice Programmer to programmer přibližuje tvorbu webových aplikací ASP.NET pomocí konkrétních projektů, jež autor řeší od sestavení úkolu přes návrh ... (celý popis)
Titul doručujeme za 3 pracovní dny
Vaše cena s DPH:  199 Kč 169
+
-
rozbalKdy zboží dostanu
5,6
bo za nákup
rozbalVýhodné poštovné: 69Kč
rozbalOsobní odběr zdarma

hodnoceni - 0%hodnoceni - 0%hodnoceni - 0%hodnoceni - 0%hodnoceni - 0%   celkové hodnocení
0 hodnocení + 0 recenzí

Specifikace
Nakladatelství: » Computer press
Médium / forma: Tištěná kniha
Rok vydání: 2013
Počet stran: 648
Rozměr: 167 x 225 mm
Vydání: Vyd. 1.
Název originálu: ASP.NET 2.0 Website programming
Spolupracovali: překlad Lukáš Krejčí
Vazba: brožovaná lepená
Datum vydání: 1. 9. 2013
Nakladatelské údaje: Brno, Computer Press, 2007
ISBN: 9788025118931
EAN: 9788025118931
Ukázka: » zobrazit ukázku
Popis

Světový bestseller z legendární edice Programmer to programmer přibližuje tvorbu webových aplikací ASP.NET pomocí konkrétních projektů, jež autor řeší od sestavení úkolu přes návrh řešení až po kompletní realizaci aplikace. Na praktických ukázkách v jazyce C# se naučíte navrhovat a tvořit kompletní weby v ASP.NET 2.0 obsahující součásti, které najdete na jakémkoli moderním webovém portálu: diskuzní fóra, ankety, zasílání novinek, správa článků, elektronický obchod a mnoho dalšího. Autor v každé kapitole, jež se věnuje vývoji jedné konkrétní součásti webu, nejdříve popisuje řešený problém, poté probere prvky, s nimiž se bude návrh potýkat, a nakonec předvede, jak efektivním a moderním programováním problém vyřešit. Výklad postupuje krok za krokem a doplňují jej rozsáhlé ukázky zdrojových kódů jednotlivých příkladů. S touto knihou se naučíte: - Plně využívat nové funkce verze 2.0 ke snížení množství nutného kódu - Jedinečným a praktickým způsobem zvládnout různé problémy, s nimiž se setkáte v průběhu vývoje jakýchkoli webů - Implementovat nové možnosti včetně témat, členství, personalizace, lokalizace, vzorových stránek, webových částí a kešování - Využívat mnoho nových serverových ovládacích prvků včetně GridView, DetailsView, MultiView, Wizard, Menu, SiteMap a Login Všechny zdrojové kódy příkladů z knihy si čtenáři mohou stáhnout z webové stránky knihy na adrese http://knihy.cpress.cz/k1457. „Tato publikace je jiná než většina těch, které můžete běžně sehnat v obchodech. Pokud berete v úvahu výkon, bezpečnost, robustnost, škálovatelnost a potrpíte si na detaily, Marcova Pivnice jako vzorová webová aplikace je reálnější než většina ve skutečnosti existujících stránek, které jsem kdy viděl. Vlastně, tento styl psaní je tou nejlepší demonstrací nových možností ASP.NET 2.0.“ – z předmluvy ke knize; Francesco Balena, zakladatel .Net2TheMax, autor a regionální ředitel společnosti Microsoft (problém, návrh, řešení)

Předmětná hesla
Kniha je zařazena v kategoriích
Recenze a komentáře k titulu
Zatím žádné recenze.


Ukázka / obsah
Přepis ukázky

27

2

Návrh webové aplikace

Prvním krokem při vývoji nového webu je návrh jeho vizuální podoby, která sestává z celkového

rozvržení jednotlivých grafických prvků. Vizuální architektura webu významnou měrou ovlivňuje

pocit, jaký bude mít uživatel při jeho prohlížení. Začneme tedy tak, že si stanovíme, jak by měl na

uživatele působit, načež navrhneme mechanismy, s jejichž pomocí tohoto cíle dosáhneme. Zamě

říme se především na menu a navigaci, na obrázky a uspořádání prvků na stránce. Menu musí být

intuitivní a mělo by být doplněno navigačními pomůckami, jako je mapa stránek nebo navigační

cesta (navigace pomocí „sypaných drobků chleba“ – breadcrumb navigation), které uživateli při

pomínají, kde se právě nachází vzhledem k webu jako celku. Navigační cesta se skládá z posloup

nosti krátkých odkazů, které tvoří stezku, po níž se může uživatel vydat, chce-li se po hierarchii

stránek vracet vzhůru, zpět ke dříve navštíveným úrovním.

Před zahájením vlastního programování je vhodné vzít v potaz specifické prostředky nabízené tech

nologií ASP.NET 2.0, a tak si ušetřit spoustu práce, kterou za nás již udělali lidé ze společnosti Micro

soft. Položením vhodných základů pro technickou architekturu můžeme zvýšit znovupoužitelnost

a udržovatelnost našeho kódu. V této kapitole se podíváme na celkové vizuální uspořádání našeho

webu a vysvětlíme si, jak s výhodou používat užitečné techniky, jako jsou vzorové stránky a motivy.

Pomocí vzorových stránek lze seskupovat funkční prvky do šablon, které umožňují sdílet společné

prvky na více stránkách. Motivy zase dovolují uživatelům přizpůsobení jistých aspektů webu, jehož

vzhled si tak přizpůsobí dle vlastních potřeb a chuti (této technice se také říká skinning).

Problém

Řada vývojářů začne psát zdrojový kód, aniž by věnovali pozornost hlavnímu cíli webové aplika

ce: poskytovat uživatelům jednoduchou, ale vysoce funkční grafickou aplikaci. Vývoj uživatelské

ho rozhraní vypadá jako poměrně elementární úkol. Není-li však proveden pořádně, může se stát,

že bude nutné se k němu v průběhu vývoje několikrát vracet. Ovšem pokaždé, když je nutné se

vrátit a provést na nějakých významných prvcích změny, vyžaduje to nemalé množství práce na

víc, a to nepočítáme nové kolo testování jednotek a integračních testů. A co hůř, je-li uživatelské

rozhraní bráno příliš na lehkou váhu, může se stát, že nakonec odradí uživatele, kteří se rozhod


Kapitola 2 – Návrh webové aplikace

28

nou pro jinou webovou stránku. Existuje celá řada prvků, které je nutné zvážit při tvorbě návrhu

webové stránky. Nejdříve si musíme uvědomit jeden základní fakt: vzhled je opravdu důležitý! Po

kud totiž stránka nevypadá dobře, ani lidé se na ní nebudou cítit dobře a pravděpodobně se na ni

již nebudou vracet. Pozornost vývojářů snadno strhávají na první pohled obtížné úkoly, jako je or

ganizování zdrojového kódu do tříd nebo programování aplikační logiky, takže význam vzhledu

webové aplikace je často neprávem umenšován. Ale uživatelské rozhraní je přeci první věcí, kte

rou uživatel při otevření webu spatří. Je-li ošklivé, zmatené a vesměs nepoužitelné, pak si uživatel

s největší pravděpodobností utvoří podobný obrázek i o společnosti, kterou taková webová strán

ka v podstatě reprezentuje. A to naneštěstí bez ohledu na ostatní významné vlastnosti webové

aplikace, jakými jsou rychlost a škálovatelnost. Dále je třeba vzít v potaz, že ne všichni uživatelé

sdílí stejný názor, co se týče zvolené šablony. Pro některé může být text v rámci použitého barev

ného schématu obtížně čitelný, takže mohou dávat přednost jiným barvám, které zase nemusejí

vyhovovat ostatním. Je tedy velice těžké zavděčit se jediným barevným schématem všem uživate

lům. Proto některé webové stránky nabízejí několik barevných schémat a někdy také několik různých uspořádání textu, čímž uživatelům umožňují, aby si vzhled stránky přizpůsobili dle svých

představ a často i fyziologických překážek, mezi něž se řadí například barvoslepost. Studie ukáza

ly, že částečnou barvoslepostí trpí překvapivě velký počet lidí, kteří tak nejsou schopni od sebe

odlišit určité barvy. Musejí mít tedy možnost zvolit si takové barevné schéma, které jim umožní

rozlišit použité barvy a s nímž bude webová stránka vypadat i tak docela příjemně.

Poté, co stanovíme rozvržení a barvy, potřebujeme zajistit, aby stránka vypadala v různých prohlí

žečích stejně. Před pár lety dominoval mezi uživateli operačního systému Windows Internet Ex

plorer (IE), takže při vývoji odborné stránky zaměřené na vývojáře pro Windows bylo možné

předpokládat, že většina této uživatelské základny používá právě IE. Stačilo tedy vyvíjet a testovat

pouze pro prohlížeč IE. Dnes však stále více získává na popularitě prohlížeč Firefox, který je k dis

pozici pro více operačních systémů (např. Linux a Mac OS). Cílová skupina uživatelů našeho webu

je poměrně pestřejší (nejedná se jen o vývojáře pro Windows, ale o potenciálně všechny návštěv

níky hospůdky našeho klienta) a kvůli tomu, že na platformách odlišných od Windows existují i jiné populární prohlížeče, je bezpodmínečně nutné zajistit, aby i na nich naše webová stránka bez obtíží fungovala. Pokud bychom tak neučinili a zaměřili se pouze na IE, mohlo by se stát, že by uživatelé Firefoxu měli prvky na stránce oproti očekávání uspořádané úplně jinak, špatně zarovnané, v nesprávných velikostech a barvách, s překrývajícími se panely a textovými rámečky – jinými slovy, obdrželi by naprostý guláš. Není těžké uhádnout, že uživatel, kterému bychom naservírovali takto nepěknou stránku, by jistě odešel, což by ale znamenalo, že bychom přišli i o potenciálního klienta či zákazníka internetového obchůdku. Když už nic jiného, tak ztráta návštěvnosti snižuje počet zobrazení reklamních proužků. A poněvadž návštěvníky ztratit nechceme, budeme se věnovat oběma hlavním prohlížečům, tedy Internet Exploreru i Firefoxu. Plánování vrstvy uživatelského rozhraní nesestává jen z psaní HTML-kódu nějaké stránky. Zahrnuje také navigační systém a možnost pro webmastera či správce stránky (nebo i pro koncového uživatele) snadno změnit vzhled stránky, aniž by do ní musel jakkoliv zasahovat. Je tedy velmi užitečné vytvořit systém, s jehož pomocí lze jednoduše měnit jednotlivá menu a upravovat vzhled (fonty, barvy a velikosti nejrůznějších částí stránky), protože tím minimalizujeme práci správců, kteří nám za to jistě poděkují. Jakmile dokončíme úvodní stránku, zabere nám vývoj ostatních

stránek mnohem méně času, neboť úvodní stránka již obsahuje kompletní uspořádání a navigační prvky, které se uplatní v rámci celé webové aplikaci. Pokud jsme vytvořili společné uživatelské rozhraní sdílené mnoha dalšími stránkami, tak jakákoliv pozdější úprava uspořádání prvků na

Návrh

29

stránce (třeba přidání rámečku s hlasováním na pravou stranu všech stránek) bude velice jednoduchá. To je také důvod, proč skutečně stojí za to strávit nějaký ten čas navíc přemýšlením o kvalitním návrhu základní vrstvy uživatelského rozhraní namísto okamžitého spuštění aplikace Visual Studio .NET následované bezmyšlenkovitým programováním. Jde vskutku o strategické rozhodnutí, které nám může ušetřit hodiny nebo i dny práce navíc. Pamatujme si tedy, že začlenění zásadních změn aplikovaných v pozdější, vývojové fázi, vyžaduje mnohem více času a úsilí. Návrh V této části se podíváme na problémy popsané výše a promyslíme způsob jejich řešení, přičemž vytvoříme technický návrh systému. V praxi to znamená navrhnout a implementovat následující prvky:

dobře vypadající grafická šablona (rozvržení grafických prvků), která se bude zobrazovat

stejně v Internet Exploreru i Firefoxu, včetně mechanismu pro dynamickou aplikaci různých

barevných schémat a ostatních vizuálních atributů na tuto šablonu;

jednoduchý způsob sdílení vytvořené šablony všemi stránkami webové aplikace, aniž by

chom do každé z nich museli kopírovat a vkládat celý kód;

navigační systém, jenž umožní snadnou úpravu odkazů v menu, z něhož bude uživatelům

zřejmé, kde se v rámci mapy webu právě nacházejí a kudy se mohou vydat zpět;

mechanismus, který umožní nejen společný vizuální návrh všech stránek webové aplikace,

ale také jejich společné chování, jako je například počítání zobrazení stránky či aplikace ob

líbeného stylu uživatele; Při implementaci požadavků týkajících se uživatelského přizpůsobení parametrů, znovupoužitelnosti, menu a navigace si popíšeme, jak s výhodou využít některé z nových prostředků technologie ASP.NET 2.0. Později, v části „Řešení“, si tyto užitečné prvky oživíme! Návrh uspořádání grafických prvků Při vývoji návrhu webové stránky se obvykle pomocí grafické aplikace (např. Adobe Photoshop či Jasc Paint Shop Pro) nejdříve vytvoří maketa, z níž by měla být patrná finální podoba stránky, a to ještě před tím, než začneme s jakýmkoliv programováním. Jakmile máme maketu připravenou, můžeme ji ukázat nejrůznějším uživatelům, testerům a manažerům, kteří poté mohou rozhodnout o zahájení vlastního programování. Stačí i obyčejný obrázek podobný tomu na obrázku 2.1, který zachycuje rozdělení textu do jednotlivých oblastí stránky. Jedná se o typické třísloupkové uspořádání s hlavičkou a patičkou. Po schválení jej musíme sestavit znovu, tentokráte však s opravdovou grafikou a HTML-kódem. Pro maketu se používá grafický program, protože s tímto typem programu zabere návrháři webových stránek její vytvoření mnohem méně času. Poté, co klient finální podobu makety odsouhlasí, může ji návrhář webových stránek rozřezat na malé kousky a použít je pro tvorbu HTML-stránky. Tvorba makety není vždy jednoduchá, obzvláště pro ty, kteří nejsou od přírody umělecky založeni. Pro střední či větší firmu to většinou nebývá problém, protože často je tu někdo jiný, konkrétně profesionální návrhář webových stránek, který vytvoří grafický návrh, z něhož pak vývojáři při práci na webové aplikaci vycházejí. Někdy může být vhodné najmout externí firmu, která se o grafický návrh postará sama, nebo lze tvorbu šablony svěřit ve formě sub-kontraktu

Kapitola 2 – Návrh webové aplikace

30

někomu talentovanějšímu. Pro účely našeho projektu jsme sáhli po jedné z šablon serveru

TemplateMonster (www.templatemonster.com), z níž jsme vytvořili poměrně slušný grafický ná

vrh webové stránky, na němž budeme dále stavět. Server TemplateMonster nabízí šablony ve

formě souborů typu PSD (ty lze otevřít v aplikaci Photoshop či Paint Shop Pro), JPEG a HTML,

přičemž obrázky jsou již rozřezané na části a uspořádané pomocí HTML-tabulek. HTML-stránky

však nepoužijeme bez předchozích úprav, chceme totiž vytvořit alespoň do jisté míry náš vlast

ní styl. Nicméně je velmi užitečné, máme-li nějakou vizuální předlohu, od které se můžeme od

razit. Náš web tak navíc od počátku získá profesionální nádech, což může výrazně pomoci při

dalším prodeji návrhu.

Obrázek 2.1: Maketa naší nové webové stránky

Technologie použité pro implementaci návrhu

Technologie ASP.NET 2.0 zaujímá vzhledem k fungování naší webové aplikace prvotní místo.

Běží na webovém serveru a s výhodou využívá funkční prvky poskytované rámcem .NET Fra

mework. Nicméně ASP.NET neběží na počítači uživatele, ale dynamicky generuje prvky, které

používá prohlížeč pro vykreslování webových stránek. Patří mezi ně HTML-značky, obrázky

a definice kaskádových stylů (CSS – Cascading Style Sheets), které definují barvy, velikosti a po

lohy nejrůznějších objektů na HTML-stránce. ASP.NET dále generuje procedurální kód jazyka

JavaScript, který posílá prohlížeči pro kontrolu uživatelem zadaných údajů a také pro ustavení

způsobu interakce s webovým serverem.

Návrh

31

HTML-kód lze definovat několika různými způsoby. Můžeme sáhnout po vizuálním návrháři formulářů v prostředí Visual Studio, který jej automaticky vygeneruje na základě vkládaných řídicích prvků z palety na formulář. Nebo můžeme ručně upravit či vytvořit vlastní HTML-kód v souboru typu .aspx, čímž získáme přístup také k těm prvkům, se kterými bychom pomocí návrháře formulářu pracovat nemohli. Poslední možností je nechat HTML-kód vygenerovat dynamicky z našeho kódu v jazyku C# nebo ze tříd rámce .NET Framework. Prostředí ASP.NET 1.x používá model s tzv. kódem v pozadí (code-behind): HTML-kód (a některý prezentačně orientovaný C#-kód) byl uložen v souboru typu .aspx a implementační C#-kód se nacházel ve zvláštním souboru, od kterého byl soubor typu .aspx odvozen. Soubor typu .aspx se nazývá „stránka“, poněvadž definuje vizuální podobu webové stránky. Tento model poskytuje určitou míru separace mezi prezentačním a s ním spojeným implementačním kódem. Ovšem jeden s problémů s tímto modelem spočívá v tom, že kód automaticky generovaný návrhářem formulářů je umístěn ve stejných souborech, které používá vývojář pro svůj vlastní kód. ASP.NET 2.0 tento model upravuje a přidává k němu prvky z nové verze rámce .NET Framework 2.0, mezi které patří i částečné třídy. Princip je jednoduchý: umožnit definici jediné třídy překlenout několik souborů. Prostředí aplikace Visual Studio tak může za běhu generovat kód pro deklaraci řídicích prvků a registraci událostí a kombinovat jej s kódem, který píše vývojář. Výsledkem je pak jediná třída, od které je odvozena stránka v souboru typu .aspx. V něm je deklarována direktiva @Page, která pomocí atributu CodeFile odkazuje na soubor typu .cs obsahující kód v pozadí psaný uživatelem. Další změna v ASP.NET 2.0 spočívá v eliminaci souborů projektu. Prvky projektů se nyní rozpoznávají na základě definované struktury adresářů. Kód všech stránek projektu byl navíc v ASP.NET 1.x generován do jediného souboru typu .dll. ASP.NET 2.0 však generuje kód pro každou stránku zvlášť. Z jakého důvodu? Při změně jediné stránky tak není třeba opětovně nasazovat větší množství kódu. Stačí totiž opětovně nasadit jen kód příslušný dané stránce, takže vývojáři mají jemnější kontrolu nad správou změn zdrojového kódu. Použití jazyka CSS pro definici stylů Tato kniha nemá ambice poskytnout vyčerpávající výklad o jazyku CSS, nicméně některé obecné pojmy si alespoň stručně vysvětlíme. Pro podrobnější informace o jazyku CSS je třeba se obrátit na některé další zdroje. Cílem jazyka CSS je specifikovat způsob vykreslení HTML-značek pomocí nejrůznějších stylistických prvků, jako je velikost fontu, barva, zarovnání a tak podobně. Tyto styly lze ve formě atributů vložit do HTML-tagů přímo nebo je lze uložit zvlášť a odvolat se na ně přes jejich jméno či ID. Někdy mají HTML-soubory styly napevno vloženy do HTML-značek, jak je tomu v následujícím příkladu:

<div style="align: justify; color: red; background-color: yellow; font-size:

12px;">nějaký text</div> To však není dobré, neboť je obtížné tyto stylistické prvky upravovat, aniž by bylo nutné procházet všechny HTML-soubory a hledat příslušné CSS-atributy. Místo toho by definice stylů měly být vždy umístěny ve zvláštním souboru s příponou .css nebo alespoň v horní části HTML-souboru v rámci značky <style>. Kapitola 2 – Návrh webové aplikace 32 K seskupování CSS-stylů dohromady lze vytvářet malé třídy, které svou syntaxí připomínají třídy či funkce v C#. Lze jim přiřadit jméno, neboli ID, takže se na ně můžeme v HTML-značkách odkazovat pomocí atributu class. Při použití tříd definujících styl můžeme změnit velikost fontu všech HTML-značek, které se ni odkazují, pouhou úpravou hodnoty v rámci její deklarace, čímž dojde ke změně celé řady vizuálních HTML-prvků daného typu. Pokud styl definujeme v odděleném souboru, pak stačí upra

vit jediný soubor, načež svůj vzhled může změnit hned několik stránek.

Hlavní výhoda při použití jazyka CSS spočívá v minimalizaci úsilí při správě stylů a k prosazení

jednotného vzhledu většího počtu stránek. Ovšem kromě toho, jazyk CSS svým způsobem také

zajišťuje bezpečnost HTML-kódu a potažmo i celého webu. Předpokládejme, že klient chce

změnit některé styly na stránkách, které jsou již v ostrém provozu. Pokud bychom styly umístili

do HTML-prvků stránky napevno, museli bychom při provádění jakýchkoliv změn procházet

množství souborů, což může vést k chybám zapříčiněným překlepy či přehlédnutím hledaného stylu. Máme-li však třídy stylů uložené ve zvláštních souborech typu CSS, pak je mnohem snazší vyhledat třídy, které je třeba změnit, přičemž náš HTML-kód zůstane v bezpečí a nedotčen. Kromě toho mohou soubory typu CSS celé webové stránky zefektivnit. Prohlížeč je totiž stáhne pouze jednou a umístí si je do vyrovnávací paměti. Jednotlivé HTML-stránky pak neobsahují opakující se definice stylů, ale mohou se odkazovat na tyto sobory ve vyrovnávací paměti, čímž dojde ke snížení jejich velikosti, což zase vede ke zrychlení jejich stahování. V některých případech může tento způsob práce se styly způsobit dramatické zvýšení rychlosti načítání webové stránky v prohlížeči uživatele. Následuje ukázka redefinice stylu výše uvedeného objektu typu DIV. Styl jsme uložili do samostatného souboru jménem styles.css:

.mystyle

{

align: justify;

color: red;

background-color: yellow;

font-size: 12px;

}

Všiměte si, že jsme při deklaraci stylu uvedli před jménem třídy tečku. U všech vlastních tříd stylů

je nutné tento prefix uvádět.

S HTML-kódem v souboru typu .aspx nebo .htm jej propojíme takto:

<head>

<link href="/styles.css" text="text/css" rel="stylesheet" />

<!-- další meta-značky ... -->

</head> Nakonec zapíšeme HTML-značku <div> a určíme, kterou CSS-třídu má použít:

<div class="mystyle"> nějaký text </div>

Návrh

33

Chceme-li námi definovaný styl aplikovat na všechny HTML-objekty určitého typu (například na všechny značky <p> nebo <body>), s nimiž není explicitně spojena nějaká jiná třída, pak můžeme do souboru se styly zapsat následující specifikace:

body

{

margin: 0px;

font-family: Verdana;

font-size: 12px;

}

p

{

align: justify;

text-size: 10px;

} Tímto způsobem nastavíme z jednoho místa výchozí styl pro všechny značky <body> (tělo stránky) a <p> (odstavec). Nicméně stále máme možnost pro některé odstavce definovat odlišný styl explicitním uvedením jména třídy stylu v příslušné značce <p>. Další způsob propojení třídy definující styl s HTML-objektem spočívá ve využití jeho ID. Jméno třídy definujeme v tomto případě s prefixem #:

#header

{

padding: 0px;

margin: 0px;

width: 100%;

height: 184px;

background-image: url(images/HeaderSlice.gif);

} Nyní můžeme propojit styl s HTML-objektem pomocí jeho atributu id. Tímto způsobem lze například definovat HTML-značku <div>, která používá styl s názvem #header:

<div id="header"> nějaký text </div> Výše uvedený postup se obvykle používá pro neopakující se objekty, jako je kupříkladu hlavička, patička, kontejner pro levý, pravý či prostřední sloupek a podobně. Oba přístupy lze bez problémů kombinovat. Předpokládejme, že chceme dát jistý styl všem odkazům v kontejneru se stylem sectiontitle a jiný styl odkazům v kontejneru se stylem sectionbody. Můžeme to provést například takto: V souboru typu .css

.sectiontitle a

{

color: yellow; Kapitola 2 – Návrh webové aplikace 34

}

.sectionbody a

{

color: red;

} V souboru typu .aspx / .htm

<div class="sectiontitle">

nějaký text

<a href="http://www.cpress.cz">Computer Press

nějaký text

</div>

<div class="sectionbody">

nějaký jiný text

<a href="http://knihy.cpress.cz">Knihy

nějaký jiný text

</div> HTML-tabulky se pro uspořádání prvků na stránce nehodí Vývojáři občas používají HTML-tabulky pro uspořádání objektů na webové stránce. Před vytvořením jazyka CSS šlo o standardní postup, nicméně řada vývojářů používá tuto techniku dodnes. Ačkoliv jde o velmi rozšířenou praxi, organizace W3C od ní oficiálně odrazuje tvrzením (viz http://www.w3.org/TR/WAI-WEBCONTENT/): „Pomocí tabulek by se měly označovat pouze informace skutečně tabulkového charakteru (tzv. datové tabulky). Neměly by se používat pro uspořádání prvků na stránkách s textovým obsahem (tzv. rozvrhovací tabulky). Tabulky používané k v podstatě jakýmkoliv účelům představují zvláštní problémy pro uživatele se čtečkami obrazovek.“ Jinými slovy, HTML-tabulky by se měly používat pro zobrazování tabulkových dat, a ne pro celkové rozvržení stránky. K tomuto účelu bychom měli vždy sáhnout po řídicích prvcích kontejneru (jako je např. značka <div>) s příslušným nastavením jejich stylu, nejlépe prostřednictvím zvláštní sekce <style> nebo samostatného souboru. Jedná se o ideální řešení, a to hned z několika důvodů:

Pokud definujeme vzhled a rozmístění pomocí značek <div> a samostatného souboru se styly,

nemusíme na každé stránce opakovat tyto definice stále znovu, což vede k webové stránce,

která je zároveň rychleji vytvořena a snadněji se udržuje.

Stránka se koncovému uživateli načte mnohem rychleji! Pamatujme, že klient si soubor se styly

stáhne pouze jednou a poté jej bude mít pro následující požadavky k dispozici ve vyrovnávací

paměti, dokud se jejich obsah na straně serveru nezmění. Pokud bychom definovali rozvržení

uvnitř HTML-souboru pomocí tabulek, musel by klient stahovat tabulkové rozvržení pro kaž

dou stránku zvlášť, čímž by přenášel větší množství bajtů, což by zabralo více času. Rozvržení

řízené styly typicky sníží počet stahovaných bajtů až na polovinu, takže výhoda tohoto přístu

pu je ihned viditelná. Tyto úspory jsou navíc mnohem více patrné na těžce zatěžovaných

webových serverech, poněvadž snížení počtu zasílaných bajtů každému z uživatelů se násobí

počtem souběžně připojených klientů.


Návrh

35

Čtečky obrazovek, což je software, který dokáže číst text a ostatní informace na stránce slepým

a zrakově handicapovaným uživatelům, mají při použití tabulek pro rozvržení prvků na stránce

mnohem těžší práci. Z toho vyplývá, že při rozvrhování bez použití tabulek můžeme zvýšit pří

stupnost webové stránky, což je naprosto nezbytná nutnost pro určité skupiny serverů, jako je

veřejná správa a vládní organizace. Některé společnosti jsou místo přijetí takto jednoduchých

pravidel ochotné odepsat celé skupiny uživatelů.

CSS-styly a značky <div> jsou na rozdíl od tabulek mnohem všestrannější. Můžeme mít napří

klad různé soubory se styly definující odlišné vzhledy a umístění pro nejrůznější objekty na

stránce. Přepínáním připojeného souboru se styly tak můžeme kompletně měnit vzhled strán

ky, aniž bychom cokoliv upravovali na samotných stránkách s obsahem. S dynamickými strán

kami využívajícími technologii ASP.NET lze navíc měnit soubor se styly za běhu a snadno tak

implementovat mechanismus, díky němuž si mohou koncoví uživatelé vybrat styl, který jim

nejvíce vyhovuje. Přitom nejde jen o barvy a fonty – v souborech typu CSS totiž můžeme stano

vit polohy jednotlivých objektů a vytvořit si tak soubor, který umístí rámeček s menu do levého

horního rohu stránky, a k tomu jiný, který jej zasadí do spodního pravého rohu. To je velice dů

ležité, neboť chceme, aby si uživatelé zvolili svůj oblíbený styl ze seznamu dostupných motivů.

Jazyk CSS umožňuje vyvíjet pro různé typy zařízení, v některých případech dokonce bez nut

nosti nového HTML-kódu. Patří mezi ně například mobilní zařízení, jako jsou PDA či chytré te

lefony. Kvůli menší obrazovce je nutné přizpůsobit rozvržení obsahu na stránce, aby se vešel

na tak malou obrazovku a byl stále dobře čitelný. Lze to provést pomocí zvláštního souboru se

styly, který změní velikost a polohu některých kontejnerů (např. svislé sloupky umístí pod se

be) nebo je úplně skryje. Můžeme například skrýt kontejner pro reklamní proužky, hlasování

a hlavičku s velkým logem. Pokud bychom se o něco takového pokoušeli s tabulkami, bylo by

to mnohem obtížnější. Bylo by nutné pořádně promyslet mechanismus uživatelského přizpů

sobení skinů, přičemž by bylo zapotřebí napsat samostatné stránky pro každé rozvržení. Opro

ti prostému vytvoření nového souboru typu CSS se jedná o neúměrně větší množství práce.

Všimněte si, že výše uvedená diskuse se týká použití tabulek pro celkové rozvržení prvků na webo

vé stránce. Tvorba vstupních formulářů s tabulkovou strukturou pomocí tabulek je však přípustná.

V opačném případě by totiž k jejich snadnému zápisu a údržbě bylo zapotřebí příliš mnoho CSS-kó

du. Navíc není pravděpodobné, že bude nutné dynamicky měnit rozvržení vstupního formuláře,

čímž se celá flexibilita jazyka technologie CSS stává zbytečnou a použití HTML-tabulek tak zůstává

mnohem přímočařejší. Sdílení společného vzhledu mezi více stránkami Jakmile dokončíme grafický návrh naší webové stránky, musíme najít způsob, jak jej jednoduše aplikovat na n dalších stránek, kde n může znamenat desítky, či dokonce stovky stránek. V předchozí edici této knihy týkající se ASP.NET 1.x jsme se drželi klasického postupu izolace společných částí návrhu do souborů s uživatelskými řídicími prvky, které se poté importovaly do všech stránek, které je potřebovaly. Speciálně jsme museli vytvořit jeden řídicí prvek pro hlavičku a druhý pro patičku. Ačkoliv šlo o výrazně lepší postup, než je kopírování kódu do všech stránek, a o něco lepší techniku, než je vkládání souborů s klasickým ASP-kódem (kvůli jejich objektově orientované povaze), stále to nebylo ono. Problém tkvěl především v tom, že pro každou stránku bylo stále nutné k importování řídicích prvků napsat několik řádků do souboru typu .aspx a k tomu přidat pár dalších řádků pro jejich umístění na vybraná místa na stránce. Pokud bychom je tedy umístili Kapitola 2 – Návrh webové aplikace 36 do určité pozice na první stránce a do jiné na druhé stránce, vypadaly by tyto dvě stránky při spuštění odlišně. Není však možné, abychom se při každé tvorbě nové stránky neustále věnovali těmto detailům. Místo toho bychom se spíše měli zaměřit na vlastní obsah přidávané stránky a společné rozvržení prvků si nechat aplikovat na všechny stránky zcela automaticky. Ve skutečnosti potřebujeme nějaký druh vizuální dědičnosti, s jejíž pomocí bychom mohli definovat „základní“ stránku a ostatní stránky od ní odvodit. V ASP.NET 1.x je však možné aplikovat dědičnost pouze na úrovni programového kódu v pozadí, který má vliv pouze na chování stránky (např. co se stane, když se stránka načte či vykreslí), a ne na její vzhled. I tento problém se dal několika způsoby obcházet, žádný z nich však nesplňuje naše požadavky co se funkčnosti a podpory ve fázi návrhu týče. Řešení tak nakonec přinesla sama technologie ASP.NET 2.0. Model vzorové stránky Technologie ASP.NET 2.0 zavádí nový prvek, tzv. „vzorové stránky“, které umožňují definovat společné oblasti (např. hlavičky, patičky, menu a podobně) sdílené všemi stránkami. Vzorová stránka dovoluje umístit kód s uspořádáním stránky do jediného souboru, od kterého budou vizuálně dědit všechny ostatní stránky. Vzorová stránka obsahuje celkové rozvržení grafických prvků webové aplikace. Stránky s obsahem mohou vzhled vzorové stránky zdědit a vlastní obsah umístit do řidících prvků typu ContentPlaceHolder. I když výsledkem je určitá forma vizuální dědičnosti, samotný mechanismus není ve skutečnosti realizován jako dědičnost ve smyslu objektově oriento

vaného programování. Jeho implementace je totiž založena na modelu šablon.

Příklad řekne víc než tisíc slov, pojďme se tedy podívat, jak tento princip vypadá v praxi. Vzo

rová stránka má příponu .master a „pod povrchem“ je podobná uživatelskému řídicímu prvku.

Následuje ukázka kódu vzorové stránky obsahující nějaký text, hlavičku, patičku a mezi nimi

řídicí prvek ContentPlaceHolder:

<%@ Master Language="C#" AutoEventWireup="true"

CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>

<html>

<head id="Head1" runat="server">

<title>Pivnice

</head>

<body>

<form id="Main" runat="server">

<div id="header">Pivnice

<asp:ContentPlaceHolder ID="MainContent" runat="server" />

<div id="footer">Copyright 2005 Marco Bellinaso

</form>

</body>

</html> Jak je patrné, vzorová stránka je velmi podobná stránce standardní, až na to, že má v horní části místo direktivy @Page direktivu @Master a deklaruje jeden nebo i více řídicích prvků typu ContentPlaceHolder, do nichž mohou stránky typu .aspx umisťovat svůj obsah. Vzorová a obsahová stránka za běhu splynou v jednu, a protože vzorová stránka definuje značky <html>, <head>,

Návrh

37

<body> a <form>, není překvapivé, že stránky s obsahem již tyto značky definovat nesmějí. Měli by definovat pouze obsah pro řídicí prvky typu ContentPlaceHolder. Následující úryvek zachycuje ukázku obsahové stránky:

<%@ Page Language="C#" MasterPageFile="~/MasterPage.master"

AutoEventWireup="true" CodeFile="MyPage.aspx.cs" Inherits="MyPage"

Title="Pivnice - Moje stránka" %>

<asp:Content ID="MainContent" ContentPlaceHolderID="MainContent"

Runat="Server">

Obsah stránky bude tady ...

</asp:Content> Prvním pravidlem je, že direktiva @Page nastavuje atribut MasterPageFile na virtuální cestu ke vzorové stránce, která se má použít. Vlastní obsah jsme umístili do řídicího prvku typu Content, jehož atribut ContentPlaceHolderID musí být nastaven na ID jednoho z řídicích prvků typu ContentPlaceHolder ve vzorové stránce. Do stránky s obsahem nelze umístit nic jiného než řídicí prvky typu Content, přičemž všechny ostatní řídicí prvky jazyka ASP definující vizuální prvky musejí být seskupeny v nejzevnějším prvku typu Content. Další novinkou, která stojí za pozornost, je nový atribut Title direktivy @Page, jehož prostřednictvím je možné přepsat hodnotu specifikovanou v meta-značce <title> vzorové stránky. Pokud atribut Title pro danou stránku s obsahem nedefinujeme, použije se nadpis zadaný ve vzorové stránce. Při úpravě obsahové stránky v prostředí Visual Studio, vykreslí návrhář formulářů obě stránky (vzorovou i obsahovou) správně, přičemž obsah vzorové stránky bude „zašedlý“. Jedná se o připomenutí, že při úpravě obsahové stránky není možné modifikovat obsah vzorové stránky. Nyní je třeba připomenout, že i vzorová stránka má svůj soubor s doprovodným kódem (codebeside), který lze využít pro zápis vlastností a funkcí jazyka C#, k nimž můžeme přistupovat jak ze souborů typu .aspx, tak i z doprovodného kódu obsahových stránek. Obrázek 2.2: Grafická reprezentace vzorové stránky Kapitola 2 – Návrh webové aplikace 38 Při definici prvků typu ContentPlaceHolder ve vzorové stránce můžeme také specifikovat jejich výchozí obsah, který se použije v případě, že konkrétní obsahová stránka neobsahuje odpovídající prvek typu Content. Následující úryvek demonstruje specifikaci výchozí obsahu:

<asp:ContentPlaceHolder ID="MainContent" runat="server">

Zde může být výchozí obsah ...

</asp:ContentPlaceHolder> Výchozí obsah je velice užitečný při řešení takových situací, kdy potřebujeme přidat novou část do většího počtu obsahových stránek, aniž bychom chtěli či mohli upravit každou z nich. Ve vzorové stránce můžeme připravit nový prvek typu ContentPlaceHolder, přiřadit mu nějaký výchozí obsah a pak beze spěchu přidávat nové informace na stránky s obsahem, přičemž na těch, ke kterým jsme se dosud nedostali, se bez problémů zobrazí výchozí obsah ze vzorové stránky. Atribut MasterPageFile na úrovni stránky je užitečný v případě, kdy pro odlišné sady obsahových stránek potřebujeme použít různé vzorové stránky. Pokud by však pro všechny stránky naší webové aplikace používaly tutéž vzorovou stránku, pak by bylo jednodušší, specifikovat ji prostřednictvím elementu <pages> v souboru web.config:

<pages masterPageFile="~/Template.master" /> Pokud i v této situaci uvedeme na úrovni stránky atribut MasterPageFile, přepíšeme pro příslušnou stránku hodnotu v souboru web.config. Vnořené vzorové stránky Půjdeme-li o krůček dále, pak obsahem vzorové stránky může být opět jiná vzorová stránka.

Jinými slovy, vzorové stránky můžeme vnořovat, takže jedna vnořená vzorová stránka zdědí

vzhled nadřazené vzorové stránky, přičemž obsahové stránky typu .aspx dědí od vnořené vzo

rové stránky. Vzorová stránka druhé úrovně může vypadat například takto:

<%@ Master Language="C#" MasterPageFile="~/MasterPage.master"

AutoEventWireup="true" CodeFile="MasterPage2.master.cs"

Inherits="MasterPage2" %>

<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">

Nějaký další obsah ...

<hr style="width: 100%;" />

<asp:ContentPlaceHolder ID="MainContent" runat="server" />

</asp:Content> K tomu, aby obsahová stránka začala používat vzorovou stránku druhé úrovně, stačí upravit pouze hodnotu jejího atributu MasterPageFile, což je dáno tím, že prvky typu ContentPlaceHolder v rodičovské i odvozené vzorové stránce mohou mít totožné ID. Díky tomu můžeme mít vnější vzorovou stránku, která definuje velmi hrubé rozvržení (často jde

o rozvržení typu companywide), a pak ostatní vzorové stránky, jež stanoví uspořádání pro speci

fickou oblast webu, jako je například Internetový obchod či administrační část. Jediný problém

s vnořenými vzorovými stránkami spočívá v tom, že pro ně (narozdíl od vzorových stránek první

úrovně) neexistuje v prostředí Visual Studia podpora ze strany vizuálního návrháře. Při úpravě ob


Návrh

39

sahových stránek je nutné vše programovat přímo ve zdrojových souborech, přičemž výsledek lze zhodnotit až při otevření stránky v prohlížeči. Pro vývojáře, kteří si raději většinu kódu píší sami v okně SOURCE VIEW, to zase tak velký problém není, a také ti ostatní by měli možnost použití vnořených vzorových stránek zvážit, protože se skutečně jedná skvělou techniku! Přístup z obsahové do vzorové stránky Z obsahové stránky můžeme přes vlastnost Master třídy Page přistupovat k její vzorové stránce. Obdržíme objekt typu MasterPage, který je přímo odvozen od třídy UserControl (říkali jsme si, že vzorové stránky jsou podobné uživatelským řídicím prvkům), k níž přidává několik vlastností. Nabízí kolekci Controls, jejímž prostřednictvím lze z obsahové stránky přistupovat k řídicím prvkům stránky vzorové. To se může hodit, zvláště pak chceme-li na určité stránce skrýt některé řídicí prvky vzorové stránky (např. rámeček s přihlašovacími údaji či reklamou). S kolekcí Controls bychom sice mohli pracovat přímo, získané objekty bychom však museli manuálně přetypovat z obecného typu Control na správný typ, což by znamenalo používat slabě typovaný přístup. Mnohem lepší postup, který je navíc v souladu s objektovým myšlením, spočívá v přidání nových vlastností do třídy v doprovodném kódu vzorové stránky. V našem případě to znamená zabalit vlastnost Visible nějakého řídicího prvku, což můžeme provést například takto:

public bool LoginBoxIsVisible

{

get { return LoginBox.Visible; }

set { LoginBox.Visible = value; }

} Nyní můžeme k obsahové stránce přidat za direktivu @Page následující řadek:

<%@ MasterType VirtualPath="~/MasterPage.master" %> Tím jsme stanovili cestu ke vzorové stránce, kterou použije prostředí ASP.NET k dynamickému vytvoření silně typované třídy MasterPage, jež odhaluje vlastnosti nově přidané ke třídě v jejím doprovodném kódu. Vypadá to sice jako kopírování atributu MasterPageFile direktivy @Page, jde však o způsob, jak obsahové stránce zpřístupnit vlastnosti stránky vzorové. Vzorový typ lze kromě virtuální cesty (jako ve výše uvedeném příkladě) specifikovat také pomocí jména příslušné třídy, k čemuž slouží atribut TypeName. Jakmile tuto direktivu přidáme do souboru s doprovodným kódem obsahové stránky (nebo do sekce <script runat="server"> samotného souboru typu .aspx), můžeme se snadno dostat k vlastnosti vzorové stránky LoginBoxIsVisible, přičemž používáme silně typovaný přístup:

protected void Test_OnClick(object sender, EventArgs e)

{

this.Master.LoginBoxIsVisible = false;

} Z použití silně typovaného přístupu mimo jiné plyne, že v prostředí Visual Studia máme k dispozici pomocný nástroj Intellisense, který nám po napsání „this.Master.“ bez problému nabídne také naši nově přidanou vlastnost! Kapitola 2 – Návrh webové aplikace 40 Metodologie přístupu ke vzorovým objektům z obsahových stránek je užitečná zvláště v případě, kdy potřebujeme do vzorové stránky umístit metody, běžně používané na odvozených stránkách. Pokud bychom neměli přístup k silně typovanému objektu MasterPage vytvořenému za běhu v prostředí ASP.NET, museli bychom pro volání těchto metod využít reflexi, která je pomalejší a rozhodně ne tak jednoduchá (v našem případě by bylo snazší umístit sdílené metody do samostatné třídy, ke které mají přístup všechny stránky). Co se první edice této knihy týče, je třeba upozornit na rozdíly při používání bázové stránky ve smyslu OOP a vzorové stránky (MasterPage). V první edici jsme si definovali bázovou třídu ThePhile, od níž jsme odvodili všechny „obsahové“ stránky. Šlo o skutečnou dědičnost dle OOP, ale s omezenými možnostmi, neboť jsme od bázové třídy nemohli odvodit žádný z prvků definujících vzhled stránky. K realizaci společných vizuálních prvků jsme museli vytvořit vlastní řídicí prvky. Ovšem s nástupem ASP.NET 2.0 jsme při definici vzorové stránky schopni zajistit úplnou vizuální dědičnost (ne tak dědičnost kódu ve smyslu OOP). Neexistence dědičnosti kódu není ve skutečnosti nijak vážným omezením, protože ke kódu vzorové stránky se můžeme dostat přes odkaz MasterType, jak jsme si vysvětlili výše. Přepínání vzorových stránek za běhu Poslední věcí, které se budeme v tomto úvodu ke vzorovým stránkám věnovat, je možnost dynamické změny vzorové stránky za běhu webové aplikace! Vskutku, můžeme mít několik vzorových stránek a po spuštění si vybrat, kterou chceme použít. Stačí v obslužné metodě události PreInit nastavit hodnotu vlastnosti stránky MasterPageFile:

protected void Page_PreInit(object sender, EventArgs e)

{

this.MasterPageFile = "~/OtherMasterPage.master";

} Událost PreInit je v prostředí ASP.NET 2.0 nová, přičemž vlastnost MasterPageFile lze nastavit pouze v ní, protože sloučení vzorové a obsahové stránky musí proběhnout v rané fázi životního cyklu webové stránky (v obslužné metodě události Load či Init by již bylo pozdě). Při dynamické změně vzorové stránky se vždy musíme ujistit, že řídicí prvky typu ContentPlaceHolder mají ve všech vzorových stránkách totéž ID, jinak by se řídicí prvky typu Content definované v obsahových stránkách s nimi nepropojily. Díky této úžasné možnosti můžeme vytvořit několik vzorových stránek definujících naprosto odlišné uspořádání prvků na stránce, takže uživatelé si mohou zvolit přesně takové, které jim nejvíce vyhovuje. Nevýhodou tohoto postupu však je, že pokud k doprovodnému kódu jedné vzorové stránky připíšeme vlastní kód, pak jej musíme zkopírovat do souborů s doprovodnými kódy všech ostatních vzorových stránek. V opačném případě by jej obsahová stránka nemusela vždy najít. Navíc nemůžeme použít silně typovanou vlastnost Master, poněvadž typ vzorové stránky za běhu změnit nemůžeme. Lze jej totiž nastavit pouze direktivou @MasterType. Z uvedených důvodů nebudeme pro mechanismus změny rozvržení prvků používat odlišné vzorové stránky. Místo toho budeme mít pouze jednu, na níž budeme aplikovat různé soubory se styly. Přitom díky tomu, že jsme se rozhodli nepoužívat pro uspořádání tabulky, můžeme pomocí stylů zcela změnit vzhled (fonty, barvy, obrázky a pozice) našeho webu.

Návrh

41

Tvorba sady volitelných motivů Motivy jsou v prostředí ASP.NET 2.0 novým prvkem, který uživatelům nabízí větší kontrolu nad vzhledem webové stránky. Pomocí motivu lze definovat barevná schémata, názvy, velikosti a styly fontů, a dokonce obrázky (mají-li mít hranaté či zakulacené okraje, nebo prostě obrázky v různých barvách a s různým stínováním). Podpora „skinů“ v ASP.NET 2.0 vznikla jako rozšíření principu kaskádových stylů. Každý uživatel si může zvolit motiv z dostupné nabídky, přičemž vybraný motiv určuje „skin“, jenž přesně stanoví, jaká vizuálně-stylistická nastavení se mají v rámci daného sezení použít. Skiny jsou tedy jakýmisi příbuznými kaskádových stylů, k jejichž zpracování dochází na straně serveru. Soubor skinu je podobný CSS-souboru, ale narozdíl od něj může přepsat nejrůznější vizuální vlastnosti, jež byly pro řídicí prvky na straně serveru explicitně nastaveny v rámci stránky (globální CSS-specifikace nemůže nikdy přepsat lokální styl konkrétního řídicí prvku). Motivy mohou uchovávat speciální verze obrázků, což se může hodit, máme-li několik sad obrázku, které používají odlišná barevná schémata založená na aktuálním skinu. Nicméně motivy kaskádové styly nijak nenahrazují, spíše je vhodně doplňují. Při použití obou technologií lze dosáhnout skutečně vysoké míry flexibility a přitom mít vše pěkně pod kontrolou. Co se souborů se styly týče, v ASP.NET 2.0 nedošlo k žádným velkým změnám, snad až na pár řídicích prvků, kterým přibyla vlastnost CssClass, a několik řídicích prvků, pro něž lze ve vizuálním návrháři zvolit předpřipravený CSS-styl. Motiv tvoří skupina vzájemně souvisejících souborů uložených v nějakém podadresáři adresáře /App_Themes, které mohou obsahovat následující položky:

Soubory se styly (typu .css), které definují vzhled HTML-objektů.

Soubory skinu, které definují vzhled řídicích prvků prostředí ASP.NET na straně serveru.

Můžeme se na ně dívat jako na soubory se styly na straně serveru.

Ostatní zdroje (např. obrázky). Jedna ze skvělých věcí týkajících se způsobu, jakým ASP.NET 2.0 implementuje motivy, spočívá v tom, že při aplikaci motivu na stránku (popíšeme si později), vytvoří ASP.NET za běhu a zcela automaticky na všech stránkách meta-značku <link> pro každý soubor typu .css, který se nachází v adresáři motivu! To je výborné, protože stačí jen přejmenovat existující CSS-soubor nebo přidat nový, a rázem se s ním automaticky propojí všechny stránky. To je nesmírně důležité, protože, jak uvidíme později, při dynamické změně motivu (podobně jako při změně vzorové stránky) připojí ASP.NET soubory z adresáře nového motivu, čímž změní vzhled webu dle preferencí jednotlivých uživatelů. Bez tohoto mechanismu bychom museli za běhu ručně vytvářet meta-značky <link> podle toho, jaký motiv by uživatel zvolil, což by bylo velice obtížné. Nejlepší novinkou v rámci motivů jsou styly na straně serveru, kterým se říká skiny. Jedná se o soubory s příponou .skin, které obsahují deklaraci řídicích prvků prostředí ASP.NET, která může vypadat například takto:

<asp:TextBox runat="server" BorderStyle="Dashed" BorderWidth="1px" />

Vše je stejné jako při normální deklaraci v souboru typu .aspx, jedinou výjimkou je, že řídicím prvkům nepřiřazujeme ID. Po aplikaci motivu na stránku dostanou její řídicí prvky vzhled dle definic v souboru skinu. Co se řídicího prvku typu TextBox týče, nemusí technika skinů zatím vypadat tak úžasně, poněvadž stejného výsledku bychom dosáhli vytvořením stylu pro HTML-element <input>. Nicméně ihned poté, co si uvědomíme, že to samé lze provádět i s mnohem složitějšími Kapitola 2 – Návrh webové aplikace 42 řídicími prvky, jako je například Calendar či DataGrid (nebo nový GridView), začne celý mechanismus dávat větší smysl, neboť tyto prvky se nevztahují pouze k jednomu HTML-elementu, takže jejich styl nelze definovat tak snadno jen jedinou třídou v klasickém souboru se styly.

Můžeme mít jediný soubor typu .skin, do něhož umístíme definice pro řídicí prvky jakéhokoliv typu,

nebo si můžeme vytvořit samostatné skiny pro každý typ zvlášť (např. TextBox.skin, Data

Grid.skin, Calendar.skin a podobně). K jejich sloučení dojde v paměti za běhu webové aplikace,

takže jde jen o to, aby si každý uspořádal definice skinů podle vlastní chuti. Pro aplikaci motivu na jedinou stránku stačí použít atribut Theme direktivy @Page:

<%@ Page Language="C#" Theme="NiceTheme" MasterPageFile="~/MasterPage.master"

... %>

Při aplikaci na všechny stránky můžeme využít atribut theme elementu <pages> v souboru web.config:

<pages theme="NiceTheme" masterPageFile="~/MasterPage.master" />

Stejně jako v případě vzorových stránek i motivy lze měnit z programového kódu, konkrétně z metody obsluhující událost PreInit ve třídě Page. Motiv, jehož jméno je uloženo v proměnné Session, lze aplikovat například takto:

protected void Page_PreInit(object sender, EventArgs e)

{

if (this.Session["CurrentTheme"] != null)

this.Theme = this.Session["CurrentTheme"];

}

V kapitole 4 tento mechanismus vylepšíme nahrazením proměnné Session novou vlastností

Profile.

Při použití atributu Theme direktivy @Page (nebo atributu theme v souboru web.config) potlačí

atributy vzhledu specifikované v souborech skinu své protějšky specifikované v souborech typu

.aspx. Mají-li motivy fungovat podobně jako kaskádové styly (styly definované v souborech typu

.skin půjdou v souborech typu .aspx přepsat), musíme motiv připojit přes atribut

StylesheetTheme direktivy @Page nebo atribut styleSheetTheme elementu <pages> v souboru

web.config. Atributy Theme a StylesheetTheme bychom si tedy v žádném případě neměli plést! Dosud jsme probírali anonymní skiny – tedy skiny, které definují vzhled všech řídicích prvků daného typu. V některých případech však budeme potřebovat řídicí prvky s odlišným vzhledem, než jak jej definuje soubor skinu. Toho dosáhneme třemi různými způsoby: 1. Jak jsme si popsali výše, motiv můžeme aplikovat pomocí vlastnosti StylesheetTheme (na

místo vlastnosti Theme), takže vizuální vlastnosti zapsané do souborů typu .aspx přepíší

vzhled definovaný v souboru skinu. Nicméně výchozí chování mechanismu motivů zajišťuje,

aby všechny řídicí prvky téhož typu měly stejný vzhled, což se hodí zejména v situacích,

kdy na stránkách pracuje několik vývojářů, přičemž nemůžeme zajistit, že všichni budou

používat atributy ve stránkách typu .aspx, pouze pokud to bude striktně vyžadováno.

Návrh

43

2. Můžeme vypnout aplikaci motivu jen pro daný řídicí prvek a aplikovat na něj atributy

vzhledu standardním způsobem:

<asp:TextBox runat="server" ID="btnSubmit" EnableTheming="False"

BorderStyle="Dotted" BorderWidth="2px" /> 3. Můžeme použít pojmenovaný skin, který oproti anonymnímu navíc obsahuje atribut SkinID:

<asp:Label runat="server" SkinID="FeedbackOK" ForeColor="green" />

<asp:Label runat="server" SkinID="FeedbackKO" ForeColor="red" /> Při deklaraci řídicího prvku je třeba uvést odpovídající hodnotu vlastnosti SkinID:

<asp:Label runat="server" ID="lblFeedbackOK"

Text="Zpráva byla úspěšně odeslána."

SkinID="FeedbackOK" Visible="false" />

<asp:Label runat="server" ID="lblFeedbackKO"

Text="Omlouváme se, ale při odesílání zprávy se vyskytl problém."

SkinID="FeedbackKO" Visible="false" /> Jedná se pravděpodobně o nejlepší variantu, neboť se nám tak otevírá cesta k definici něko

lika vzhledů v jednom souboru pro tentýž typ řídicího prvku, které pak můžeme aplikovat

na jakékoliv stránce. Ponecháme-li navíc definice všech stylů v souborech typu .skin místo

toho, abychom je vkládali do samotných stránek, budeme schopni kompletně změnit

vzhled webové stránky pouhým přepnutím aktuálního jména motivu (což bylo také důvo

dem zavedení motivů).

V části „Řešení“ této kapitoly použijeme motivy pro vytvoření několika různých vizuálních reprezentací téže vzorové stánky. Tvorba navigačního systému Jak jsme si již řekli v části „Problém“, potřebujeme vytvořit nějaký systém pro menu, který by se jednoduše udržoval a pro uživatele by byl snadno pochopitelný. Mohlo by se zdát, že stačí menu zapsat napevno ve formě HTML-kód, ale to není vhodná volba, protože v případě, že bychom chtěli mít menu na více stránkách nebo bychom jej potřebovali změnit, museli bychom jeho kód pokaždé kopírovat (tedy hlavičku a patičku). V první edici této knihy jsme vytvořili svůj vlastní řídicí prvek, který vzal XML-soubor obsahující mapu stránek (tj. jméno a URLadresu odkazů pro zobrazení v menu) a pomocí XSL-souboru sestavil výsledný HTML-kód. Prostředí ASP.NET 2.0 zavádí některé nové řídicí prvky a vlastnosti, které dovedou v podstatě to samé, ale způsobem, který je pro vývojáře podstatně snazší. Definice souboru s mapou webu Položky menu specifikujeme v XML-souboru s mapou webu. Soubor s hlavní mapou webu, určený pro web jako celek, nese název web.sitemap. Tvoří jej hierarchická struktura uzlů <siteMapPath> s atributy title a url, která může vypadat například takto:

<?xml version="1.0" encoding="utf-8" ?>

<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >


Kapitola 2 – Návrh webové aplikace 44

<siteMapNode title="Úvod" url="~/Default.aspx" />

<siteMapNode title="O nás" url="~/About.aspx" />

<siteMapNode title="Kontakt" url="~/Contact.aspx" />

</siteMap> V případě našeho projektu budeme mít jak uzly první (např. „Úvod“, „Kontakt“ a „O nás“), tak I uzly druhé a možná i třetí úrovně (např. „Obchod / Košík“). Následuje o něco složitější příklad se záznamy na druhé úrovni, který se navíc odkazuje na soubor s o úroveň nižší mapou webu obsahující položky pro menu Internetového obchodu:

<?xml version="1.0" encoding="utf-8" ?>

<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0” >

<siteMapNode title="Knihy" url="~/Books/Books.aspx">

<siteMapNode title="Autoři” url=”~/Books/Authors.aspx" />

<siteMapNode title="Vydavatelství” url=”~/Books/Publishers.aspx" />

</siteMapNode>

<siteMapNode title="DVD" url="~/DVDs/DVDs.aspx">

<siteMapNode title="Filmy" url="~/DVDs/Movies.aspx" />

<siteMapNode title="Hudba" url="~/DVDs/Songs.aspx" />

</siteMapNode>

<siteMapNode siteMapFile="~/StoreMenu.sitemap" />

</siteMap> Webová mapa na nižší úrovni (StoreMenu.sitemap) má stejný formát jako soubor web.sitemap a obsahuje vnější uzel typu siteMap. Vazba mapy webu na řídicí prvky menu Poté, co jsme definovali soubor typu sitemap, můžeme jej použít jako datový zdroj pro nové řídicí prvky prostředí ASP.NET 2.0, mezi něž patří například Menu a TreeView. K dispozici máme též řídicí prvky nevizuálního charakteru jménem DataSource, které se dovedou připojit k databázi, XML-souboru nebo ke třídě komponenty. Využívají je grafické řídicí prvky pro získávání dat určených k zobrazení na obrazovce. Ve skutečnosti slouží jako most mezi vizuálním prvkem a právě používaným datovým úložištěm. Jedním z těchto řídicích prvků typu DataSource je i prvek typu SiteMapDataSource, který byl navržen zejména pro soubory s mapou webu. Lze jej definovat například takto:

<asp:SiteMapDataSource ID="SiteMapDataSource1" runat="server" /> Všimněte si, že jsme nedefinovali cestu k souboru web.sitemap, což si můžeme dovolit díky tomu, že pro celý web existuje pouze jeden soubor se jménem ~/web.sitemap. Při tvorbě map webu na nižší úrovni pro podadresáře umístěné v rámci adresářového stromu naší webové aplikace dochází k transparentnímu zpracování vazeb, neboť všechny začínají v souboru web.sitemap.

V případě, že by se nám nelíbil způsob, jakým řídicí prvek typu SiteMapDataSource funguje (třeba

proto, že chceme mít několik souborů typu sitemap nebo potřebujeme uložit mapu webu do data

báze místo do XML-souborů), musíme si buď napsat vlastní řídicí prvek typu DataSource, nebo vy

tvořit novou třídu, která by transparentně poskytovala obsah pro prvek typu SiteMapDataSource.


Návrh

45

Řídicí prvek typu Menu vytváří pomocí jazyka DHTML oblíbené vysouvací menu orientované buď vertikálně, nebo horizontálně. Ve verzi ASP.NET 1.1 neexistovaly žádné slušné a přitom standardní řídicí prvky pro menu a pravděpodobně každá společnost vyvíjející webové komponenty nabízela své vlastní řešení. Nicméně s příchodem ASP.NET 2.0 již máme zdarma k dispozici standardní prvky pro menu, které lze navíc integrovat s nejrůznějšími datovými zdroji. K vytvoření řídicího prvku typu Menu svázaného s prvkem SiteMapDataSource definovaného výše stačí jen jediný řádek:

<asp:Menu ID="mnuHeader" runat="server" DataSourceID="SiteMapDataSource1" /> Řídicí prvek typu Menu samozřejmě nabízí velké množství vlastností, s jejichž pomocí můžeme stanovit jeho orientaci (vlastnost Orientation), CSS-třídu (CssClass) či vzhled jednotlivých částí, počet vnitřních úrovní mapy, které se zobrazí při rozbalení menu (StaticDisplayLevels), a celou řadu dalších. Jejich kompletní popis však přesahuje rámec této knihy; zájemce o podrobnější informace tedy odkazujeme na oficiální MSDN-dokumentaci. Zobrazení mapy webu ve formě stromu namísto vysouvacího menu je otázkou záměny deklarace řídicího prvku Menu za prvek TreeView:

<asp:TreeView runat="server" ID="tvwMenu" DataSourceID="SiteMapDataSource1" /> Navigační cesta Kromě menu potřebujeme svým uživatelům také nabídnout nějaké vizuální vodítko poskytující informace o tom, kde se právě nacházejí a kudy vede cesta zpět na úvodní stránku. Tento problém se obvykle řeší pomocí navigační cesty, což je navigační lišta s odkazy na všechny stránky nebo sekce v hierarchii od úvodní až po aktuální stránku. Uživateli, který si právě prohlíží svůj nákupní košík, se může zobrazit například takto:

Úvod > Obchod > Košík Nyní se uživatel může přesunout o dvě stránky zpět, aniž by ve svém prohlížeči musel stisknout tlačítko „Zpět“ (které nemusí být z mnoha důvodů viditelné) nebo se vracet na úvodní stránku a pokoušet se rozpomenout na stránky, které předtím procházel. S ASP.NET 2.0 můžeme na náš web přidat navigační cestu pomocí jediného řádku kódu, v němž deklarujeme instanci nového řídicího prvku typu SiteMapPath:

<asp:SiteMapPath ID="SiteMapPath1" runat="server" /> A jako vždy má i tento řídicí prvek řadu vlastností, díky nimž si můžeme zcela přizpůsobit jeho vzhled, o čemž se blíže přesvědčíme v části „Řešení.“ Tvorba stránky přístupné všem skupinám uživatelů Všechny standardně vestavěné řídicí prvky prostředí ASP.NET 2.0 generují ve výchozím stavu validní kód dle standardu XHTML 1.0 Transitional. XHTML je v podstatě HTML dodržující pravidla jazyka XML, takže pro jeho syntaxi platí mnohem přísnější pravidla. Například všechny hodnoty atributů musí být uzavřeny do uvozovek, všechny značky musí mít explicitní zakončení nebo k nim musí existovat odpovídající ukončovací značka (např. místo <br> a <img src="..."> musí být <br /> a <img src="..." />) a vnořené značky musí být uzavírány ve správném pořadí (např.

Kapitola 2 – Návrh webové aplikace

4



       
Knihkupectví Knihy.ABZ.cz - online prodej | ABZ Knihy, a.s.