[Alg] Webbased Rapport genereren *

[Verwijderd]

Ik heb me vandaag verdiept in het online genereren van o.a. PDF-documenten.
Er zijn talloze componenten op de markt waar je met ASP zelf een PDF-document kan generen.

Helaas is dit nog niet zo eenvoudig; vooral als je iets dieper wil en meer gegevens wilt combineren.
Weet iemand of er een soort report-generator bestaat waarmee ik online rapporten kan genereren ?

Ik stel me voor dat er wellicht iets bestaat als een MS Access Reportprogramma waarmee ik m'n rapport op kan maken en vervolgens als PDF aanbieden aan de bezoeker van de site.

Iemand meer info hierover ?

[justmental]

Een commercieel pakket waarmee je dit mooi kunt doen is Crystal Reports:
http://www.serversys.com/crystal_reports.html

[Verwijderd]

Ik weet toevallig dat Apache Cocoon d.m.v. XML -> XSLT -> PDF documenten kan maken. Er zit een voorbeeld bij cocoon, waarbij een hello world of zo naar PDF wordt omgezet. Cocoon is gratis en beschikbaar op alle platformen (maakt gebruik van java).

[mbravenboer]

Direct PDF genereren is nutteloos. Gebruik dan liever bijvoorbeeld xsl formatting objects. Je kan een willekeurig xml taal (zelf ontworpen, standaard, of van een ander bedrijf) transformeren naar xsl-fo, welke je dan weer kan omzetten in pdf, maar ook in bijvoorbeeld postscript. Die laatste omzetting wordt gedaan door een tool als fop (van apache).

[Verwijderd]

Misschien even voor de duidelijkheid; het gaat erom dat de applicatie op een IIS-omgeving kan draaien (in combinatie met ASP).

Waarom is direct PDF-genereren nutteloos ? PDF is toch een perfect medium om af te drukken documenten aan een eindgebruiker te verschaffen ?

[Verwijderd]

In de developer versie van Crystal Reports heb je hiervoor verschillende ActiveX componenten die je gewoon in je ASP opneemt met wat script.
Deze kunnen afdrukken naar scherm en printers maar bv. ook naar PDF, Excell etc. exporteren.
Verder heb je ook nog speciaal hiervoor Crystal Enterprise maar deze vind ik iets te prijzig.

[mOrPhie]

Hoewel ik zaken als Crystal Reports al erg goed vind werken kun je ook 'ns nadenken over XML-Reports.

Je schrijft alle report-info weg in een mooie XML. Vervolgens kun je die XML:
• opslaan in een database
• opslaan als file
• met een xslt gigantisch mooi tonen
• als merge-source voor document-merging in Word gebruiken
• als datafile, om een crystal-report te maken, gebruiken
• een pdf opmaken

Vooraf het report als XML opslaan geeft dus als voordeel dat je nu niet hoeft te kiezen welk report-medium je gaat gebruiken. Je reporter kun je dus volledig maken en de presentatie van dat report kun je dan later regelen.

[bigoldie]

[off topic]
Ik heb zelf een systeem gebouwd waarbij er doormiddel van php en pdflib een pdf wordt gemaakt met inloggegevens. Hierbij worden adressen uit een database gehaald, teksten worden vooraf opgegeven en inloggegevens worden ook uit een database gehaald.
[/off topic]

Reden van deze opmerking? Om maar te zeggen dat pdf-generen niet nutteloos is.

[mbravenboer]

bigoldie: Reden van deze opmerking? Om maar te zeggen dat pdf-generen niet nutteloos is.

Tja, het spijt me, maar ik blijf zelfs na jouw 'succes verhaal' nog zeggen dat direct PDF genereren nutteloos is. Kennelijk is het niet duidelijk wat ik met 'direct' bedoelde en waarom het dan nutteloos is, dus hier dan maar een beetje uitleg.

Allereerst: met 'direct' bedoel ik dat je een document genereert in termen van pdf: je bent zelf aan het programmeren met als direct doel om een pdf op te bouwen.

Waarom is dit dan nutteloos? Je code is voor een enorm deel niet herbruikbaar als je een ander output formaat nodig hebt. Je code is namelijk bezig met het genereren van pdf en houdt daarbij, tenzij je een briljante programmeur bent, niet rekening met mogelijke uitbreiding naar andere output formaten. Je bindt je applicatie dus direct aan pdf. In de toekomst is er een grote kans op code duplicatie als je een ander output formaat wilt.

Directe bindngen moet je altijd voorkomen als het enigzins mogelijk is. Je wilt bijvoorbeeld niet dat je tekstverwerker alleen maar kan printen naar bijvoorbeeld een HP Deskjet. Je wilt niet dat je processor alleen in een Asus moederbord werkt. Ook wil je niet dat de webbrowser die jij gebruikt alleen kan communiceren met een specifieke webserver (of andersom). Ik heb deze voorbeelden bewust gekozen: in alle gevallen is er namelijk een standaard interface waardoor de verschillende onderdelen kunnen communiceren, maar toch niet direct van elkaar afhankelijk zijn.

Bij het genereren van PDF is dit ook zo. Er bestaan mogelijkheden om je applicatie niet direct te verbinden aan PDF. Waarom die dan niet benutten?

Zoals al eerder in dit topic is opgemerkt moet je dus proberen om de zaken te scheiden. Jouw programma is alleen geinteresseerd in het produceren van een rapport. Of dat rapport nu uiteindeljk aangeboden gaat worden in een van de formaten pdf, postscript, rtf, word, open-office doc, png, html pagina of wat dan ook is, maakt voor je applicatie (meestal) niets uit. Beter is het daarom om het produceren van een bepaald output formaat te scheiden.

Hoe kan je dit dan realiseren? Een mogelijke oplossing is dat je applicatie een rapport (of de data voor een standaard rapport) in een XML formaat produceert. XML is ideaal voor het uitwisselen van data tussen software componenten. Wat voor XML formaat moet je dan kiezen? Goede vraag. Liefst wil je natuurlijk een soort standaard, want daar is vast goed over nagedacht en daar bestaan wellicht al allemaal tools en APIs voor.

Uiteindelijk wil je dit XML formaat natuurlijk toch nog gaan presenteren. Dit kan je doen door het het transformeren naar bijvoorbeeld XHTML of XSL Formatting Objects. Deze transformatie kan je implementeren in XSLT. XHTML kan je natuurlijk direct bekijken in een browser, XSL Formatting Objects kan je door een processor laten omzetten naar concrete output formaten die een gebruiker wil krijgen: PDF of Postscript bijvoorbeeld. FOP kan dit klusje voor je opknappen. Op deze manier worden ook boeken geproduceerd, dus ik kan je garanderen dat dit een krachtige oplossing is!

Ik lever dus vooral kritiek op het direct produceren van PDF omdat je de mogelijkheden van je applicatie onnodig beperkt. Met enige investing in het verkrijgen van kennis van betere technieken kan je je applicatie omtoveren in een systeem waar de taken en verantwoordelijkheden prachtig gescheiden zijn. Dit zorgt ervoor dat je applicatie flexibel is en goed voorbereid is op de toekomst.

Je zou eens moeten weten hoeveel muggen me gestoken hebben tijdens het tikken van dit verhaal .

[mbravenboer]

Oh ja, er moet natuurlijk nog wel even een succes verhaal bij .

In een applicatie die ik geschreven heb pastte ik gelukkig al de hierboven beschreven methode toe om documenten te kunnen afdrukken en exporteren. Het programma produceerde XML en via een XSL Transformatie kan dit omgezet worden naar XHTML of XSL-FO. Deze aanpak werkt leuk, want FOP handelt verder de output naar een printer, pdf of postscript wel af.

Maar ... behalve dat je verschillende output formaten zou willen ondersteunen, wil de afnemer van je software misschien ook wel kunnen kiezen tussen verschillende opmaken van de documenten zelf. Als je de presentatie niet goed gescheiden hebt zal je dan bijvoorbeeld voor veel varianten pdf genereer code moeten gaan schrijven.

In deze applicatie was dit echter geen probleem. Ik heb gewoon verschillende transformaties gemaakt. Nu zal je misschien zeggen "is dat dan geen duplicatie?". Nee: die transformatie lossen namelijk precies 1 concreet probleem op. Verschillende opmaken zorgen ervoor dat er varianten zijn van dit concrete probleem. Zodra een component teveel doet (bijvoorbeeld 2 of 3 verschillende zaken), heb je een probleem als voor 1 van die delen een variant beschikbaar moet zijn.

Dus daarom moet je componenten netjes scheiden en laten communiceren via duidelijke interfaces. Dit zou je overigens ook zelf in je programma kunnen realiseren zonder XML, XSL-FO en XSLT erbij te slepen, maar dan moet je wel een hele goede programmeur zijn .

[mOrPhie]

mbravenboer schreef op 02 August 2003 @ 02:43:
[...]

Zoals al eerder in dit topic is opgemerkt moet je dus proberen om de zaken te scheiden. Jouw programma is alleen geinteresseerd in het produceren van een rapport. Of dat rapport nu uiteindeljk aangeboden gaat worden in een van de formaten pdf, postscript, rtf, word, open-office doc, png, html pagina of wat dan ook is, maakt voor je applicatie (meestal) niets uit. Beter is het daarom om het produceren van een bepaald output formaat te scheiden.

...

Ik lever dus vooral kritiek op het direct produceren van PDF omdat je de mogelijkheden van je applicatie onnodig beperkt. Met enige investing in het verkrijgen van kennis van betere technieken kan je je applicatie omtoveren in een systeem waar de taken en verantwoordelijkheden prachtig gescheiden zijn. Dit zorgt ervoor dat je applicatie flexibel is en goed voorbereid is op de toekomst.

Precies, my point exactly. Ik programmeer al een aantal jaren in het wild en heb al veel mensen de fout in zien gaan met reports maken. Waarom? Ze creëerden de reports niet in 2 stappen, maar direct naar het medium. Gevolg: Als morgen de vraag kwam of er in plaats van een PDF een Word-document uit kan komen rollen, kun je je reporting zelf niet meer hergebruiken. Een splitsing tussen functionaliteit en presentatie is aloud en ik zou bijna wijzen naar een aantal n-tier-modellen.

[Verwijderd]

Ok; dus het is verstandiger om eerst een XML - bestand te genereren en dan met behulp van XSL format-opties aan te brengen.

Op zich klinkt dit erg logisch. Ik ga me hier even wat verder in verdiepen.
Ik heb het gisteren nog met Crystal Reports geprobeerd; dat werkt inderdaad ook prima (alleen is het nog even wat uitzoekwerk om alles aan de gang te krijgen!)

[Verwijderd]

Crystal Reports is een van de goedkoopste pakketten om rapportages mee te genereren, alleen is het een onhandig pakket. Layout is lastig te definieren, dmv lijnen trekken, er zijn diverse bugs in oa berekeningen en tonen van rapportages. Oracle heeft imo een beter product beschikbaar maar dit is natuurlijk veel duurdre.

[Dutch_guy]

Ik heb zelf met behulp van ASPEasyPDF iets gemaakt dat automatisch van iedere boot uit een database een PDF-on-the-fly maakt. Voor ASPEasyPDF, zie: http://www.mitdata.com/AspEasy/index_pdf.htm

Op m'n werk maak ik rapportages in PDF op, door simpelweg de rapportage te maken in een asp pagina, en die te "printen" naar de "PDF printer".