Javlog @cacek.cz

Když už jsem v úvodu seriálu zmínil možnost přístupu k Excel souborům přes JDBC, měl bych teď přidat více detailů. Ale nečekejte žádné zázraky. Osobně jsem tímto způsobem s excelem nikdy nepracoval a ani samotná myšlenka se mi moc nelíbí, nicméně je to také jedna z cest. Narazil jsem pouze na dvě knihovny, které poskytovaly JDBC rozhraní pro Excel: xlSQL - open-source HXTT JDBC Drivers for MS Excel - komerční implementace HXTT JDBC driver jsem nezkoumal a xlSQL mě zklamal - chybí dokumentace, vývoj zamrzl v roce 2004 a příklady použití aby člověk hledal "kupou v lupce sena" :-). Pro zpracování xls dokumentů používá xlSQL knihovnu projektu JExcelApi , ke které se snad dostaneme v některém z příštích dílů. Zpracování SQL dotazů probíhá v režii knihoven z MySQL connectoru a HSQLDB. A abych zůstal věrný tradici a netrápil vás pouze šedou teorií, tak tady je příklad kódu jak na excel přes JDBC: Class.forName("com.nilostep.xlsql.jdbc.xlDriver"); String ur...

V Hibernate existuje yes_no typ, který vám umožňuje mapovat B(b)oolean property na databázové sloupce typu CHAR(1). Pro pravdivostní hodnotu true je při reprezentaci v databázi použito hodnoty 'Y' a pro false 'N'. Občas se ale setkáte s databází jejíž tvar nemůžete ovlivnit a pro pravdivostní hodnoty jsou použity jiné zástupné znaky např. 'A', 'N' (ano/ne) nebo 'J', 'N' (ja/nein). Pro některé typy úkolů sice postačuje modifikovat nastavení hibernate, aby v dotazech na yes_no hodnotu nahradil příslušné znaky: < prop key = "hibernate.query.substitutions" > yes 'A', no 'N' < /prop > Tento přístup si ale už neporadí s nahráváním celých objektů z databáze - také hodnoty 'A' budou konvertovány na false. V tomto případě se hodí vytvořit si nový typ a můžeme využít toho, co pro nás už Hibernate připravil. Rozšíříme abstraktní třídu CharBooleanType : package cz.mujpackage; import org.hibernate.ty...

Problém s aplikacemi pro různé jazyky je, že musíte udržovat překlady konzistentní. Já jsem si své property fajly zatím spravoval ručně jen editací v Eclipsu, ale tenhle stav už je celkem neudržitelnej, takže se poohlížím po vhodném nástroji, který by se staral za mě. Při svém hledání jsem narazil na vhodný odrazový můstek a tím je tato stránka: http://attesoro.org/similar.html Zatím se mi nejvíc líbí Babel Fish , ale jestli víte ještě o něčem lepším, tak napište do komentářů.

V třetím díle seriálu o práci s Excelem v Javě si popíšeme přístup přes DCOM bez využití JNI. Tento způsob práce se hodí v případě, kdy potřebujete úplnou funkcionalitu Excelu, ale vaše aplikace neběží na počítači kde by byl Excel nainstalovaný. Přístup je velice obdobný tomu, co jsme si ukázali v druhém díle seriálu — tedy využití COM přes JNI. Opět existují implementace pomocí zástupných objektů (komerční J-Integra , WebLogic jCOM ) i pomocí volání IDispatch (opensource J-Interop ). Výhoda přístupu přes DCOM spočívá v tom, že vaše java aplikace nemusí běžet na windows a nevyužívá nativní knihovny (je zachována platformová nezávislost). Na druhou stranu vám díky síťové komunikaci může výrazně klesnout výkon. DCOM přístup je také náročnější na nastavení na straně windows serveru (vzálený přístup k DCOM nebývá ve výchozím nastavení povolený). Další problém nastane se sdílením souborů, když chcete číst nebo zapisovat XLS soubor windows server na něj musí vidět (cesty k souboru ...

První metoda pro práci s Excelem v Javě, kterou si v seriálu ukážeme je využití MS Automation. To znamená že budeme s Excelem pracovat stejným způsobem jako při psaní skriptů ve windows (viz Windows Scripting ). To sice přináší největší funkcionalitu, ale na druhé straně spoustu omezení spočívající v předpokladech, které musí aplikace splnit. Tuto metodu doporučuji pouze v případě, že chcete používat funkcionalitu, které se nedá docílit použitím jiných metod (viz Jak na Excel 1) - například spouštění maker. Co budeme muset splnit pro využití této metody? naše Java aplikace musí běžet na stroji s Windows, kde musí být nainstalovaný Excel musíme mít Java-COM bridge, t.j. nástroj který nám umožní v Javě pracovat s COM objekty, většinou nějakou knihovnu volající přes JNI funkce z MS Windows Existuje několik open source knihoven implementujících Java-COM bridge. Tyto knihovny pracují v některém ze dvou základních režimů (některé zvládají oba). První typ přístupu využívá vygenerovan...

Už se mi několikrát stalo, že v zákaznických požadavcích na aplikaci byl i export tabulek do Excelu nebo naopak import dat z .xls souborů, proto bych chtěl napsat pár záznamů do blogu i na toto téma. Existuje několik různých přístupů jak v Javě pracovat s dokumenty Excelu, každý má svá pro i proti. Zde je stručný přehled: přístup výhody nevýhody JNI a Excel Automation (COM) jednoduše implementovatelné "úplná" funkcionalita (v rámci toho co Excel nabízí přes komponentový model) nehrozí nekompatibilita (když nepočítám některé nekompatibility mezi jednotlivými verzemi Excelu) musí být nainstalovaný Excel přicházíme o platformní nezávislost (JNI) většina řešení pouze pro windows Java DCOM + Excel Automation nehrozí nekompatibilita (když nepočítám některé nekompatibility mezi jednotlivými verzemi Excelu) nevyužívá JNI musí být povolen DCOM přístup na počítač s nainstalovaným Excelem větší časová náročnost (síťová komunikace) nez...

Nedávno jsem dostal za úkol implementovat autentizaci a autorizaci (přihlašování a implementace přístupových práv) v několika webových aplikacích u zákazníka. Aplikace sice využívají Hibernate , ale bohužel už ne Spring , pro který existuje security framework Acegi , poskytující přesně tu funkcionalitu, kterou potřebujeme. Acegi už jsem v jednom projektu úspěšně použil a tak jsem nebyl nadšenej z toho, že musím hledat jiné řešení. Nakonec jsem část Acegi (zdrojáků) přeci jen použil. A to mírně upravené třídy z balíku org.acegisecurity.context , pomocí kterých lze jednoduše (s využitím servlet filtru) získat kdekoliv v aplikaci právě přihlášeného uživatele. Další krok bylo vynucení přihlášení pro přístup k chráněným částem aplikace. Přemýšlel jsem o využití možností servlet kontejneru (např. Security Realm v Tomcatu ), ale nevýhodou je, že pak pro deploy aplikace nestačí mít soubor s archivem (war), ale musíte také nakonfigurovat daný Realm přímo v instalaci Tomcatu. Navíc je toto ...