Nástroje pro tvorbu interaktivních internetových aplikací

Se zaměřením na jejich historii, jazyk PHP a technologii ASP.NET
Jan BENDA
  1. Úvod
  2. Historie
    1. Hypertext
    2. Www a statické HTML
    3. HTML, HTTP a URL
    4. CGI a SSI
    5. Rodina jazyků Java a JavaScript
    6. Rozvoj serverových nástrojů
  3. Významné klientské technologie
    1. Java
      1. Vznik
      2. Nástin jazyka Java
    2. JavaScript, JScript, DHTML
      1. Historie JavaScriptu
      2. Příchod DHTML
      3. Programování s DHTML
      4. Java-skripty
    3. Flash
      1. Historie
      2. Flash ActionScript
  4. Významné serverové nástroje
    1. J2EE
      1. Java Server Pages a Servlety
      2. Enterprise JavaBeans
    2. PHP
      1. Zrod a vývoj
      2. Základy jazyka PHP
      3. Obsluha formulářů
      4. Práce se soubory a databázemi
      5. Knihovna PHPLIB
    3. ASP.NET
      1. Potíže současných technologií
      2. Lehký úvod do .NET Framework
      3. Principy ASP.NET
      4. Kód v pozadí
      5. Ovládací prvky
      6. Řízení relací
      7. Webové služby
    4. Srovnání ASP.NET a PHP
  5. Budoucnost
  6. Literatura

I - Úvod

Internet je zásadní technologie moderní doby pro komunikaci a bleskovou distribuci informací. Často je chybně nazýván médiem (stejně jako by bylo chybné nazývat médiem rozhlasový vysílač, či rotační tiskárnu), ale není tomu tak - Internet je "pouze" rozsáhlý komplex počítačových sítí, který nabízí širokou varietu protokolů a poskytovatelných služeb. Pouze jednou z nich, přestože co do objemu přenášených dat dominantní, je potom World-Wide Web - systém hypertextových elektronických dokumentů.

Mnohým dnes totiž pojmy WWW a Internet zcela splývají. Má to svůj důvod - teprve WWW jako pasivní konzumentské médium mohlo dosáhnout sktečně masového rozšíření. Tímto nechci snižovat význam dalších služeb, třeba e-mailu. Je ale nesporné, že boom Internetu byl způsoben právě rozvojem WWW.

Vydáme se po stopách zrodu tohoto obrovského média, budeme sledovat, jak vznikaly principy hypertextu, jak se vyvíjely nároky na poskytované informace a nástroje, které na tyto požadavky odpovídaly. Nakonec se podívame podrobněji na nejvýznamnějsí technologie, které určují podobu dnešního Webu a pokusíme se nastínit směr, kterým se ubírá dnešní vývoj.

II - Historie

Technologie WWW prodělala za necelých 13 let od svého vzniku skutečně bouřlivý vývoj. Vznikla v roce 1990 a od té doby se rozvíjí a rozšiřuje. Principy, na kterých stojí, ovšem nevznikly ze dne na den. Určitě nebude od věci udělat si malou exkurzi do doby "před WWW" a začít u jednoho základního principu: pojmu hypertextu.

Pak konečně přejdeme k samotnému WWW. Podíváme se po časové ose od vzniku statického WWW a budeme sledovat, jak se postupně přeměnil v dynamické médium, jak jej známe dnes. Médium, které umožňuje interakci s uživatelem a poskytování požadovaných informací v reálném čase. Je vidět, že nás čeká velmi dlouhá cesta.

2.1 - Hypertext

Definice pojmu hypertexu vznikla už v roce 1965. Za jeho tvůrce je považován spisovatel Theodor Holm Nelson, který jej definuje jako "nesekvenční psaný materiál" - text, který se větví a dává čtenáři možnost volby. Základy hypertexu však byly položeny ještě o dost dříve - už v roce 1945.

Prvním člověkem, který představuje a rozvíjí myšlenku hypertextu, byl Dr. Vannevar Bush, pordace amerického prezidenta pro vědecké záležitosti během druhé světové války. Je tvůrcem ideje nástroje jménem Memex - hypotetického stroje, který by obsahoval všechny poznatky a textové i grafické zdroje jeho majitele.

Zásadní myšlenkou Memexu je princip asocitivních odkazů. Dr. Bush si bere za vzor lidský mozek, který, narozdíl od v literatuře běžně používaných odkazů pomocí kategorií a indexů (jako při vyhledávání článku v knihovně), pracuje na základě asociací. Memex umožňuje, aby samotná část textu přímo odkazovala na libovolnou část textu v jakémkoli dokumentu. Uvažuje se implementace na nějakém interaktivním zařízení (v té době se jednalo o promítání mikrofilmů na plátno), které vedle velkokapacitního skladiště dat nabízí také možnost v reálném čase otevírat dokumenty a přecházet po asociacích mezi nimi. Neméně důležitá byla také možnost zaznamenat cestu, kterou procházel uživatel při čtení, a později ji znovu přehrávat.

První implementace hypertextu pak byla vyvinuta v roce 1967 na univerzitě v Brown týmem doktora Andries van Dama. Výzkum byl podporován firmou IBM a nástroj běžel na počítači IBM/360. Tento produkt byl nasazen do komerčního provozu a byl využit například pro dokumentaci vesmírného projektu Apollo.

Z dalších hypertextových nástrojů není možné nezmínit Symbolics Document Examiner (1985) Janet Walkersové, jenž jako první dává uživateli možnost vytvářet vlastní záložky v databázi dokumentů, a HyperCards (1987) Billa Atkinsona, první opravdu masově rozšířený systém distribuovaný s počítači Apple Macintosh, jenž dokázal zobrazovat text i obrázky. Oba tyto nástroje měly grafické uživatelské rozhraní a byly dostatečně univerzální, aby umožňovaly vytváření vlastních hypertextových prezentací třetími stranami, narozdíl od předchozích jednoúčelových projektů.

Ovšem jedním z nejmystičtějších počítačových projektů je bezpochyby systém Xanadu. Představen Tedem Nelsonem, otcem hypertextu, Xanadu představuje nástroj pro vytvoření "dokuversa" - úplného universa všech dokumentů, které zahrnuje veškeré lidské poznání. Dokumenty v něm existují ve všech svých verzích a jsou navzájem propojeny pomocí tzv. transkluzí. To jsou hypertextové analogie inkluzí - části dokumentů nejsou přímo vloženy, ale pouze referencovány. Jde přitom o mnohem silnější nástroj, než jsou třeba HTML-odkazy: transkluze totiž dokáže adresovat libovolný podřetězec cílového dokumentu.

Přestože vývoj Xanadu trvá přes dlouhých 30 let a své schopnosti i peníze do něj investovaly takové osobnosti, jako třeba John Walker - zakladatel firmy Autodesk, světlo světa dosud nespatřil. Jde bezpochyby o jednu z nejúžasnějších, ale také nejnedosažitelnějších myšlenek počítačového průmyslu.

2.2 - Www a statické HTML

Přestože implementací hypertextu vznikla od roku 1967 celá řada, žádná z nich nedosáhla tak zásadního úspěchu, jako World-Wide Web.

V roce 1980 nastoupil mladý Tim Berners-Lee jako doktorand na Centre European pour la Recherche Nucléaire (CERN). V CERNu v té době pracovalo několik oddělených systémů pro ukládání dokumentů a data každého z pracovníků byla roztroušena po mnoha nezávislých strojích. Snem Tima Berners-Lee bylo vytvořit systém, který by umožnil označit každý dokument jednoznačným identifikátorem, ale také zaznamenat libovolné asociace mezi jednotlivými částmi dokumentů. Přestože nebyl podrobně obeznámen s prací Teda Nelsona, jeho první projek Enquire (1986) věrně kopíruje myšlenku hypertextu. Podle jeho vlastních slov však šlo pouze o přesnou odpověi na problémy, se kterými se v CERNU v té době potýkali.

Systém Enquire se ovšme téměř vůbec nerozšířil. Mezitím vznikl protokol TCP/IP a CERN se stal největším internetovým sídlem. Zájem o objektové a distribuované programování a ještě palčivější situace co do objemu publikovaných dokumentů vedly k úspěchu Berners-Leeova návrhu Informační infrastruktury World-Wide Web - systému, který by implementoval principy Enquire v heterogenním prostředí TCP/IP komunikace. První implementace z roku 1990 se jmenovala WorlDwidEweb a pracovala na strojích NeXT. Šlo zároveň o prohlížeč i WYSIWYG editor HTML-dokumentů, současně byla k dispozici multiplatformní textová verze prohlížeče. Už v roce 1991 bylo WWW portováno na další platformy a uvolněno veřejnosti.

Rok 1993 přinesl "Mosaic for X" - první prohlížeč pro platformu UNIX, na podzim téhož roku uvolnil autor Marc Andreesen, student univarzity v Illinois, také porty pro Windows i Macintosh. O rok později pak založil se svými spolupracovníky firmu Netscape. Začala éra moderního, veřejného World-Wide Web.

2.3 - HTML, HTTP a URL

V samotných počátcícu služby WWW jsme si vystačili s pouhými třemi technologiemi. První z nich byl jazyk HTML (HyperText Markup Language), který sloužil k zápisu webových stránek. HTML je dodnes ústřední technologií Webu, okolo které se vše točí. Dnes sice dospěl vývoj jazyka HTML verzí 4.0 ke svému konci a chystá se jeho nahrazení jazykem XHTML, ovšem stále je zachována zpětná kompatibilita s původní jednoduchou verzí HTML. Nutno podotknout, že po krátkém odcizení do domény nástroje pro tvorbu grafických a vizuálních prezentací se jazyk HTML opět díky příchodu CSS (Cascading Style Sheets) vrací ke své prapůvodní filosofii, být jazykem pro popis struktury dokumentů.

Druhou nezbytnou technologií je přenosový protokol HTTP (HyperText Trasnfer Protocol), který zajišťuje přenos HTML-stránek z WWW-serveru do prohlížeče. Tento protokol existuje ve třech verzích 0.9, 1.0 a 1.1, přičemž ta poslední patří dnes mezi nejrozšířenější. Původní verze HTTP 0.9 byla opravdu velmi jednoduchá. Sestává z jediného řádku popisujícího metodu (HTTP 0.9 zná pouze metodu GET - odešli dokument) a adresy požadovaného dokumentu vzhledem ke kořenovému adresáři WWW-serveru. V důsledku zvýšených požadavků na možnosti kontroly přenosu dokumentů a samotné zrychlení přenosu postupně vznikly nové verze HTTP 1.0 a 1.1. Tyto protokoly přidávají další metody (POST k odesílání dat z formulářů, HEAD pro informace o dokumentu a PUT a DELETE pro potřeby jednoduchého publikování na Webu) ale hlavně přinášejí možnost zasílání tzv. hlaviček a to jak směrem ke klientovi, tak i k serveru. Těch je dnes nepřeberné množství a umožňují jednak poskytovat informace o serveru a o dokumentu, ale také řídit spojení se serverem, ukládání stránek do cache-pamětí nebo třeba automatické přesměrování při přesunutí dokumentu. Od HTTP/1.0 má navíc server možnost odeslat v odpovědi tzv. stavový kód, který standardním způsobem popisuje případné problémy při spojení a usnadňuje jejich odstraňování (díky němu dnes můžeme v prohlížeči vidět například tolik oblíbené "Error 404: Not Found"). Proto se HTTP 1.1 dnes stává standardem, který podporují všechny nejvýznamnější WWW-servery a prohlížeče.

Třetí technologií nezbytnou pro implementování služby WWW jsou URL (Uniform Resource Locator). V původním projektu pana Berners-Lee nazývané UDI (Universal Document Identifiers) implementují principy hypertextu: v rámci jednoho dokumentu je možné vytvářet odkazy na části dokumentů jiných. Bylo třeba určit stroj, na kterém se cílový dokument nachází, cestu k tomuto dokumentu a cílový fragment. Ten byl v  dokumentu označen pomocí značky HTML (pojmenovaná značka <a> - Anchor). Postupně se UDI rozšířily do podoby dnešních URI (Uniform Resource Identifier), ty se zapisují podle přesných pravidel ve formátu schéma://uživatel:heslo@server/cesta?parametry#fragment.

URI je tedy specifikace syntaxe identifikátorů. Vezmeme-li pouze URI, která využívají platná internetová schémata (např. http:, ftp:, gopher: ap.), dostaneme pak nám dobře známé URL, jež jednoznačně identifikují dokument přístupný z Internetu včetně autentikace, parametrů dynamických dokumentů (ve tvaru dvojic argument=hodnota oddělených znakem "&") i cílové části dokumentu.

Z dnešního pohledu spojení těchto tří technologií nenabídlo až tak mnoho - umožnilo pouze prohlížení elektronických dokumentů, které jsou provázány systémem odkazů. Přesto bylo přijetí WWW skutečně bleskové. Do roku 1992 dosáhl počet strojů v síti Internet jednoho milionu. Jen na prvním WWW-serveru info.cern.ch se díky HTTP objem datových přenosů každý rok zdesetinásoboval - v roce 1994 už dosahoval tisícinásobné hodnoty. Téhož roku také překročil protokol HTTP co do objemu datového toku systém Gopher a stal se tak po třech letech od ostrého spuštění nejpoužívanější službou Internetu. Bylo vidět, že WWW je velmi slibná technologie. S jejím masivním rozšířením ovšem přestalo postačovat poskytování neměnných informací. WWW bylo elektronickým médiem a tak zbýval jen krůček k tomu, začít vytvářet jeho obsah dynamicky.

2.4 - CGI a SSI

Obrovskou inovací Webu se stala možnost automatického generování stránek, které obsahují informace proměnlivé v čase. HTML-stránka je soubor uložený na disku WWW-serveru, který má své URL. Nic však nebrání tomu, aby URL ukazovalo na nějaký spustitelný soubor (program), který bude vyvoláván WWW-serverem a vygeneruje HTML-stránku s aktuálními údaji. Bylo pouze zapotřebí rozhraní, které by definovalo způsob spuštění programu a předávání dat mezi WWW-serverem a programem. Uvidíme ale, že nových technologií vznikla v souvislosti s  dynamickými stránkami celá řada.

Rozhraní mezi serverem a programem se jmenuje CGI (Common Gateway Interface). Programům, které generují HTML-stránky se proto často říká CGI-skripty. CGI vzniklo pochopitelně na platformě Unix (webové servery na jiných platformách byly v té době hudbou opravdu vzdálené budoucnosti), odpovídá principům klasických Unixových textových aplikací - komunikace probíhá přes proměnné prostředí, parametry příkazové řádky a standardní vstup a výstup.

Další vývoj přirozeně směřoval k tomu, aby uživatel mohl ovlivňovat chování CGI-skriptu. Přibyla tedy nová část URL - parametry CGI-skriptu. Zapisují se ve dvojicích argument=hodnota oddělených od sebe znaky "&" a od jména skriptu znakem "?". Server celý řetězec argumentů předává v proměnné prostředí QUERY_STRING. CGI také definuje možnost jednoduchého parametru (bez "="), ten se potom předává jako první argument spouštěného programu. Toto předání odpovídá metodě GET protokolu HTTP. Nový protokol HTTP/1.0 pak přidal metodu POST - data se odesílají v hlavičce požadavku na Webový server. Ten je potom předá CGI-skriptu na jeho standardní vstup.

Protože zadávání parametrů v adresovém řádku prohlížeče by bylo velmi nekomfortní, přichází HTML 2.0 s novými elementy, které umožňovaly na stránce definovat formulář. Údaje vyplněné uživatelem do formuláře odeslal prohlížeč serveru a ten je pomocí rozhraní CGI předal CGI-skriptu k dalšímu zpracování.

Jednoduchým příkladem dotazu (nikoli ovšem příkladem jednoduché aplikace) může být vyhledávací server. Uživatel zadá do vstupního pole formuláře klíčová slova. Ta se odešlou vyhledávacímu serveru, kde CGI-skript prohledá indexy. Výsledkem běhu CGI-skriptu je pak stránka v HTML, která obsahuje odkazy na stránky vyhovující dotazu.

Zdá, že CGI přineslo vše, co je pro tvorbu dynamických aplikací třeba. Je tomu opravdu tak. Tímto způsobem vlastně funguje dynamické WWW dodnes. Uživatel si stáhne stránku s nějakým druhem formuláře. Vytvoří dotaz a odešle jej na server. Ten mu oplátkou vrátí vygenerovanou stránku s požadovanými informacemi. Hlavní problém byl v tom, že psaní CGI-skriptů nebylo vůbec snadné. Pro jejich psaní se používaly nejčastěji různé interpretované jazyky, jako Perl nebo příkazové shelly Unixu. Nebyl však problém použít v podstatě libovolný programovací jazyk a tak existuje mnoho CGI-skriptů napsaných v jazycích C a C++. Velké databázové systémy, jako například Oracle, umožňují psaní CGI-skriptů přímo ve svém vlastním jazyce (např. PL/SQL).

Pro vytvoření CGI-skriptu tedy byla nutná znalost nějakého programovacího jazyka. Kromě toho musel člověk také ovládat rozhraní CGI, které předávalo parametry skriptu v ne zrovna jednoduchém formátu, na jeho výstupu pak očekávalo kompletní stránku v HTML. Většina CGI-skriptů se proto skládala převážně z kódu pro vstup a výstup. Na jedné straně byl potřebný kód, který převáděl parametry do použitelné podoby. Jak bylo uvedeno výše, podle metody a druhu dotazu dostával CGI-skript svoje paramtery hned třemi různými způsoby a ve třech různých formátech. V interpretovaných CGI-skriptech navíc spoustu práce stálo dostatečné zabezpečení skriptu. Jednoduché techniky zpracování parametrů například pomocí příkazu eval Unixového shellu jsou totiž také jednoduše zneužitelné. Zkušený hacker mohl odesláním speciálního textu v polích formuláře přimět systém, na kterém běžel WWW-server provést příkazy, jimiž nad ním získal plnou kontrolu. Na druhé straně bylo třeba vygenerovat výstup v jazyce HTML. Jazyk HTML však nejde přímo kombinovat s jinými jazyky, a proto bylo generování HTML-kódu v CGI-skriptu záležitost, kde se každá řádka HTML-kódu zadávala jako parametr příkazu pro tisk (print, echo apod. podle použitého jazyka). Správa větších aplikací byla rovněž náročná, protože generování výstupu bylo typicky roztroušeno v mnoha samostatných funkcích a aplikace byla často rozdělena na několik samostatných souborů s HTML-stránkami a CGI-skripty.

Schopný programátor však pomocí CGI-skriptů dokázal vytvořit přímo kouzla. I technologie CGI však má své meze a přestože je dodnes všemi webovými servery implementována, byla převážně vytlačena modernějšími nástroji. Dnešení preprocesorové nástroje jako PHP či ASP nabízejí oproti CGI mnohem snazší správu a rozšiřitelnost internetových aplikací. Kromě toho byla technologie CGI výkonnově překonána specializovanými API technologiemi, které umožňují mnohem efektivnější propojení WWW-serverů s dynamickými serverovými nástroji (například ISAPI pro webové servery Microsoftu či NSAPI společnosti Netscape).

Zhruba ve stejné době jako CGI-skripty se také poměrně rozšířila i další technologie, SSI (Server Side Includes). SSI byly jednoduché příkazy, které se zadávaly přímo do HTML-stránky jako komentář. Stránky však byly uloženy se speciální příponou .shtml a tak WWW-server věděl, že před odesláním stránky v ní má provést všechny SSI. SSI umožnily provádění jednoduchých úkonů, jako vložení jiného souboru do stránky, nebo vypsání data poslední modifikace dokumentu. Z dnešního pohledu byly velmi jednoduché, typické uplatnění nalezly především na rozsáhlých serverech, které chtěly mít na všech svých stránkách standardizované záhlaví a patičku - ideální úloha pro nasazení SSI. Přišly ovšem s důležitým principem, se kterým se setkáváme dodnes a to, že základem dynamického dokumentu je HTML-stránka. Úlohou skriptu je pouze hotovou stránku doplnit o aktuální informace. Tento přístup je dnes preferovaný, přestože v podstatě všechny moderní nástroje umožňují též "po staru" (ve stylu CGI) vygenerovat kompletní HTML-stránku svými přikazy pro tisk. Formát dokumentu má určovat HTML-stránka, skript pouze dodá obsah.

2.5 - Rodina jazyků Java a JavaScript

Viděli jsme, že CGI-skripty se provádějí na WWW-serveru. Uživatelská odezva je tedy velmi pomalá - uživatel si stáhne stránku, poté vyplní a odešle formulář zpět na server, server spustí CGI-skript a od něj získaný výstup zašle zpět do uživatelova prohlížeče. řešení pomalé odezvy spočívalo v přesunutí provádění programů na stranu klienta - do prohlížeče. Zhruba ve stejné době - během roku 1996 - byly představeny dvě technologie, který daný problém řeší.

První technologií byl nový jazyk Java, o němž budeme pojednávat v samostatné kapitole. Tento interpretovaný jazyk přinesl Webu možnost psaní tzv. Java-appletů, malých aplikací začleněných přímo do HTML-stránky. Ve stránce měly vyhrazen obdélníkový prostor, který byl zcela pod jejich kontrolou, navíc měly applety možnost (pod přísnými bezpečnostními pravidly) využívat některé služby prohlížeče a operačního systému. Pro psaní seriózních protějšků klasických programů byl však jejich bezpečnostní model příliš restriktivní a pro psaní čistě grafických appletů byla interpretovaná Java příliš pomalá.

V oblasti Java-appletů ji dnes zcela nahradil Flash, který si rozhodně zaslouží samostatnou kapitolu. Java nyní zažívá boom v oblastech, kam od začátku patřila - na mobilních zařízeních, a nově i na Webových serverech. Snad proto o ní budeme mluvit hned dvakrát: jednou v kapitole o Java-appletech, podruhé v kapitole o servletech - protějšcích appletů na straně serveru.

Druhou novou technologií roku 1996 byl JavaScript. JavaScript se zapisoval přímo do HTML-kódu stránky a byl interpretován prohlížečem Navigator od firmy Netscape. JavaScript uměl posloužit v mnoha situacích. Jeho nejčastější použití bylo ve spojení s formuláři. Krátké  java-skripty mohly kontrolovat správnost údajů v polích formuláře ještě před odesláním na server. Uživatel tak získal nesrovnatelně rychlejší odezvu v porovnání s klasickým způsobem využívajícím pouze CGI-skripty. Druhou oblastí použití JavaScriptu byla drobná vylepšení interaktivnosti stránek - celkem snadno šlo například zařídit, aby odkaz změnil barvu po najetí myší. Je ovšem pravda, že téhož lze mnohem elegantněji dosáhnout za pomocí CSS neboli Kaskádních stylů, které umožňují skromě statické formy definovat i formu dynamickou - tedy i například vzhled prvků při najetí myší. Přesto zůstává mnoho oblastí, kde se klientský skript velice hodí. JavaScript a jemu příbuzné jazyky proto mají samostatnou kapitolu mezi významnými klientskými technologiemi.

2.6 - Rozvoj serverových nástrojů

Úspěch JavaScriptu byl tak obrovský, že se firma Nestcape rozhodla pro využití JavaScriptu na straně serveru. Na serverech Netscape šlo do HTML-stránek mezi tagy <SCRIPT> a </SCRIPT> vkládat skripty, které se provedou přímo na serveru. Výsledkem jejich běhu pak byl HTML-kód, který se vložil na původní místo a prohlížeči už se odeslala obyčejná HTML-stránka. řešení se původně šířilo pod jménem LiveWire, dnes nese mnohem příznačnější název SSJS (Server-Side JavaScript). SSJS se stala první významnou preprocesorovou technologií. Díky množství implementovaných funkcí (pro práci s daty z formulářů, s databázemi...) jsou možnosti SSJS srovnatelné s CGI, správa dokumentů je ovšem nesrovnatelně jednodušší.

Aby firma Microsoft nezůstala pozadu, uvedla na trh svou implementaci, pochopitelně s vlastní implementací JavaScriptu - JScriptem. Navíc přidala možnost programování v oblíbeném VBS (VisualBasic Script) a rozšiřitelnost o další jazyky třetích stran. Řešení vyvíjené pod kódovým jménem Denali se pod názvem ASP (Active Server Pages) objevilo na poli serverových technologií v roce 1996 a co do výkonu a možností je podobné SSJS. Jeho zásadní předností oproti ostatním nástrojům byla v první řadě cena: ASP bylo dodáváno zdarma s webovým serverem IIS (Internet Information Server) firmy Microsoft. To je rozhodně dobrá cena.

Právě markentingové důvody stály za tím, proč ASP překonalo například technologii ColdFusion, která dovedla totéž co ASP, ale o více než o rok dříve. Přestože ColdFusion je u nás nástroj téměř neznámý, ve Spojených státech je poměrně oblíbený. Zdálo by se, že jde o klasický preprocesorový nástroj, jakých dodnes vznikla celá řada. Se svou první verzí vydanou v  polovině roku 1995 jde ale nepochybně o jeden z prvních nástrojů svého druhu - bohužel ve své době málo rozšířený. Stránky pro ColdFusion se píší v CFML, což je nadmnožina jazyka HTML rozšířená o speciální tagy formátu <cf...>. Narozdíl od ostatních technologií zde programování probíhá neprocedurálně pomocí specializovaných tagů (např. cfquery pro spojení s databází nebo cfform pro tvorbu formuláře apod.) spíše než psaním komplexních skriptů. Dnes patří do rozsáhlé rodiny vývojových nástrojů Macromedia MX, což mu rozhodně slibuje velmi zajímavou budoucnost.

Aby výčet nástrojů neskončil těsně před těmi nejdůležitějšími, je třeba zde zmínit technologie PHP a ASP.NET. Protože jde o zásadní nástroje moderního dynamického Webu, dostanou obě svou hlavní kapitolu, kde bude dost prostoru probrat i jejich historii. Co do principů vlastně obě navazují na výše zmíněné technologie a v mnohém je pochopitelně rozšiřují.

III - Významné klientské technologie

3.1 - Java

Jedním z principiálních průlomů v oblasti dynamického WWW byl bezpochyby zrod jazyka Java. Přestože Java je dnes považována za typický příklad distribuovaného internetového jazyka, její cesta na pole WWW-prohlížečů rozhodně nebyla přímočará. Považuji ji za natolik zajímavou, že jí věnuji celkem rozsáhlou kapitolu. Až si povíme, odkud se Java vzala, zkusíme si zlehka nastínit, co všechno nám může nabídnout.

3.1.1 - Vznik

Při pátrání po stopách jazyka Java se budeme muset vrátit dost daleko do minulosti (v měřítkách internetového věku pochopitelně) - až do počátku devatesátých let. V zimě roku 1990 vzniká v rámci Sun Microsystems zvláštní pracovní skupina, která má za úkol identifikovat další "novou vlnu" ve vývoji počítačového průmyslu a jeho aplikaci na segment spotřební elektroniky. Skupina vedená Billem Joyem, Jamesem Goslingem a Patrickem Naughtonem začíná pracovat pod příznačným jménem "Stealth Project", později překřtěném na "Green Project ", na projektu systému heterogenních elektronických zařízení centrálně ovládaných inteligentním přenosným zařízením.

Počátkem roku 1991 se ke skupině připojije Ed Frank - architekt SPARCstation 10, který zahajuje práci na hardware. Vzniká prototyp PDA (Portable Digital Assistant) přístroje později pokřtěného *7 (Star7 - jméno to bylo příznačné, šlo totiž o kombinaci kláves, kterou používali v kancelářích pro přijetí hovoru z jiného vyzvánějícího telefonu). Na svou dobu to bylo až vizionářské zařízení. Šlo o miniaturní SPARCový počítač vybavený pětipalcovým barevným dotykovým displejem, připojením k bezdrátové síti, dálkovým ovládáním na televizi, rozhraním pro PCMCIA karty, multimediálním přehrávačem, uživatelským rozhraním s animovaným průvodcem a Unixovým operačním systémem běžícim v méně než jednom megabytu paměti, které se nechalo skutečně držet v dlani.

Pro potřeby projektu bylo potřeba kromě grafického systému vyvinout zcela nový programovací jazyk, který by sice vycházel z osvědčených principů C++, ale lépe se hodil pro spolehlivé modulární aplikace na omezené architektuře mobilního zařízení. Potenciálně nebezpečné konstrukce a zdroje častých chyb v jazyce C++, jako například vícenásobná dědičnost, přetěžování operátorů, explicitní správa paměti a přímá práce s ukazateli, byly odstraněny. Vznikl plně objektově orientovaný jazyk pracující výhradně s referencemi na objektové typy, využívající Garbage Collector pro správu paměti a zcela izolovaný od hardware.

Kromě bezpečnosti byla důležitou podmínkou také nezávislost na platformě. Jazyk tedy měl být interpretovaný, ale zároveň nesměl příliš zatěžovat systémové zdroje, bylo proto rozhodnuto ve prospěch předkompilovaného "bytového mezikódu". K jeho běhu je pak na cílové platformě potřeba pouze nativní interpret mezikódu - Virtual Machine.

Jazyk byl vyvíjen pod pragmatickým jménem Oak. Jeho architekt James Gosling měl totiž ze svého okna výhled právě do koruny dubu. Později se ovšem ukázalo, že toto jméno už bylo registrováno s jiným programovacím jazykem; bylo třeba vymyslet nové. Nakonec se ujala zkratka z iniciálů hlavních vývojářů Oaku: James gosling, Artur Van hoff, A ndy bechtolsheim.

Zařízení *7 bylo po 18 měsících práce na podzim roku 1992 hotovo a bylo předvedeno představitelům společnosti. Na svůj triumf si ale Java musela počkat ještě dlouhé dva roky. Dá se říct, že *7 dost předběhlo svou dobu a, jak v téže době ukázal i neúspěch PDA Newton od Apple Computer, trh nedokázal tuto technologii ocenit.

Green Project, nyní pod jménem FirstPerson se stále marně snaží vyvinuté technlogoie uplatnit. V roce 1994 spouští Bill Joy projekt odlehčeného operačního systému Liveoak. Patricka Naughtona, v té době pracujícího na vlastním webovém prohlážeči, napadá uplatnit Liveoak v prostředí Internetu. Šlo opravdu o vynikající tah. Právě na Internetu se totiž mohou plně uplatnit základní principy, se kterými se Java zrodila, její spolehlivost, bezpečnost a přenositelnost. Po síti se Java šíří ve formě appletů - aplikací určených do okna prohlížeče přeložených do byte-kódu. Pro prohlížení na cílovém stroji tak stačí browser vybavený JVM (Java Virtual Machine).

Naughton vyvíjí takový prohlížeč jménem WebRunner, později překřtěný na HotJava. Jeho předvedení prý vzbudilo nebývalý ohlas. Během demonstrace, kdy naplněná prezentační místnost sledovala předvádění "dalšího Webového prohlížeče", někteří klimbali. Ovšem v okamžiku, kdy demonstrátor najel myší na diagram jakési molekuly a začal jím otáčet, sál naplnily výkřiky nadšení. Web se začal hýbat!

Technologie Java appletů byla bleskově přijata a jazyk si záhy získal ohromnou popularitu. HotJava byla oficiálně předvedena na SunWorld '95, brzy nato oznámila firma Netscape plánovanou podporu Javy ve svém Navigatoru - tehdy dominantním Webovém prohlížeči, což byl ohromný úspěch. Microsoft se svým Internet Explorerem také dlouho neotálel. Tak se Java vlastně stala prvním standardním a opravdu univerzálním klientským nástrojem pro webové aplikace. Vydání JDK 1.0 (Java Deveopment Kit - sada utilit pro překlad Javy distribuovaná zdarma) na jaře roku 1996 udělalo z Javy skutečně všeobecně dostupný výkonný programovací nástroj pro WWW.

3.1.2 - Nástin jazyka Java

Java je objektově orientovaný jazyk výrazně ovlivněný C++. Ve výkladu o principech Javy se proto budeme na C++ často odvolávat. Půjde spíš o srovnání a nástin odlišností než o úplný výklad.

Základem programu v Javě je třída (class). Každý kód i data musí být členy nějaké třídy, což platí bez výjimky (třeba i funkce main známá z C++ je vždy statickou metodou nějaké třídy). Metody jsou v Javě striktně buď statické (společné pro celou třídu) nebo virtuální, nevirtuální dědičnost neexistuje. Všechny objekty vznikají dynamicky a po zániku jsou automaticky dealokovány Garbage Collectorem (GC). Během jejich života se s nimi pracuje výlučně pomocí reference, chceme-li kopírovat hodnoty objektů, používámě standardní metodu Clone() předdefinovanou pro všechny vestavěné typy.

Velkou odlišností od C++ je spojení deklarace třídy s její implementací - kód se vpisuje do složených závorek hned za deklarací metody. Díky tomu úplně odpadá práce s hlavičkovými soubory (Java vůbec neobsahuje preprocesor). Pokud se kód odkazuje na nějaké jiné třídy, překladač je dokáže automaticky dohledat, neboť způsob ukládání zdrojových souborů podléhá striktním pravidlům. Třídy lze totiž spojovat do logických balíků (packages) a vždy platí, že adresářová struktura uložení zdrojových kódu musí odpovídat hierarchii balíků, každá veřejná třída (taková, kterou mohou využívat libovolné jiné třídy) navím musí být uložena v samostatném souboru stejného jména. Důležitou schopností Javy je pak připojovat celé třídy dynamicky za běhu, což uvidíme později u Java-appletů.

Objektový model Javy také určuje repertoár datových typů, se kterými můžeme pracovat. Existují v něm drobné prohřešky proti principům striktních objektově orientovaných jazyků (jako je třeba SmallTalk) motivované zachováním rozumného výkonu bez újmy na logice architektury a bezpečnosti. Jednoduchým příkladem může být existence sklalárních typů - bez modifikace přejatých od C/C++ (celočíselné typy jako int, unsigned a bool nebo čísla s plovoucí desetinnou čárkou jako float a double). Celkově se dá říct, že v Javě jsou dvě skupiny datových typů: aritmetické typy a objekty.

Co do operátorů, výrazů a aritmetiky vůbec je Java s C++ skoro k nerozeznání. Platí ale, že Java není tak typově benevolentní. Například int a bool jsou nekompatibilní typy a tak třeba místoif (i = f(x)) musíme pěkně explicitně psátif ((i = f(x)) ! = 0) , je ale praxí ověřeno, že čas strávený psaním těch pár znaků navíc je bohatě odměněn úsporou času stráveného hledáním chyb pramenících z nechtěných implicitních konverzí. Konstrukce řízení běhu jsou téměř doslovně přejaty od C++ a syntaxe je vůbec dost podobná.

Java měla hned od počátku dvě důležité oblasti nasazení: doménu desktopových aplikací a technologii Java-appletů. My se soustředíme na druhou z nich. Java-applet je vždy potomkem třídy java.applet.Applet. Narozdíl od desktopové aplikace neobsahuje metodu main(), protože není prohlížečem spouštěn. Sám prohlážeč (nebo alespoň jeho část zodpovědná za applety) je naopak Java-aplikace a jednotlivé applety pouze dynamicky připojuje do svého adresového prostoru. Třída Applet pak definuje důležité virtuální metody (jako třeba init(), update() a destroy()), které volá prohlížeč. Typicky stačí implementovat vytvoření appletu v init() a jeho překreslení v update() (o úklid se postará GC) a funkční applet je na světě.

Chceme-li spustit applet v prohlížeči, vložíme do stránky HTML tag <applet> s atributem, který specifikuje umístění bytového kódu na serveru. Jakmile prohlížeč načte tento tag, spustí tzv. Class Loader (součástí JVM), jenž ze serveru stáhne kód appletu a kód všech potřebných tříd, na než se applet odkazuje a které ještě na klientovi nejsou. Jsou-li všechny požadované soubory dostupné, je applet spuštěn. Aby byla zajištěna nezbytná bezpečnost při běhu appletu, omezuje dostupnou funkcionalitu tzv. Security Manager, který umožňuje uživateli zvolit, jaké skupiny funkcí mají být povoleny či zakázány. Obvykle nemají applety přístup do souborového systému a nemohou navazovat spojení s jinými servery, než odkud byly stáhnuty.

Appletu je ve stránce vyhrazen obdélníkový prostor (velikosti určené v atributech tagu <applet>), který je plně pod jeho kontrolou a prohlížeč jeho vykreslování nijak neovlivňuje. Applety se dnes používají především k implementaci složitějšího grafického prostředí na straně klienta, než je schopen poskytnout jazyk DHTML. Navíc mohou být snadno konfigurovatelné pomocí uživatelských atributů a tak je na Internetu k  dispozici mnoho zajímavých appletů, které můžeme snadno přizpůsobit pro svoje účely.

3.2 - JavaScript, JScript, DHTML

Technologií, která dnes dominuje na straně klienta, je rodina skriptovacích jazyků vestavěných do webových prohlížečů. Jmenovitě jde o JavaScript, JScript a Visual Basic Script. O prvních dvou zástupcích je tato kapitola.

3.2.1 - Historie JavaScriptu

JavaScript je jazyk vyvinutý firmou Netscape pro potřeby jejího legendárního prohlížeče Netscape Navigator. Původně se jmenoval LiveScript, ale po obrovském úspěchu Javy uzavírá Netscape dohodu s firmou Sun, že upraví syntaxi do podoby jazyku Java a na oplátku bude smět používat obchodního jména JavaScript. Možná to byl dobrý marketingový tah, ale rozhodně vnesl do věcí pořádný chaos. JavaScript není Java a odhlédneme-li od blízké syntaxe ve stylu jazyka C++ a náznaku objektovosti JavaScriptu, nemají vlastně společného vůbec nic.

JavaScript měl veliký úspěch. Dokonce takový, že se firma Microsoft rozhodla narychlo implementovat jeho analogii do svého chystaného prohlížeče Internet Explorer 3.0. Bohužel v Netscape tak dlouho otáleli s vydáním specifikace jazyka JavaScript, až vývojářům Microsoft nezbylo, než vytvořit svou vlastní. Tak vznikl JScript, jazyk řekněme ne úplně nepodobný JavaScriptu, a my dnes máme při psaní skriptů dvojnásobnou práci, chceme-li je vytvořit kompatibilní s oběma rodinami prohlížečů. Nějakou implementaci JavaScriptu dnes má v podstatě každý významný vizuální prohlížeč. Na druhou stranu objektový model DHTML v Internet Exploreru přinesl natolik bohaté možnosti JScriptu, že je dnes psaní rozsáhlých přenositelných skriptů obtížné; to co je s JScriptem snadné, je v JavaScriptu ostatních prohlížečů kvůli slabší implementaci DHTML často téměř nemožné.

3.2.2 - Příchod DHTML

Píše se rok 1996 a Adam Bosworth, systémový programátor u Microsoftu, začíná pracovat na projektu s kódovým jménem Trident. Jde o rozšíření HTML o schopnosti, které byly do té doby přisuzovány pouze Javě a ActiveX: animované ikony a tlačítka, pohyblivé objekty a další speciální efekty vznikající dynamickou modifikací elementů na HTML-stránce. Vzniká technologie dynamického HTML (DHTML).

Geniální myšlenka Bosworthova nástroje tkví v tom, že využívá standardní technologii HTML, která je známá a všeobecně rozšířená, a připojuje k ní výkonný nástroj, po kterém designéři dlouho toužili ve věčné snaze odlišit právě své webové sídlo od těch ostatních, který je ale ve srovnání s tehdejšími technologiemi úžasně snadno použitelný. Není totiž třeba žádného dalšího vývojového nástroje, stačí použít existující editor HTML schopný práce s  JavaScriptem a ihned začít na svou stránku přidávat dynamická kouzla. Webovou komunitou bylo DHTML přijato s nadšením.

Neméně důležitou příčinou úspěchu DHTML byla intenzívní kooperace Microsoftu a konsorciem W3C na začlenění DHTML mezi webové standardy. Úzká spolupráce vývojářů s tvůrci standardů měla pro Microsoft hned dva důležité důsledky. Nejen, že potvrzovala dávná tvrzení společnosti o podpoře otevřených standardů, ale hlavně přiměla Netscape přijmout nově vznikající standard DHTML a navždy opustit svoje snahy o vlastní rozšíření HTML. Tím se Internet Explorer vyšvihnul na špičku vizuálních webových prohlížečů a setrvává na ní dodnes.

Je třeba dodat, že pojmy DHTML a JavaScript jsou často chybně směšovány. Je pravda, že na straně klienta jsou jejich úlohy velmi těsně provázány. JavaScript je ovšem programovací jazyk, který lze využít nejen k oživení HTML-dokumentu, ale své uplatnění nachází i jinde - například v ASP-stránkách. DHTML je oproti tomu rozhraní, které struktorovaným způsobem zpřístupouje obsah HTML-dokumentů skriptům. Ani ono není pevně spjato s JavaScriptem; libovolný skript, jenž je prohlížeč schopen interpretovat, muže přistupovat přes DHTML k objektovému modelu dokumentu.

3.2.3 - Programování s DHTML

Protože programování v JavaScriptu na straně klienta je velmi úzce spjato s rozhraním DHTML, povíme si nejprve krátce o možnostech, které nám jeho objektový model nabízí.

DHTML vytváří hierarchickou strukturu objektů plně popisujících dokument a nabízí techniky, jak touto strukturou procházet, číst ji a modifikovat. Nejjednodušší přístup k elementu je pojmenovat ho pomocí atributu id. V JavaScriptu k němu potom přistupujeme jako k objektu stejného jména. V souladu s principy objektových jazyků potom můžeme u takového objektu volat metody (třeba metodu open() objektu window) nebo nastavovat datové položky, těm se zde říká vlastnosti (např. vlastnost value prvku input ve formuláři). Využíváme k tomu dnes již klasickou tečkovou notaci (např. window.history.back()). DHTML navíc nabízí ještě události a kolekce.

Událost je asynchronní obsluha nějaké akce vyvolané uživatelem. Když například klepne myší do dokumentu, zasažený element to umí oznámit skriptu; tomu se říká vyvolání události. Pokud chceme mít možnost na událost reagovat, musíme jí odchytit. To provedeme tak, že objektu, který nás zajímá, přiřadíme její obsluhu. S událostmi se tu pracuje jako s vlastnostmi, přiřazení obsluhy události se provede jednoduše dosazením kódu, který se má provést při jejím vyvolání (např. oBody.onload = 'doInit()').

Událostí je celá řada, ruzné objekty nabízejí odchycení rozličných událostí. Například většina elementů na stránce zpřístupňuje množinu událostí vyvolaných myší (např. onmouseover, onclick...). Další události upozorňují třeba na stisk klávasy, vybrání prvku formuláře nebo zvětšení okna prohlížeče.

Kolekce pak jsou objekty umožňující procházet hierarchií dokumentu. Jde vlastně o pole zpřístupňující různé podřízené objekty. Každý element například obsahuje kolekci all, která umožňuje procházet všechny jeho potomky, a kolekci childNodes, která obsahuje jen jeho přímé následníky. Kromě toho all disponuje užitečnou metodou tags(), která omezí výběr jen na elementy určitého typu (třeba všechny prvky H1).

3.2.4 - Java-skripty

Konečně se dostáváme k samotné otázce tvorby skriptu. Skripty se do HTML-stránky vkládají třemi základními způsoby. Buď přímo napíšeme do dokumentu dvojici tagu <script> a </script> a mezi ně rovnou píšeme kód skriptu. Duležitým atributem tohoto tagu je language, jelikož vedle JavaScriptu existuje ještě několik dalších jazyků, které dnes mužeme v  prohlížečích použít. Druhou možností je nastavit atribut src tagu <script>, a připojit k dokumentu kód ze samostatného souboru. Je třeba říct, že v dnešní době jde o nanejvýš doporučený zpusob, protože směšování různých jazyků (zde jazyka HTML a jazyka skriptu) je považováno za přinejmenším neelegantní. Třetím způsobem je potom možnost zapsat jednoduchý kód pro obsluhu události přímo jako atribut cílového elementu (např. <body onload="doInit()">).

Jazyk JavaScript je syntakticky velmi podobný jazykům Java a C++. Disponuje shodnými konstrukcemi pro tvorbu výrazů i řízení běhu programu. Příjemným rozšířením je konstrukt for.. in, který umožňuje jednoduše procházet přes všechny prvky pole nebo vlastnosti objektu (např. for (i in myArray)).

JavaScript nabízí pouze 6 typů proměnných: číslo, řetězec, booleovská hodnota, objekt, null a undefined, přičemž typ proměnné se určuje automaticky. Předtím, než je proměnná inicializována, je jednoduše typu undefined. Poté má vždy typ podle hodnoty kterou jí přiřadíme, v průběhu zpracování skriptu se muže její typ libovolně měnit. Narozdíl od obvyklých vyšších programovacích jazyků není třeba proměnné deklarovat, přesto se to velmi doporučuje. Stejně tak se doporučuje proměnné pojmenovat mnemotechnicky včetně označení typu, který má nést (například začínající na n pro číslo, s pro řetězec ap.) a její typ v pruběhu neměnit. Proměnnou deklarujeme klíčovým slovem var (např. var nCount), pokud to neuděláme explicitně, je deklarována prvním použitím. Duležité je vědět, že lokální proměnné musíme deklarovat explicitně, implicitní proměnné jsou vždy globální a to i tehdy, pokud vznikly v těle funkce.

Ještě se chvíli zastavíme u objektů. V JavaScriptu nemůže programátor využívat plnohodnotné objekty - nejsou k dispozici virtuální metody ani dědičnost (toto ovšem není pravda pro JScript .NET, jak se dozvíme v kapitole o ASP.NET). Jazyk nám dává k dispozici toliko konstruktory, manipulaci s datovými položkami a definici metod. Konstruktor je zvláštní funkce, která definuje nový objekt:

function Pt(x, y) { this.x = x; this.y = y; } var zero = new Pt(0, 0);

Objekty jsou ve skutečnosti spíše kolekcemi datových položek. Dokonce jsou i implementovány jako asociativní pole a i v programu můžeme obojí syntaxi, tedy přístup k členským datům objektu nebo ke stejnojmennému prvku asociativního pole, libovolně směšovat. Kdybychom tedy například chtěli vytvořit metodu určitého objektu, přiřadíme mu nějakou funkci jako datovou položku. Interpret se potom k takovému volání funkce bude chovat jako k metodě a předá mu správný ukazatel na objekt this :

oPt.toString = printPt; function printPt { return 'x: ' + this.x + ', y: ' + this.y; }

Výše uvedené konstrukce byly viditelně určeny pro manipulaci s objektem, jako s instancí - s jedním exemplářem. Pokud chceme manipulovat s celou třidou, odkážeme se na ni názvem konstruktoru a klíčovým slovem prototype (Pt.prototype.vlastnost = 'hodnota').

V praxi jsou mnohem více než uživatelské objekty využívány tzv. intrinsic neboli přednastavené objekty. Mezi těmi nejdůležitějšími zmiňme alespoň Date pro práci s datem a časem, Math obsahující matematické funkce, String pro řetězcové funkce a v neposlední řadě Array, které přidává možnost indexace celými čísly (řetězcové indexy totiž zvládne libovolný objekt).

3.3 - Flash

Flash se za posledních několik let stal vedle JavaScriptu nejvýznamnějším klientským nástrojem. Svým nasazením se od JavaScriptu, o němž byla řeč doteď, poněkud liší - JavaScript manipuluje s textovým obsahem stránky, Flash je objekt, který se do stránky vkládá podobně jako třeba Java-applet. Přesto v mnoha oblastech Flash vytlačí i JavaScript - ve Flashi lze vytvářet celé webové aplikace bez použití HTML.

Nejprve se podíváme, odkud se vůbec Flash vzal a proč se stal ze dne na den tak slavným. Potom si ukážeme, jaké možnosti nám nabízí ve své široké paletě nasazení od jednoduchých animací oživujících stránku po komplexní autonomní webové projekty.

3.3.1 - Historie

Stejně jako většina zde popisovaných nástrojů, i Flash byl původně soukromým projektem jediného autora, Jonathana Gaye.

Gay se už na střední škole zabývá programováním grafických editorů (jeho první projekt jménem SuperPaint byl napsán v Pascalu a běžel na počítačích Apple II), současně se ale věnuje psaní počítačových her. Právě zde získává cenné zkušenosti v oblasti synchronizace zvuku a obrazu a tvorby software optimalizovaného pro zobrazování grafiky v reálném čase.

Po absolvování nastupuje ke společnosti Silicon Beach Software, kde vytváří program jménem Super Paint II. Jde o nástupce jeho úspěšného školního projektu, který umožňuje tvorbu PostScriptových kreseb. Bohužel ani další projekt jménem IntelliDraw na trhu, dominovaném slavnými produkty jako Adobe Illustrator nebo Aldus Freehand, neuspěl.

Gay se rozhodne založit vlastní firmu, FutureWave Software a orintovat se na nově vznikající trh přenosných počítačů. Jeho cílem je vytvořit software, který by umožnil pomocí stylusu a dotykové obrazovky kreslit snadněji než na papíře. Zde, počátkem roku 1993, vzniká program SmartSketch, a spolu s ním vlastně i Flash, jak jej známe dnes. Dodnes Flash obsahuje části kódu určené původně pro kapesní počítače.

Bohužel společnost Go, která vyvíjela operační systém pro přenosné počítače, se dostává do finančních problémů a je koupena společností AT&T. Ta ovšem vývoj ukončuje a FutureWave nezbývá než přeorientovat svůj SmartSketch zpět do prostředí osobních počítačů - na platformu Windows a Macintosh. Tady má ale v silném konkurenčním prostředí stejné problémy jako jeho předchůdce IntelliDraw. Naštěstí z řad jeho uživatelů přichází rozhodující impuls: přeměnit SmartSketch v nástroj pro tvorbu animací. To bylo v roce 1995 a Gayovi je jasné, že musí kromě tvorby animací vytvořit i nástroj pro jejich distribuci. V té době totiž jediný způsob, jak distribuovat animace, bylo pomocí CR-ROM či VHS nahrávek. Na scénu ale přichází Internet a právě v něm chápe Gay velkou příležitost.

První přehrávač pro SmartSketch Animator byl vytvořen v Javě a byl neskutečně pomalý. Vývoj projektu (nyní pod jménem FutureSplash Animator) ale pokračuje a na podzim roku 1995 přichází společnost Netscape s technologií přídanvých modulů, která umožnila rozšířit prohlížeč o přehrávač, který byl dostatečně výkonný. Skutečně masového rozšíření ale dosáhla až ActiveX verze přehrávače pro Internet Explorer od společnosti Microsoft.

ActiveX se na straně klienta stalo takovým převratem, jako server API na straně webových serverů. Obecně je ActiveX standard pro programové komponenty, který použitelný k rozšiřování aplikací za běhu. Internet Explorer takto umožňuje, aby byla na stránce pomocí tagu object definována komponenta, která po stažení stejně jako třeba Java-applet obdrží ve stránce obdélníkový výřez. Narozdíl od ní ale běží v nativním kódu cílového procesoru a využívá přímo API operačního systému, díky čemuž běží nesrovnatelně rychleji. Všechno dobré je ale také k něčemu špatné a tak i ActiveX má svoje slabé stránky. V první řadě je to otázka bezpečnosti, jelikož bez ochrany virtuálního stroje je počítač zcela vydán na milost ActiveX komponentě. Proto také instalace komponenty nemůže probíhat automaticky, ale vždy jen se souhlasem uživatele. Za předpokladu, že uživatel se na základě potvrzovacího dialogu dovede rozhodnout, zda je stahovaná komponenta bezpečná, je vše v  prořádku...

Na konci roku 1996 koupila FutureWave firma Macromedia a z FutureSplash Animatoru se stává Macromedia Flash 1.0. Dnes je Flash již ve verzi 5.0 a je součástí perspektivní rodiny internetových produktů Macromedia MX. Flash MX je v současnosti využíván asi 500.000 vývojářů a jeho přehrávač je instalován asi v 250 milionech počítačů, což z něj dělá nejrozšířenější klientský nástroj současnosti. Díky tomu, že jde o produkt jediné společnosti, stal se Flash nepsaným standardem pro dynamické klientské aplikace.

Osobně přisuzuji formátu SWF, což je datový formát pro přehrávač Flash velikou budoucnost. Jde totiž o bohatý a přitom velice kompaktní formát vektorové grafiky, jenž narozdíl od formátů pro rastrové obrázky dosud neměl na Internetu svůj standard. Macromedia bezproblémově licencuje použití tohoto formátu dalšími výrobci, čímž se SWF stává právě tím otevřeným standardem úsporného přenositelného vektorového formátu, který na Internetu citelně scházel.

3.3.2 - Flash ActionScript

Původně byl Flash jednoduše animátor. Grafický nástroj, kde je možné kreslit objekty, slučovat je do tzv. sprite a těm přisuzovat různé akce - zvětšovat, posouvat, plynule zprůhlednit a podobně. Tak mohly vznikat animace - kreslené filmy, které je možné někam odeslat a tam přehrát.

Aby mohl být Flash interaktivní, bylo třeba mít možnost spouštět akce jednotlivých objektů na pokyn uživatele. Tyto akce obvykle reagují na nějakou událost - když třeba uživatel klepne myší na tlačítko, spustí se určitá animace. Vzniká ActionScript - objektový, událostmi řízený jazyk blízký JavaScriptu.

Podobnost s JavaScriptem není náhodná. Stejně jako JavaScript byl určen k oživení textových objektů (elementů HTML-stránky), ActionScript slouží k oživení grafických objektů Flash-animace. Výhodou Flashe oproti HTML-stránce je fakt, že Flash je z principu pohyblivý, o animaci objektů se nemusíme starat ručně. K tomu slouží tzv. timeline (časová osa). Nejen celý film, ale i každý samostatný sprite má svou časovou osu. To mu umožňuje vykonávat své akce nezávisle na jeho pohybu scénou - například animovaná postava může pohybovat nohama ve své časové ose, zatímco v časové ose filmu se bude přesouvat po scéně.

Událostí, na které může reagovat ActionScript, jsou v principu dvě skupiny. Jedna z nich odpovídá akcím uživatele: stisk klávesy nebo tačítka myší, najetí myší nad objekt ap. Druhá odpovídá událostem v rámci animace: dosažení určitého políčka časové osy nebo třeba dokončení nahrávání nějaké části animace.

Kromě grafických elementů dnes umožňuje Flash definici datových kontejnerů a formulářových prvků. Spolu s množstvím systémových objektů a jimi poskytovaných služeb (například pro vzdálený přístup k datovým zdrojům na serveru) a možností úzké spolupráce se serverovými technologiemi rozsáhlé rodiny webových produktů Macromedia MX poskytuje Flash MX možnosti pro tvorbu komplexních interaktivních webových aplikací, které jsou provozovány novým způsobem bez nutnosti klasických explicitních požadavků odesílaných uživatelem pomocí HTML-formulářů. Vzniká nový druh distribuovaných internetových aplikací terminálového typu, kde prohlížeč slouží jako tzv. tenký klient - veškerá aplikační logika je implementována pomocí přenositelného datového formátu. Tím se stává Flash zcela plnohodnotným nástupcem Java-appletů a já osobně mu přisuzuji velkou budoucnost.

IV - Významné serverové nástroje

4.1 - J2EE

Java 2 Enterprise Edition je standard společnosti Sun Microsystems pro nástroje pro vývoj javovských aplikací. Vlastní implementace přímo od firmy Sun je J2EE SDK, ale existují i další - např. Borland JBuilder 5 Enterprise.

Z logiky věci snad jasně vyplývá, že programovacím jazykem platformy J2EE je jazyk Java, o níž jsme už mluvili dost detailně. Víme, že jde o interpretovaný jazyk, který ke svému běhu na cílovém počítači potřebuje Virtual Machine - virtuální stroj interpretující bajtový mezikód. Kromě toho program samozřejmě využívá nějaké služby runtime prostředí. A právě podle toho se dělí Java 2 na jednotlivé edice: Internetové aplikace využívají rozsáhlou Enterprise Edition, řada aplikací si vystačí jen s omezenou Standard Edition, mobilní telefony a přenosná zařízení mají svou Micro Edition.

V této kapitole nás z J2EE bude zajímat specifikace technologií použitelných na straně webového serveru.

4.1.1 - Java Server Pages a Servlety

Servlety jsou objekty napsané v Javě. Po umístění na server jsou adresovatelné protokolem HTTP. Pokud klient pošle požadavek na servlet, je servlet zaveden do paměti serveru, pokud tam ještě není. Poté je spuštěna metoda servletu odpovídající metodě HTTP (např. metodě GET odpovídá metoda doGet). Úkolem těchto metod je vytvoření odpovědi (např. stránky HTML). Ta je poté serverem odeslána klientovi. Servletu jsou k dispozici metody pracující s hlavičkou a parametry HTTP, session objekty, cookies, apod.

Java Server Pages (JSP) jsou podobné PHP nebo ASP stránkám. Jsou to textové HTML-soubory rozšířené o příkazy pro preprocesor a některé speciální tagy. V tom je patrná jistá inspirace (okrajově zmíněným) nástrojem ColdFusion. Jeden druh zvláštních "tagů" jsou dnes již klasické kódové závorky <% %>. Mezi ně se vkládá kód skriptu, zde samozřejmě napsaný v Javě. Dlaší skupina přidaných tagů je serverem automaticky nahrazována určitým HTML-kódem, typicky se používají tagy pro konstrukci vhodných formulářových prvků pro konkrétní prohlížeč. Poslední skupina tagů slouží k přístupu na komponenty JavaBeans implementující aplikační logiku. JavaBeans jsou komponenty se speciálním rozhraním, které podporuje řadu protokolů pro vzdálená volání, jako Remote Method Invocation (RMI) nebo třeba Internet Inter-ORB Protocol (IIOP) pro komunikaci s objekty modelu CORBA (Common Object Request Broker Architecture). V JSP-stránkách lze za pomoci zvláštního XML-souboru, tzv. tag library, vytvářet i uživatelské tagy.

4.1.2 - Enterprise JavaBeans

Enterprise JavaBeans (EJB) jsou komponenty běžící na serveru naprogramované v Javě. Jsou dvojího typu: session beans a entity beans. Volání služeb EJB je vždy vzdálené, tj. pomocí RMI.

Entity bean je trvalý objekt uložený např. v databázi využívaný zpravidla více klienty. Reprezentuje nějaký skutečný objekt se složitějším rozhraním, se kterým aplikace pracuje a který je třeba poskytnout více klientům současně. Příkladem entity bean může být uživatelský účet.

Session bean je dočasný objekt vytvořený pro jednoho klienta existující po dobu existence jeho session. Session bean, které udržují svůj stav vzhledem ke klientovi (tj. jsou vázány na konkrétního klienta), se nazývají stateful session beans. Používají se k implementaci aplikační logiky (řízení jiných objektů) nebo reprezentují dočasné objekty (např. nákupní košík v elektronickém obchodu). Naopak funkcionalita poskytovaná stateless session beans nezávisí na klientovi, který se k nim připojí. Není třeba pro ně udržovat vazbu na klienta a proto také nekonzumují tolik systémových prostředků serveru.

EJB lze použít i pomocí běžného formuláře na HTML stránce. Nelze to však přímo, ale přes servlet. Prohlížeč pošle na servlet dotaz metodou GET resp. POST a servlet zavolá příslušnou metodu EJB přes RMI a podle ní vytvoří odpověď, jenž bude poslána zpět prohlížeči jako HTML stránka.

4.2 - PHP

PHP dnes nepochybně patří mezi nejrozšířenější serverové nástroje. Významným způsobem k tomu přispívá jeho cenová dostupnost. PHP je totiž k dispozici zdarma a spolu s operačním systémem Linux, webovým serverem Apache a databázovým strojem mySQL tvoří "velkou trojku" webových nástrojů. Nutno podotknout, že díky filosofii Open Source, která umožňuje participaci obrovského množství zapálených programátorů, všechny zmíněné produkty patří ve své oblasti ke špičce. PHP je skutečně nejdostupnějším webovým nástrojem a rozhodně si zaslouží rozsáhlou kapitolu.

4.2.1 - Zrod a vývoj

Na počátku zrodu PHP stál Rasmus Lerdorf. Psal se rok 1994 a Rasmus si ve volném čase vytvořil v Perlu jednoduchý systém pro evidování přístupu k jeho stránkám. Jelikož neustálé spouštění interpretu Perlu velmi zatěžovalo WWW-server, přepsal autor systém do jazyka C.

Ačkoliv byl celý systém původně určen pro Rasmusovo vlastní použití, zalíbil se i ostatním uživatelům serveru a začali ho používat. Systém se stal oblíbeným a používalo jej stále více uživatelů. Ti přicházeli s požadavky na jeho vylepšení. Autor proto systém rozšířil, doplnil o dokumentaci a uvolnil jej pod názvem Personal Home Page Tools, který se později změnil na Personal Home Page Construction Kit. Celý projekt byl uvolněn včetně zdrojových souborů, což umožnilo, aby nadšenci z celého světa přispívali svými vylepšeními a opravami. Přesto bylo PHP stále víceméně projektem jednoho autora.

Kromě již zmíněného systému pro evidování přístupů ke stránkám vytvořil pan Lerdorf i nástroj, který umožňoval začleňování SQL-dotazů do stránek, vytváření formulářů a zobrazování výsledků dotazů. Program, který umožnil zpřístupnění databází na Webu se jmenoval Form Interpreter (FI).

Celosvětovou proslulost si získal systém PHP/FI 2.0, který vznikl spojením dvou zmíněných programů. Po dlouhém stadiu beta-verzí vychází jediná oficiální verze PHP/FI 2.0 v listopadu 1997, velmi záhy je ale již následována prvími alfa-verzemi PHP 3.0. V této podobě se jednalo o jednoduchý programovací jazyk, který se zapisoval přímo do HTML-stránek, zvládal automatické vyhodnocování údajů z formulářů a propojení s databázemi. PHP/FI 2.0 se rozšířilo opravdu po celém světě i na mnoha českých serverech (celkem asi 50.000 instalací), bylo odhadováno řádově několik tisíc vývojářů používajících tento nástroj.

PHP 3.0 je v podstatě nový projekt navazující na dobrou tradici PHP/FI. Ujali se ho autoři Andi Gutmans a Zeev Suraski, kteří nejen zcela od základů přepsali celý projekt, ale také upravili a rozšířili samotný jazyk PHP do podoby, jak jej známe dnes. Přibyly například základy objektového programování, operátor zřetězení '.' (do té doby se používal operátor '+', který ovšem spolu s  implicitnámi konverzemi vedl k nejednoznačné syntaxi) a mnoho dalších úprav ve prospěch jednoznačnosti a systematičnosti programování v PHP (jako třeba jednotná politika návratových hodnot vestavěných funkcí). PHP 3.0 je sice zpětně kompatibilní s PHP/FI, ale asi jako C++ s jazykem C: není přímo jeho nadmnožinou, protože některé nevhodné konstrukce zakazuje.

Obrovským přínosem PHP 3.0 se ovšem stala technologie tzv. extensions. Ty umožňují připojovat k PHP samostatné moduly, které mohou úzce spolupracovat s PHP-skriptem a dnes poskytují obrovské množství služeb od přístupu snad ke všem myslitelným databázím (mySQL, MS SQL, PostgreSQL, Oracle, ODBC), přes širokou paletu internetových protokolů (FTP, IMAP, LDAP, SSL) a knihoven pro práci s  různými textovými a grafickými formáty (PDF, XML, GIF, JPG, SWF) až po integraci s dalšími programovacími jazyky (Java, .NET). Možnosti jsou takřka neomezené - každý si může vytvořit svou vlastní extension. Díky tomu se PHP stalo skutečně celosvětovým projektem s několika desítkami přispěvatelů. Jádro PHP ovšem stále zůstává převážně v rukou pánů Gutmanse a Suraského. PHP 3.0 bylo oficálně vydáno v červnu 1998, počet jeho uživatelů dosáhl statisíců. Asi 20% webových serverů používalo PHP. Od verze 3.0 také běží PHP i pod Windows.

Obsah zkratky PHP byl převážně z marketingových důvodů přehodnocen. Jeho výklad jako nástroje pro tvorbu osobních stránek už není vhodný. Proto je také od verze 3.0 oficiální název systému hypertextový preprocesor PHP (PHP: Hypertext Preprocessor).

Už v roce 1998 začali autoři PHP pracovat na zcela novém jádru, které by lépe odpovídalo požadavkům, jež jsou kladeny na moderní rozsáhlé aplikace. Vzniklo jádro Zend nazvané podle křestních jmen autorů (Zeev a Andi), které přináší v porovnání s PHP 3.0 až desetinásobný nárůst výkonu. Verze s číslem 4.0 vyšla oficiálně v polovině roku 2000 a přinesla nejen zrychlení aplikací, ale i vyšší spolehlivost a lepší spolupráci se širší paletou webových serverů a některá příjemná vylepšení jazyka.

V současné době probíhá intenzívní práce na jádru Zend Engine 2.0, které by se mělo stát základem připravovaného PHP 5.0. To by mělo přinést zcela nový objektový model a pochopitelně mnohá další vylepšení a rozšíření. PHP je rozhodně velmi perspektivní projekt. Jeho komunita se dnes může pochlubit statisíci uživatelů a několika miliony webových serverů provozujících PHP.

4.2.2 - Základy jazyka PHP

PHP je z historických důvodů jazyk velmi podobný Perlu. Zahrnuje v sobě ale mnoho šikovných obratů z jazyka C, unixového shellu a dalších.

Do webové stránky jej zapisujeme, konzistentně se specifikací SGML, mezi závorkami pro preprocesor <? ?>. Zmíněná specifikace umožňuje také definovat kód pro více preprocesorů zároveň, takže preferované uzávorkování kódu pro PHP je dnes <?php ?>. Existují i další možnosti, ale tyto dvě jsou doporučené.

Jazyk PHP narozdíl od současných zvyklostí není case-sensitivní, s výjimkou názvů proměnných. Tedy můžeme používat velká i malá písmena například ve jménech funkcí a klíčových slovech, ale třeba $var a $Var jsou různé proměnné.

Proměnné se v PHP nedeklarují, označují se symbolem '$' a mají platnost rozdělenou na globální a lokální. Pouze chceme-li používat globální proměnné uvnitř funkcí, musíme je zde deklarovat klíčovým slovem global. PHP rozeznává podobně jako JavaScript jen velmi málo typů proměnných (jmenovetě jsou to integer, double, boolean, string a object) a podle potřeby provádí implicitní konverze mezi čísly a řetězci. Jazykové konstrukce jsou převzaty z jazyka C, máme ale k dispozici různá příjemná rozšíření. Každý blokový konstrukt (jako např. if, for, while) má i svou neblokovou variantu něco:.. endněco; které můžeme kombinovat s částmi kódu v HTML. Například:

<?php while ($i--): ?>
   <td>buňka <?php echo $i?></td>
<?php endwhile; ?>

Podobně JavaScript, i PHP má velmi silné konstrukce pro práci s poli, například šikovný cyklus foreach (pole as index = > hodnota), který prochází všechny prvky libovolných polí - tedy i asociativních.

Jakákoli proměnná v PHP se může stát polem, stačí použít operátor indexace []. Klíčem pole mohou být celá čísla, booleovské hodnoty nebo řetězce, ostatní typy se podle potřeby konvertují. Pro zjednodušení práce s poli obsahuje PHP užitečné konstrukce array ($pole = array(1=>'prvni prvek', 'a'=>b)) a list ( list($prvni, $druhy)= $pole).

Určitě je vhodné zmínit se alespoň okrajově o řetězcích. PHP jako preprocesorový jazyk je pochopitelně převážně zaměřen na práci s řetězci. Narozdíl třeba od jazyka C máme kromě řetězcových konstant k dispozici též řetězcové konstrukce s proměnnými. Zde je nápadná inspirace Perlem: pokud uvedeme řetezec v apostrofech, jde o konstantu, pokud ale v uvozovkách, při interpretaci se v něj expandují všechny proměnné.

PHP nám nabízí možnost tvorby vlastních funkcí. Až do verze 4.0 ale třeba chyběla možnost (byť díky implicitním konverzím spíše informativní) specifikace typu parametrů. Ani dnes se tato možnost příliš nevyužívá. Podobně jako v jazyce C++ můžeme určit implicitní hodnoty parametrů, zcela narozdíl od tohoto jazyka ovšem návratovou hodnotou funkce může být jakákoli proměnná - tedy například řetězec nebo objekt.

Díky tomu, že PHP je interpretovaný jazyk, můžeme využívat vlastností, které u kompilovaných jazyků nemají obdoby. Jako příklad mohu uvést alespoň funkci eval, která provede svůj parametr, jakoby to byl úsek kódu zapsaný v programu nebo předávání proměnných jménem (např. $b='c'; $a=$$b; uloží do proměnné a obsah proměnné c!).

4.2.3 - Obsluha formulářů

Už od dob PHP/FI byla snadná obsluha formulářů velmi silnou stránkou tohoto nástroje. Před spuštěním vlastního skriptu totiž provedl zpracování parametrů a skriptu už je předal jako správně nastavené globální proměnné. Nerozhodovalo, jestli šlo o informace předané pomocí metody GET, POST nebo třeba prostřednictvím cookie. Použití bylo vždy stejně jednoduché - pracovalo se s obsahem stejnojmenné proměnné.

Postupem času se od tohoto přístupu z bezpečnostních důvodů upustilo. Šikovně předanými parametry totiž bylo možné inicializovat libovolnou proměnnou a pokud programátor aplikace spoléhal na to, že je prázdná, mohlo jít o vážné narušení běhu skriptu. Dnes tedy zpracované hodnoty najdeme po řadě v asociativních polích $_GET, $_POST resp. $_COOKIE. Můžeme sice zapnout zpětně kompatibilní chování nastavením register_globals v inicializačním souboru na 1, ale není to doporučeno. Nemyslím si, že by šlo o velkou újmu na pohodlí programátora a věřím, že ta trocha práce navíc s explicitním zpracováním potřebných parametrů je bohatě vyvážena klidným spánkem webmastera.

4.2.4 - Práce se soubory a databázemi

Jedna z dalších možností využití interpretovaného jazyka je konstrukce kódu za běhu. Kromě zmíněné funkce eval k tomu můžeme s výhodou využít příkazů include, které můžeme volat s nekonstantními parametry. Díky tomu můžeme za běhu připojovat části HTML-dokumentů i PHP-kódu ze samostatných souborů.

Práce se soubory v PHP vychází zcela z Unixu, dokonce i jména funkcí jako fopen(), fseek() a podobně odpovídají. Mezi nejpoužívanějšími bych jmenoval alespoň ty funkce, které kombinují zpracování souborů se silnými stránkami PHP: file() pro načtení celého souboru po řádkách do pole, fgets() pro načtení do jednoho řetězce a fpassthru() pro odeslání souboru do výstupních bufferů. To, čím jsou souborové funkce v PHP zvláštní, je jejich úzká spolupráce s internetovými protokoly pro přenos dat. Parametrem funkce fopen() tak může být nejen soubor přístupný přes lokální souborový systém, ale třeba data přístupná vzdáleně pomocí protokolu HTTP. Čtení takového zdroje je zcela transparentní, v PHP s ním pracujeme stejně jako s lokálním souborem.

Zásadní vlastností, která způsobila masové přijetí PHP, byla jednoduchost, s jakou v něm lze přistupovat k databázím. Převážná většina dynamických aplikací má totiž za úkol publikovat informace z nějakého datového zdroje. S databázemi pak může využívat silných nástrojů pro třídění, vyhledávání a další organizaci těchto dat.

Přejmutí dat z databáze jen těžko může být jednodušší než jak je provedeno v PHP. Skládá se ze tří snadných kroků: nejprve je třeba se k databázi připojit, pak odeslat dotaz a typicky v nějakém cyklu převzít výsledky. Názorně:

$spojeni = ODBC_Connect("db", "user", "password");
$vysledek = ODBC_Exec($spojeni, "SELECT * FROM TABLE1")
while (ODBC_Fetch_Row($vysledek))
  echo "Sloupec 'Col1': ".ODBC_Fetch_Field($vysledek, "Col1");

Při tvorbě rozšíření pro mySQL šli návrháři ještě dál a spojili nejpoužívanější funkce dohromady. Jen těžko si lze představit úspornější kód:

$vysledek = MySQL_DB_Query("db", "SELECT * FROM ADRESAR");
while ($zaznam = MySQL_Fetch_Array($vysledek))
   echo "<tr><td>". $zaznam["jmeno"]. "<td>". $zaznam["email"];

4.2.5 - Knihovna PHPLIB

Knihovna PHPLIB je soubor funkcí, jenž přináší do PHP vlastnosti, které v jeho základním návrhu citelně chyběly. Jednou z nejzásadnějších je nepochybně správa relací, tzv. session managment. Je pravda, že tato technologie je postupně doplňována přímo do PHP a od PHP 4.0 můžeme využívat některé jeho vlastnosti, jako třeba session proměnné - proměnné, které si uchovávají svou hodnotu napříč jednotlivými stránkami navštívenými jedním uživatelem. My si zde povíme, jak je session managment implementován v PHPLIB.

Session management je technika, která obchází neschopnost protokolu HTTP uchovávat stavové informace. Session management umožňuje uchovávat na serveru proměnné, které jsou spojeny s klientem procházejícím naše stránky. Uživatel očekává, že webová aplikace se bude chovat podobně jako klasické desktopové aplikace, na něž je zvyklý - informace, které do systému jednou zadal v něm jsou uchovány a on je může postupně doplňovat. Svůj pobyt na stránkách určitého serveru považuje za souvislou činnost, relaci neboli session. To poněkud odporuje principu HTTP, jenž je takzvaně bezstavový protokol. Klientský prohlížeč odešle požadavek na webový server a ten mu vrátí HTML-stránku. Tím jeho úloha končí. Další odezva od téhož uživatele je izolovaná akce, která z pohledu webového serveru, jemuž se prohlížeč žádným způsobem neidentifikoval, nemá s předchozím požadavkem nic společného. Snadným řešením by bylo nějak indentifikovat klientský prohlížeč, třeba pomocí cookie. Tomu se ale uživatelé v pochopitelné touze po soukromí brání a posílání cookie mohou, ale nemusejí dovolit.

Jak tedy vyřešit správu relací na serveru? Když klient navštíví první stránku, je mu přiděleno jedinečné číslo identifikující jeho relaci. Toto číslo (session-id) se poté protokolem HTTP přenáší od serveru ke klientovi a zpět s každým dotazem a odpovědí tak, aby bylo na serveru k dispozici vždy, když je generována stránka. Skript má pak k dispozici všechny proměnné uložené na serveru patřící dotyčnému klientovi (jaké proměnné to jsou se pozná právě pomocí session-id).

Přenos session-id se provádí dvěma způsoby. Snazší možností je využít cookie v HTTP. Session-id se uloží do cookie na klientském počítači a je automaticky prohlížečem posíláno zpět na server. To ale díky možnosti zákazu cookie není použitelné vždy, což nutí programátory umožnit jiný způsob přenášení session-id. Jeho předávání se pak provádí prostřednictvím parametru za URL nebo přímo v URL jako součást cesty. Na severu potom musí docházet k doplňování session-id do všech odpovídajících odkazů. To je samozřejmě možné udělat i ručně. Nástroj, který to ale udělá za programátora mu ušetří mnoho sil na řešení zajímavějších problémů.

4.3 - ASP.NET

ASP.NET je nejnovější technologie na poli serverových nástorojů. Díky tomu, že byla vytvořena poctivě od základů a že si její vývojáři byli dobře vědomi problémů, se kterými se současný svět webových technologií potýká, jde o nástroj z dnešního pohledu dokonalý. Nejprve si nastíníme některé z nejpalčívějších problémů dnešních nástrojů, pak se podíváme na .NET Framework, nejen proto, že ASP.NET je nad ním provozováno a využívá jeho principů a služeb, ale tako proto, že velké množství potíží (napřiklad problémy komponentového programování) bylo elegantně vyřešeno právě v něm. Pak konečně přijde na řadu ASP.NET s jeho nosnými vlastnostmi jako je správa stavů, webové formuláře, ovládací prvky a webové služby.

4.3.1 - Potíže současných technologií

Problémy, proti kterým se staví ASP.NET, je celá řada. Některé z nich, jako třeba způsob konstrukce komponentových aplikací a zajištění bezpečnosti, řeší už .NET Framework. Jiné, jako například potřeba komplikované správy relací nebo zajištění přehlednosti kódu a výkonnosti heterogenních aplikací, jsou specifické pro webové aplikace.

Problém komponentového programování je tak starý jako tato technologie tvorby programů sama. Důvodem je poněkud nekoncepční evoluční vývoj tohoto přístupu s COM (Component Object Model) na svém vrcholu. COM je bezpochyby užitečné a výkonné řešení, ale má několik zásadních slabin:

Za prvé, COM komponenty jsou distribuovány v podobě DLL (Dynamic Link Library). To je formát určený pro oddělený překlad spustitelných souborů a jejich připojování za běhu. Není ovšem nativně určen ke komponentnímu programování. Jeho formát je "plochý" - připojená data a metody sdílí s hlavním programem jmenný i adresový prostor. To je pro tvorbu komplexních komponentních aplikací velmi nevhodné.

Potom je zde problém instalace COM knihoven. Vznikl trochu nešťastný princip UUID (Unique Identifier), což jsou statisticky unikátní "magická čísla" specifikující komponentu. Jde o 128-bitová náhodná čísla, která rozhodně nevnášejí do tvorby aplikací velkou přehlednost. Ovšem DLL knihovna sama, která distribuuje COM-objekt, je pojmenována autorem komponenty a při instalaci se snadno může dostat do konfliktu se stejnojmennou knihovnou jiného autora. Všechny DLL se totiž instalují do jednoho systémového podadresáře Windows.

Ani v rámci jedné komponenty ještě nemá COM vyhráno. Nová verze aplikace s sebou může přinést novou verzi určité komponenty. Původní (zastaralou) verzi tedy při instalaci přepíše. Ta byla ovšem shodou okolností využívána jinou aplikací a nová verze komponenty bohužel není zcela kompatibilní s původní. "DLL peklo ", jak zní příznačný název tohoto problému, je na světě. Po instalaci nové aplikace přestávají staré aplikace záhadně fungovat, aniž bychom na nich byli cokoliv změnili.

Jaké jsou problémy současných serverových technologií? v první řadě je to tzv. Spaghetti code, který vzniká mísením různorodých jazyků v rámci jednotlivých souborů webové aplikace. Vždyť vývojář webového projektu dnes používá často až pět jazyků (jmenovitě například HTML/XML pro tvorbu stránky, CSS pro její vzhled, SQL pro přístup k datům, PHP/ASP pro tvorbu obsahu a JScript pro jeho oživení) a současné nástroje mu nebrání nasypat je všechny do jediného souboru tvořícího web-aplikaci. Je snad zřejmé, že takový přístup je přinejmenším nešťastný.

Mezi další významné potíže, které stejně jako ta předchozí nejsou nepřkonatelné úsilím programátora, ale zabraňují efektivní tvorbě komplexních aplikací přílišným odčerpáváním lidských zdrojů, patří uchovávání stavu aplikace, její zabezpečení, modularita a výkonnost. Uživatel očekává chování známé z desktopových aplikací, že totiž webová aplikace bude během jeho procházení stránkami zaznamenávat a uchovávat informace, které průběžně zadával. Vedle toho vývojář dnes požaduje robustní nástroj, ve kterém by například mohl "doopravdy" používat rysy objektově orientovaného jazyka, málokterý by také odmítnul například kvalitní debugger. Pro opravdu rozsáhlé webové aplikace už nedostačuje rychlost interpretovaných jazyků a bylo by vhodné převést je do nativního kódu serveru. To vše stávajícím technologiím chybí.

4.3.2 - Lehký úvod do .NET Framework

Microsoft .NET je nový soubor technologií pro vývoj desktopových aplikací i aplikací pro Internet. Jeho základem je .NET Framework, což je prostředí pro vývoj a běh programů. Zatím je implementováno jen pod operačním systémem Windows, ale není z principu omezeno jen na tuto platformu. Není totiž součástí operačního systému, ale jeho rozšířením.

.NET je v principu založen na opačných prioritách, než jazyk Java: účelem není provozovat jeden jazyk na všech platformách, cílem je naopak umožnit vývoj pro platformu Windows pomocí co nejširší palety různých jazyků. Přenositelnost je až na druhém místě. Spolu s .NET jsou distribuovány kompilátory pro C#, Visual Basic, JScript a C++, ale je možné použít i kompilátory třetích stran. Všechny jazyky, které mají spolupracovat na platformě .NET ovšem musí splňovat tzv. Common Language Specification (CLS). Ten předepisuje v první řadě tzv. Common Type System, definici typů kterou musí shodně implementovat všechny jazyky. Dále definuje způsob vyvolání a zachycení výjimek, přístupu k objektům, volání metod apod. Díky tomu je možná úzká kooperace jazyků a není problém vytvářet projekt v několika jazycích zárověň. Díky CLS jsou vedle samozřejmých mezijazykových volání jednoduše k dospozici i natolik netriviální konstrukce jako mezijazyková dědičnost tříd a zpracování výjimek.

Stojí zato poznamenat, že jazyky JScript a Visual Basic (VB) musely být pro splnění CLS od základů přebudovány. Nové verze se jmenují JScript .NET resp. VB .NET a s těmi původními mají společného asi tolik, co C a C#. Aby ale mohlo být ponecháno zažité pojmenování, byly učiněny snahy o maximální zpětnou kompatibilitu. Přesto je potřebná investice do osvojení nových technologií v těchto jazycích značná a osobně bych doporučoval naučit se rovnou C# jako nativní jazyk platformy .NET, který je nejen velmi výkonný, ale díky nezatíženosti balastem zpětné kompatibility také velmi elegantní.

Hlavní částí .NET Framework je Common Language Runtime (CLR). Jak název napovídá, jde o společné běhové prostředí, které všem jazykům jednotně zpřístupňuje služby operačního systému a spravuje běh .NET aplikací. Každý program určený pro .NET je totiž nejprve přeložen do jazyka Microsoft Intermediate Language (MSIL), k němuž jsou připojeny řídící informace - tzv. metadata. Takto přeloženému kódu se říká metadaty řízený kód (managed code).

MSIL je jazyk velmi blízký assembleru, avšak narozdíl od assembleru je procesorově nezávislý a umožňuje vyšší úroveň programování. Kromě instrukcí jako jsou například instrukce realizující aritmetiku, přesuny paměti, řízení toku programu, které má každý assembler, jsou v MSIL také instrukce řízení výjimek, práce s objekty, volání virtuálních metod či přímá manipulace s prvky polí. MSIL je navržen tak, aby šel jednoduše přeložit do assembleru procesoru, kterým má být program vykonáván. Žádné programy na platformě .NET nejsou interpretovány. Kód v MSIL musí být vždy přeložen do nativního kódu a pak vykonáván přímo procesorem. Tento překlad je realizován tzv. just-in-time kompilátorem (zkráceně JITter), jež je přímo součástí CLR.

Překlad aplikace má dvě fáze: překlad z vyšších programovacích jazyků do MSIL, který probíhá při vývoji, a překlad z MSIL do strojového kódu cílového procesoru, jenž probíhá buď při instalaci programu nebo dokonce až při spuštění programu - tu má ji na starosti právě JITter.

Důležitou součástí .NET Framework je tzv. Class Library. Jde o knihovnu obsahující množství tříd a rozhraní. Některé z nich jen obalují API funkce systému, jiné poskytují rozšířenou funkcionalitu. S přechodem na jiný operační systém, na kterém je implementován .NET Framework, není třeba aplikace přepisovat ani znovu překládat, neboť již jsou přeloženy do MSIL a volají stále stejné metody knihovny tříd. Pomocí MSIL a Class Library je dosaženo nezávislosti aplikací na operačním systému a použitém hardwaru. Stačí, aby na cílovém systému a hardware byl implementován .NET Framework - v tom se cíle .NET Frameworku blízce shodují s filosofií Javy. Je ovšem pravda, že .NET Framework je co do přenositelnosti mnohem tvrdší oříšek než třeba Java Virtual Machine. V principu to ale možné je.

.NET přichází s novým způsobem konstrukce a správy komponentových aplikací. Každý program tvořený pro .NET je tvořen alespoň jednou komponentou, tzv. assembly. To je kolekce souborů s kódem nebo daty, jenž je vždy doplněna tzv. manifestem. V manifestu jsou uložena metadata popisující assembly. Musí zde být přesně specifikovaná verze assembly, její kultura (tj. národní prostředí), seznam obsažených souborů a seznam jiných assemblies, jejichž služeb je využíváno, a to včetně jejich kultur a verzí. Kromě toho obsahuje manifest šifrované informace o obsažených souborech umožňující při spouštění aplikace zkontrolovat, zda nebyl měněn její kód či data.

Assemblies mohou být buď soukromé nebo sdílené. Soukromé jsou vytvářené bez úmyslu poskytovat služby cizím programům - nejsou nikde registrovány a není třeba, aby se systém zabýval jejich verzováním, jelikož pocházejí od jednoho autora. Naopak sdílené assembly jsou poskytovány jiným vývojářům a proto musí mít celosvětově jednoznačná jména (generovaná na základě šifrovacího klíče autora) a systém musí umožnit správu jejich verzí. Sdílené assembly jsou uloženy v Global Assembly Cache (GAC), kam jsou nahrány při instalaci aplikace a jelikož mají jednoznačná jména a verze, nedochází k jejich přepisování. Při hledání assembly, která se má použít, systém vybere tu, jejíž verze odpovídá a jež má nejvyšší build a revision number - je tedy z  kompatibilních assemblies nejnovější. Pokud není nalezena kompatibilní verze, je ohlášena chyba a aplikaci nelze spustit.

Nejen k assembly, ale i k jednotlivým souborům i jejich částem lze připojovat metadata. K připojení ke kódu jsou určeny tzv. atributy. Ty umožňují, aby byl kód sebe-popisující. Atributy se do kódu vpisují mezi hranaté závorky. Překladač je zpracuje a připojí ke kódu MSIL. Podle hodnot některých atributů se pak řídí běh aplikace v CLR, některé atributy jsou také využívány kompilátory. Programátor má rovněž možnost s metadaty pracovat za běhu programu.

Každý atribut je definován třídou odvozenou ze základní třídy System.Attribute. Je možné nejen využívat celou škálu předdefinovaných atributů, ale i definovat vlastní. Atributy užívané pro celou assembly nesou např. jméno autora, verzi, popis assembly, apod. Příkladem atributu používaného na metody je atribut Obsolete. Pokud je tímto atributem označena metoda, kterou někde voláme, kompilátor nám u jejího volání zobrazí varování, že voláme zastaralou metodu.

4.3.3 - Principy ASP.NET

ASP.NET je souhrnný název pro prostředky, které poskytuje platforma .NET pro vývoj aplikací běžících na serveru. Jeho součástmi jsou tzv. Web Forms, Web Controls a Web Services.

Podle názvu ASP.NET by bylo možné usoudit, že se jedná o další verzi ASP. Web stránky napsané v ASP skutečně budou i nadále fungovat. ASP.NET však představuje mnohem komplexnější řešení programování na serveru. V první řadě přivádí do prostředí serverových nástrojů výkonný a spolehlivý .NET Framework se všemi jeho výhodami, o kterých jsme mluvili výše. Do tvorby webových stránek potom přináší prostředky pro oddělení kódu od HTML-stránek a zjednodušení tvorby formulářů, správu stavu aplikace a v neposlední řadě kompilaci do nativního kódu pro zvýšení výkonu aplikací.

ASP.NET nadále umožňuje vkládat do zdrojového HTML kódu stránek "závorky" <% %>. Do nich lze však doplnit kód psaný v libovolném jazyce dostupném na platformě .NET (například C#). Tento způsob se však nedoporučuje hojně používat, jelikož vede k nepřehlednému kódu. Místo toho se do HTML vkládají speciální tagy s nastaveným atributem runat na hodnotu "server". Tyto tagy jsou při genezi stránky nalezeny, zpracovány a místo nich se může vygenerovat nějaký HTML kód. Aby se soubory s novým způsobem zpracování odlišily od stránek ASP, přidává se za jejich jméno přípona .aspx místo původní přípony .asp. Tagy obsažené v .aspx stránce můžeme rozdělit do tří skupin. První skupinou jsou stávající tagy HTML, druhou nové tagy implicitně zabudované do ASP.NET a poslední skupinu tvoří uživatelsky definované tagy. Tagy zpracovávané na serveru se nazývají ovládací prvky (Web Controls). Každý ovládací prvek je instancí třídy, která implementuje jeho vlastnosti a chování, všechny jsou potomky třídy System.Web.UI.WebControls.WebControl. Celá stránka se v ASP.NET také chová jako objekt, je potomkem třídy System.Web.UI.Page.

4.3.4 - Kód v pozadí

Ve třídě stránky i v každé třídě ovládacího prvku jsou definovány různé události. Umožňují pokročilou práci se stránkou na straně serveru. Kde je však tento kód umístěn? Je-li na stránce třeba obsloužit jednoduchou událost, je přijatelné vkládat kód pomocí "závorek" <% %> nebo lépe pomocí tagu <script runat="server"></script>.

Je-li však potřeba komplexnější kód, umisťuje se do separátních souborů, které jsou ke stránce připojeny v jejím záhlaví, kde je deklarován seznam připojených souborů. Takový kód v pozadí stránky se označuje jako Code Behind.

Důležitou vlastností ASP.NET je, že nejen Code Behind a kód vložený do stránky .aspx, ale celá .aspx stránka, se kompiluje a výsledný kód MSIL je ukládán na serveru. Tím dochází ke podstatnému zrychlení běhu kódu na serveru. Celá stránka .aspx se za běhu chová jako dynamická knihovna, která poskytuje serveru rozhraní a přes něj také výstupy, jež mají být odesílány klientovi. Aby nebylo třeba stále kompilovat kód a zpracovávat stránky, je použito několika úrovní cache. První přístup na stránku je sice o něco pomalejší, to je ale bohatě kompenzováno rychlostí odezvy následujících přistupů. Dokud je stránka v cache a není třeba ji znovu překládat, běží totiž v nativním kódu serveru a zpracování dotazu spočívá ve vyvolání metody, která rovnou generuje odpověď.

4.3.5 - Ovládací prvky

ASP.NET obsahuje implicitně 45 předdefinovaných ovládacích prvků (Web Controls). Jejich syntaxe vychází z jazyka XML, jsou umístěny v namespace asp. Uveďme několik jednoduchých příkladů:

<asp:Button id="Button1" runat="server" Text="Button"></asp:Button>
<asp:Label id="Label1" runat="server">Label</asp:Label>

Uvedený kód ASP.NET se po zpracování na serveru nahradí kódem HTML:

<input type="submit" name="Button1" value="Button" id="Button1">
<span id="Label1">Label</span>

Kromě předdefinovaných ovládacích prvků lze definovat i prvky uživatelské (User Controls). Ty se definují opět zcela odděleně od stránky, kde jsou použity. První možností, jak definovat uživatelský prvek, je napsat Code Behind a v něm implementovat potomka třídy určené k vytváření uživatelských prvků (vhodné především pro prvky, které se nenahrazují kódem HTML nebo se nahrazují jen kódem krátkým). Druhou možností je vzít část .aspx stránky, přesunout ji do zvláštního souboru (označeného příponou .ascx) a prohlásit ji za uživatelský prvek. Na takovýto soubor pak stačí přidat odkaz do záhlaví stránky, kde chceme vytvořený prvek použít, a v tomto odkazu definovat jméno a předponu tagu (namespace). K souboru .ascx lze opět připojit Code Behind a tím prvek "oživit". Při zpracování takto definovaného prvku je nejprve zpracován soubor .ascx (může totiž obsahovat další server-side prvky) a výsledek je vložen na místo zpracovávaného prvku.

4.3.6 - Řízení relací

O řízení klientských session jsme už podrobně mluvili v kapitole o PHPLIB. Oba způsoby přenosu session-id, tedy jak pomocí cookie, tak prostřednictvím upravovaných odkazů jsou samozřejmě k dispozici i v ASP.NET. Navíc jsou jednoduše nastavitelné pomocí konfiguračních souborů bez nutnosti použití nějaké přídavné knihovny. O správu session se ASP.NET umí postarat automaticky.

Co se týká uchování samotných session proměnných, ty je možné přímo předávat klientovi a vracet na server přes URL nebo cookie. Navíc je ale lze uchovávat také ve zvláštním procesu běžícím na serveru (ASP.NET State Server Process) nebo i v databázi na SQL serveru. Uchovávání objektů v databázi je pomalejší, umožňuje však vysokou spolehlivost.

Další otázkou je uchovávání stavu samotných stránek například při opakovaném, či postupném vyplňování formulářů. Zachovávání stavu stránek již není třeba do stránek dodělávat. Je totiž na stránky přidáváno automaticky, pokud není programátorem v objektu stránky nastaveno jinak. Stav stránky je dán daty, která nesou ovládací prvky. Každá stránka zachovávající si svůj stav obsahuje formulář (tag <form runat="server" method="post">), ve kterém jsou umístěny všechny ovládací prvky. Třídy všech ovládacích prvků mají vlastnost jménem ViewState. Jde o asociativní pole, ve kterém může mít ovládací prvek uloženy proměnné, jež chce zachovávat. Při genezi stránky se pak automaticky projdou všechny ovládací prvky na stránce, obsahy jejich vlastností ViewState se zakódují do řetězce a ten je pak vložen do formuláře pomocí skrytého tagu <input type="hidden" name="__VIEWSTATE">. Data formuláře jsou vždy odesílána na stejnou stránku, jakou byla vygenerována (parametr action tagu <form> je prázdný). Před spuštěním Code Behind reagujícím na doručení dat jsou serverem obnoveny hodnoty vlastností ViewState stránky a všech ovládacích prvků. Tento způsob je pro programátora stránky naprosto transparentní a k jeho uplatnění nemusí napsat ani jedinou řádku kódu.

4.3.7 - Webové služby

Webové služby implementují princip, o němž jsme mluvili už v souvislosti s J2EE. Šlo o tzv. stateless session beans, které bezestavově poskytovaly určitou službu. Zpravidla musí jít o službu poskytující odpověď na nějaký jednoduchý dotaz - všechny parametry dotazu musí být předány jako argumenty volání služby. Podobně i webová služba je objekt umístěný na serveru, který poskytuje přes své rozhraní funkcionalitu jiným aplikacím.

Web services přicházejí se zásadním přístupem důsledné standardizace. Jejich účelem totiž je, aby webové služby byly použitelné automaticky bez předchozí znalosti nejen konkrétního poskytovatele služby, ale i druhu služby a formátu parametrů a návratových hodnot. K tomu zřejmě potřebujeme hned několik dost silných nástrojů.

K vyhledávání služeb na Internetu slouží UDDI (Universal Description, Discovery and Integration), což je registr služeb umístěný na Internetu s možností vyhledávání. Tento registr je vlastně také služba, ke které lze přistupovat programově. Její umístění je však známé. Výstupem z UDDI je seznam serverů, na kterých najdeme služby vyhovující zadaným kritériím. Pokud chceme zjistit seznam služeb dostupných na konkrétním serveru, použijeme protokol SOAP Discovery (zkracované jako Disco). Tím tedy zjistíme, kde je služba umístěna a jak se přesně jmenuje.

Dále bychom potřebovali zjistit, jak se službou komunikovat. Popis metod dostaneme od služby, zavoláme-li její metodu, která musí být v každé službě přítomna a která vrací definici svého rozhraní v jazyce WSDL (Web Service Description Language), jenž je podmnožinou XML. Ten přesně popisuje, jaké metody můžeme volat (včetně typů jejich parametrů), k jakým properties můžeme přistupovat a případně poskytuje nějaké komentáře. Každá služba je díky použití atributů v jejím MSIL kódu sebe-popisující a není třeba ji doprovázet dalšími popisy jako např. IDL. Aby nebylo nutné při vytváření služeb psát WSDL dokument ručně, což by byla dosti vyčerpávající práce, při které by docházelo ke zbytečným chybám, umožňují vývojové nástroje jeho automatickou genezi na základě zdrojového textu třídy, která implementuje danou službu.

Když už víme, jaké metody můžeme volat, potřebujeme také komunikaci nějakým protokolem realizovat. K tomu slouží přímo protokol HTTP nebo protokol SOAP (Simple Object Access Protocol) nad protokolem HTTP, jenž oproti HTTP umožňuje přenos komplikovanějších struktur (definuje jejich popis pomocí XML). Jeho prostřednictvím můžeme volat metody služby, předávat jim parametry a získávat návratové hodnoty.

V ASP.NET je zabudovaná výrazná podpora pro vytváření služeb. Každá služba je potomkem třídy System.Web.Services.WebService. Její vytvoření je velmi jednoduché, jelikož veškerá nízkoúrovňová funkcionalita pro komunikaci protokoly je již zabudována v .NET Frameworku. Kód služeb lze pochopitelně psát v libovolném jazyce dostupném na .NET. K vytvoření služby stačí implementovat potomka třídy WebService. Potomek může mít libovolné metody, ale pro klienty jsou dostupné jen ty, které jsou označeny atributem WebMethod. Atribut může obsahovat i komentář, který je použit při generování WSDL popisu služby. Po kompilaci do MSIL a umístění na server je služba připravena reagovat na dotazy od klientů.

Dotazy na web služby lze posílat protokoly HTTP a to buď přímo (používáno nejčastěji při dotazu z HTML formuláře, parametry předáme službě úplně stejně, jako bychom otevírali dynamickou stránku) nebo použitím protokolu SOAP, který se používá pro standardizované předávání jiných než řetězcových parametrů. Odpověď je odeslána zpět klientovi ve formátu XML.

Kromě klientů dotazujících se na web služby pomocí formulářů HTML lze samozřejmě psát desktopové aplikace využívající web služeb. Jelikož všechny protokoly použité pro komunikaci jsou standardní, nemusí být tito klienti vytvářeni pod .NET. Stačí implementovat konstrukci dotazů SOAP a jejich posílání na server, kde se služba nachází. S výhodou lze však využít nástrojů, které z popisu služby ve WSDL vygenerují kód proxy třídy. Tato třída je v ASP.NET vždy potomkem třídy SoapHttpClientProtocol nacházející se v namespace System.Web.Services.Protocols a implementuje potřebné komunikační schopnosti. Proxy třídu přidáme ke zdroji programu klienta a vytvoříme v něm její instanci. Tato instance se bude chovat přesně jako web služba, kterou voláme, volání přes vzdálený komunikační kanál proběhne zcela transparentně.

4.4 - Srovnání ASP.NET a PHP

Při výkladu o PHP a ASP.NET byly občas vyzdvihovány společné rysy, ale zatím nepadlo mnoho o jejich rozdílech. Je jasné, že se oba nástroje liší, dokonce v principu a od základů jde o rozdílné technologie, které pouze mají společné nasazení. Je vůbec možné tyto dva nástroje objektivně porovnat? Dá se říct, jestli je některý z nich lepší a druhý horší?

Myslím, že technologie PHP a ASP.NET jsou neporovnatelné, protože každá z nich má jiné nasazení. Z toho také vychází jejich silné i slabé stránky.

PHP vzniklo evolučně a jeho prvotním účelem bylo zjednodušit práci při drobých rutinních úlohách. Dodnes je v tom velmi dobré. Programování malých projektů je snadné, rychlé a přehledné. Na PHP mě osobně uchvacuje magicky jednoduchá práce s řetězci spolu se vkládáním proměnných a elegantní a výkonná manipulace s asociativními poli. Jednoduché úlohy jsou s PHP skutečně jednoduché.

Proti němu stojí ASP.NET jako striktní, standardy svázaný nástroj, který sice umožňuje starý nesystematický přístup, ale není pro něj optimalizován. Jeho doménou je oblast rozsáhlých komplikovaných aplikací vyvíjených mnohačlenným týmem, kde vládne pořádek a štábní kultura. Vývojáři dostávají do rukou všechny oblíbené nástroje pro komponentální programování stránek, oddělení deklarativního kódu stránky od procedurálního kódu pracujícího se stránkou a všechny výhody plynoucí z objektově orientovaného přístupu k ovládacím prvkům stránky a dalším třídám objektového modelu webové aplikace, na druhou stranu jsou ale svázáni mnohem komplikovanějšími formalismy. Zpracování stránek postavených na takto komplexním a univerzálním základě je pochopitelně o něco pomalejší, což ovšem v ASP.NET bohatě kompenzuje překlad do nativního kódu a propracovaný caching.

Jedním z důležitých faktorů hrajících ve prospěch PHP je jeho dostpnost. Úzká vazba na komerční platformu Windows dělá z ASP.NET na první pohled nástroj pro tvorbu rozsáhlých firemních obchodních a prezentačních portálů. Naproti tomu PHP jako multiplatformí volně šiřitelný nástroj může využívat opravdu kdokoli. Jednou větou ASP.NET je na světě proto, aby vydělalo hodně peněz, PHP potom proto, aby ušetřilo hodně práce.

V - Budoucnost

Velmi podrobně jsem popsal současné technologie a u nástrojů, kterým osobně přisuzuji velký význam v budoucnosti, jsem to explicitně uvedl. Domnívám se, že poskytování informací na Internetu bude stále interaktivnější a z uživatelského rozhraní se postupně vytratí dnes již deset let starý princip explicitních požadavků uživatele na data ze serveru. Vývoj internetových technologií spěje k úzkému propojení světů destopových a webových aplikací. Stejně jako se, spolu s rostoucí konektivitou, desktopové aplikace stále častěji odkazují na on-line zdroje, tak se chování webových aplikací blíží principu souvislé relace známé z klasických programů. Uživatel přestává vnímat webovou aplikaci jako systém propojených stránek, mezi kterými prochází při vyhledávání potřebných informací. Chce interaktivně ovládat intuitivní rozhraní, které mu bude informace dodávat průběžně bez potřeby otravného obnovování stránek. Právě proto jsem přisoudil velkou budoucnost nástroji Flash, který toto vše již dokáže - umí elegantně a poutavě interagovat s uživatelem a zároveň přijímat a vizualizovat data v reálném čase.

Druhou důležitou oblast jsme zachytili v kapitole o webových službách. Internet byl totiž původně určen ke komunikaci mezi lidmi. Je dobře patrné, že všechny internetové protokoly a služby zachovávají formát snadno pochopitelný lidskou bytostí. Vedle toho ale v oblasti internetu začalo pracovat velké množství automatizovaných nástrojů. Ty však mají v doméně dokumentů a dat určených převážně k prohlížení uživatelem velmi nesnadnou pozici. Například zpracování dat publikovaných pomocí HTML je obzvláště komplikované a zatím v této oblasti uspěly snad toliko vyhledávací stroje, které stejně pracují spíše v rovině cílového čtenáře nalezeného dokumentu. Spolu s webovými službami ale začínají na Internetu koexistovat klasická data a data či služby výhradně určené pro strojové zpracování. Tyto umožní automatizovaným procesům komunikovat stejně efektivně, jako dnes mezi sebou prostřednictním Internetu komunikují lidé. To je druhá velká oblast webových aplikací budoucnosti. Narozdíl od té první se zatím rýsuje mnohem neznatelněji. Přesto věřím, že jsme svědky podobného převratu, jako byl před 13 lety příchod WWW.

VI - Literatura

Pro zpracování kapitol o jednotlivých technologiích jsem využil několik knižních zdrojů:

Pro kapitoly o historii pak převážně zdroje internetové: