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...
Příspěvky
4 komentáře:
My jsme meli s BIRTem celkem velke problemy pri nasazeni do aplikacniho serveru. Tim ze je BIRT kompletne postaveny nad OSGi a s necim takovym nepocita embednuti jako soucast EARu. Uz si presne nevzpominam na detaily, ale myslim, ze problem byl v tom, ze BIRT nedokaze bezet v zabalenem EARu/WARu. Museli jsme udelat nejaky hack, ktery se vzdy postaral o rozbaleni a potom o nakopnuti BIRT enginu. Dalsim problemem byly nejake handlery navesene uvnitr java.net.URL, ktere si napriklad JBoss nastavil jak potreboval, ale BIRT se je snazil prerazit podle vlastniho mineni. No a vn eposledni rade tim, ze je postaveny nad OSGi tak to delal problem v OSGi kontejnerech tusim zrovna na WebSpheru. Takze nas rozbehani BIRTu na WebSphere, OASu, Weblogicu a JBossu stalo nemale usili vcetne par patchu, ale funguje to ;-).
Celkom by ma zaujimalo, ze preco je skriptovanie v javascript plusom? Predsa pokial viem, tak Jasper podporuje skript pisany priamo v jave alebo groovy. O tomto fakte nie je ani zmienka...
Taktiez autor asi preferuje eclipse pre ostatnymi prostrediami. Editor sablon pre birt je sice plug-in do eclipse tak ako editor jasper reports je plug-in do netbeans. O tom sa ale samozrejme nic nepise.
Velmi jednostranne a nevyvazene napisany clanok...
JR pouzivam, BIRT brzy urcite zkusim. Bylo by fajn jeste podotkout, ze kompilace sablony v JR se dela jednoduse pres API a nekde v tutorialech je jednoduchy priklad, jak se kompilaci vyhnout, pokud nebyl puvodni XML soubor zmenen. Jinak ten JR plugin do NB je opravdu bezva, funguje to jako normalni GUI builder. Jen nechapu, proc je treba pri pouziti nejakeho fieldu v sablone jej navic definovat v inspectorovi.
Pro mne JR vyhral hlavne tim, ze je vedle JSP, FreeMaker a Velocity ctvrtym sablonovacim systemem pro Spring. Ve skutecnosti se pak s reportem pracuje uplne stejne jako s JSP starankou. Muzu nad nim mit naveseny controler atd. stejne jako nad JSP strankou. Navic o kompilaci se da proves za behu, stejne jako kompilace JSP.
Btw. Primy pristup do JDBC mi prijde jako neco zbytecneho. Vy snad pouzivate v JSP primi pristup do databaze pres JDBC?
Dalsi super vec (i kdyz placena) je JR server, ktery vam dava tvurce reportu jako portlety (tudiz uzivatel muze primo z browseru editovat tiskove sestavy). To je hodne dobra vec.
P.S.: Birt sem nezkousel.
Okomentovat