Zápisky.info

Dnes přidám jen jeden tip pro ty, co hledají stejně dlouho v dokumentaci Oracle databáze jako já, jak pracovat s pohledy. Máte–li „view“ (pohled) nad tabulkami v databázi a chcete, zjistit, jaký SQL dotaz se vykonává, dá se jednoduše získat dotazem:

SELECT text
FROM all_views
WHERE view_name = '%VIEW_NAME%';

Každý report v napsaný v JasperReport / navržených v editoru iReport může obsahovat pouze jeden jediný zdrojový dotaz pro získání dat — definovaný v elementu <queryString>. V některých případech potřebujete získat data pomocí dvou či více dotazů. V takových případech si s jediným reportem nevystačíte — pro tento účel jsou k dispozici subreporty složící pro vložení jiných reportů do hlavní šablony. Jednoduše připojíte jiný JRXML soubor, předáte spojení, parametry, … Pokud reporty nahráváte na JasperServer, situace se trochu komplikuje o správné nastavení cesty k druhé šabloně.

Pokračování »

Dříve či později při vývoji reportů nad JasperServer narazíte na požadavek, aby parametry a vstupní prvky dovolovaly zvolit více jak jednu hodnotu. Typicky je třeba prvek, kde se volí právě jeden prvek, jeden a nebo všechny, a nebo jeden až všechny. Samozřejmě, že vstupní prvky by měly mít hodnoty naplněné z databáze, což jsem popsal nedávno.

Dnes popíšu, jak vytvořit vstupní prvek s možností volby různého počtu hodnot. Základem je definice parametru. Stačí v iReport editoru, v panelu Struktura dokumentu (Document structure) kliknout pravým tlačítkem na Parametry (Parameters) a Add… > Parameter. Důležité je nastavit datový typ java.util.Collection.

V JasperServeru pak definujeme příslušný vstupní prvek, která musí umožňovat volbu více hodnot. Máme-li k dispozici hotový Dotaz (Query) v JasperServeru pro získání hodnot, v panelu JS-Plugin 3.0 zvolíme dialog Add > Input Control a vybereme typ Multi–Select Query a vyplníme ostatní parametry stejně jako u Single–Select Query. Vstupní prvek přiřadíme do reportu (Report Unit).

Poslední a nejdůležitější je použít parametr v reportu. Jelikož hodnot může být různý počet, v dotazu použijeme omezující podmínku WHERE table.attr IN(…). Klasické parametry s jednou hodnotou zapisujeme pomocí $P{ParameterName}. Pro parametry s více hodnotami existuje speciální zápis – $X{IN, table.attr, ParameterName}, který vygeneruje celou podmínku v dotazu. Místo IN můžete použít také NOTIN, pokud chcete vygenerovat klauzulin NOT IN(…).

Vstupní prvek se zobrazí jako selectbox s více zobrazenými hodnotami, kde můžete i více hodnot zvolit.

Moje práce na reportech a JasperServeru pro jejich správu pokračuje i nadále. Aktuálně jsem řešil problém, jak správně vytvořil lineární graf (Line Chart) v editoru iReports. Kde byl problém? Byly dokonce dva. První se týkal správného umístění elementu grafu v JRXML šabloně, druhý zadání zdrojových políček z dotazu. Druhý ze zdrojů uváděl, že do libovolné části šablony, která se neopakuje. Po spuštění reportu, kdy se mi vygeneroval graf na tolik stránek, kolik bylo řádků zdrojových dat, jsem pochopil, že to nepůjde do libovolného elementu. Tutoriál ke grafům v iReports dal správnou odpověď — graf umístěte do elementu <summary>. Řešení, jak nastavit zdrojová pole, jsem našel na Java Lobby. Máme-li dotaz:

SELECT
  workstatus.time AS DATE_TIME,
  workstatus.active_projects_count AS PROJECT_COUNT
FROM workstatus
WHERE workstatus.time BETWEEN $P{VALID_FROM} AND $P{VALID_TO}
ORDER BY workstatus.time ASC

Můžeme nastavit graf tímto způsobem:

• Výraz pro sérii: název jedné linie v grafu, např. "Počet aktivních projektů"
• Výraz pro kategorii: Osa X, $F{DATE_TIME}
• Hodnota výrazu: Osa Y, $F{PROJECT_COUNT}

Graf se vykreslí v horizontální orientaci, kde na ose X budou data, na ose Y počty projektů a pod grafem v legendě název tohoto datového zdroje. Do grafu lze samozřejmě zadat více datových setů a mít více přímek.

Pokud jste někdy řešili úkol tvorby reportů, určitě jste při hledání vhodné technologie neopomenuli prohlédnout nebo dokonce použili JasperReports. Tento framework poskytuje flexibilní šablonovací nástroj založený na vlasním XML formátu, který navíc můžete navrhnout v grafickém WYSIWYG editoru iReport od stejných tvůrců. Škála výstupních formátů je širová – hlavně PDF a XLS budou zajímavé. Pokud se chcete o nástroji dozvědět více, doporučuji krátké představení nástroje a integrace se Springu od Vlasty Vávrů nebo tutorial z ČVUT.

Minulý týden jsem řešil přípravu několika reportů nad Oracle databází. Výhodou bylo, že máme nainstalovaný JasperServer – ten slouží k hostování, správě, automatizovanému spouštění reportů a správě vygenerovaných reportů. Pro editor iReport je vytvořen předinstalovaný plug–in, kterým můžete server spravovat. Stačí přidat adresu a přihlašovací údaje, do widgetu se vám načte kompletní obsah, se kterým můžete manipulovat a vlatní šablony přímo v editoru upravovat. Co nepřidalo na jednoduchosti, byl požadavek na vstupní parametry. Např. volba jedné ze stavů faktury, či omezení časového intervalu. Protože mě to stálo minimálně den pátrání, popíšu, jak vytvořit na JasperServeru znovupoužitelné vstupní komponenty, jejichž výčet hodnot se načítá z databáze.

Základem je mít v šabloně reportu vytvořené vstupní parametry. Jméno vstupní komponenty se musí se jménem parametru shodovat! Máte–li šablonu hotovou, můžete připravit vstupní komponenty. Pro naplnění komponenty daty potřebujete Query (dotaz). Nabídku Add > Query najdete po pravém kliku na některou složku v JS plug–inu. Záložka General vyžaduje vyplnit Name (ID komponenty) a Label (libovolný popisek pro orientaci na JasperServeru). Záložka Query poskytuje volby pro vlastní získání dat. Je třeba zvolit dotazovací jazyk (např. SQL, EJBQL, HQL či XPath), najít již definované spojení na datový zdroj (databázi) a zadat vlastní dotaz.

Máte–li definovaný Dotaz, můžete vytvořit vlastní vstupní komponentu. Dialog najdete pod Add > Input Control. Ze zajímavých voleb uvedu Type, který je třeba nastavit na Single Select Query, dále najít na JasperServeru námi definovaný dotaz a pak, Value Column určuje jméno sloupce s hodnotou. Naopak Visible Query Columns sloupce, které budou v roletce zobrazeny.

Když vytvoříte všechny potřebné komponenty, otevřete si strukturu vašeho reportu (Report Unit) a všechny postupně připojte přes volbu Link an Existing Input Control (pravý klik na Input Controls). V této chvíli jsou již nabízený v komponentách správné hodnoty a report je pak se zvolenými hodnotami předanými přes parametry spuštěn a vygenerován.

Již před rokem jsem absolvoval přednášku Ing. Buchalcevové, Ph.D. –VŠE Praha– na téma metodik vývoje. Mnoho praktických či pochopitelných informací jsem nezískal, skripta byla v tomto ohledu ještě žalostnější. Rok s rokem se sešel. Můj zaměstnavatel na mně vyzkoušel upravený RUP, několik dalších upravených verzí a ve výsledku z něho vyvinul SCRUM … a proto jsem s odstupem dvou semestrů opět zavítal na přednášku výše zmíněné vyučující, zda–li se její přednáška srozumitelnější nestala. (A to také proto, že jsem ji potkal na březnovém CZJUGu.)

Jistě příznivou informací je, že náplň tohoto tématu je rozdělena do dvou přednáška a příští pondělí 30.4. 2007 v 16:15 v Nové aule VŠE bude přednáška o metodice SCRUM. Všechny zájemce zvu na porovnání s CZJUGem a páně Filemonovou přednáškou.

Obsah přednášky dnešní, co si vybavuji, doznal změn. Faktů je shodně, snad i více, ale některé informace se mi nápadně shodují s CZpodcastem#8 a přednáškou o metodikách na CZJUGu. Vítám jejich zařazení. Uvědomuji si, že některé informace jsou zmiňovány v ne zcela jasném kontextu a studenti, co zde sedí, asi nepochopí, proč jsou tyto informace zmiňovány. Já to také před rokem nechápal. A k pochopení mi pomohla jen a jen praxe. A i rok po té je zde ta záhadná metodika MMDIS!

Porovnání této a druhé zmiňované přednášky je obtížné. Filemon vše podal více „z praxe“, Ing. Buchalcevová bere téma více teoreticky. Množstvím informací si však obě dvě konkurují.

Metodiky vývoje se snaží maximálně zjednodušit procesy v rámci vývojového týmu a maximálně zefektivnit práci. V rámci své praxe jsem narazil na dvě obecně platné pravidla:

1. „Zdrojové kódy v souborovém úložišti musí být vždy aktuální – kdyby byl člen týmu nedostupný, nečekaně odříznutý od zbytku týmu, nebo nešťastnou náhodou přišel o život, tým musí být schopný pokračovat v jeho práci.“
2. „Zdrojové kódy v souborovém úložišti musí být vždy zkompilovatelné.“

Jistě chápete, co se stane, pokud nebude dodržováno první pravidlo. Pominu-li morbidní kontext této poučky, může vzniknout například situace, kdy člen týmu dokončí prioritní úkol, ale neodešle hotové soubory na úložiště. Pokud následně není v dosahu – třeba z důvodu dovolené – tým musí problém řešit i za cenu toho, že vynaloží další penzum pracnosti na znovu–vytvoření již hotového. V horším případě všechny musí vyčkat s dokončením všech návazných úkolů, až se pracovník vrátí.

Nyní si uvědomme, co říká pravidlo první a co pravidlo druhé!

Co se stane, pokud pracovník těsně před koncem směny nemá hotovou funkční verzi. Má nebo nemá soubory nahrát do úložiště? Měl by, protože jinak nebude tým v případě potřeby schopný za něj práci dokončit.

Ale je tu jiný problém. Uvažujme tým, kde jeden vývojář pracuje na modelu aplikace a další vývojáři na uživatelském rozhraní (UI). Pokud vývojář pracující na modelu aplikace provede refaktoring, který není dokončený, jak na toto zareagují pracovníci uvázaní na UI aplikace? Jak se vůbec dozví, že model není aktuálně kompilovatelný a proto by jej neměli na své vývojové stanici aktualizovat, protože jinak nebudou moci pracovat – zkompilovat projekt!

Už jsem zažil mnoho dohod typu „chybí mi třída Aaa, Abb, Ac, můžeš je nahrát? Chvilku …“ nebo ještě horší „kluci, neaktualizujte model, neprochází junit-testy a nejde ani zkompilovat!“ Horší jsou ale stavy, kdy aktualizujete zdrojové kódy a netušíte, že vše jde zkompilovat, ale změnila se třeba struktura databáze, implementace a aplikace pak nejde po sestavení spustit …

V těchto případech by mnohé vyřešilo zavedení nepřetržité integrace (continuos integration) v rámci metodiky vývoje. Ta umožňuje v pravidelných intervalech nebo na požádání spustit kompletní sestavení aplikace a následně nad ní spustí zvolenou sadu jednotkových testů (nejen JUnit, ale třeba i HTTPUnit, atp.) Tím je vždy aktuálně k dispozici informace, zda-li je poslední verze projektu funkční (a to po všech stránkách). Jak s takovou informací naloží vývojáři jednotlivých vrstev, to už je zcela v jejich kompetenci.

Již jsem překousl všechny choutky i nechoutky Sesame 2 a minulý týden se pustil do programování komponenty, která z RDF konfiguračního souboru přečte popis nastavení (definovaný dle dříve implementované ontologie) a následně příslušné nastavení Repository vytvoří – zde se uplatnila hlavně Java reflexe. A jelikož Sesame 2 nemá identické API s Jenou, opět jsem se spoustu času bloudil v tutorialu a javadocu. Přináším pár maličkostí, které jsem řešil a vyřešil.

Logování — existuje univerzální komponenta ThreadLog, která zapisuje veškeré hlášení do společného logu Sesame.

// presmerovani do spravneho souboru
ThreadLog.setDefaultLog("./log.txt", 5);
// zapis zpravy do logu
ThreadLog.log("An error message");

Model / úložiště v paměti — neexisuje nic jako MemModel. Veškeré úložiště se vytváří shodně.

Repository repository = new RepositoryImpl(new MemoryStore());
Connection connection = repository.getConnection();

Objekt Connection se používá k přístupu do úložiště.

Načtení dat ze souboru — pomocí objektu Repository načteme a uložíme data.

connection.add(file, null, RDFFormat.RDFXML);

Dotazování na tvrzení a procházení výsledku — dotazujeme se přímo připojení na repository, za parametry předmět, predikát či objekt můžeme zadat objektu reprezentující kontrétní zdroj / literál nebo null, pokud tento parametr má být libovolný. Poslední parametr includeInferred určuje, jestli se ve výsledku mají objevit i tvrzení odovozená ze schématu / ontologie.

boolean includeInferred = false;
CloseableIterator<? extends Statement> statements =
  connection.getStatements(subject, predicate, object, includeInferred);
while (statements.hasNext() {
  Statement statement = statements.next();
  Subject subject = statement.getSubject();
  // ...
}

Vždy jsem myslel, že nejvíce záludností skýtá vývoj aplikací s Glassfish, EJB 3.0, JSF 1.2, NetBeans a nějakou tou databází. Ani si nepamatuju, kolikrát jsem tento kolotoč načítání zdrojových kódů, instalaci serveru, nastavení projektu v IDE, nastavení databáze, deploye a řešení problému dělal … :-) naposledy včera … ale to se vhodným manuálem dá podchytit. V rámci práce na projektu K–Space vyvstala nutnost si stáhnout projekt RDF repository Sesame2 a v té chvíli jsem poznal, co to je špatně navržená struktura projektu.

Zdrojové kódy jsou umístěny v SVN, to je v pořádku. Bohužel původně jednolité API se autoři během verzí alpha 3 a 4 rozhodli udělat „modulární“. Rozsekali jej tedy do mnoha podprojektů, které jsou v tomto repository naházeny v různých složkách — bohužel nejsou na stejné úrovni. Také klasická zásada, že obsah repository by měl jít vždy zkompilovat, zde neplatí — nenajdete zde žádné externí knihovny a zvláště utility z domény info.aduna se špatně hledají. Důvodem je fakt, že projekt je sestavován pomocí nástroje Maven 2, který by měl mít na starosti a) stažení knihoven b) nastavení projektů v IDE c) kompilaci. V praxi jsem přišel na to, že B mi nijak neulehčil a já musel vše naklikávat ručně a C jinak, než přes Maven vůbec nejde, něco tomu prostě chybí.

A to zde máme také maličkost takovou, že vývojáři Sesame asi zapomněli, co jsou správné zásady refaktoringu. Verze, kterou jsem z repository stáhnul, měla v části tříd odkazy na utility před jejich přetažením do samostatných util info.aduna a některé metody, které se volaly, v cílových objektech neexistovaly. Výsledný stav projektu po načtení do Eclipse si prohlédněte ve screenshotu na boku tohoto článku.

K dobrému tak přispívá jen fakt, že ze stránky projektu lze stáhnou oficiální build alpha 4, který funguje, obsahuje všechny externí knihovny a proto není potřeba si vlastní verzi ze zdrojových kódů sestavovat. Takže dokud nebudeme v K–Space přímo contribuovat Sesame2, můžeme se spolehnout na binárky.

A k čemu je to dobré?

Jedná se RDF knihovnu podporující veškeré operace, které se s těmito daty dělají. Výhodou je hlavně integrace úložiště. Dnes již asi slabší alternativou je Jena.

… není ve standardní distribuci přiliš příjemný. Důvodem je fakt, že sice jde o technologii postavenou na JavaServer Faces, ale jsou zde rozdíly, např. že jednotlivé tagové knihovny se načítají přes jmenné prostory XML. NetBeans 5 následně takové JSP stránky interpretuje tak, že JSF tagy vůbec nepozná a za chybné označuje použití Expression Language (EL) výrazů #{bean.property}. Řešením je podpůrný plu–in pro Facelets, který upraví JSP/JSF editor v NetBeans a také doplní několik užitečných wizardů.