Myšlenky dne otce Fura

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

(more…)

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?

(more…)

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í.

(more…)

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):

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:

1. messages_cs_CZ.properties
2. messages_cs.properties
3. messages_en_US.properties
4. messages_en.properties
5. 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?

(more…)

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 )
• 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ů

(more…)

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.

(more…)

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.

(more…)

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í.

V tomto příspěvku se nechci věnovat popisu zprovoznění jCaptchy v bezpečnostní frameworku Acegi Security, jelikož toto je velmi dobře popsáno již v existujícím článku na MoroSystems weblogu. Spíš se chci zaobírat způsobem, jakým se k integraci do Acegi frameworku autoři postavili. Tento způsob mi přijde totiž přinejmenším neobvyklý. Zachovává sice zavedené principy Acegi, ale ten neodpovídá mým (ale řekl bych vcelku přirozeným) představám o tom, jak by měla captcha ve web strákách fungovat.

Princip práce s captchou v Acegi je podobný principu standardního přihlašování. Acegi při přístupu na “chráněné url” kontroluje ověření uživatele v SecurityContextu a pokud uživatel není ověřen, přesměruje tok aplikace na přihlašovací formulář nebo v případě captchy na formulář obsahující obrázek a textové pole pro vepsání rozpoznané captchy. Pokud řešíme přihlašování, je tento způsob přirozený – v případě captchy však očekávám, že captcha bude rovnou součástí formuláře, který je “hlídán”. Tak ale integrace jCaptchy v Acegi ve svém základu nefunguje.

Pokud Vám tento způsob připadne taky trochu podivný a zajímá Vás, jak si s tím poradit, čtěte dál.

(more…)

Though most of articles at this blog are written in my native language – Czech, this one will be different. I have chosen an English to address wider community of Stripes developers – I think there would’nt be enough readers in our beautiful small country. So, please, excuse possible errors and mistakes in the article, I will try my best .

Common introduction to AJAX in Stripes

Stripes framework offers basic but sufficient support for AJAX that is covered with article at official web site. Article recommends using commonly known PrototypeJS AJAX client side library. On the server side, request is processed by Stripes themselves by standard population and execution as any other http request (that means that data from client to server are sent as a standard URL encoded parameters). What you get is correctly populated and validated action bean – and until now you haven’t even recognize, that request is made by JavaScript on the client side not even you have to care of it. You can access session, exchange cookies and so on.

(more…)