[algemeen]printen vanuit database

[seweso]

Ik zou eigenlijk willen weten wat op het moment (met de huidige stand van de techniek) de 'beste' manier is om complexe gegevens om te zetten naar een printbaar formaat, en welke methodes jullie daarvoor gebruiken. Ik heb het over complex data omdat ik gegevens die je gewoon met een raport-generator kan uitvoeren niet echt PW waardig is.

Als oplossing spreekt xhtml mij heel erg aan omdat deze simpel te genereren is met behulp van xslt. Met die methodiek loop ik namelijk nooit tegen limieten aan...werkelijk alles kan. Maar xhtml is niet gemaakt om te printen. En Xsl-Fo staat nog te veel in de kinderschoenen....

De methode die ik momenteel gebruik is een hibryde oplossing waarbij eerst de gegevens worden samengevoegd in Microsoft Word (mailmerge) en vervolgens word alle ingevoegde (x)html vervangen (insert file). Wat ik zelf redelijk brilliant vind maar niet echt een 'officiele' methode. Ooh ik gebruik dit systeem om klantkaarten op te bouwen, deze bestaan o.a. uit bedrijfsgegevens. contactpersoon-gegevens en een inventarisatie (een soort ingevulde/gedigitaliseerde enquete die telkens andere vragen kan bevatten). Hier wat voorbeeld xml die ik invoeg/exporteer in ms-word: http://test.seweso.com/inventarisatie.xml en http://test.seweso.com/script.xml

Andere methodes waar ik mee gewerkt heb:
• Rtf codes genereren (voor het genereren van de Acsi-gids)
• Via het ms-word active-x component (t.b.v. documenten voor ziekteverzuim registratie waarbij de structuur van de documenten dynamisch c.q. instelbaar is)
• Op de print-knop rammen in internet-explorer bij gegenereerde xhtml.

Dus.... kan dit slimmer of beter?

Ergens verwacht ik trouwens wel een discussie over wat raport-generatoren tegenwoordig allemaal wel niet kunnen. Maar in die discussie heb ik eigenlijk helemaal geen zin, behálve als je er werkelijk de door mij hierboven complexe data mee kan uitvoeren (als je twijfelt aub niks posten).

[ Voor 5% gewijzigd door seweso op 02-07-2004 10:08 . Reden: voorbeelden toegevoegd ]

[Alarmnummer]

Wat me zelf nog te binnen schiet zijn:
-template engines zoals velocity.
-latex, docbook of een ander formaat bestand genereren op basis van je data.

Met latex kan je oa pdf`s en html pagina`s maken dus dat zou misschien ook nog een optie zijn. Met docbook kan je ook een heel scala aan formaten uithoesten waar er vast wel een paar printbare tussen zitten.

En verder ben je met XML niet alleen beperkt tot XSLT om een ander formaat document aan te maken. Je zou eventueel ook met XPath/XQuery over je XML document heen kunnen wandelen om alle relevante data eruit te peuteren en op basis daarvan weer iets nieuws te maken.

[ Voor 28% gewijzigd door Alarmnummer op 02-07-2004 08:02 ]

[Verwijderd]

Ik doe het nu met XML en XSLT.. en printen gaat prima hoor, zelfs netjes per pagina een header etc.

Je moet je dan wel gaan beroepen op ietwat 'smerige' truukjes, door bv. een pagebreak te gebruiken.

Mag je IE-only ontwikkelen?

offtopic:
overigens lijkt het mij sterk dat bv. crystal reports niet kan wat je wil, als die het niet kan zul je er zelf ook een ENORME kluif aan hebben

[ Voor 29% gewijzigd door Verwijderd op 02-07-2004 08:05 ]

[P_de_B]

Ik waag me toch aan de uitspraak dat het goed met een rapport generator te doen is. Wij hebben dermate complexe rapporten met een rapport generator (CR) gemaakt dat ik niet snel overtuigd ben van het feit dat het niet zou kunnen. Kun je misschien ergens een voorbeeldje van een rapport plaatsen?

Exporteren naar verschillende bestandsformaten is ook eenvoudig mogelijk.

[Verwijderd]

Ik weet niet in welke taal je devved, maar is die koppeling met Word niet rete-traag? Hoe koppel je dat dan? Over het algemeen gaat dat via OLE, en dat is niet vooruit te branden in mijn ervaring.

[Alarmnummer]

Als jullie mogen, dan mag ik ook: Jasper Reports

[seweso]

Alarmnummer schreef op 02 juli 2004 @ 07:58:
Wat me zelf nog te binnen schiet zijn:
-template engines zoals velocity.
-latex, docbook of een ander formaat bestand genereren op basis van je data.

Met latex kan je oa pdf`s en html pagina`s maken dus dat zou misschien ook nog een optie zijn. Met docbook kan je ook een heel scala aan formaten uithoesten waar er vast wel een paar printbare tussen zitten.

En verder ben je met XML niet alleen beperkt tot XSLT om een ander formaat document aan te maken. Je zou eventueel ook met XPath/XQuery over je XML document heen kunnen wandelen om alle relevante data eruit te peuteren en op basis daarvan weer iets nieuws te maken.

Ik beschouw XPath en XQuery als onderdeel van XSLT, wat een beetje verwarrend is...volgens mij is Xsl de officiële overkoepelende naam. Als je met XSLT aan de slag gaat gebruik je sowieso automatisch XPath.

Pdf's genereren lijkt me sowieso beter dan met MS-Word klooien. Kun je een gegenereerde pdf ook heel makkelijk (en snel) naar een printer sturen? Maar om nou nog een taal/formaat (latex) te gaan gebruiken als tussen-laag tussen xml en pdf lijkt me niet zo handig.

Het grote voordeel van xhtml gebruiken voor het printen van gegevens is dat je dezelfde xhtml ook op internet kan gebruiken (en deze in intern desktop-applicaties kan tonen middels een web-browser component). Dat scheelt natuurlijk ontwikkel-tijd.

Verwijderd schreef op 02 juli 2004 @ 08:04:
Ik doe het nu met XML en XSLT.. en printen gaat prima hoor, zelfs netjes per pagina een header etc.

Je moet je dan wel gaan beroepen op ietwat 'smerige' truukjes, door bv. een pagebreak te gebruiken.

Mag je IE-only ontwikkelen?

offtopic:
overigens lijkt het mij sterk dat bv. crystal reports niet kan wat je wil, als die het niet kan zul je er zelf ook een ENORME kluif aan hebben

Ik wil eigenlijk liever niet afhankelijk zijn van enig microsoft product. Dat is nou júist de reden om xml en xhtml te gaan gebruiken.

Ik heb het trouwens niet over het genereren van raporten maar over het genereren van documenten. Ik versta onder raporten een veredelde lijst met gegevens die opgebouwd word naar aanleiding van een (platgeslagen) tabel. En een document kan eigenlijk vanalles bevatten: dynamisch gegenereerde plaatjes, grafieken, complexe tabellen, complexe opsommingen, hyperlinks. Eigenlijk op het niveau van een webpagina, die genereer je namelijk ook niet ff met crystal reports.

P_de_B schreef op 02 juli 2004 @ 08:07:
Ik waag me toch aan de uitspraak dat het goed met een rapport generator te doen is. Wij hebben dermate complexe rapporten met een rapport generator (CR) gemaakt dat ik niet snel overtuigd ben van het feit dat het niet zou kunnen. Kun je misschien ergens een voorbeeldje van een rapport plaatsen?

Exporteren naar verschillende bestandsformaten is ook eenvoudig mogelijk.

Een goed voorbeeld van wat niet met een raport generator kan is dit: http://test.seweso.com/inventarisatie.xml en http://test.seweso.com/script.xml

Verwijderd schreef op 02 juli 2004 @ 08:08:
Ik weet niet in welke taal je devved, maar is die koppeling met Word niet rete-traag? Hoe koppel je dat dan? Over het algemeen gaat dat via OLE, en dat is niet vooruit te branden in mijn ervaring.

Ik ontwikkelde toen in Visual Basic, en dat was inderdaad erg traag maar dat was toendertijd acceptabel. Nu ontwikkel ik in Visual Foxpro en PHP.

Alarmnummer schreef op 02 juli 2004 @ 08:11:
Als jullie mogen, dan mag ik ook: Jasper Reports

Heb op er op geklikt, ging er vanuit dat het vast weer zo'n 'acht in een dozijn'-raportgenerator zou zijn.... maar ik zie allemaal leuke woordjes: Java , Html (waar is de x?), Xml . Mijn interesse is gewekt... ik ga daar zeker nog een keer goed naar kijken (maar nu even niet).

[Alarmnummer]

seweso schreef op 02 juli 2004 @ 09:44:
[...]
Ik beschouw XPath en XQuery als onderdeel van XSLT, wat een beetje verwarrend is...volgens mij is Xsl de officiële overkoepelende naam. Als je met XSLT aan de slag gaat gebruik je sowieso automatisch XPath.

Je kunt XPath,XQuery ook buiten XSLT gebruiken. Je kunt bv vanuit java ook met XPath/XQuery over je documenten wandelen. XSLT is heel leuk en aardig, maar soms heb je een echte programmeertaal nodig en is XSLT qua mogelijkheden te beperkt.

Pdf's genereren lijkt me sowieso beter dan met MS-Word klooien. Kun je een gegenereerde pdf ook heel makkelijk (en snel) naar een printer sturen? Maar om nou nog een taal/formaat (latex) te gaan gebruiken als tussen-laag tussen xml en pdf lijkt me niet zo handig.

Latex is geen formaat maar een opmaak taal (net zoals html dat ook is). Maar dan voor het maken van postscript, pdf en nog een hele rits andere formaten.

Het grote voordeel van xhtml gebruiken voor het printen van gegevens is dat je dezelfde xhtml ook op internet kan gebruiken (en deze in intern desktop-applicaties kan tonen middels een web-browser component). Dat scheelt natuurlijk ontwikkel-tijd.

Niets belet je toch om een aantal verschillende backends te gebruiken?

[P_de_B]

seweso schreef op 02 juli 2004 @ 09:44:
Een goed voorbeeld van wat niet met een raport generator kan is dit: http://test.seweso.com/inventarisatie.xml en http://test.seweso.com/script.xml

Ik weet niet hoe je backend er precies uitziet, maar dat vragenrapportje kun je gerust maken met een rapportgenerator.

[seweso]

Alarmnummer schreef op 02 juli 2004 @ 09:51:
[...]

Je kunt XPath,XQuery ook buiten XSLT gebruiken. Je kunt bv vanuit java ook met XPath/XQuery over je documenten wandelen. XSLT is heel leuk en aardig, maar soms heb je een echte programmeertaal nodig en is XSLT qua mogelijkheden te beperkt.

Ik gebruik reeds XQuery als ik gegevens middels MSXML4 weer terug inlees in de database.

[...]

Latex is geen formaat maar een opmaak taal (net zoals html dat ook is). Maar dan voor het maken van postscript, pdf en nog een hele rits andere formaten.

Hmm, misschien zie ik het verkeerd maar de Latex 'opmaak taal' heeft toch ook een bepaald formaat. Dat is dan toch weer iets wat ik er bij moet gaan leren, en dat kost tijd. Daarnaast denk ik dat een taal als xhtml meer toekomst heeft dan Latex.

[...]

Niets belet je toch om een aantal verschillende backends te gebruiken?

Op één of andere manier klinkt 'verschillende backends' als veel extra werk. Of mis ik hier iets? Kun je backends in deze context voor mij uitleggen?

[seweso]

P_de_B schreef op 02 juli 2004 @ 09:54:
[...]
Ik weet niet hoe je backend er precies uitziet, maar dat vragenrapportje kun je gerust maken met een rapportgenerator.

Je hebt me overtuigd met je goede argumentatie

[Alarmnummer]

seweso schreef op 02 juli 2004 @ 10:01:
[...]
Hmm, misschien zie ik het verkeerd maar de Latex 'opmaak taal' heeft toch ook een bepaald formaat.

Het zijn gewoon tekst bestanden netzoals als html dat ook is.

Dat is dan toch weer iets wat ik er bij moet gaan leren, en dat kost tijd. Daarnaast denk ik dat een taal als xhtml meer toekomst heeft dan Latex.

Je bent nu appels met peren aan het vergelijken. Ik denk dat Latex eigelijk een van de weinig serieuze opmaaktalen is om documenten op te maken.

Op één of andere manier klinkt 'verschillende backends' als veel extra werk. Of mis ik hier iets? Kun je backends in deze context voor mij uitleggen?

Ik bedoel met backend dat je informatie ophaalt en daarna een 'outputter' selecteerd, bv een html outputter en een latex outputter. De outputters zijn dan de backend van je systeem.

De kreet komt meer uit de compilerbouw waar een backend dan het onderdeel is dat instructies genereerd voor een specifiek platform (machine, os). Maar de applicatie in het geheel die is niet gebonden aan dat specifieke platform.

[ Voor 3% gewijzigd door Alarmnummer op 02-07-2004 10:09 ]

[P_de_B]

seweso schreef op 02 juli 2004 @ 10:06:
[...]
Je hebt me overtuigd met je goede argumentatie

Wat verwacht je dan? Dat ik het rapportje even voor je ga maken?

maar goed: Groeperen op vraag, de mogelijke antwoorden in de detailsectie, en de detailsectie opmaken in kolommen.

[ Voor 22% gewijzigd door P_de_B op 02-07-2004 10:15 ]

[Verwijderd]

V.V.I.P van xerox kan je ook gebruiken, maar ik denk dat dat net als velocity (EFI) allemaal wat te duur is. Werken doet het zekers wel, en de mogelijkheden zijn legio.

[Alarmnummer]

Verwijderd schreef op 02 juli 2004 @ 10:13:
velocity (EFI) allemaal wat te duur is.

Velocity is opensource. Een fantastisch jakarta/apache project.

[seweso]

P_de_B schreef op 02 juli 2004 @ 10:12:
[...]

Wat verwacht je dan? Dat ik het rapportje even voor je ga maken?

Ik durfde het eigenlijk niet te vragen, maar aangezien je het zelf voorsteld: graag! Je bent een schat

Verwijderd schreef op 02 juli 2004 @ 10:13:
V.V.I.P van xerox kan je ook gebruiken, maar ik denk dat dat net als velocity (EFI) allemaal wat te duur is. Werken doet het zekers wel, en de mogelijkheden zijn legio.

Mijn ervaring met paketten waar je (veel) geld voor moet betalen is dat ze nooit kunnen wat ze beloven en/of ze kunnen veel te veel. Ik hou persoonlijk meer van programma's die gratis zijn. Ooh wacht velocity is open-source... hmm.

Alarmnummer schreef op 02 juli 2004 @ 10:08:
[...]
Het zijn gewoon tekst bestanden netzoals als html dat ook is.

Eeh een html document is toch echt niet in hetzelfde formaat als een text document. Net zo min als een xml document in hetzelfde formaat is als csv. Latex heeft net als (x)html, xml en csv bepaalde regels waaraan het document moet voldoen, al die regels bepalen het bestands formaat (volgens mij vallen we over de uitleg van het woord 'formaat'). Deze regels/c.q. dit formaat van Latex die je moet kennen wil je er gebruik van kunnen maken, en dus kost het meer tijd dan dat je een bekende techniek gebruikt die veelzijdiger is toe te passen (op internet/in mail/etc).

[...]

Je bent nu appels met peren aan het vergelijken. Ik denk dat Latex eigelijk een van de weinig serieuze opmaaktalen is om documenten op te maken.

Dat kan zijn, maar is er een über xslt welke xhtml naar Latex omvormt? Dan heb ik er misschien wel oren naar...

[...]

Ik bedoel met backend dat je informatie ophaalt en daarna een 'outputter' selecteerd, bv een html outputter en een latex outputter. De outputters zijn dan de backend van je systeem.

De kreet komt meer uit de compilerbouw waar een backend dan het onderdeel is dat instructies genereerd voor een specifiek platform (machine, os). Maar de applicatie in het geheel die is niet gebonden aan dat specifieke platform.

Waarom zou ik meerdere outputters maken als ik er nu maar één hoef te maken? Ik wil één uitvoer genereren en vervolgens standaard software gebruiken om deze uitvoer om te zetten naar andere formaten (pdf/ms-word/print).

[P_de_B]

seweso schreef op 02 juli 2004 @ 10:29:
[...]
Ik durfde het eigenlijk niet te vragen, maar aangezien je het zelf voorsteld: graag! Je bent een schat

Je kunt wel heel sarcastisch doen, maar ik krijg de indruk dat je gewoon minimaal drie mooie woorden in je oplossing wilt hebben.

Een rapportgenerator neemt je gewoon veel werk uit handen (bijv. het rechtstreeks exporteren naar word/pdf).

[Alarmnummer]

seweso schreef op 02 juli 2004 @ 10:29:
[...]
Ik durfde het eigenlijk niet te vragen, maar aangezien je het zelf voorsteld: graag! Je bent een schat

Deze opmerking past hier niet.

Dat kan zijn, maar is er een über xslt welke xhtml naar Latex omvormt? Dan heb ik er misschien wel oren naar...

Ik denk dat dat wel mogelijk is, maar je moet er rekening mee houden dat pdf, postscript (dingen die latex kan maken) zich beter laten printen dan html pagina`s. HTML kan een fucking pain in the ass zijn om te printen.

Waarom zou ik meerdere outputters maken als ik er nu maar één hoef te maken? Ik wil één uitvoer genereren en vervolgens standaard software gebruiken om deze uitvoer om te zetten naar andere formaten (pdf/ms-word/print).

Het kan afhankelijk zijn van de situatie. Als jij iets heel strak wilt printen dan kom je waarschijnlijk in de problemen op het moment dat jij op de html toer gaat. En als jij iets gaafs op het internet wilt zetten, kom jij in de problemen als je het alleen maar hebt gemaakt voor de printer.

Het is dus afhankelijk van de situatie of jij meerdere outputters nodig bent.

[seweso]

P_de_B schreef op 02 juli 2004 @ 10:34:
[...]

Je kunt wel heel sarcastisch doen, maar ik krijg de indruk dat je gewoon minimaal drie mooie woorden in je oplossing wilt hebben.

Een rapportgenerator neemt je gewoon veel werk uit handen (bijv. het rechtstreeks exporteren naar word/pdf).

Ik probeerde jou op een leuke manier aan te moedigen om te onderbouwen waarom jij denkt dat het wél kan. Hoewel dat misschien de omgekeerde situatie is en juist ík moet uitleggen waarom het níet kan en jij vervolgens dat kan weerleggen.

Ik weet dat je met een raport generator soms met een paar klikken meer kan doen dan je met bijvoorbeeld xslt in een uur. Maar het probleem is dat de data waar ik het over heb té complex is om in een raport-generator te stoppen. En volgens mij is de mate van complexiteit redelijk duidelijk in het eerste voorbeeld dat ik gegeven heb (2e voorbeeld is een stuk simpeler). Als je goed naar het eerste voorbeeld heb gekeken dan zie je dat de antwoorden gecodeerd zijn (opzoeklijstjes) en dat de naam én de code word afgedrukt, kan zoiets ook in een raport generator?

Alarmnummer schreef op 02 juli 2004 @ 10:35:
[...]

Deze opmerking past hier niet.

het was niet lullig bedoelt

[...]

Ik denk dat dat wel mogelijk is, maar je moet er rekening mee houden dat pdf, postscript (dingen die latex kan maken) zich beter laten printen dan html pagina`s. HTML kan een fucking pain in the ass zijn om te printen.

[...]

Het kan afhankelijk zijn van de situatie. Als jij iets heel strak wilt printen dan kom je waarschijnlijk in de problemen op het moment dat jij op de html toer gaat. En als jij iets gaafs op het internet wilt zetten, kom jij in de problemen als je het alleen maar hebt gemaakt voor de printer.

Het is dus afhankelijk van de situatie of jij meerdere outputters nodig bent.

Het door mij genoemde voorbeeld komt behoorlijk strak uit de printer. Maar ik vraag me idd af of ik uiteindelijk dezelfde xhtml kan gebruiken op het internet, veel van de technieken zijn in elk geval hetzelfde wat tijdswinst oplevert.

[P_de_B]

seweso schreef op 02 juli 2004 @ 11:09:
[...]
Ik probeerde jou op een leuke manier aan te moedigen om te onderbouwen waarom jij denkt dat het wél kan. Hoewel dat misschien de omgekeerde situatie is en juist ík moet uitleggen waarom het níet kan en jij vervolgens dat kan weerleggen.

Ik weet dat je met een raport generator soms met een paar klikken meer kan doen dan je met bijvoorbeeld xslt in een uur. Maar het probleem is dat de data waar ik het over heb té complex is om in een raport-generator te stoppen. En volgens mij is de mate van complexiteit redelijk duidelijk in het eerste voorbeeld dat ik gegeven heb (2e voorbeeld is een stuk simpeler). Als je goed naar het eerste voorbeeld heb gekeken dan zie je dat de antwoorden gecodeerd zijn (opzoeklijstjes) en dat de naam én de code word afgedrukt, kan zoiets ook in een raport generator?

Ok, dan heb ik het verkeerd opgevat. Het eerste voorbeeld snap ik niets van, wat moet daar precies weergegeven worden? Ik zie alleen rare opmaakcodes.

[seweso]

P_de_B schreef op 02 juli 2004 @ 11:15:
[...]
Ok, dan heb ik het verkeerd opgevat. Het eerste voorbeeld snap ik niets van, wat moet daar precies weergegeven worden? Ik zie alleen rare opmaakcodes.

Ik heb even de xml data van voorbeeld 1 wat overzichtelijker gemaakt zodat je deze beter kan begrijpen als je de bron toont... (in IE onder menu beeld > bron). (hoewel ik ook nog eens de xml online had kunnen zetten zonder verwijzing naar het xslt-sjabloon ... hmmm)

[P_de_B]

seweso schreef op 02 juli 2004 @ 11:20:
[...]
Ik heb even de xml data van voorbeeld 1 wat overzichtelijker gemaakt zodat je deze beter kan begrijpen als je de bron toont... (in IE onder menu beeld > bron). (hoewel ik ook nog eens de xml online had kunnen zetten zonder verwijzing naar het xslt-sjabloon ... hmmm)

Aha, in Firefox ziet het er niet uit, in IE zie ik wat de bedoeling is.

Natuurlijk afhankelijk van hoe de database eruit ziet, denk ik nog steeds dat het wel kan. Kun je een voorbeeldje van de db geven?

[seweso]

P_de_B schreef op 02 juli 2004 @ 11:23:
[...]

Aha, in Firefox ziet het er niet uit, in IE zie ik wat de bedoeling is.

Natuurlijk afhankelijk van hoe de database eruit ziet, denk ik nog steeds dat het wel kan. Kun je een voorbeeldje van de db geven?

Hier het relationele schema van de desbetreffende database:

[Alarmnummer]

Staat de relatie antwoord en antwoord code niet verkeerd? En wat ben je verder aan het maken? Ik ben zelf namelijk veel bezig met knowledgebases ed.

[Verwijderd]

Alarmnummer schreef op 02 juli 2004 @ 10:35:
Ik denk dat dat wel mogelijk is, maar je moet er rekening mee houden dat pdf, postscript (dingen die latex kan maken) zich beter laten printen dan html pagina`s. HTML kan een fucking pain in the ass zijn om te printen.

Dat is een understatement .. bv. zo'n tabel als uit je voorbeeld, wat als daar niet 5 items maar 500 in staan?

Het kan afhankelijk zijn van de situatie. Als jij iets heel strak wilt printen dan kom je waarschijnlijk in de problemen op het moment dat jij op de html toer gaat. En als jij iets gaafs op het internet wilt zetten, kom jij in de problemen als je het alleen maar hebt gemaakt voor de printer.

Daarom zou ik niet gaan 'klooien' met latex oid. Ik zou het gewoon bij een .xml houden, met daarbij verschillende .xsl(t)'s/xpath/xquery/whatever om de juiste presentatievorm te maken.

Het helpt als je je kunt beperken voor één browser.

Overigens, niet om vervelend te zijn, maar ik weet eigenlijk wel zeker dat bv. Crystal Reports gewoon kan wat jij wil. Het kan even zoeken zijn om e.e.a. goed te krijgen, maar dat pakket kan verdomde veel. Je kunt bv. heel uitgebreid met subreports gaan werken, cross-tabs, formules, functies, etc, om je rapport te customizen. Crystal kan exporteren naar verschillende formaten en wordt geleverd met een server die je rapporten bv. op je intranetserver kan publiceren.

Eerlijk gezegd vind ik dat gezien de situatie de 'professionelere' optie. Met XML icm. andere zaken blijft het toch altijd een beetje gekunsteld. Je wilt de ICT-ers de kost niet geven die bv. nog nooit van latex gehoord hebben, of denken dat je dat tegen een muur moet smeren. Vanuit het oogpunt van onderhoudbaarheid is dan een prefab rapportenbakker imo verstandiger..

[seweso]

Alarmnummer schreef op 02 juli 2004 @ 13:25:
Staat de relatie antwoord en antwoord code niet verkeerd? En wat ben je verder aan het maken? Ik ben zelf namelijk veel bezig met knowledgebases ed.

Het word een beetje offtopic hierzo, en het gaat een beetje over mijn probleem en niet over complexe document generatie in het algemeen. Of ben ik de enige die daar mee bezig is c.q. dat nodig heeft?

Nee die relatie staat goed (een antwoord kan nul of meerdere codes bevatten en een code kan bij 0 of meer antwoorden worden gebruikt), de tabel antwoordcodes is simpelweg de 'implementatie' van de veel-op-veel relatie tussen antwoord en code.

Hier staat meer over de knowledge-base die ik in elkaar gedraaid heb, verder kun je ook woovi zoeken op google .

[Alarmnummer]

Verwijderd schreef op 02 juli 2004 @ 13:43:
[...]


Dat is een understatement .. bv. zo'n tabel als uit je voorbeeld, wat als daar niet 5 items maar 500 in staan?

Daarom zou ik niet gaan 'klooien' met latex oid. Ik zou het gewoon bij een .xml houden, met daarbij verschillende .xsl(t)'s/xpath/xquery/whatever om de juiste presentatievorm te maken.

Ik weet niet of XML automatisch de goeie oplossing is. Stel dat de informatie die je krijgt uit een database komt, of mooi uit eigen interne structuren. Dan hoeft het niet noodzakelijk te zijn om XML te gebruiken om je data in op te slaan en dat te gaan gebruiken om de transformaties op te laten plaatsvinden. Voor mensen die een beetje creatief zijn kan je op heel veel mooie manieren ook zelf transformaties op eigen structuren loslaten.

XML is dus niet automatisch de juiste oplossing.. en in sommige gevallen is het domweg overbodig.

Verder kan latex wel een mogelijk eindproduct zijn van die XSLT transformatie op je XML. Dan hoef je alleen nog maar documenten erop te genereren. ALs XML wel noodzakelijk is, dan zou ik meteen voor FOP gaan.

[Alarmnummer]

seweso schreef op 02 juli 2004 @ 13:46:
[...]
Het word een beetje offtopic hierzo, en het gaat een beetje over mijn probleem en niet over complexe document generatie in het algemeen. Of ben ik de enige die daar mee bezig is c.q. dat nodig heeft?

Ik ben zelf veel bezig met expertsystemen en in de toekomst gaan we ook een document generatie systeem ontwikkelen wat een samenwerking is tussen het expertsysteem, een template engine en de gebruiker Je bent dus zeker niet de enigste.

Hier staat meer over de knowledge-base die ik in elkaar gedraaid heb, verder kun je ook woovi zoeken op google

Ik kan niet echt uit je verhaal opmaken wat voor mechanisme je gebruikt om de vragen te beantwoorden? Heb je voldoende aan de sql functionaliteit? Gebruik je een inference engine/ rule engine? Of heb je alles hard in een normale imperatieve taal geprogrammeerd?

[ Voor 4% gewijzigd door Alarmnummer op 02-07-2004 13:57 ]

[Verwijderd]

Alarmnummer schreef op 02 juli 2004 @ 13:50:
Ik weet niet of XML automatisch de goeie oplossing is. Stel dat de informatie die je krijgt uit een database komt, of mooi uit eigen interne structuren. Dan hoeft het niet noodzakelijk te zijn om XML te gebruiken om je data in op te slaan en dat te gaan gebruiken om de transformaties op te laten plaatsvinden. Voor mensen die een beetje creatief zijn kan je op heel veel mooie manieren ook zelf transformaties op eigen structuren loslaten.

Uiteraard.. ik zie vaak projecten waarin men via kunst en vliegroutes ergens .xml in gaat passen, zuiver omdat je dan xml gebruikt hebt, niet omdat dat technisch beter is.

Toch.. als je van dezelfde informatie verschillende representaties nodig hebt, dan is XML al snel een van de betere opties imo.

Verder kan latex wel een mogelijk eindproduct zijn van die XSLT transformatie op je XML. Dan hoef je alleen nog maar documenten erop te genereren. ALs XML wel noodzakelijk is, dan zou ik meteen voor FOP gaan.

Eigenlijk nog te vroeg voor.. ze geven het zelf al aan 'the worlds first' dus ik zou zeker nog wat kinderziektes verwachten. 't is ook nog een 0.20 versie, dus niet klaar voor serieus gebruik imo. Ze hebben nog niet eens de hele W3C XSL-FO recommendations geimplementeerd.

http://xml.apache.org/fop/

[ Voor 3% gewijzigd door Verwijderd op 02-07-2004 14:00 ]

[Bobco]

Verwijderd schreef op 02 juli 2004 @ 13:59:
[...]
Eigenlijk nog te vroeg voor.. ze geven het zelf al aan 'the worlds first' dus ik zou zeker nog wat kinderziektes verwachten. 't is ook nog een 0.20 versie, dus niet klaar voor serieus gebruik imo. Ze hebben nog niet eens de hele W3C XSL-FO recommendations geimplementeerd.
http://xml.apache.org/fop/

Ik gebruik FOP al wel voor het genereren van kleine PDFs en dat werkt uit de kunst. Ik ben bang dat voor complexere documenten geldt 'eet het en je weet het'.

[BestTested!]

seweso schreef op 02 juli 2004 @ 11:09:
Ik weet dat je met een raport generator soms met een paar klikken meer kan doen dan je met bijvoorbeeld xslt in een uur. Maar het probleem is dat de data waar ik het over heb té complex is om in een raport-generator te stoppen. En volgens mij is de mate van complexiteit redelijk duidelijk in het eerste voorbeeld dat ik gegeven heb (2e voorbeeld is een stuk simpeler). Als je goed naar het eerste voorbeeld heb gekeken dan zie je dat de antwoorden gecodeerd zijn (opzoeklijstjes) en dat de naam én de code word afgedrukt, kan zoiets ook in een raport generator?

Naar mijn weten wel. Alleen zou je wel een paar omwegen moeten gebruiken. Zelf gebruik in Crystal Reports. (Crystal Repors 9.0 Enterprise Edition om precies te zijn). En na het volgen van een aantal cursussen kom je er inderdaad achter dat zo'n pakket alles kan wat het belooft (die scriptjes in CR zijn errrrug handig).

Ik gebruik het nu geintegreerd in VB6.0 en moet zeggen dat ik er zeer tervreden over ben. Ik zal even een paar puntjes aanduiden:

1 Het opstellen van toch wel complexe rapporten vergt niet veel tijd
2 Het makkelijk kunnen outputten naar verschillende formaten (pdf, html, doc, txt etc.)
3 Het direct kunnen mailen/faxen/printen van de rapporerten.
4 De integratie in VB6.0 (niet alleen invullen, maar ook het designen van nieuwe rapporten)
5 Er is alleen wel 66MB aan dll's nodig om te kunnen werken (gelukkig wel licentie-vrij)
6 De ingebouwde SQL variant (een of andere mix tussen SQL en VB) is erg snel
7 Gelukkig is er wel de mogelijkheid om gewoon SQL te kunnen gebruiken (na enig speurwerk)

Zelf gebruik ik het om facturen, loonlijstjes, verlof- en ziekerapporten mee te genereren in een zelfgebouwde app. Ik kan nu met een enkele knop de facturen of loonlijstjes naar werknemers of klanten mailen en faxen.