This week I got a simple request from our customer – to count plays of videos embeded at their site. We currently support different kinds of players – from FLVs interpeted by JwPlayer, Vimeo, Czech Stream.cz to YouTube movies. The task was so simple that I (fool) made a prototype only for FireFox and estimated at most few hours for the implementation. I couldn’t have been dumber …
Web
Partial update neboli částečná aktualizace stránky (pomocí AJAXu) není technika zrovna nová. Po pravdě řečeno však stále není běžná, přestože její správné použití může velmi pozitivní dopady na celkový výkon systému a také je velmi dobře přijímána uživateli. Na otázku proč, můžeme odpovědět problematickou podporou ve frameworcích – některé se na jedné straně snaží o maximální odstínění programátorů od JavaScriptu, čímž z dané techniky dělají věc více méně magickou – jinde naopak použití vyžaduje větší než malé znalosti „skriptování“, což zase většinu Javistů, paradoxně, vyřadí ze hry.
V tomto článku si vysvětlíme základní principy, které jsou s touto technikou spojovány a ukážeme si je na příkladech živé aplikace. Způsob jakým jsme tuto techniku implementovali my, by se měl přibližovat k vlastnímu jádru věci, takže by vám měl být princip zřejmý.
O autorovi: Jetyho blog | LinkedIn
Pavel Jetenský se věnuje Java/J2EE vývoji již od roku 2003, z toho několik let v Irsku. Zajímají ho techniky automatického testování. V současné době pracuje jako metodický vedoucí Java/J2EE v Deltax Systems a.s.
Občas při tvorbě automatických testů potřebujeme otestovat funkcionalitu, která stahuje nějaká data z Internetu. V mém případě to byla funkce na stahování seznamu zneplatněných certifikátů (CRL). Původně jsem měl automatický test napsaný tak, že se seznam skutečně stahoval. To bylo nevýhodné ze dvou důvodů:
- test nefungoval bez připojení k internetu
- těžko šlo ovlivnit v rámci testu stahovaná data
Napsal jsem si tedy jednoduchou implementaci HTTP serveru, která publikuje soubory z classpath pod stejnou relativní cestou na localhost adrese. Např. soubor s CRL umístěný v src\test\resources\crl\emptyCrl.crl je po spuštění serveru ke stažení na:
http://localhost:8001/ResourcePublishServer/crl/emptyCrl.crl
V předchozím článku jsme si ukázali vylepšení iBatisu v souvislosti s XML deklaracemi. Tento navazující článek rozebírá novinky v oblasti Java API. Základem pro toto rozšíření se staly vlastnosti dostupné od verze Javy 1.5 – tedy generiky a anotace. Jednou z velkých kritik původního iBatisu bylo množství XML, které bylo nutné psát. Našlo se mnoho lidí, kterým tento přístup vadil a kteří by spíše uvítali mít vše na jednom místě v kódu. Autoři tyto kritiky vyslyšeli a vytvořili plnohodnotné API, před které je možné využít libovolnou funkcionalitu iBatisu.
Před tím, než se pustím do rozebírání detailů bych se s Vámi rád podělil o jeden velmi zajímavý úryvek z dokumentace, který má s výše uvedeným souvislost:
Java Annotations are unfortunately limited in their expressiveness and flexibility. Despite a lot of time spent in investigation, design and trials, the most powerful iBATIS mappings simply cannot be built with Annotations – without getting ridiculous that is. C# Attributes (for example) do not suffer from these limitations, and thus iBATIS.NET will enjoy a much richer alternative to XML. That said, the Java Annotation based configuration is not without its benefits.
Zdá se mi to jen nebo se povzdechy nad rigiditou Javy stávají normálním trendem?
Absolutním Cimrmanovým rýmem začínám další ze série článků o Javascriptu. V něm bych chtěl rozebrat pár postřehů při práci s časovači (timery) v JavaScriptu. Ty se používají k lecčemu – při jQuery animacích, zobrazování aktuálního času, periodickém dotazováním serveru atp. Intuitivně jsme vždycky tušili, že jejich časování nemusí být úplně přesné, ale přesto jsme hrubě podcenili význam pro aplikaci, pro kterou je aktuální čas zásadní.
Stáli jsme před relativně jednoduchým problémem. Odpočítávat čas do okamžiku T a vypočítávat slevu v ceně na základě času, který do okamžiku T zbývá. Samozřejmě všechny údaje (ať čas nebo cena) musely být u všech klientů naprosto stejné a musely se měnit každou vteřinu. Tento jednoduchý problém nás ale docela potrápil a proto vznikl tento článek, který by měl zachytit problémy a jejich řešení.
Tento článek mám ve WordPressu rozepsaný snad už rok. Jeho původní název zněl „ResourceBundle – stačí Javě beze změny?“. Plno věcí, které jsme původně jako Java vývojáři dělali my, postupně uzpůsobujeme tak, aby je mohli dělat web designeři. Na prezentační vrstvu zcela jistě patří lokalizované texty a zprávy, pro které standardně používáme ResourceBundly Javy, které se načítají z property souborů. Ideální model pro web developery je iterace: navrhnu stránku, vložím text do property bundlu, uložím, reloadnu stránku a kouknu jak to vypadá. V tomhle jednoduchém scénáři jsme však narazili hned na několik problémů.
Standardní PropertyResourceBundle se obvykle získává takto (to je mmch. cesta zmíněná v dokumentaci ResourceBundle):
ResourceBundle myResources =
ResourceBundle.getBundle("MyResources", currentLocale);
Takto načítaný property soubor („MyResources.properties“) musíme mít na classpath (kde samozřejmě není editovatelný) a musíme jej mít ve Ascii formátu zkonvertovaný utilitou Native2Ascii. Dalším problémem je sekvence, ve které se hledají konkrétní lokalizované varianty bundlu. Díky tomu, že Java původně vznikla hlavně pro desktopové aplikace se do posloupnost hledání bundlů dostává i bundle pro systémové locale stroje, na kterém aplikaci spouštíme. V případě volání metody getBundle s Locale(„cs“,“CZ“) se na anglickém Ubuntu hledá property bundle v této posloupnosti:
- messages_cs_CZ.properties
- messages_cs.properties
- messages_en_US.properties
- messages_en.properties
- messages.properties
Tuto věc jsem ještě před rokem nevěděl, a to možná také proto, že není nijak zmíněná v dokumentaci Javy.
Tak se nám těch problémů nakonec sešlo docela dost – na to, že řešíme takovou hloupost jako je lokalizace – že?
V minulém článku, ve kterém jsem se zabýval JavaScript Closures, jsem se zmiňoval o tom, že mě k jejich studiu donutilo používání efektů z knihovny jQuery. Také jsem sliboval, že o svých zkušenostech něco málo napíšu v dalším článku. Nuže směle do toho.
jQuery je obecná knihovna obalující odlišné implementace (více než odlišnosti jazyka, míním odlišnosti práce s DOM reprezentací) JavaScriptu v běžně používaných prohlížečích. Efekty jsou pouze její minoritní částí, kterou možná většina vývojářů pracujících s jQuery ani nevyužívá. Jelikož jsem hračička, koketoval jsem s efekty už od první chvíle, kdy jsem s jQuery začal. Z globálního pohledu musím říct, že mě překvapuje, že tyto efekty fungují velmi dobře skrze všechny podporované prohlížeče a kupodivu jsou poměrně svižné i na pomalejších počítačích (pomalejšími mám na mysli, průměrný počítač koupený před 3-4 lety). Základní použití je velmi jednoduché a zvládne ho i člověk, který s JavaScriptem a jQuery teprve začíná. Kromě základních efektů dodávaných přímo jako součást jQuery Core (show, hide, toggle, fadeIn, fadeOut, animate), je k dispozici ještě oficiální dodatečná knihovna s widgety a dalšími effekty známá jako jQuery UI (zde najdete řadu dalších pěkných efektů, které byly kdysi součástí js knihovny interface.js).
Pokud máte zájem o to shlédnout některé z animací, které jsme pro naše zákazníky vytvořili, zde nabízím pár odkazů:
-
Moje Firma – web Komerční Banky zaměřený na podnikatelskou sféru
- v části podnikatelská poradna jsme využili efekty k odeslání formuláře s daty na server bez reloadu celé stránky, efekt si můžete bez následků vyzkoušet pokud se pokusíte odeslat prázdný formulář – výsledkem bude animace, která vám zobrazí chyby, které ve skutečnosti generuje server v odpovědi na odeslání formuláře (žádné JS kontroly
)
Update 29.10.2010 Odkaz již není funkční
- v části podnikatelská poradna jsme využili efekty k odeslání formuláře s daty na server bez reloadu celé stránky, efekt si můžete bez následků vyzkoušet pokud se pokusíte odeslat prázdný formulář – výsledkem bude animace, která vám zobrazí chyby, které ve skutečnosti generuje server v odpovědi na odeslání formuláře (žádné JS kontroly
-
TROTINA AUTO, s.r.o. – stránky prodejce ojetých vozidel ve Východních Čechách
- vyzkoušejte si třeba vložit pár vozidel na parkoviště, vybrat ve vyhledávání terénní vozidla, v detailu vozidla odeslat doporučení příteli apod.
- kapitolou samou o sobě je potom Dražba na ruby, kterou si můžete vyzkoušet je v případě, že je nějaká aktuálně vypsaná – zde se veškerá logika aplikace odehrává v podstatě jen na dvou obrazovkách a zbytek je řešen AJAXem s využitím jQuery efektů
Javascript používám několik let, snad už od doby kdy jsem na univerzitě začal koketovat s webem. Celou dobu ho používám jen na jednoduché skriptování bez ambic na jakýkoliv propracovanější programovací model. S nástupem kvalitních frameworků jako je třeba jQuery, PrototypeJS, MooTools, Script.aculo.us a další, je člověk přinucen ponořit se do tajů JavaScriptu hlouběji a narazí na věci o kterých se mu před tím ani nesnilo. V tomto článku bych se s vámi rád podělil o pár zkušeností a především odkazů na kvalitní články o tzv. Closures v JavaScriptu. Dopředu upozorňuji, že nejsem žádný JavaScript guru a že čerpám především z odkazovaných článků a z několika projektů, kde jsem díky jQuery a DWR s closures přišel do styku.
Templatovací jazyky v Javě mají poměrně dlouhou minulost. První a zřejmě nejznámnější jsou JSP, které jsou součástí javy. Jsou nejstarší z rodiny templatovacích jazyků a přestože jsou masivně používány dodnes, mnoho lidí k nim má své výhrady:
- psaní JSP je obtížné pro ne-java programátory – přestože původní myšlenkou bylo, aby JSP psali odborníci na web (tedy „webdevelopeři“) tato myšlenka zcela jistě minula realitu; praxe je taková, že JSP píší z různých důvodu opět Java developři, jejichž je jednak nedostatek a jednak jejich zaměření je spíš na aplikační kód než na validitu a použitelnost HTML výstupu
- JSP stránky nejsou použitelné, díky životnímu cyklu JSP (JSP -> .java -> .class), mimo servletový kontejner – to znamená, že teprve servletový kontejner po nadeployování web aplikce JSP převede na implementace Servletů a přeloží je do binární podoby. Dopady tohoto mechanismu jsou poměrně jasné
- JSP stránky mají své pevné umístění – hledají se vždy na filesystemu v adresáři web aplikace; nelze je umístit na classpath (a učinit je tak součástí přenositelných knihoven), nelze je načítat z jiného zdroje – např. databáze (a umožnit tak vznik nových stránek za běhu na systémech, kde nemáme přístup na filesystém), nelze definovat jakoukoliv složitější logiku načítání stránek krom dodání Erorr 404 stránky (např. custom logika ve smyslu neexistuje-li primární šablona, použij záložní, neexistuje-li ani ta, zobraz chybu)
- JSP stránky není možné jednoduše testovat – jejich výstup získáme teprve až dotazem na servletový kontejner
- JSP nelze použít pro skládání jiného výstupu než do web browseru – např. pro skládání těl emailů musíme volit jiný templatovací engine
- debugování JSP nebylo poměrně dlouho možné a ani dnes to není zcela samozřejmá a jednoduchá věc (co se setupu týče)
- chybové hlášky JSP stránek jsou při určitém (často standardním) nastavení kontejnerů nečitelné (vztahují se k vygenerovaným servletům a nikoliv k původní template) – změna tohoto nastavení typicky vyžaduje stop/start kontejneru
- JSP stránky díky možnosti psaní scriptletů vybízejí k míchání aplikační logiky do prezentační vrstvy – s tím se myslím setkal každý z nás a leckdo se k tomu někdy i uchýlil
- v případech některých kontejnerů je při změně JSP a požadavku na její opětovné vyrenderování znatelná časová prodleva – kompilace JSP vyžaduje nějaký čas (možná se jedná jen o zlomky vteřiny, maximálně vteřiny, ale při ladění nějakých drobnostní na stránce se jakákoliv prodleva počítá)
Reakcí na zmíněné nevýhody byl vznik interpretovaných templatovacích jazyků. V tomto příspěvku bych se chtěl podívat na zoubek dvěma nejznámnějším – Apache Velocity a FreeMarkeru.
V odkazech na sledované blogy se mi objevil Blog v pavučině, který píše můj kolega z web designerského oddělení Forrestu. Blog je zaměřen na JavaScript a webdesign, což je oblast, kterou možná jako Javisti orientovaní na web nemáme úplně rádi, ale je pro naši práci nezbytně potřeba (i když s nástupem jQuery se můj pohled na JavaScript radikálně změnil 
). Vypíchnu jen pár jeho článků a názor si udělejte sami:
- Seriál o regulárních výrazech v JavaScriptu – vyšlo také na www.interval.cz
- Loading… animace na pár kliknutí – rozřešení záhady, kde se neustále berou nové verze „loading“ animací
- jQuery: AJAX load a cache – IE a cache, kapitola sama pro sebe
- Textarea de Luxe – luxusní TextArey pro editaci zdrojového kódu
- Alternativní scrollIntoView() pro IE
- Rozlišení CSS stylů pro různé verze Internet Exploreru
Přeji příjemné čtení.
