ta metoda, ze nejaka aplikace vytvori "stream" dat, ktery nejaky filtr zachyti a zpracuje do vystupniho formatu ANIZ by tento filtr nejakym zpusobem mohl zpetne komunikovat s aplikaci, ktera ten "stream" vyrabi funguje jen do "stredne" problematickych reportu. Pri vetsi komplexite se nelze vyhnout primemu vytvareni dokumentu z nejake aplikace za pomoci nejakeho jazyka - nejlepe interpretacniho...
Vyhnout se tomu jde, akorát se to formátování musí provést v několika průchodech, kdy se výsledek předchozího kola formátování může použít jako jeden ze vstupů do kola dalšího.
Nevím jestli tohle zvládá FOP, ale komerční implementace XSL-FO (třeba XEP) to umí, a jde s tím udělat už opravdu vše (s čím jsem se zatím setkal:-).
ne, nejde to z principielnich duvodu, neni to tedy otazka jestli je nejaky produkt (filtr) lepsi nebo horsi a nebo jestli jiz ma neco implementovano, co konkurence jeste neovlada.
Beznym prikladem je faktura, kde se podle velikosti doprovodneho textu podari vytisknout jednou 5 a jindy treba 15 pozic. Na konci stranky je zapotrebi vydat sumy platne pro tuto stranku pricemz sumy se deli na zakladni castku a castku za doplnky - pricemz JEN aplikace je v danem okamziku sto rozhodnout, ktere z vytistenych pozic jsou obsahem zakladni dodavky a co jsou doplnky. Filtr by to mohl zjistit jen tak, ze by se v okamziku formatovani zeptal aplikace, co je treba nyni vytisknout, ale aplikace treba jiz nezije, nebot vyrobila stream pred dvema dny.
Samozrejme ze existuji pokusy zabudovat do formateru (filtru) callback funkce, ktere by komunikovaly s nejakou aplikaci, databazi, coz samozrejme take nevede k cili, nebot udaje v databazi mohou byt jina, nez v okamziku produkce onoho streamu dat.
Samozrejme, ze se jedna o komplikovane pripady ale i ty je treba resit a protoze z duvodu vyskytu takoych pripadu je interpreter zapotrebi, je nasnade ze se nasadi i na ty pripady jednodussi...
Jestli to je informace, ktera je nutna pri tisku a zaroven to vi jen aplikace, pak udelal autor streamu chybu. Zakladnim predpokladem spravnosti reseni je to, ze aplikace poskytuje vsechny dulezite informace. Co je dulezite specifikuji vsechny prvky retezu (aplikace, filtry, vizualizace).
asi jste presne nepochopil o co jde. My nehledame, jestli je nekdo vinen, jde o to, ze "prakticky" NENI mozne u komplikovanych reportu zaslat vsechny "dulezite" informace.
Tedy jeste jednou, ja odpovidal panu Koskovi na jeho mineni, ze pomoci mechanizmu roury (nebo retezu, jak pisety vy) lze realizovat i komplikovane reporty. (komplikovane jsou vesmes takove, ktere maji vice stranek a vyzaduji nejake mezisoucty apod). Toto neni definitivne mozne, protoze aplikace nemuze tusit jak bude probuhat proces formatovani a filtr/tisk zase netusi, jaka data bude zpracovavat. Jedine reseni teto situace je to (jak jsem psal), ze vse bude realizovane v jednom programu...
Přiznám se, že této argumentaci nerozumím. Pokud mám informaci a umím ji použít, pak jsem schopen ji zapsat do XML, třeba označit pomocí nějakého atributu. Pokud jsem s takovým atributem nepočítal, pak mám chybu v návrhu. Pokud uživatel ten atribut nepoužil, má chybně zadaná data. Pokud neexistuje možnost, jak informaci uložit v XML, pak pochybuji, že se dá vůbec nějak využít a je diskutabilní, jestli nějakou informaci mám.
U nás ve fy děláme něco jako ReportBuilder. Právě tyto věci jsou řešeny scriptováním na straně report builderu.
Pokud jsou řádky ve faktuře různě vysoké, přičemž velikost se řídí obsaženým textem, opravdu nikdo neví, kolik řádků na stránku se vejde na stránky než to je vyrenderováno.
No průběžné mezisoučty jde v XSL-FO udělat jedním průchodem (přes fo:marker). Pokud se jedná o součty pouze za jednu stránku, jde to bez problémů vyřešit dvěma průchody. Není potřeba přitom nějak zpětně komunikovat s aplikací, která daa generoval. Proces vypadá tak, že se v první fázi na XML aplikuje XSLT, které generuje FO. To se však neppřevede do PDF, ale do XML dokumentu, který u jednotlivých textů definuje, kde se na stránce vyskytují, jakým jsou fontem apod. Kromě toho se do tohoto dokumentu vloží (pomocí extenze XSL-FO značky, indentifikující jednotlivé položky reportu).
V druhém kole XSLT transformace na vstupu bere originální XML plus výsledek formátování z prvního kola. Díky informacím o layoutu a neviditelným identifikátorům položek ví, které položky jsou spolu na stránce a může je sečíst a součet vložit na konec stránky.
S tímto přístupem jde řešit opravdu složité situace, a zatím jsem v praxi nenarazil na situaci, která by tímto postupem nešla řešit (pravda někdy jen dva průchody nestačily).
Ano, máte pravdu v tom, že velmi složité reporty se nedají pomocí "jednocestného" filtru většinou vytvářet. V reálných informačních systémech to také může vypadat tak, že se export provede do Excelu a všechny další zpracování se udělají buď ručně nebo pomocí maker (cesta je to sice trnitá, ale pro mnoho firem i úřadů je to kupodivu zdaleka nejlevnější řešení).
Ze by byl problem v hrubem nepochopeni vyrazu "Jednocestny filtr"? Jednocestny znamena, ze jednorazove nacte data, zpracuje je (napriklad makra v excelu, uzivatel u klavesnice) a pak jednorazove poskytne vysledek.
Vami popsane reseni s excelem je jednocestne. Tedy pokud jeho soucasti neni zvednuti telefonu a domahani se doplnujicich informaci u 'dodavatele' vyexportovaneho souboru.
No, myslel jsem to tak, ze exporty z IS jsou vetsinou nedodelky. To neni ani tak problem programatoru (spis nedostatecne analyzy problemu), jako koncepce vyvoje techto IS, ktere jsou vlastne porad o krok pozadu za pozadavky uzivatelu - ti totiz dopredu nevedi, co chteji :-).
Potom to vypada napriklad tak, ze se nejprve na Excelovskem "reseni" zjisti, co vlastne uzivatele pozaduji a potom se to teprve (kdyz jsou penize) zavede jako bezna operace do IS.
Vystup do Excelu je samozrejme temer vzdy jednocestny, zpetna vazba je sice mozna (makra s OLE nebo HTTP/SMTP), ale v realnem provozu to spis nefunguje, nez funguje.