Wie erzeugt man heutzutage (Massen)Druckoutput?

[Sir Rufo]

Zitat:

Zitat von delora (Beitrag 1342241)

Zitat:

Zitat von Sir Rufo (Beitrag 1342236)

Wenn man mehrere Sprachen unterstützen will, dann legt man sich pro Sprache ein Template an. Das wird dann durch die Engine mit den Daten gefüllt und fertig.

Es handelt sich hier nicht nur um statische Texte, sondern hauptsächlich um dynamische, die aus der Datenbank kommen.
Da ist nix mit Template ;) Diese Texte müssen zur Laufzeit übersetzt werden (also der übersetzte Text muss zur Laufzeit anstelle des Originaltextes aus der DB geladen werden).

Die statischen Texte gehören ins Template, die dynamischen sind Teil der Daten und für die Beschaffung sollte das Template nicht verantwortlich sein. Wenn die Engine die Daten mit dem Template zusammenfügt, dann muss alles soweit bereit sein, dass wirklich nur noch zusammengefügt werden muss.

Das Übersetzen der dynamischen Texte erfolgt also mindestens ein Schritt vorher.

[p80286]

Zitat:

Zitat von Lemmy (Beitrag 1342254)

Um MS Office/LibreOffice würde ich einen Bogen machen: die Steuerung müsste zwangsläufig über OLE/COM erfolgen, was leider fehlerträchtig geworden ist vor allem weil bei so Sachen auch gerne mal Virenscanner unerwartet zuschlagen...

hast Du dafür Beispiele? bei uns funktioniert das eigentlich ganz gut, da gibt es keinen Ärger mit Virenscannern.

Zitat:

Zitat von Lemmy (Beitrag 1342254)

Und wenn das ganze von einem "normalen" Anwender geändert werden sollte, scheidet im Grunde alles aus, was keinen grafischen Editor hat, weil es sonst ganz bitter wird und am Ende wieder "nur" der Entwickler Änderungen machen kann.

der "normale" oder auch der "fortgeschrittene" Anwender, sind ja sehr relative Einordnungen.
Die Erfahrung lehrt leider daß Du Recht hast.

@Delora
Ich werde das Gefühl nicht los, daß Ihr vieles so macht wie Ihr es macht, weil Ihr es schon immer so gemacht habt. Vielleicht wäre es jetzt sinnvoll, falls machbar, sich zu überlegen wie man es machen würde wenn man keine Altlasten hätte. Das kostet nur etwas Zeit und etwas Papier.

Gruß
K-H

[sh17]

XSL-FO ist definitiv ein Blick Wert. Mittels der FO-Prozessoren können auch jede Menge Ausgabe-Varianten erzeugt werden. Würde ich Report.XY auf jeden Fall vorziehen. Zumindest war das mein Eindruck. Am Ende haben wir unsere Druck-Engine doch nochmal umgeschrieben. Aber wenn wieder die Entscheidung ansteht, ist XSL-FO wieder im Boot.

[hoika]

Hallo,
ich werfe mal QuickPDF in die Runde.

Hier kommt es aber auf die Komplexität der Dokumente an.

Bei List&Label hatte mir daals missfallen (Version 6-10 ...),
dass das alles sehr statisch war.
Mittlereise kan man das Teil aber auch komplett dynamisch benutzen.

Im Vergleich zu Crystal Reports war L&L ein Traum.


Heiko

[mm1256]

Zitat:

Zitat von hoika (Beitrag 1342269)

...Bei List&Label hatte mir damals missfallen (Version 6-10 ...),
dass das alles sehr statisch war.
Mittlereise kan man das Teil aber auch komplett dynamisch benutzen.

Im Vergleich zu Crystal Reports war L&L ein Traum.

Heiko

Ich benutze L&L seit Version 4. Mittlerweile sind wir bei Version 21. Das kann man mit den Versionen VOR Version 12 nicht mehr vergleichen. Ab Version 16 gab es dann neben den üblichen Erweiterungen dank Einsatz von Multithreading einen Performance-Schub um ca. 80%.

Was die Steuerung des Ausdrucks (und die vorher gegangene Diskussion um Templates) anbelangt. Man kann die Druckausgabe entweder automatisiert über die Datenbank (TDataSet) ablaufen lassen, oder den Ausdruck selber manuell Datensatz für Datensatz erledigen. Diese Flexibilität ist auch mir wichtig, weil beim Ausdruck manchmal (also nicht immer) Daten erst während des Ausdruckes zusammengestellt werden müssen. Beispielsweise beim Druck eines Lieferscheines oder einer Rechnung die dazugehörigen Seriennummern, das Aufmaß, oder bei Leistungspositionen die Zuordnungen.

Der grafische Formulardesigner (mit echtem Preview, also ganz anders als z.B. bei FastReport) wird mitgeliefert. Jeder der sich damit beschäftigt (auch neugierige Kunden) kann den bedienen. Man kann ihn aber auch sperren, was ich über die Benutzerverwaltung wahlweise mache.

[delora]

Hallo zusammen,

ich denke, dass ich mir den List&Label mal ansehe. Die Infos auf der Homepage sind ja ganz ansprechend. Und eine 30 Tage Testversion gibt es auch (obwohl ich in dem Zeitrahmen wahrscheinlich nicht so viel reißen kann :lol:)
Und wenn das nichts ist, werde ich mir mein XSL-FO Buch nochmal herholen.

Zitat:

Zitat von p80286 (Beitrag 1342264)

@Delora
Ich werde das Gefühl nicht los, daß Ihr vieles so macht wie Ihr es macht, weil Ihr es schon immer so gemacht habt. Vielleicht wäre es jetzt sinnvoll, falls machbar, sich zu überlegen wie man es machen würde wenn man keine Altlasten hätte. Das kostet nur etwas Zeit und etwas Papier.

Da hast Du vollkommen recht - ich habe das auch so gesagt, dass das Ganze gewachsen ist, wir uns aber davon trennen möchten - daher bin ich hier ;)

Nochmals vielen Dank für Eure Ideen!

[juergen]

@hoika,
der TE spricht von Milliarden Datensätzen, da sollte Geld keine Rolle spielen und die Entscheidung IMHO für die größten Hersteller in diesem Bereich gefällt werden (SAP (Crystal Report) usw.).
Wir nutzen (noch) Crystal Report, mich würde mal die Aussage interessieren, was an L&L besser ist wie bei Crystal Report. Das hört sich interessant an! Ich hatte vor längerer Zeit auch mal L&L getestet, konnte damals (Version 14?) keine so großen Vorteile erkennen um CR zu ersetzen.

Zitat:

Zitat von hoika (Beitrag 1342269)

Im Vergleich zu Crystal Reports war L&L ein Traum.Heiko

[mjustin]

Anstelle Template zu verwenden die manuell erstellt sind, könnte man versuchen das gesamte Layout dynamisch zu erzeugen. Das geht bei einigen mir bekannten Reportgeneratoren entweder indem man die Reportdefinitionsdatei per Code erzeugt, oder über ein Layout-API.
Dann würde man nur noch ein Programm benötigen, das über diese API die gewünschten Variationen der Reportlayouts erzeugt.

Mit diesem Programm würde man den Report dann aus Bausteinen zusammensetzen, die speziell dem geschäftlichen Feld angepasst sind.

Das Zusammenbauen kann hart kodiert im Code ablaufen:

Code:

Quartalsabrechnung := TQAbrechnung.Create;
Quartalsabrechnung.AddInfoBlock(...);
Quartalsabrechnung.AddWerbungsBlock(...);
QuartalsabrechnungLayout := Quartalsabrechnung.ErstelleLayout;
LayoutRepository.AddLayout(REPORT_QA, QuartalsabrechnungLayout);

An das generierte Layout werden dann alle Datensätze übergeben.

Code:

ReportGenerator := TRG.Create;
ReportGenerator.Layout := LayoutRepository.LoadLayout(REPORT_QA);
ReportGenerator.LoadDataSet(...);
ReportGenerator.CreateReport;
...

Manuelle Nachbearbeitung der generierten Layouts sollte dann nicht mehr stattfinden.


p.s. Auf jeden Fall würde ich vermeiden, zur Laufzeit des Reportgenerators noch Code mit Datenbankzugriff auszuführen. Eine Funktion, die innerhalb des Ausdrucks noch Lookupfelder in der Datenbank nachschlägt wäre ein No-Go. Für die saubere Trennung wäre es zum Beispiel möglich, die Daten als XML Dokument bereitzustellen.

[Valle]

Hi,

ich weiß nicht ob ich hier etwas sinnvolles zu beitragen kann, aber bevor ich es verschweige, teile ich mal unsere Lösung mit.

Ich bin in der Webentwicklung bei einem Reiseunternehmen tätig, wo wir natürlich auch einige Dokumente wie beispielsweise Rechnungen drucken müssen.

Wir verwenden Python im Backend. Mit unserem Python Framework benutzen wir auch eine Templating Engine für Python. Mit dieser können wir nicht nur HTML generieren, sondern auch LaTeX Dateien. Mit Schleifen und If-Abfragen sind wir so recht mächtig in der Generierung der LaTeX-Quelldateien. Mittels selbst definierten Dokumenttypen und LaTeX-Befehlen ist das Generieren daher auch recht einfach.

Änderungen an den Templates waren oft schwierig, meist aber nur, weil das System über seine ursprünglichen Grenzen gewachsen ist und wir keinen LaTeX-Profi im Team haben. Bei einer eventuellen Neuentwicklung würde ich den Weg über LaTeX allerdings erneut gehen. Diesmal mit mehr Augenmerk auf Modularität, Unicode (!!!) und einfacheres Debugging.

LaTeX Generierung ist nach meinem Empfinden alles andere als rasend schnell. Ich weiß aber auch nicht von welchen Maßstäben wir reden. Weiterhin umfasst unser Volumen nur wenige Dokumente pro Tag. Allerdings lässt sich diese Technik denke ich problemlos vertikal und horizontal skalieren.

[mm1256]

Zitat:

Zitat von juergen (Beitrag 1342276)

@hoika,
der TE spricht von Milliarden Datensätzen, da sollte Geld keine Rolle spielen und die Entscheidung IMHO für die größten Hersteller in diesem Bereich gefällt werden (SAP (Crystal Report) usw.).
Wir nutzen (noch) Crystal Report, mich würde mal die Aussage interessieren, was an L&L besser ist wie bei Crystal Report. Das hört sich interessant an! Ich hatte vor längerer Zeit auch mal L&L getestet, konnte damals (Version 14?) keine so großen Vorteile erkennen um CR zu ersetzen.

Zitat:

Zitat von hoika (Beitrag 1342269)

Im Vergleich zu Crystal Reports war L&L ein Traum.Heiko

Das Problem ist ja, wenn man sich mal auf eine Lösung eingeschossen hat, ist ein Wechsel sehr zeitaufwändig. Nicht nur wegen der Programmierung, sondern auch wegen der Neugestaltung der Formulare bei den Kunden. Und darum ist man natürlich erst mal skeptisch. Das ist normal.

Unsere erste Lösung war damals auch CR. Ist schon eine ganze Weile her (wie schon gesagt, seit L&L Version 4) und mit Sicherheit kein Vergleich mehr mit heutigem Stand. Was mich damals letztendlich überzeugt und den Ausschlag für den Wechsel gegeben hat, war die Performance und die Flexibilität. Wenn ich will, kann ich den kompletten Ausdruck mit einer eigenen Druckschleife generieren. Ich muss dann zwar alle Variablen und Felder selber erzeugen. Das ist die Grundlage für die Flexibilität, aber, ein einmaliger Programmier-Vorgang. Ich habe Druckschleifen die laufen schon jahrelang ohne jegliche Änderung, denn wenn der Kunde etwas ändern/ergänzen möchte, neue Berechnungen braucht usw. dann passiert das alles im Formular-Designer.

Ein Nachteil von L&L könnte sein, dass man roundabout 20 Dateien (dll's) mitliefern muss. Bisher hatte ich aber damit kein Problem.