Firma Yahoo je u nás známa jako provozovatel „již nemoderního“ vyhledávače. Nicméně jako většina velkých internetových firem je také tvůrcem open source software. O jednom takovém bych vám chtěl něco napsat – o javascriptovém frameworku Yahoo User Interface, zkráceně YUI.

YUI není v českých zemích známé či rozšířené, alespoň podle počtu českých odkazů na Google. Jinak je tomu na západ od našich hranic – YUI používá ve svých aplikací (pochopitelně) firma Yahoo, najdete ho na stránkách PayPalu či LinkedIn.

Komponenty

YUI obsahuje mnoho propracovaných komponent. Jmenujme alespoň některé: autocomplete, datová tabulka, stránkovač, záložky, strom, kalendář, posuvník a několik dalších.

Svého času se většina redakčních systémů prodávala s marketinkovým sloganem „texty budete moci editovat jako ve Wordu“. Prohlížečové WYSIWYG editory sice od té doby vyspěly, ale přesto do Wordu mají hodně daleko. Nicméně v té době byl vytčen faktický standard v oboru redakčních systémů, takže dnes i většina Open Source redakčních systémů nějaký WYSIWYG editor má.

K věci lze ale přistoupit jinak – nenechat uživatele zadávat co nejpřesnější grafickou podobu, ale naopak ho nechat vyjádřit, co chce zobrazit. Tento „alternativní“ přístup v sobě obsahuje jazyk a knihovna Texy, chtěl bych mu věnovat tento svůj článek.

Teoreticky by se dalo říci, že vytvářet nové komponenty je ve webovém frameworku zbytečnost. Stačí vybrat framework s dostatečným počtem kvalitních komponent a z nich sestavit aplikaci. Realita života je ale jiná – napadají mě přinejmenším tři důvody, proč jsou vlastní komponenty potřeba:

1. První důvod se jmenuje RIA.
2. Dobře použitá „nestandardní“ komponenta může velmi zvýšit uživatelskou přívětivost aplikace.
3. Základním programátorským vzorem je kompozice menší prvků do větších částí – stejně tak i komponenty potřebujeme sdružovat do větších relativně izolovaných provázaných celků. A určitě tyto celky by také měly komponentami.

Tolik filozofický úvod, pojďme k praxi – jak udělat vlastní komponentu ve Wicketu.

Porovnání podílu prohlížečů se stalo vděčným tématem internetových časopisů v době, kdy není o čem psát. Jde o relikt minulosti, souboj o podíl uživatelů byl zajímavý před čtyřmi lety – v listopadu 2004, kdy vyšla první verze Mozilla Firefoxu a začala soupeřit s Internet Explorerem. Od té doby se prohlížeče z pohledu vývojáře internetový aplikací téměř nevyvíjí. Diskuze o prohlížečích se na internetu již nevede o množství podporovaných standardů, ale o záložkách, zásuvných modulech, implementaci v mobilech atp. (Čestnou vyjímkou je Google Gears.)

Stagnace má svoji pozitivní stránku (není potřeba tak často spravovat design), ale i negativní – všechny nectnosti prohlížečových technologií zůstávají nezměněny. Jde o určitou chaotičnost HTML tagů, malou předvídatelnost následků změn v CSS souborech, některé nectnosti interpretru JavaScriptu, vzájemné nekompatibility prohlížečů… Zkrátka spousta práci znepříjemňujících „drobností“. Naštěstí existuje řešení: použít javascriptový framework. Dokonce máme na výběr z několika frameworků a několika možných přístupů. Pojďme se podívat na několik různých koncepcí.

Důležitým pojmem při vývoji software je model. Zpravidla se tento pojem odkazuje na návrhový vzor MVC. Zdatnější vývojář se pak při vyslovení tohoto pojmu odkáže jednak Swing a jednak na Struts, který model přinesl do světa webového vývoje. Jenže, přiznejme si to, pojmy model a MVC jsou poněkud mlhavé a neurčité. Pojďme se tedy podívat na různé implementace modelu v několika frameworcích – za základ vezmu tři oblíbené: Swing, Spring MVC a Apache Wicket.

Ukázkový příklad – zobrazujeme kočky

Použití modelu bych chtěl ukázat na tabulce, která zobrazuje atributy následující třídy Kočka. (Kočka je užitečná entita – používají ji i autoři dokumentace Spring Frameworku.)

public class Cat {
   String name;
   int age;

   public String getName(){
      return name;
   }
   public void setName(String name){
      this.name=name;
   }

   public int getAge(){
      return age;
   }
   public void setAge(int age){
      this.age=age;
   }
}

Vytvořit AJAXovou či přímo RIA aplikaci se zdá být snadné – stačí umět JavaScript a HTML a vhodně použít XMLHttpRequest… Jenže tak jednoduché to není. Nedávno jsem nalezl článek, který přirovává problémy AJAXového vývoje k vývoji rezidentních programů v DOSu. (Nevím, jestli ty doby pamatujete: šlo o programy čekající na pozadí na systémové volání OS.) Zde je můj zkrácený překlad:

• JavaScriptový engine v prohlížeči neumí multithreading (stejně jako DOS).
• Velikost kódu je limitovaná (v DOS bylo limitem 640kB RAM).
• JavaScript nepodporuje složitější kolekce, které známe např. z Javy.
• Na serveru i ve Win32/Linuxové aplikaci si můžete vybrat programovací jazyk.
• Horší možnosti debuggingu.

Co s tím? Odpověď je jednoduchá a tradiční: využít práce jiných programátorů a použít framework. Chtěl bych v následujícím textu projít několik frameworků. Nejprve ale jednoduchý případ užití, který najdete v každém internetovém autobazaru – a to spřažená komba pro výběr značky a modelu auta:

Jde o to, aby se po výběru značky nabízely jen odpovídající modely aut. Jsou tři možnosti řešení:

• serverové – po výběru značky překreslí celou stránku
• javascriptové – po výběru značky JavaScriptový kód prohodí obsah komba s modely
• AJAXové – po výběru značky odešle požadavek na data na server a stáhne z něj modely aut.

Aplikační server je výkonná vrstva ve třívrstvé architektuře. V javovém světě se pod pojmem aplikační server myslí běhové prostředí s podporou EJB. Zkusme se na chvíli povznést nad oba zažité pojmy a představme si, že aplikační server je prostě prostředí pro běh serverové aplikace. Ano, přesně to je Spring Framework. (V dokumentaci ovšem najdeme označení Application Framework). Pojďme se na něj krátce podívat.

Jednou z knihoven, kterou vaše aplikace „musí mít“, je knihovna pro logování Log4J. Každá aplikace, která je víc než jen školní úlohou, by měla kvalitně logovat. Co znamená kvalitně? V přiměřené míře podrobnosti (aby bylo možné najít chybu), ale zároveň v přiměřeném objemu (aby logovací soubory neúměrně nenarůstaly). Aby bylo možné logovat podle různých politik (jeden nebo víc souborů a jejich rotace, logování do databáze atp.) Všechno tohle a ještě mnohem víc knihovna Log4J umožňuje. Nejde o složitou knihovnu, přesto její naučení a pochopení její vnitřní logiky chvíli trvá.

V následujícím článku nechci Log4J dopodrobna rozebírat, ale rád bych tuto knihovnu přiblížil začátečníkům.

Pokud na něco z „dřevních dob DOSu“ opravdu nerad vzpomínán, tak to jsou převody mezi kódováním českých znaků v textech. V té době existovalo a reálně se používalo několik standardů:

• kódování bratrů Kamenických bylo oblíbené v DOSových aplikacích. Výhodou bylo, že text byl čitelný i na zařízení, které češtinu neumělo.
• KOI-8 byl oficiální „východní“ standard, nikdy jsem se s ním nesetkal.
• CP852 bylo oficiální kódování češtiny pro DOS.
• windows-1250 je kódování od MS, které přišlo s Windows.
• ISO Latin 2/ISO 8859–2 se používá v Unixech.

Naštěstí se situace od těch dob zlepšila. Nevím, jestli za to může globalizace, sjednocování Evropy nebo šíření internetu, ale konečně lidé chápou, že počítače mohou také sloužit ke komunikaci… v každém případě mají (nejen) programátoři a administrátoři situaci snažší než dřív.

Možná vám bude připadat divné, proč mít nainstalovaného na serveru webového klienta k Subversion. Vždyť existuje mnoho nástrojů k tomuto verzovacímu systému, nemluvě o integraci do IDE. Přinejmenším dva důvody by tu však byly, oba vycházejí z webové podstaty tohoto klienta:

1. Můžete poslat odkaz mailem na konkrétní soubor zdrojového kódu či jeho verzi
2. Nemusíte si nic instalovat, nemusíte checkoutovat…

Webový klient, který bych vám chtěl ukázat, je Sventon. Jde o klienta napsaného v Javě a vydaného pod licencí BSD.