29. prosince 2008

JSF: zkušenosti s NetAdvantage

O NetAdvantage komponentách jsem již několikrát psal (1, 2, 3) a rád bych napsal ještě jednou a tím to uzavřel. Již jsem se dříve snažil o nějaké zhodnocení a na to bych rád dnes navázal. Pokud se od té doby něco změnilo nebo jsou určité věci jinak než dříve, tak to nyní uvedu, jinak platí to co jsem již napsal.

S NetAdvantage komponentami jsme dělali přibližně půl roku, z toho tři měsíce celkem intenzivně. Projekt jsme zdárně stihli, takže (snad) všechny problémy, které jsme s komponentami měli, jsme dokázali nějak vyřešit. O použitých technologiích jsem psal v tomto příspěvku.

Ještě uvedu, že se budu vyjadřovat k verzi 8.2.20082.1003 - od té doby byly vydány dva nové hotfixy, takže něco může být lehce jinak.

Výhody

Seznam výhod nebudu rozšiřovat, stále platí co jsem již napsal. U podpory prohlížečů jsme narazili pouze na jeden problém a to v nastavení modality okénka (ig:dialogWindow) v IE 6 - v této verzi IE se nám prostě modální okénka nepodařilo rozchodit.

Obecně bych jako největší výhody NetAdvantage označil vzhled a AJAX. Komponenty vypadají hned "v základu" moc hezky, vše je možné skinovat. AJAX funguje bez problémů, člověk ho může používat, aniž by o něm něco věděl.

Nevýhody

Seznam nevýhod resp. nedostatků musím celkem rozšířit. Nejdříve bych ale doplnil informace uvedené v předchozím shrnutí:
  • dokumentace - úroveň uvedené dokumentace (JavaDoc a příručka programátora) jsou pořád na stejné úrovni, jen navíc přibyly nové stránky s ukázkami a příklady. Tyto stránky jsou moc pěkně udělány a navíc obsahují hodně vychytávek, které nikde jinde v dokumentaci uvedeny vůbec nejsou.

  • AJAX a MyFaces Orchestra spolu moc nefungují (neplatí) - toto již neplatí, chyba na straně Apache Orchestra (pozn. ona to úplně nebyla chyba, protože nikde není přesně popsáno jak má fungovat JSF a AJAX dohromady) byla opravena.

  • podpora pouze JSF 1.1 (neplatí) - jak jsem již psal, tak je možné již používat JSF 1.2.


Nyní bych rozšířil seznam nedostatků, na které jsme narazili v průběhu vývoje:
  • JSF chybové zprávy - v konfiguraci JSF jsme nastavili odkaz na vlastní properties soubor s chybovými hláškami. Správně se používají u standardních JSF komponent, ovšem s NetAdvantage komponentami (konkrétně např. ig:dateChoose) se pořád používají chybové hlášky z myfaces.jar.

  • nemožnost používat čisté HTML - i když samotné facelets umožňují libovolné používání "čistého" HTML včetně EL bez nějakých tagů (kdekoliv na stránce mohu použít #{data}), tak bohužel toto neplatí pro NetAdvantage komponenty. Uvnitř těchto komponent (my jsme to raději používali všude) je nutné EL volat pomocí h:outputText a čisté HTML tagy (konkrétné DIV) nahrazovat tagy z Tomahawku (t:div).

  • komponenta ig:dropDownList nefunguje s konvertery - o této chybě jsem již psal, zde uvádím znovu jen kvůli úplnosti

  • ig:link nemá onClick() - NetAdvantage náhrada za h:commandLink má navíc hlavně vestavěnou podporu pro AJAX, ale bohužel nemá metodu onClick. To je například problém, když máte tabulku s možností smazání libovolného řádku s tím, že vlastní smazání musí být ještě potvrzeno. Pokud chci AJAX, tak nemám možnost toto udělat, museli jsme použít normální h:commandLink a oželet v tomto případě AJAX.

  • ig:dateChooser ignoruje locale

  • problémy s ig:dialogWindow - ig:dialogWindow vytváří modální/nemodální okénko (ne pop-up okénko). Zde máme občas problémy s tím, že modalita není dodržena (při více aktivních okénkách na stránce) nebo si uživatel občas může všimnout problikávání při načítání stránky. Ale toto jsou pouze "kosmetické" věci, které bohužel uživatel připomínkuje nejčastěji.

  • předávání parametrů do komponent - vytvářeli jsme si Facelets komponenty pro různé tabulky (ig:gridView), protože jednou se tabulka použije v detailu, podruhé v editaci atd. Naše komponenty měly vždy alespoň jeden parametr a to dataSource pro načtení dat do tabulky. Bohužel předávání proměnné datového zdroje jako parametr naší Facelets komponenty nefungoval.

  • rekurzivní vytváření stromu - komponenta ig:tree umožňuje vytvářet stromy. Jednou z možností načtení dat do stromu je rekurzivní přístup, který nám bohužel nefungoval.

  • předávání objektu řádky tabulky pomocí f:setPropertyActionListener - NetAdvantage komponenta pro tabulku ig:gridView nabízí objekt #{DATA_ROW}, který představuje aktuální objekt pro určitou řádku tabulky. Bohužel není možné tento objekt nasetovat pomocí f:setPropertyActionListener.

  • ...


Závěr

Nakonec jsem vypsal jen ty nejdůležitější nedostatky, protože jich je mnohem více. Většina z nich je reportována výrobci jako chyba a většina z reportovaných chyb je označena statusem "In Development", tak snad budou někdy opravené.

Pokud nás během vývoje něco brzdilo, tak to byly NetAdvantage komponenty, protože vždy nějakou dobu trvalo, než jsme našli tu správnou cestičku. Musím hned ale dodat, že absolutní většinu všech nedostatků se nám podařilo vyřešit, obejít. Také je otázka, zda by to bylo výrazně jiné s jinými JSF komponentami? Pro nás to byl první větší projekt s JSF, takže jsme se učili spoustu věcí za běhu. Během vývoje jsme se několikrát ptali sami sebe, zda nezkusit jiné komponenty, ale dobře jsme udělali, že jsme vydrželi.

Závěrečná otázka asi bude "Použít či nepoužít"? Vzhledem k tomu, že již znám "cestičku", kudy jít při vývoji s NetAdvantage komponentami, tak bych se nebál je použít i na dalším projektu. Zvláště pokud by byla možnost do projektu zasahovat již v době návrhu, tak aby se již v této fázi eliminovaly "neprůjezdné cestičky". U nového projektu nevím. Pokud by to mělo být jen pro jeden projekt a nic dále, tak bych do toho nešel, ale pokud je to s vidinou toho, že to budete využívat i na dalších projektech, tak se pak ten čas navíc (u našeho projektu cca 20% času vývoje) celkem vrátí.

23. prosince 2008

Druhý rok Javičky

K napsání tohoto příspěvku mě inspiroval Otec Fura :). Sice (bohužel) nemám takové výsledky jako on, ale i přesto si myslím, že špatné to úplně není. Jedna věc jsou statistiky a druhá věc je vlastní naplnění, tedy že to vůbec dává nějaký smysl psát blog. Na úplném začátku psaní tohoto blogu jsem měl určité představy a musím říct, že se my všechny tyto představy naplnily. Proto asi pořád ještě píšu :).

Používám také Google Analytics, ale začal jsem ho používat až v polovině května, takže mé statistiky nejsou za celý rok. Sice od začátku používám službu Navrcholu, ale ta pro neplatícího uživatele mnoho nenabízí.

Mě se dosud v tomto roce podařilo napsat 35 článků. Aspoň pro mě je to celkem velké číslo, protože roční holčička bere čím dál více času a práce je také celkem dost. Podle rozvržení jednotlivých článků v průběhu roku je hezky vidět, kdy jsem měl napilno (to jsem moc nepsal, protože člověk je rád, že u toho počítače nemusí pořád sedět) a kdy jsem něco navrhoval nebo zkoušel (to jsem psal nejvíce, protože člověk má nejvíce nových podnětů a rád se s nimi podělí).

Souhrnné statistiky za rok 2008

  • Počet příspěvků: 35
  • Počet unikátních návštěvníků: 8,419 (max. 1,517 září 2008)
  • Počet unikátních návštěv: 15,166 (max. 2,344 září 2008)
  • Počet zobrazení: 22,275 (max. 3,447 září 2008)

Nejčtenější příspěvky (počet přístupů)

  1. Máte čas na unit testy? (1,135, 5.10%)
  2. Srozumitelnost zdrojového kódu (1,020, 4.58%)
  3. JSF - sestava sedmi statečných (957, 4.30%)
  4. Hibernate - práce s kolekcemi, ManyToMany vazba (912, 4.09%)
  5. Jakou databázi používáte? - výsledky (810, 3.64%)
  6. OSGi: Použít nebo nepoužít? (763, 3.43%)
  7. Nástroje SoapUI a JMeter (753, 3.38%)
  8. JSF zase nejsou tak špatný ... (751, 3.37%)
  9. Jaký webový framework používáte - výsledky (716, 3.21%)
  10. JSF s NetAdvantage (713, 3.20%)
  11. Komentovat? Určitě ano. (668, 3.00%)
  12. Open-source ESBs (667, 2.99%)
  13. Verzování entit - JBoss Envers (662, 2.97%)
  14. Přechod z Acegi na Spring security (614, 2.76%)
  15. JSF - FacesTrace a MyFaces Orchestra (596, 2.68%)
  16. NTLM a Spring security (486, 2.18%)
  17. Výhody a nevýhody EJB (398, 1.79%)
  18. JSF a Spring - postup o krok dále (353, 1.58%)
  19. Proč nemám rád Seam (347, 1.56%)
  20. Ukázka konfigurace Acegi security (347, 1.56%)

Zdroje přístupu (počet přístupů)

  1. java.cz (7,057, 46.51%)
  2. google (3,491, 23.01%)
  3. přímý přístup (1,768, 11.65%)
  4. root.cz (649, 4.28%)
  5. seznam.cz (613, 4.04%)

Lokace návštěvníků (počet návštěvníků)

  1. Česká Republika (12,211)
  2. Slovensko (1,628)
  3. Německo (350)
  4. Finsko (206)
  5. Velká Británie (180)

Rozvržení prohlížečů (počet návštěvníků)

  1. Firefox (10,470, 69.04%)
  2. Opera (1,912, 12.61%)
  3. Internet Explorer (1,874, 12.36%)

Rozvržení operačních systémů (počet návštěvníků)

  1. MS Windows (12,004, 79.15%)
  2. Linux (2,774, 18.29%)
  3. MacOS (318, 2.10%)

BIRT reports vs. Jasper Reports

Je to dost častý problém - aplikace sbírá data a tyto data je potřeba nějak prezentovat formou reportů. Standardní výstupní formáty jsou HTML (na prohlížení) a PDF (na tisk).

Asi nejznámější řešení na vytváření reportů je Jasper Reports (pěkný článek o Jasper Reports vyšel na Java.cz).

My jsme pro náš projekt zvolili jiné řešení - Eclipse BIRT reports.

Rád bych nyní uvedl takové malé srovnání Jasper Reports a BIRT reports (s laskavým souhlasem mého kolegy Ondřeje Světlíka, který měl reporty na starosti).

Společné vlastnosti

  • umí lokalizaci textů
  • umí přistupovat k datům přímo přes JDBC, ale i jinými způsoby
  • umí grafy
  • umí všechny možné výstupní formáty - pdf, html, doc/rtf, xls a další

Jasper Reports

  • + výrazně menší runtime - cca 5M
  • + editor podporuje přímo práci se Spring beany
  • - nutnost kompilovat .jrxml na .jasper
  • - horší editor
  • - neumí tabulky, skládají se pouze buňky, takže něco jako změna šířky celého sloupce najednou (hlavička, obsah, patička) je nemyslitelné

BIRT reports

  • + lepší editor
  • + editor součástí Eclipse i standalone
  • + umí tabulky
  • + stylování pomocí CSS
  • + umožňuje skriptování v JavaScriptu
  • - obrovský runtime - cca 42M
  • - pokud má být datovým zdrojem Spring bean, musí se použít skriptovaný datový zdroj
  • - větší nároky na PermGen space, je nutné spouštět tomcat s -XX:MaxPermSize=256m (odzkoušená hodnota, zřejmě bude fungovat i menší, ale default 64m nestačí)


Já bych ještě doplnil mé osobní pocity. Velikost BIRT enginu (engine musí být součástí aplikace, generuje samotné reporty) je opravdu značná, v konečném důsledku asi 50MB. To už je celkem nárůst velikosti aplikace, i když se jedná o server.

Moc se mi líbil editor a obecně možnosti BIRTu samotného. Spoustě lidí může vadit přítomnost Javascriptu, ale já s ním problém nemám.

Trochu jsme měli problém s češtinou v PDF reportech, ale to jsme vyřešili nastavením kódování cp1250 v souboru fontsConfig_pdf.xml.

Propojení BIRT enginu a samotné aplikace je realizováno přes servlet - servlet zjistí potřebné informace o reportu (většinou z URL adresy) a předá je BIRT enginu. Ten pak už jen vygeneruje výstup, který se odešle klientovi.

Všechny definice reportů jsou v XML, takže z pohledu verzování nebyl žádný problém.

Jediný problém, který jsme zatím nevyřešili, je horizontální stránkování při výstupu do PDF. Toto BIRT ještě neumí.

S Jasper Reports jsem nikdy moc nedělal, ale asi už ani dělat nebudu. BIRT mě celkem zaujal...

Další odkazy

1. prosince 2008

Jakou databázi používáte? - výsledky

Druhá minianketka je u konce s těmito výsledky:

  1. MySQL (51%)
  2. Oracle (47%)
  3. PostgreSQL (36%)
  4. MSSQL (12%)
  5. Apache Derby (Java DB) (10%)
  6. Jiná embedded (9%)
  7. DB2 (5%)
  8. Jiná standalone (5%)
  9. InterSystems Caché (0%)
Hlasovalo celkem 121 lidí.

Co k tomu říci? Umístění volně dostupných databází MySQL a PostgreSQL není asi žádným překvapením. MySQL je velice rychlá databáze (sice trochu na úkor funkcionality, ale ta není vždy potřeba) s množstvím administračních nástrojů. Já osobně dávám spíše přednost PostgreSQL, protože jednak toho umí opravdu hodně a v případě potřeby je možné bez větších problémů přejít na databázi Oracle.

Odhaduji, že spousta z vás dělá na velkých projektech, protože jinak by nemohla databáze Oracle být na druhém místě :).

Já jsem svůj největší projekt dělal nad MSSQL databází a byl jsem s ní hodně spokojený. Databáze byla určena již zákazníkem před realizací projektu a já jsem se k tomu stavěl trochu skepticky, ale nebylo třeba. Asi hlavní důvod byl ten, že já jsem přeci jen "klikací" uživatel, a proto se mi moc líbila administrace v této databázi - vše velice intuitivní.

Zajímalo by mě vaše využití embedded databází? Já jsem je používal pouze ve spojení s desktopovými aplikacemi, kdy jsem potřeboval ukládat data mezi jednotlivými spouštěními aplikace.

Co mě možná trochu překvapilo je to, že se nenašel nikdo, kdo by používal objektovou databázi Cache. Je to možná tak dva roky, co byla celkem masivní kampaň na používání a výhody Cache a asi se nikdo nechytil. Já osobně nemám žádnou zkušenost, takže nemohu soudit, ale relační databáze tu již jsou hodně dlouho a je to mnohdy jediná věc v IT oddělení firem, která se po léta nemění.