Java na web serveru nejen pro starší a pokročilé

23. ledna 2003

•

Titulek pravděpodobně přivábil ty čtenáře Intervalu, kteří v uplynulých týdnech hltali seriál Marka Branického o JSP. Přinejmenším tento úvodní článek je však určen zejména těm, kteří by jej bez upozornění, které právě čtete, bez uzardění přeskočili. Nebo těm z nich, kteří se aspoň rekreačně věnují webovému programování. Rovnou drze přiznávám, že jeho účel tkví pouze v tom, aby vás nalákal na další pokračování. Předem však slibuji, že se vynasnažím, aby aspoň dnes vůbec nepadlo slovo Java.

Na Intervalu i jinde vyšla spousta článků typu „Internetový bazar v PHP“, „Fotoalbum v PHP“ a podobně. V takovémto článku jste se obvykle kromě vlastního textu mohli dočíst následující:

Přestože na tak krátké ploše nevyznívá tento kód až tak strašidelně, modří možná již vědí, kam mířím.

Upozornění

Předchozí věta naznačuje, že následuje pasáž obsahující kritická vyjádření. Jejich cílem však v žádném případě nebude hanění autorů citovaných článků. Je zřejmé, že příklady v nich uváděné jsou ryze demonstrativní. Nicméně porozhlédneme-li se po open-source projektech (či po leckterých vlastních aplikacích), zjistíme, že až příliš mnoho programátorů považuje nebezpečně často výše naznačený kód za zcela běžný způsob vývoje aplikací, což snad dává následujícímu textu jisté opodstatnění.

Obvykle totiž nepíšeme jednoúčelové internetové bazary či fotoalba. Chceme napsat fotoalbum, které použijeme podruhé, potřetí, tu v jiném grafickém kabátě, onde zakomponované do jiné aplikace. Třeba do internetového bazaru fotografií. Provázaného s diskusním fórem. A ještě ke všemu tam přijde nějaký reklamní systém – fantazii se meze nekladou.

Je jistě patrné, že citovaný pseudokód má do znovupoužitelné komponenty daleko. Při jakékoli změně vzhledu je nutno provést zásah do kódu. Při častých změnách požadavku na grafiku můžeme narazit na to, že webdesignér se v PHP kódu zcela neorientuje a naopak programátor se cítí otráven požadavkem, že by se měl vrtat v nějakém HTML, které je již dávno pod jeho úroveň. Nehledě na to, že pro optimální využití projektového týmu je jistě lepší mít specializovaného programátora a specializovaného webdesignéra, jejichž znalosti se překrývají minimálně. (Jistě, existují všeumělové, ale kde je vzít, a nekrást, že…)

Úlitba zkušenějším webprogramátorům

Nyní může zkušený čtenář namítnout, že on si je veškerých výtek vědom a že v žádném případě takovýmto způsobem – až na nutné výjimky – webové aplikace nepáše. Že má ve svém kódu pořádek. Že intuitivně tuší, že oddělovat výkonný kód (vznosně aplikační logiku) a HTML (tedy prezentační vrstvu) je Dobrá Věc. Že si proto vytvořil vlastní balík knihoven a programovacích postupů, který umožňuje vyhnout se výše uvedeným připomínkám, případně pod tímto balíkem leží některá z mnoha knihoven pro práci se šablonami. Atd. atd.

Hloubavá povaha se sklony k vymýšlení univerzálních abstrakcí se může pokusit zobecňovat a začít rozvíjet úvahy typu:

Co dělá taková typická webová aplikace?
Typicky zobrazuje nějaká data.
A není to málo?
Dobře, napřed tedy přijme nějaký vstup, a ten zpracuje.
Jaké mohou být vstupy?
Typicky:
- uživatelská data z formuláře – ta je třeba důkladně ověřit a v případě problému vyplodit co nejsrozumitelnější výstup
- řídící data, podle nichž se aplikace rozhoduje, co vlastně udělat (mezi tato data lze zařadit i samotné názvy skriptů, rozhodování podle nich za nás pochopitelně řeší HTTP server)
Tak to by na to šla napsat nějaká strašně obecná mašinka, ne?
Hm…

Povzbuzení

Pozornost znaveného čtenáře si dovoluji zaměřit na skutečnost, že se nachází ve zlomovém bodu článku, v němž pomalu přecházíme k informacím konstruktivnějšího charakteru. Doporučuji tedy vytrvat.

Samozřejmě, že vytváření obecných mašinek, které spasí svět, je úkol ošidný. Od určité míry zobecňování nemůžeme chtít vše vyjádřit jazykem knihovních tříd či rozhraní, ale nastupuje něco, pro co se ujal název design patterns. Tedy popisy typických doporučených programátorských postupů a technik – namísto deklarací a definicí strukturovaný text prokládaný diagramy.

Výše popsané pochopitelně zaujalo před námi ledaskoho a výsledkem byl právě takový jeden design pattern. Onen pattern pochopitelně neříká nic převratného, popisuje to, co všichni ze své praxe známe či aspoň tušíme – ale ony patterny často nejsou od toho, aby obsahovaly nečekané objevy lidského ducha, ale spíše aby seděly programátorovi na rameni a říkaly mu: „Hele, nepras ten kód, ono by se to vážně mělo dělat trochu čistěji, a to tak a tak, a nehádej se, já jsem design pattern a musím to vědět nejlíp.“

Fanfára

Tramtadadá! Po slavnostní fanfáře na jeviště přichází avizovaný design pattern zvaný Model-View-Controller, známý též pod familiární zkratkou MVC. Podívejme se mu nyní na zoubek.

Pokusme se nejprve jednoduchým diagramem zachytit přímočaře psané webové aplikace:

přímočaře psaná aplikace

Snad je to srozumitelné – webserver zvolí vhodný skript [1], ten poklábosí [2,3] s trvalým úložištěm dat (typicky SQL databází) a nakonec vrátí zpět trochu toho HTML [4]. Nyní se pokusíme ukázat, jak nám ono zatím záhadné MVC při troše uvažování z tohoto obrázku samo vyplyne.

V terminologii MVC zde webserver hraje část role Controlleru – na základě informací přicházejících s HTTP požadavkem rozhoduje, kam dále předat řízení. Skripty, jak jsem výše uvedl, se podívají na zadané parametry, podle nich „něco udělají“ (například vymění si pár slov s databází) a výsledek toho „něčeho“ vizualizují.

Ono „něco“ se honosně nazývá aplikační logikou (nebo též anglicismem „business logika“ či zhovadilým anglicismem „obchodní logika“) a spolu s daty, popisujícími stav aplikace, je zahrnuto pod slůvko Model.

A na View pochopitelně nezbude nic než generování výsledné podoby výstupu, v našem případě HTML.

Nyní pozorný čtenář správně tuší, že MVC pattern pojednává o tom, jak elegantně vytvářet GUI aplikace (a nejen webové) pomocí rozdělení do tří základních částí, implementující jednotlivé role – Controller, Model a View. Spolupráci těchto prvků – pro větší názornost se budeme věnovat pouze webovému prostředí – popisuje diagram z blueprints od Sunu.

Tedy:

uživatel zašle požadavek
Controller posoudí, které komponentě přidělí zpracování požadavků (typicky na základě konfiguračního souboru)
volaná komponenta zavolá příslušnou aplikační logiku (tedy Model), pak vrátí Controlleru informaci o tom, jak dopadla
Controller podle toho usoudí (na diagramu za pomocí komponenty nazvané „flow manager“), co dál – buď zavolá další komponentu nebo…
…nebo předá řízení View vrstvě, která mu vygeneruje kýžený výstup
výstup je nakonec vrácen uživateli, který (nejen) na jeho základě může zaslat další požadavky

A je to. Zájemci si mohou prohlédnout: