pondělí 13. října 2008

Apache Wicket - IBehavior, Tabulky

Minule jsem psal o možnosti spojení Wicketu s EJB3 a o Wicket Security. Dnes se podívám na další vlastnosti a možnosti tohoto webového frameworku.

IBehavior

Jedná se o interface, který je označován jako druh pluginu wicket komponent. Já jsem dané řešení využil například pro statistiku návštěvnosti či pro zjistění, jak dlouho trvalo vyrendrování wicket stránky.

Příklad, pro zjištění doby trvání vyrendrování wicket stránky:
public class TimeBehavior extends AbstractBehavior {
private long start;

@Override
public void beforeRender(Component component) {
start = System.currentTimeMillis();
}

@Override
public void onRendered(Component component) {
super.onRendered(component);
long dobaBehu = System.currentTimeMillis() - start;
// dalsi zpracovani
}
}


Třída je potomkem AbstractBehavior, což je adaptér pro interface IBehavior. Tuto implementaci stačí poté přiřadit v "BasePage" (základní Wicket Page, která je předkem všech Page). Samozřejmě, pro Wicket je Page komponenta stejně jako např. TextField. Proto je možné daný plugin přiřazovat i daným komponentám uvnitř Page, Panel, atd.

Možností, jak využít toto rozšíření pro komponenty je mnoho. Pomocí této vlastnosti se například dá z klasického input fieldu vytvořit zadávací políčko s kalendářem pro datum, atd. Stačí implementovat metodu "onComponentTag" a tu patřičně upravit. Tato funkcionalita s kalendářem je již přímo implementována (viz. wicket-datetime: DatePicker).

Tabulky

Každý webový intranetový systém se z velké části točí okolo poskytování dat v jasně specifikované formě. Nebo chcete-li: "hromada tabulek s vlastní filtrací". K tomuto účelu poskytuje Wicket přímo vlastní komponenty, viz: repeater example.

Do nedávné doby existoval web: inmethod.com, který danou funkcionalitu rozšiřoval o vlastní druh tabulek. Tato implementace byla zatím asi to nejlepší, co jsem v oblasti webu a webových frameworků viděl.

Tabulky mají statické sloupce a posuvný obsah (ala excel), možnost řazení sloupců, přesun sloupců, změnu velikosti sloupců, atd.

Příliš nechápu proč, byl tento projekt ukončen (zřejmě jako ostatní: nedostatek volného času). Naštěstí je ale možné si přes svn stáhnout zdrojové kódy, které lze použít. Je k dispozicii živá ukázka.

Daný projekt je psán vůči verzi 1.2. Pro verzi 1.3.x není k dispozici alternativa. Osobně danou knihovnu pro verzi 1.3.3 využívám, ovšem s tím, že jsem dané zdrojové kódy musel částečně upravit. Pokud by měl někdo zájem, mohu mu upravenou knihovnu zaslat.

Danou implementaci lze samozřejmě dále rozšiřovat. Stačí se například podívat jak je definována třída: "com.inmethod.grid.column.PropertyColumn".

Příště ukáži, jak lze snadno tvořit znovupoužitelné komponenty v Apache Wicket.

pátek 19. září 2008

Trocha dávky Apache Wicket

Od posledního příspěvku na tomto blogu již uplynula nějaká ta doba. Nebudu tvrdit, že jsem neměl čas. Důvodem byla spíše chuť něco nového napsat. To je ovšem pryč, takže se vrátím zpět ke svému psaní :)

Apache Wicket je zajímavý hned z několika důvodů. Některé z nich jsem prezentoval minule a proto dnes přidám snad jediný důvod: baví mě v něm psát aplikace.

Každý, kdo má alespoň obecnou znalost tohoto frameworku, musí si daný způsob ihned spojit s psaním aplikací ve swingu. Asi bych to vyjádřil slovy: piš to jako ve swingu a přidej k dané třídě html soubor.

Wicket a EJB3

Dají se tyto dvě technologie jednoduše spojit? Repektive dá se snadno zařídit závislost wicket komponenty na EJB servisní beaně? Ano dá. Stačí stáhnout wicket-contrib-javaee.

Pro schopnost provést jednoduché DI (dependency injection) přes anotaci @EJB je třeba definovat referenci ve web.xml.
<ejb-local-ref>
  <ejb-ref-name>cz.irminsul.javaee.ejb3.ServiceLocal</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>cz.irminsul.javaee.ejb3.ServiceLocal</local>
</ejb-local-ref>

Při definici ejb-ref-name používám celý název daného rozhraní. Důvod je ten, že poté nění třeba při definici DI uvádět @EJB(name="reference"). Výsledné DI vypadá následovně:
public class MyPage extends Page {
 @EJB
 private ServiceLocal service;
 ....
}




Wicket a Security

Existuje několik možností, jak definovat security. Já osobně jsem zvolil WASP. Toto řešení je postaveno na rolích (i když spíše záleží na způsobu implementace). Je zde několik důležitých kroků k uspěšnému nasazení.

1. Definovat vlastní .hive soubor

2. Base page musí být potomkem SecureWebPage

3. Wicket Session musí být potomkem WaspSession

4. Application class musí být částečně upravena (viz příklady na daném WASP webu)

5. Musí se definovat vlastní LoginContext a Principal

Nebudu zde rozepisovat jednotlivé kroky. Dané příklady lze najít na odkazovaném webu pro WASP. Uvedu jen to zajímavé:

Definice oprávnění lze použít jak na celou page, tak na danou akci, tak na daný model. Z toho lze usoudit, že daný způsob by měl být dostačující k danému použití v jakémkoli scénáři. Celá tato definice je uvedena v .hive souboru, který je poté nastaven v Application class. Samozřejmě daných .hive souborů může existovat klidně více.

U definice oprávnění v .hive souboru lze nastavit, zda se bude daná definice týkat i potomků daných page tříd. Zda je k nějaké page přístup globální, či pro danou roli, atd.

Daný způsob implementace se mi vcelku zamlouvá. Jediné, co bych danému řešení vytkl je to, že dokumentace je téměř nulová. Jediný zdroj informací jsou proto jen příklady, které si lze stáhnout a poté prozkoumat jejich kód.

Tak to by bylo asi vše. Příště ukáži jak lze využít IBehavior či jak je na tom Wicket s nenáviděnými html tabulkami.

středa 16. července 2008

Serial port v Jave aneb RXTX

Jakožto spokojený uživatel linuxu jsem dost odstíněn od windows. Bohužel to sebou přináší i určité problémy, kdy potřebuji portovat aplikaci na windows.

Ano, java je multiplatformní, jenže pouze do chvíle, kdy potřebujete přistupovat k sériovému portu a číst z něj data. K tomuto účelu existuje několik možností, které ovšem v jave znamenají implementovat funkčnost pouze pro daný OS.

Nic není tak černé, a proto existuje možnost, jak donutit vaši aplikaci, aby uměla komunikovat se sériovým portem na více OS. To vše bez nutnosti měnit stávající kód.

Ta možnost je přes RXTX. Kromě klasického COMx umí i LPT či USB.

Samotná implementace je víceméně jednoduchá:

  • nakopírují se příslušné knihovny (u linuxu do usr/lib/ a u windows do jre/bin).

  • přes JNI se zavolají příslušné metody z knihoven daných OS

  • otevře se port, zaregistruje listener a již mohu číst či zapisovat.


Jelikož na notebooku používám redukci mezi USB a sériovým portem, trochu jsem se bál samotného zprovoznění. Opak je pravdou. Přes identifikaci zařízení "/dev/ttyUSB0" jsem byl schopen se spojit stejně jako přes COM1 na windows.

Pro testovací účely jsem si napsal malý prográmek, který se snaží dohledat všechny porty. Podle identifikace je poté možné port otevřít a čekat, zda z portu přijdou nějaká data.

Ke stažení: Testovací program pro poslouchání portů

středa 18. června 2008

Je čas na Apache Wicket?

Záznam diskuze:
L: Ahoj Franto, mám menší problém.
F: Jaký Lumíre?
L: Nevím, který webový framework pro javu je nejlepší.
F: No to je jednoduché. Vyzkoušej těch 40 nejznámenjších a pak se rozhodni.
L: Hmm... :(
Konec.

Ať již člověk navštíví jakoukoli homepage webového frameworku, dočte se, že zvolil dobře. Nejlepší možné řešení, vše jednoduché, perfektně rozšířitelné a v porovnání s ostatními je proste "Number ONE".

Sám jsem již dávno rezignoval na hledání zlaté žíly v podobě nejlepšího řešení. Volbu by mělo ovlivňovat to, jakou architekturu dané aplikace plánuji či jakým backendem aplikce disponuji. I když jsou snad všechny možné kombinace možné (Seam + Spring, Seam + EJB, Wicket + Spring, ...., ne vždy je volba zrovna šťasná. Pokud do hry vložím další možnosti jako volání část aplikace jiným způsobem (např. remote EJB), dostávám již užší skupinu možností.

Z této skupiny, která se vyznačuje volnou vazbou na business logiku, snadnou rozšířitelností a možností souběžného běhu s jiným web kontextem mi zatím nejlépe vychází Apache Wicket.

Ano já vím, stále existuje lepší .... nebo ještě lepší .... a vlastně úplně nejlepší ...... Ale já nemám čas ani náladu zkoumat další desítku možností. Stačí mi ta první desítka :)

Proč Apache Wicket?

  • volná vazba na business logiku

  • žádné xml

  • žádné anotace, které z POJOs dělají komponenty použitelné pouze v daném kontextu

  • téměř čisté html

  • vše je psané v jave, takže refactoring je mnohem snažší záležitost

  • dané komponenty si pamatují předchozí stav, takže tlačítko zpět již nemusí být noční můrou

  • menší zátěž pro server oproti JSF či Seamu

  • psaní aplikace je velmi blízké psaní swingových aplikací

  • dostatek komponent + snadné psaní znovupoužitelných komponent

  • při psaní se skutečně využívá objektově orientovaných principů

  • pro běh není třeba žádného speciálního kontextu (běží stejne v Tomcatu jako v AS)

  • daná aplikace je snadno přenositelná na jakýkoli jiný web kontejner


Asi bych mohl pokračovat dalšími body. Nicméně to, co jsem zde vypsal jsou vlastnosti, které mě přesvědčují o správné volbě.

Co se týče záporů, ty si budu muset nechat na pozdější dobu. Zatím jsem jen nezávislým pozorovatelem daného web frameworku. Každopádně jsem pevně rozhodnut toto řešení použít i za cenu složitejší spolupráce s EJB modulem a částí aplikace napsané v Seamu.

Takže mám 2 favority. Seam a Apache Wicket. Každý z nich přistupuje k cíli jiným způsobem a každý z nich se rozhodně hodí pro jiný typ aplikací. Až si Apache Wicket více osahám pokusím se obě řešení více porovnat a přesněji zjistit, pro jaký typ aplikací se dané frameworky hodí.

sobota 24. května 2008

Testování EJB komponent

Všeobecně známý fakt, že se EJB komponenty špatně testují, je postaven zejména na tom, že neexistuje žádný standardní způsob, jak při psaní testů postupovat. Pokusím se sepsat způsoby, jak tento palčivý problém vyřešit.

O tom, že je testování důležitá část vývoje, nemá smysl polemizovat. V poslední době se na české scéně objevilo několik článků: "proč je testování důležité". Osobně zastávám názor, že bez testů nemohu kód považovat za funkční a jeho nasazení je velký risk, který se násobí následným refaktoringem či řozšiřováním stávajícího kódu.

V následujících odstavcích se budu zabývat jen EJB 3.0.

Způsoby testování bych rozdělil na 2 typy: testování uvnitř aplikačního serveru a mimo něj.

Testování uvnitř aplikačního serveru

Tento způsob má tu výhodu, že dané testy se mohou začít psát bez jakékoli další pomůcky pro inicializaci EJB kontejneru a služeb v něm. Ohromnou nevýhodou je ovšem to, že samotné psaní a spouštění testů je přímo závislé na nastartování a nahrání celé aplikace na server. Tato činnost může při větších projektech trvat řádově i několik minut. V takové chvíli může vývojář získat naprostý odpor k testování.

Způsob, jak testovat EJB komponenty uvnitř AS, je použití vzdáleného volání EJB komponent. Nevýhodou je ovšem to, že při návrhu musíte definovat "remote" rozhraní.

Druhým způsobem je testování přímo v EJB komponentě, kde mohu pomocí DI (dependency injection) získanou EJB komponentu otestovat. Nevýhodou je zde to, že tento způsob již překračuje základní způsoby testování. JUnit či jemu podobný framework je v takovém případě nepoužitelný.

Testování mimo aplikační server

První velkou nevýhodou tohoto řešení je samotný fakt, že nějak musíte nahradit EJB kontejner. Asi nejznámějším řešením je použití Embedded JBoss.Tento způsob vyžaduje, aby vaše aplikace byla schopná běžet pod JBoss AS, a abyste použili JVM 1.5 (na novejších verzích bohužel embedded JBoss nespustíte). Pokud aplikaci vyvíjíte pod jiným aplikačním serverem, budete s tímto mít asi problémy. Například už jen z důvodu samotné nestandardizace JNDI či použitých nekompatibilních vlastností pro Java EE 5.

Druhým způsobem, jak umožnit testování EJB komponent mimo aplikační server je, že použijete framework typu Ejb3unit, který na základě vaší definice EJB komponent sám provede dependency injection a další vlastnosti typické EJB kontejneru. Nevýhoda tohoto řešení spočívá v tom, že má příliš mnoho omezení, která poté mohou zbytečně ovlivňovat návrh business vrstvy. Na stránkách je možné se dočíst, že brzy vyjde verze 2.0, která snad přinese slibované vlastnosti.

Posledním způsobem, jak vyřešit testování, je použití vlastního řešení. Jelikož používám jako aplikační server Glassfish, byl pro mne JBoss Embedded tabu. Jelikož mám i uvnitř EJB komponent občas složitejší architekturu (dělené vrstvy), tak Ejb3unit byl nepoužitelný.

Můj vlastní způsob spočívá v tom, že testuji EJB komponenty, které obsahují vazby na další EJB pomocí anotací @EJB či vstřikují pomocí @PersistenceContext EntityManager (+ občasné delegování na Hibernate Session).

Jinými slovy, řídím EJB pomocí anotací, což mi umožňilo napsat si i vlastní řešení na testování. Moje řešení totiž využívá Java reflection API, přes které provádím jak dependency injection dalších EJB komponent, tak samotné DI EntityManageru a dalších zdrojů, které zrovna potřebuji.

Test poté vypadá jednoduše: "při inicializaci pošlu testovanou EJB komponentu do metody, která mi vrátí instanci samotné EJB komponenty i s inicializací potřebných závislostí".

Zatím jsem nenalezl lepší řešení. Pravdou je, že v této oblasti jsou EJB komponenty nechány napospas vývojářům, což s sebou přináší jen nekompatibilní způsoby testování jednotlivých částí aplikace.

Doufám, že Glassfish V3 přinese slibovanou možnost být "embeddable" v plném rozsahu či někoho v SUNu napadne s tímto problémem něco udělat. Zatím mi přijde, že každý si napíše vlastní řešení, protože kromě JBoss Embeddable jsem nenašel nic, co by alespoň trošku splňovalo mé požadavky.

Pokud má někdo zkušenosti i s dalšími možnostmi testování EJB komponent, nechť se o ně podělí v komentáři, děkuji.

neděle 4. května 2008

NetBeans 6.1 a Facelets plugin

O tom, že vyšly Netbeans 6.1 se nemá smysl zmiňovat. Ovšem výhodou této verze je zejména její rychlost, na kterou se údajně vývojáři nejvíce zaměřili.

Jedna věc mi ovšem zde chyběla. A to opět plugin pro facelets :)

Naštěstí existuje řešení, jak daný plugin dostat do této verze.

Následující text je spíše dočasný, tzn., že  až vyjde oficiální podpora, jistě bude lepší použít přímo ji.

Na stránce https://nbfaceletssupport.dev.java.net/ je k dispozici cvs repozitář. Z daného repozitáře stačí provést checkout projektu a daný projekt "nbfaceletssuite" otevřít v NetBeans 6.1. Dané pluginy poté zbuildovat a provést create nbm. Tyto pluginy jsou poté schopny pracovat ve verzi 6.1.

Pak již stačí pluginy nainstalovat a máte k dispozici starou dobrou (i když ne zrovna plnou)  code completion v xhtml souborech :)

Glassfish V3 bude embeddable

Minulý týden mi v rss čtečce přistál článek od Kohsuke Kawaguchi, že Glassfish V3 bude "embeddable".

Osobně jsem si přesně toto pro Glassfish přál. Představte si, že budete mít EJB projekt, který budete moci spouštět např. v Tomcatu. Že budete moci testovat EJB, aniž by bylo potřeba provádět deploy na server či používat remote call EJB či používat "nepoužitelné" frameworky jako je EJBUnit (i když uvidíme jak dopadne verze 2.0). Vše co obsahuje specifikace Java EE 5 a vše co implementuje Glassfish je tedy možné provozovat aniž by někde musel běžet daný server.

V současné době se touto možností může chlubit JBoss AS či Jetty, nyní již stačí počkat pár měsíců (možná týdnů do testovací fáze) a bude možné to samé dělat s GlassFish.

Díky modularitě tohoto AS je ovšem možné startovat server v řádech několika milisekund, což narozdíl od JBoss AS je podstatný rozdíl :)

Před nějakým časem jsem chtel Glassfish opustit a jít cestou JBoss, ale asi ještě chvíli počkám, je vidět, že konkurenční prostředí je prostě ideální stav.

Teď nezbývá, než držet palce, ať se dané featury dotáhnou do úspěšného konce.

Když programátor založí a řídí firmu

Jako malý jsem chtěl být popelářem. Ani ne tak proto, že bych měl nějaký zvláštní vztah k odpadkům, ale hrozně se mi líbilo, jak...