26. září 2008

JSF s NetAdvantage - pokračování

Nedávno jsem psal o zkušenostech s komponentami NetAdvantage. Od té doby vyšla nová verze s celkem zásadními změnami, tak bych je rád uvedl.

Hlavní změna je ta, že jsou již podporovány JSF verze 1.2. Vzhledem k tomu, že vývoj naší aplikace je pořád spíše na začátku, tak jsme hned stáhli novou verzi a přešli na JSF 1.2. Přechod byl na 99% úspěšný, snad jen dvě chybky jsme jim tam našli.

Také jsme se rozhodli opustit klasické JSF a přejít na facelets. Zde těch problémů ze strany NetAdvantage komponent je více, některé celkem zásadní, např. nemožnost použití WebChart komponent. Více na stránkách známých omezení (1, 2, 3).

Problém s konvertery, o kterém jsem psal minule ("komponenta ig:dropDownList nefunguje s konvertery"), se nakonec ukázal jako ještě větší a obecnější, který zasahuje přes více komponent, např. dateChooser.



Z mojí mini ankety "Jaký webový framework používáte?" zatím vyplývá, že se JSF používají celkem dost. Mě by hodně zajímalo, zda využíváte pouze open-source knihovny nebo zda máte nějakou zkušenost s jinými komerčními JSF knihovnami?

25. září 2008

Proč JPA, když mi stačí Hibernate?

Většinu projektů jsem v minulosti realizovat pomocí "čistého" Hibernatu (Hibernate Core). Na posledním projektu jsem byl nucen přejít na Hibernate Entity Manager resp. JPA z důvodu použití nástroje JBoss Envers na verzování. Sice to byl pádný důvod proč přejít na JPA, ale pokud bych tento důvod neměl, tak jina žádný důvod pro přechod k JPA nemám, spíše naopak.

Než si začnu stěžovat, tak ještě musím uvést, že píši v kontextu lightweight aplikací. Při použití EJB resp. aplikačních serverů je to zcela jiné, tam vidím velký význam a přínos ve standardizaci rozhraní datové vrstvy.

Zde jsou některé mé stížnosti:

  • JPA toho zdaleka neumí tolik co samotný Hibernate (viz list of all Hibernate extension annotations nebo Hibernate Annotation Extensions).

  • Na předchozí bod je možné namítnout, že mi nic nebrání, abych tyto rozšíření používal. To je pravda, ale proč pak nepoužít přímo Hibernate? Jedna z uváděných vlastností JPA je ta, že je možné vyměnit ORM engine pokud se budu držet JPA specifikace. Má to vůbec smysl? Občas potřebuji vyměnit databázi, ale nevím, kdy bych potřeboval vyměnit ORM engine.

  • Nedávno jsem řešil problém s ukládáním souborů (BLOB objektů) do databáze. Spring nabízí jako vždy pomoc - třída AbstractLobType a její implementace (hezký popis je na tomto blogu). Zde je ovšem podmínkou konfigurovat Hibernate pomocí LocalSessionFactoryBean, tedy používat "čistý" Hibernate Core.

  • Konfigurace Hibernatu přes JPA je trochu přes ruku. Většina věcí se musí konfigurovat přes properties v persistence.xml. Je ale pravda, že nyní (všimnul jsem si toho až v poslední verzi 3.4 Entity Manageru) je možné používat JPA a konfigurovat Hibernate přes standardní hibernate.cfg.xml soubor, viz hibernate.ejb.cfgfile property.

  • Stejnou výtku jako v předešlém bodě mohu mít ke psaní JPQL dotazů. Samotný JPQL sice vychází z HQL, ale takové možnosti nemá. Mohu zase používat HQL, mohu využívat Session, nativní JDBC dotazy, ale vše je to přímočařejší s Hibernate bez JPA.

12. září 2008

Srozumitelnost zdrojového kódu

K dnešnímu psaní mě inspirovat článek s názvem "Four harmful Java idioms, and how to fix them" na serveru JavaWorld. Nedalo mi to, abych k tomu nenapsat něco svého.

Pro ty, kdo to nechtějí číst celé mám zde krátké resumé. Autor článku navrhuje čtyři následující řešení (lépe řečeno reaguje na čtyři celkem rozšířené idiomy) pro lepší čitelnost zdrojového kódu resp. pro jeho lepší použitelnost, pochopení, údržbu:

  1. Konvence pro rozlišení lokálních proměnných, argumentů metod a proměnných tříd. Autor navrhuje použít a jako prefix pro argumenty metod, f pro proměnné třídy a lokální proměnné nechat bez prefixu.

  2. Sdružovat třídy do balíků podle funkcionality a ne podle vrstev. Hlavní myšlenkou je co nejvíce využít zapouzdřenosti jednotlivých balíků (packages) tak, aby balíky sdružovali všechny třídy (entitu, DAO, kontroller, atd.) pro jednu funkcionalitu. Oproti tomu staví běžný přístup, kdy balíky jsou členěny dle vrstev, tj. balík pro všechny entity, pro všechny DAO objekty atd.

  3. Využívat neměnitelné (immutable) objekty jak je to jen možné. Autor uvádí rozpor v tom, že dnes je všechno JavaBean, což je pravý opak.

  4. Proměnné a metody třídy řadit od nejvíce obecných k nejvíce detailním. Na místo klasického začátku s definicí proměnných začít uvedením veřejných metod, poté soukromé metody a až na konec uvést proměnné.


Tak to máme za sebou krátké resumé a teď konečně má reakce k jednotlivým bodům:
  1. Toto se mi zdá celkem přínosné, i když mě trochu odrazuje moje zkušenost s "Maďarskou konvencí" z časů, kdy jsem ještě programoval v C++. Hodně lidí bude argumentovat tím, že v IDE to každý hned pozná, ale ne vždy mohu IDE používat.

  2. K tomuto bodu mám asi největší výhrady. Sice čitelnost super (mám vše na jednom místě, nemusím skákat mezi balíkama), ale to je tak asi všechno. Další velký argument zapouzdřenost má určitě něco do sebe, ale nevidím v tom takový problém. Já se spíše snažím o zapouzdřenost na úrovni modulů, tj. několika balíků, uvnitř modulů mi to tolik nevadí. A nakonec v přístupu "package-by-feature" vidím nevýhodu při používání AOP - když mám strukturu "package-by-layer" tak mohu pěkně využívat AOP přes různé vrstvy, protože mi tomu odpovídá struktura balíků. Také se mi bude určitě lépe "řezat" aplikace, když budu potřebovat škálovat.

  3. K tomuto není co dodat, výhody jsou zřejmé. Spíše je obecný problém v tom, že JavaBeany jsou natolik rozšířené, až je to problém. Každý "nepřemýšlející" programátor sází jeden JavaBean za druhým. Polehčující okolností může být to, že často používané knihovny, např. JSF, ORM knihovny, Spring MVC ho k tomu víceméně tlačí.

  4. Autor argumentuje tím, jak člověk efektivně řeší problémy - nejdříve ho zajímají vysokoúrovňové věci a postupně jde do detailů. Zajímavé, nikdy jsem o tom takto nepřemýšlel. Zde mě ale hlavně zarazilo to, že je to vlastně v rozporu s Java konvencí od Sunu. K tomu prý Joshua Bloch říká: "I wouldn't take that document [Sun's Coding Conventions] too seriously. It is not actively maintained or used at Sun.". Co dodat :).


A jaký styl programování máte vy? Používáte třeba některý z těchto přístupů?

7. září 2008

JSF s NetAdvantage

Pro poslední projekt jsme se rozhodli použít JSF. Jedná se o intranetovou aplikaci s velkým důrazem na vzhled a funkčnost grafického rozhraní, takže jsme si řekli, že by to nemuselo být špatné to udělat pomocí JSF. Moc zkušeností s JSF jsme v týmu neměli, takže jsme se rozhodli použít nějakou komerční JSF distribuci, zejména kvůli podpoře. Nakonec jsme vybrali NetAdvantage for JSF (máme verzi 2008 Volume 1) od firmy Infragistics.

S NetAdvantage pracujeme celkem intenzivně dva měsíce, což už je doba na nějaké to shrnutí. Jako každé řešení, tak i toto má svoje výhody a nevýhody.

Výhody

  • podpora AJAXu - programátor nemusí nic vědět o AJAXu a může bez problémů dělat AJAXové aplikace. AJAXové chování lze ovlivnit jednak pomocí atributů jednotlivých komponent resp. tagů a nebo pomocí Java API z managed beanů. Už žádný Javascript, vše funguje úplně parádně samo.

  • kvalitní podpora - komponenty NetAdvantage se kupují na dobu jednoho roku a je možné si vybrat různé úrovně podpory. My máme tu základní úroveň, což znamená, že můžeme psát na fórum a nebo přímo jim s případnými problémy. Odezvy na naše dotazy jsou hodně dobré, řekněme v průměru do jednoho dne. Většinou odpovídají ještě v rámci dne (řekl bych, že někteří členové týmu jsou z východní Evropy, takže mají stejnou pracovní dobu jako my).

  • web grid (tabulka) - tabulku používáme velice často, a proto když jsme vybírali mezi různými distribucemi, tak jsme právě na tabulky dávali velký důraz. Tabulka od NetAdvantage toho umí opravdu hodně, to se nám již potvrdilo.

  • grafy - ty jsme zatím nepoužily, ale stačí se podívat do ukázek a člověk uvidí opravdu hodně velké množství všech různých typů grafů. Stačí si jen vybrat...

  • podpora Apache MyFaces a Sun RI JSF - NetAdvantage fungují nad oběma základníma implementacemi JSF. My jsme nejdříve používali Sunovskou verzi a pak jsme přešli na MyFaces verzi. Důvod? Zatím spíše subjektivní - MyFaces více žije, rychleji se opravují případné problémy a hlavně bychom rádi postupně začali využívat další komponenty (Tomahawk, Tobago, ...) od MyFaces.

  • podpora prohlížečů - vzhled a chování komponent je odladěné pro všechny nejpoužívanější prohlížeče.

  • velké množství skinů - NetAdvantage nabízí velké množství (cca 15) barevných skinů, takže není až tak velký problém s návrhem grafického rozhraní aplikace dle svých požadavků.

  • hotfixy - každý software má své chyby a nejinak je tomu u NetAdvantage. V průměru každý měsíc až dva měsíce vychází nový hotfix, který opravuje reportované chyby. Toto bych řekl, že celkem funguje.


Nevýhody

  • dokumentace - celkově mi dokumentace nepřijde moc kvalitní. JavaDoc sice existuje, ale skoro bez popisu. Zbylá dokumentace obsahuje pouze základní informace a některé věci tam ani nejsou, např. komponenta ig:link. Součástí instalace jsou i ukázky včetně zdrojových kódů, takže pro první seznámení to stačí. Horší kvalita dokumentace je vyvážena podporou ze strany výrobce komponent. Abych byl spravedlivý, tak zde musím uvést, že když jsem začínal s NetAdvantage, tak jsem začínal i s JSF, takže jsem dost často neřešil ani tak problémy s NetAdvantage jako spíše s JSF.

  • AJAX a MyFaces Orchestra spolu moc nefungují - používám MyFaces Orchestra kvůli konverzacím (viz minulý článek) a jak se ukázalo, tak neexistuje žádný standard pro implementaci AJAXu v JSF komponentách. Zatím to tedy dohromady moc nefunguje (některá AJAXová volání nesprávně ukončují konverzaci), snad se to nějak vyřeší (1, 2, 3)

  • podpora pouze JSF 1.1 - v současné verzi komponent NetAdvantage je podporována pouze JSF verze 1.1. JSF 1.2 budou podporovány od další verze.

  • komponenta ig:dropDownList nefunguje s konvertery - komponenta ig:dropDownList je náhradou za standardní JSF komponentu h:selectOneMenu, ovšem s podporou AJAXu. Bohužel ig:dropDownList nefunguje správně s konvertery, takže se s tím úplně dobře nepracuje.


Ještě toho budeme hodně zkoušet, takže pravděpodobně tento článek bude mít své pokračování. Zatím jsme třeba ještě nezapojili jiné komponenty třetích stran než od NetAdvantage, takže jsem zvědavý na vzájemnou kompatibilitu.

Další zajímavé zdroje: