Richfaces pro JSF

Komponentový framework jakým je JSF, má několik kladů, mezi kterými také nalezneme možnost rozšíření o vlastní komponenty. I když psaní vlastních komponent pod JSF není zrovna triviální záležitost.

JSF ve verzi 1.2. nabízí základní komponenty, které mohou být i rozšířitelné, ovšem ne vždy nám vyhovují.  Existence různorodých komponent za nás řeší knihovny třetích stran, které nabízejí zajímavé možnosti. Mezi nejčastějšími požadavky na komponenty jsou různé formulářové objekty, modální panely, stromy, menu, tabulky, atd. Navíc je očekávána podpora AJAXu. Jinými slovy, komponenty, které se svou vizuální a funkční podobou blíží desktop aplikacím.

Pro srovnání různých komponentových knihoven můžeme použít např. AJAX JSF Matrix. Možnost výběru je skutečně obrovský a to nepočítám další, které vznikají téměř každý den.

Samotná volba není zrovna jednoduchá. Já jsem prošel asi 3 různé knihovny z nichž jsem si vybral jasného favorita: RichFaces.

RichFaces

RichFaces má v současné době v  rukou JBoss. Jedná se klasickou JSF komponentovou knihovnu, která ovšem navíc obsahuje i přímou vazbu a podporu A4J (Ajax4JSF). A4J, jak už její název vypovídá se zaměřuje čistě na AJAX a snaží se naučit JSF komponenty asynchroní práci. Jelikož je RichFaces společně s A4J dodávaná jako jedna knihovna (projekt), může nás těšit fakt, že máme jednu z nejlepších kombinaci mezi AJAX-JSF-Komponenta.

V současné době je RichFaces ve verzi 3.2.0, která vyšla vcelku nedávno. Mezi jejími novinkami můžeme najít věci jako: vlastní combo box, progress bar, file upload, atd.

I když je pravda, že s každou novou verzí můžeme nalézt v bugtraceru hromadu opravených a hromadu nový bugů, přesto je tato knihovna použitelná v produkčním nasazení.

Mě nezbývá, než tuto knihovnu doporučit všem, kteří nemají svého favorita a hledají nejakou slušnou podporu pro JSF komponenty. Psát modální okna, kontextová menu či rozbalovací stromy už nemusí být jen výsadou programátoru desktop aplikací.

Pro zběžný přehled doporučuji samotné demo, které je plně přístupné po zaregistrování na RedHat stránkách, kde si jednotlivé vlastnosti můžete ihned vyzkoušet.

Seam - tipy a triky (EJB)

Seam je dobře použitelný s EJB, kde jsou jednotlivé EJB vystaveny jako Seam komponenty a navíc obsahují všechny služby, které EJB kontejner nabízí.

Jsou ovšem chvíle, kdy bych potřeboval obyčejnou Seam komponentu a do ní nějakým způsobem vstříknout EJB beanu. Co se týče implementaci pro glassfish, není situace tak jednoduchá, jak by se mohlo zdát.

Takže, mějme příklad, kdy potřebuji vytvořit Seam komponentu, která bude míti jednu metodu, která bude vracet seznam hodnot z nějaké entity.

Klasický přístup by mohl vypadat následovně:

@Name("testList")
public class TestList {
   @Unwrap
   public List<Entita> lookup() {
      return entityManager.createQuery("from Entita e").getResultList();
   }
}

Použití ve facelets stránce by poté vypadalo následovně:

Pravdou je, že použití samotné anotace @Unwrap může mít hezké uplatnění.

Jenže, osobně se mi nelibí možnost, že musím uvnitř samotného "testListu" volat entity manager a navíc psát nějaké OQL. Mám již definovanou DAO vrstvu pomocí EJB a chci lookupnout samotnou EJB jako Seam komponentu.

K tomtuto účelu jsem si vytvořil jednoduchou lookup službu, která vypadá následnovně:

@Stateless
@Name("lookup")
@Scope(ScopeType.APPLICATION)
@Interceptors(value = {SeamInterceptor.class})
public class LookupBean implements LookupLocal {

     @Resource
     private EJBContext context;

     @EJB
     private SessionLookupLocal sess;

     public Object ejb(String bean) {
          return context.lookup(bean);
     }

     public EntityManager getEntityManager() {
          return sess.getEntityManager();
     }

     public Session getSession() {
          return sess.getSession();
     }

}

Takže lookup služba slouží k získaní jak EJB beany tak entity manageru popřípadě Hibernate Session. Dá se sice namítnout, že Seam umí přímo injectnout EntityManager (dokonce se to dá hackem zprovoznit i v glassfish), ale já si raději vsrtvy odděluji, proto injectuji daný "persistence provider" jen v nejnutnějších chvílích. Druhou věcí je fakt, že daný provider pro persistenci přenáší jiná EJB beana. Důvodem je fakt, že při inicializaci a vytvoření Seam komponenty ještě není znám provider pro entity manager, proto ho musím získat z jiné EJB.

Ale zpět. K tomu, aby daná lookup služba (která je jak Seam komponentou tak EJB komponentou) byla schopná lookupovat EJB, musí být navíc definovana reference na dané EJB beany v ejb.jar.xml, nebo pomocí anotací. Já jsem zde raději přistoupil k možnosti pomocí XML, jelikož se jedná o speciální požadavek, který se v průběhu života může změnit.

    
        
            LookupBean
            cz.irminsul.seam.app.LookupBean
            
                NejakaDAOBean
                cz.irminsul.NejakaDAOLocal
                NejakaDAOBean
            
        
    

Díky této definici reference mám možnost uvnitř lookupBean získávat ejb dynamicky, tedy přes initialContext.

Konečné použití uvnitř Seam komponenty, která není EJB beanou, může vypadat následovně:

@Name("testList")
public class TestList {     

     @In(value = "#{lookup.ejb('NejakaBean')}")
     private NejakaLocal bean;

     private List<Entita> data;

     @Unwrap
     public List<Entita> lookup() {
          if (data == null) {
               data = bean.metodaLokalnihoInterface();
          }
          return data;
     }

}

Samozřejmě je možné získat i Entity Manager či Hibernate Session. Použití je v podstatě jasné:

@In("#{lookup.entityMananger}")
private EntityManager em;

Daný návod je funkční v Seam 2.0, EJB 3 a Glassfish V2.

DTO a ORM

Pojem DTO jistě není třeba představovat. Jedná se o objekt reprezentující data, které je třeba přenést z jedné strany na druhou. Asi nejčastějším využitím jest výsledek dotazu z persistentní vrstvy.

Při použití ORM frameworku, jako je např. Hibernate, definuji data v DB pomocí objektů (entit). Tyto entity poté mohou být i výsledkem, tedy mohou představovat jak doménový model aplikace, tak i dané DTO. Jsou ovšem chvíle, kdy takové DTO je nepoužitelné či jeho použití může znamenat výrazný pokles výkonnosti aplikace.

Prvním příkladem, kde entita nemůže (neměla by) být reprezentována jako DTO:
"Vytvoř seznam zaměstnanců s celkovým počtem odpracovaných hodin."
V takovém případě je třeba výsledek z OQL přemapovat do vlastního objektu (DTO), který bude obsahovat číslo, jméno, příjmení, celkový počet hodin. Sice by někdo mohl namítnout, že daná hodnota (odpracované hodiny) se dá do entity, jako @Transient, přidat. Ale doménový model bych se neměl "špinit" vlastnostmi, které reprezentují pouze výsledek nějakého dotazu.

Druhým příkladem je distribuovaná Java. Jinými slovy řečeno, ve chvíli, kdy vzdáleně volám remote EJB, by výsledkem mělo být pouze to, co skutečně potřebuji. Nikoli anotovaná entita, která obsahuje mapované kolekce a dalších X vlastností, které mě v té chvíli nezajímají. Dodržení této zásady bude mít pozitivní vliv na výkon aplikace.

Důvody, proč je někdy lepší použit DTO namísto entity, jsem uvedl. Nyní ovšem přichází otázka, jak takové DTO přemapovávat z OQL dotazů a jak si co nejvíce ušetřit nudného psaní kódu.

První možností je použití klauzule new z JPA. Takové OQL by mohlo vypadat následovně:

public List getList() {
   String oql = "SELECT new ZamPocetHodin(z.cislo, z.prijmeni, z.jmeno, x.vypocetHodin) FROM Zamestnanci z .....";
   return entityManager.createQuery(oql).getResultList();
}

Jak je na první pohled patrné, je třeba, aby objekt "ZamPocetHodin" obsahoval konstruktor, který obsahuje dané parametry podle daného OQL.
Tento způsob má vesměs samé nevýhody. Osobně mi asi nejvíce vadí samotná absence jakéhokoli refactoringu. Myslím, že v dnešní době neexistuje IDE, které by dokázalo poznat OQL dotazy a validovat je. Dále mi vadí, že parametrem v konstruktoru DTO může být pouze omezený výčet typů. Není možné vracet jiné Entity, či je nějak dále přemapovat. Poslední věc, která se mi nelíbí, je fakt, že píši zbytečně mnoho kódu. Někde definuji DTO a někde ho musím plnit a přitom stále hlídat, zda se mi něco nezměnilo.

Druhou možností je plnění pomoci Hibernate Criteria API:

criteria.setProjection(Projections.sqlProjection(sql + " AS " + alias,
                new String[]{alias},
                new org.hibernate.type.Type[] {TypeWrapperImpl.getType(/* type */)}));
criteria.setResultTransformer(Transformers.aliasToBean(ZamPocetHodin.class));

Uvedl jsem jen malý kus kódu, který úplně nedpovídá všednímu použití, ale jde o to, že dost často je hodnota v DTO reprezentována nějakým poddotazem, či jiným způsobem, které SQL umožňuje. Je pravda, že v Hibernate Projections si vše mohu dobře nadefinovat, ale výsledkem je poté naprosto šílený kód, který je sice "dynamičtější" a "programovější" než je tomu u JPA, ale za to je složitější.

Jelikož mi nevyhovuje ani jeden z daných způsobů, snažil jsem se nalézt nějaký vhodný způsob, jak se zbavit toho nudného či složitého psaní na přemapování do DTO.
Po pečlivém rozmýšlení jsem se rozhodl, že by nebylo špatné nahlédnout na danou věc stejně jako v případě mé implementace "Irminsul Criteria". O co vlastně šlo, si můžete přečíst zde a zde.
Cílém mého snažení bylo, abych vytvořil DTO objekt, který pomocí anotací nad atributem bude obsahovat dané SQL příkazy, které naplní příslušnou hodnotu. V této chvíli se jedná stále o testování, ale výsledkem mého snažení je již celkem funkční základní část, tedy jednoduché přemapování.

Nyní uvedu malý příklad takového přemapování:

@DTO(entity = EntitaOdkudSeDataZiskavaji.class)
@Aliases(values={
    @Alias(associationPath="strediska.provoz", alias="provoz"),
    @Alias(associationPath="rj.testPolozky.polozka", alias="polozka"),
    .....
})
public class TestDTO implements Serializable {
    @ProjectionSQL("(({polozka}.faktura * {vicePraceMena}.aktualni_kurz) * (procento / 100))")
    private BigDecimal opravy;

    @ProjectionSQL("(({polozkaZakazky}.cena * {mena}.aktualni_kurz) * (procento / 100))")
    private BigDecimal cenaVyrobku;

    @Projection("pk.cislo")
    private String cislo;

    // settry, gettry, atd.
}
List result = factory.findForDTO(TestDTO.class);

Jak je z kódu patrné, jde pouze o klasické POJO, které je anotované, aby implementace pochopila, že jde o DTO, které je spouštěne nad danou entitou (@DTO) a obsahuje ty či ony aliasy, které usnadňuj psaní ProjectionSQL.
K tomuto účelu jsem využil implementace Hibernate Projections a ProjectionsSQL, kde podle jasných pravidel převádím dané anotace na projekci, která je již obeznámena s daným typem a tím, co vlastně daný atribut reprezentuje.

Opěvná píseň

Předem musím poznamenat, že toho dané DTO umí více, jednak je to možnost spojit toto DTO i s Filtr objektem, který jsem popisoval ve výše odkazovaných člancích. Výsledkem je pote jednoduche volání:

List result = factory.findByCriteriaDTO(filtr, TestDTO.class);

Již se tedy nemusím zabývat nutností definování filtru a vrácených dat, oba stavy jsou řízeny anotacemi.

Dalšími možnostmi jsou řazení, získaní hodnoty přes alias, či přes vlastní definici, která může být ve formě SQL či OQL zápisu.

Díky tomu odpadá několik věcí:

• není třeba definovat nějaké metody v DAO


• nemusí se psát žadné přemapování, stačí jen definice DTO


• není třeba hledat, jak se dané DTO plní, je to jasné z jeho definice


• není třeba se bát refactoringu jako v případě implementace přes JPA


• není třeba určovat vrácený typ jako v případě Hibernate, typ je již jasný z definice atributu třídy DTO

Až bude daná funčnost plně funkční, nabídnu své řešení ke stažení. Zatím bych nerad někde publikoval zabugovaný nedodělek :)

Zajímal by mě Váš názor na takovouto implementaci DTO. Je dost možné, že někdo přijde s lepším nápadem či možností, která již dávno existuje a jen já o ni nevím :)

Seam - tipy a triky

Jelikož jsem zastánce tohoto frameworku, z jichž uvedených důvodů, rozhodl jsem se sepsat pár dobrých triků, které mohou pomoci při vývoji s tímto frameworkem. Dnes začnu asi tou nezajímavější a tím je Hot Deploy, nebo-li rychlá aktualizace některých částí aplikace bez nutnosti provádět celé nahrání aplikace na server.

Hot deploy - NetBeans
Netbeans 6.0 má dost slabou, respektive nulovou, podporu pro tento framework. Jednou z dobrých vlastností Seamu je tzv. hot deploy, kde změny na view vrtvě mohou být aplikovány bez nutnosti provádení undeploy-deploy aplikace. Jedná se zejména o změnu facelets stránek. Takže jak něčeho takového dosáhnout v netbeans?

Stačí vytvořit vlastní "ResourceResolver", který se poté zaregistruje v web.xml.
Příklad takového ResourceResolver:

public class FilesystemResourceResolver implements ResourceResolver {
    private static final String PATH_TO_DEVELOPMENT = "/home/ales/dev/java/Irminsul/Irminsul-war/web/";
    public URL resolveUrl(String s) {
        try {
            return new URL("file", "", PATH_TO_DEVELOPMENT + s);
        } catch (MalformedURLException e) {
            e.printStackTrace();
            return null;
        }
    }
}

Poté již stačí uvést registraci do web.xml:

    
        facelets.DEVELOPMENT
        true
    
    
        facelets.REFRESH_PERIOD
        0
    
    
        facelets.RESOURCE_RESOLVER
        irminsulweb.FilesystemResourceResolver
    

Důležitou součástí je to, aby Seam byl spuštěn v debug módu. Toho lze docílit pomocí definice v components.xml:

Díky vlastní definici "ResourceResolver", jsou nyní jednotlivé facelets stránky načítány z cesty, která je uvedena v "PATH_TO_DEVELOPMENT". Pro změnu stačí v NetBeans editovat nějakou facelets stránku, uložit změnu a ve webovém prohlížeči provést refresh.

Tato malá pomůcka je ideální zejména ve chvíli, kdy jednotlivé facelets stránky obsahují různé komponenty (rich faces, ajax4jsf, atd.). Podle toho, co jsem se dočetl v Seam dokumentaci, tak se pracuje i na možnosti provádět hot deploy nad EJB. Otázkou je, jestli tato vlastnost není spíš více ovlivněna aplikačním serverem, než tímto frameworkem.
Takový hot deploy nad EJB se dá sice také provést (v debug modu pro AS), ale jedná se o velice omezené možnosti. Není možné vytvořit novou EJB za běhu, zmenu public metod, atd. Jde tedy čistě o vnitřní implementaci uvnitř business metod. Doufám, že se jednou dočkáme změn i v této oblasti.

Linux pro javistu

Na svých oblíbených weblozích jsem našel několik příspěvků, které se věnovali linuxu, coby hlavnímu operačnímu systému pro programátora. Psal o tom dagi či ronnie. Jeden je v navážkách, druhý utekl zpět k windows.

Abych nebyl výjimkou, rozhodl jsem se, že ho teda také vyzkouším. Linux jako systém považuji za velice úspěšný na serveru, co se týče osobního desktopu, vždy jsem našel něco, co mě přinutilo vrátit se k windows. Dnes již tomu tak není a já se pokusím sepsat vše, co mě monentálně k tomuto tématu napadá.

Proč práve linux?
Není v tom nic speciálního. Na serveru nám běží bez problémů a já si chtěl vyzkoušet, zda by můj notebook nebyl s tímto systémem "rychlejší" a "efektivnější". Nehledám v tom nic převratného, a ani nechci zkoušet něco, abych jen vybočoval z "řady windowsáků".
Linux tedy zkouším čistě ze zvědavosti s nadějí, že objevím něco "užitečného".

Výběr distribuce a HW
Výběr distribucí linuxu je ohromný. Má volba padla na SuSE, jednak s touto distribucí mám trochu zkušenností a jednak ji mám instalovanou i na domácím PC, který funguje jako server.
Samozřejmě, že v "módě" je dnes Ubuntu, ale abych byl upřímný, samotná komunita, alespoň v ČR, mi tak leze na nervy, že jsem zde zaujal šovinistické stanovisko :)
Distribucí je tedy SuSE 10.3 s GNOME.
Co se týče hardwaru, instaloval jsem jej na notebook Toshiba A100-847. Jedná se o 2 jádrový Core 2 Duo, kde jsem pouze rozšířil RAM z 512MB na 2GB.

Instalace
Po rozdělení disku jsem na menší oddíl (cca asi 36GB) nainstaloval SuSE. Samotná instalace proběhla v pořádku a já si mnul ruce, jak vše dopadlo hladce. Jenže, to byl nebyl linux, aby v něm nebyl zádrhel... :)

První setkání
Při prvním pohledu se zdálo, že je vše v pořádku. Bohužel mi nefungovala WiFi a připojení druhého LCD monitoru. Po jistém vyladění ostatních věcí se mi asi po 6 hodinách povedlo rozchodit bezdrátové připojení. Bohužel u monitoru jsem nepochodil. Ani ruční konfigurace xorg.conf nepomohla a já prozatím musel monitor nahradit dalšími plochami.
Při zpětném porovnání mohu tvrdit, že kromě připojení druhého LCD je vše funkční. Samozřejmě se nevzdávám a až bude více času, pokusím se dořešit i to. Většinou vše má své řešení :)

Práce
Jelikož nepobírám mzdu za hraní si s linuxem, ale za vývoj aplikací, tak jsem se pustil do konečného nastavení. Tedy instalace JDK 1.6, Netbeans a Glassfish.
A zde to přišlo. Důvod, proč mě k windows již nikdo nedostane!
Samotný běh NetBeans je rychlejší, super. Ale co je naprosto nepochopitelné, že build&deploy projektu, který ve windows (se stejným nastavením) trvá minutu - minutu a půl, zde trvá asi 14-16 vteřin. Nevěřil jsem vlastním očím. Říkám si, asi bude někde problém v nastavení na windows. Nikoli. I samotný build projektů je prostě rychlejší a to výrazně. Sice jsem neprováděl žádné měření, ale poznal jsem na vlastní kůži, jak je to s rychlostí.

Alternativy k programům
Zde jsem nemusel nic moc řešit. Za prvé používám Javu, která je multiplatformní a za druhé programy, které jsou i pro linux. Zde jsem udělal jejich částečný výčet:

• thunderbird - thunderbird


• opera - opera


• netbeans - netbeans


• pidgin - pidgin


• total commander - midnight commander, gnome commander, muCommander


• launchy - deskbar applet


• putty - ssh

Nic víc ke své práci nepotřebuji. Jediný problém je s tím Total Commanderem. Skutečná alternativa neexistuje. Jediné, co mě čeká je, najít si nejpříjemnější alternativu, kterou zatím nemám.



Závěr
Pokud se nevyskytne skutečný problém, tak mě asi od linuxu již nic neodtáhne. Nemíním tvrdit, že windows je špatný, pouze nevyhovující pro určité typy lidí. Stejné je to i naopak. Ve chvíli, kdy jsem si nakonfiguroval klávesové zkratky, přidal přepínání ploch, zjistil jsem, že jsem shopen i efektivněji pracovat. Windows se spíše drží filozofie myš-akce, já mám raději klávesnici, protože je mnohonásobně rychlejší.
Nakonec nabízím pár screenshotů z mého nového systému:

obrazovka-3-small.png

obrazovka-3.png