Software Design DefaultCoverGenerator usw. überarbeiten bzw. erläutern

[j3nsch]

Die Interfaces CoverGeneratorInterface und PdfGeneratorInterface sind sehr ähnlich. Ziel ist es ja die Methode zum Generieren von PDFs mit Cover austauschen zu können. Dazu sollte man in der Konfiguration eine Klasse und evtl. beliebige Optionen angeben können.

Vielleicht sollte die Klasse DefaultCoverGenerator als Basisklasse dienen und von DefaultPdfGenerator (eigentlich "LatexPdfGenerator") erweitert werden. Dann kann der "CoverGenerator" ausgetauscht werden. Im ursprünglichen Entwurf des Designs war der "PdfGenerator" eine separate Klasse, aber da die Implementation ja nicht generisch ist und anderswo wiederverwendet werden kann, macht die Auftrennung wenig Sinn.

PdfGeneratorFactory\Interface würden verschwinden, wenn die konkrete Implementation, die Basisklasse erweitert. Die Klasse DefaultCoverGenerator sollte dann in AbstractCoverGenerator umbenannt werden.

Als Use-Case sollte im Kopf behalten werden, dass die Latex-basierte Generierung durch HTML/CSS oder eine andere Technik ersetzbar sein soll. Wie kann man den Konfigurations- und Entwicklungsaufwand in diesen Fällen minimieren?

[j3nsch]

Die Funktion getPdfGenerator ist eigentlich abhängig von der konkreten PdfGenerator-Implementation. Eine andere Implementation verwendet vielleicht nicht Markdown für Templates oder überhaupt keine Template-Dateien, weil die Generierung komplett im Code erfolgt.

Die Logic für getTemplateName sollte ausgelagert werden, insbesondere, wenn das Design so überarbeitet wird, dass der "LatexPdfGenerator" die Klasse "DefaultCoverGenerator" erweitert. Hier geht es ja darum für ein Dokument eine Cover-ID, ein Template-Name, zu ermitteln, und dass sollte unabhängig sein von der Technik für die PDF-Generierung.

[j3nsch]

Im Augenblick haben wir ja mind. zwei Ebenen der Abstraktion, den "CoverGenerator" und den "PdfGenerator". Es ist nicht ganz klar, dass beide Ebenen (im Betrieb) unabhängig voneinander austauschbar sein müssen. Auch jetzt enthält die CoverGenerator-Implementation schon Code der spezifisch für die "PdfGenerator"-Implementaton ist. Die Änderungsvorschläge oben versuchen eine der beiden Ebenen zu beseitigen bzw. die beiden Ebenen miteinander zu verschmelzen.

[j3nsch]

Bitte noch den "PdfGenerator" Namespace entfernen. Insbesondere wenn PdfGeneratgorFactory und PdfGeneratorInterface verschwinden, ist die zusätzlich Unterteilung unnötig.

[j3nsch]

Eine separate "PdfGenerator"-Klasse macht nur Sinn, wenn sie unabhängig ist von den speziellen OPUS 4 Datenmodell-Klassen, wenn sie keine Vorverarbeitung der Metadaten vornimmt. Eine solche Klasse sollte nur Konfiguration haben, welches Template usw. und dann die Metadaten einfach als Array bekommen. Die Aufgabe der Klasse wäre es dann nur noch die Metadaten in ein Template einzufügen, ohne zusätzliche inhaltliche Verarbeitungslogik. Eine solche Klasse wäre dann austauschbar. Man könnte die Latex-Generierung durch HTML/CSS oder eine andere Technik austauschen. Ich denke so war das ursprünglich gedacht.

Die Vorverarbeitung im "CoverGenerator" würde bestimmen welche Metadaten zur Verfügung stehen. Wenn das Array mit den Metadaten Lizenzen mehrsprachig enthalten soll, müsste dafür eine passende Datenstruktur vorbereitet werden, die es dann möglich macht im Template die gewünschte Sprache abzurufen. An vielen Stellen in OPUS 4 wird die Ausgabe mit XSLT erzeugt, z.B. in der Frontdoor. Eine mehrsprachige Anzeige von Lizenzen wären auch dort nicht direkt machbar, weil das XML die Lizenzen in nur einer Sprache enthält. Das wird sich durch einen Übersetzungsmechanismus für Lizenzen auch nicht ändern.

CoverGenerator -> Array (Json) mit Metadaten -> PdfGenerator -> PDF 

Ist es notwendig die Klassen so zu implementieren? Nein, im Augenblick glaube ich nicht, dass das notwendig ist. Es würde eine allgemeine Nutzung des PdfGenerators ermöglichen, unabhängig von Deckblättern, aber dafür haben wir bislang keine Anforderungen und es gibt viele andere wesentlich wichtigere Aufgaben. Es ist auch denkbar, dass das Dokument-XML mit XSLT direkt in ein Zwischenformat für die PDF-Erzeugung umgewandelt wird, was dann auch wieder innerhalb einer speziellen CoverGenerator-Klasse umgesetzt würde.

[extracts]

Danke für die Kommentare. Ja, die Metadaten könnten als generischer Array übergeben werden. Damit wäre die PdfGenerator Klasse nicht von OPUS 4 Datenmodell-Klassen abhängig. Die konkrete LatexPdfGenerator Implementierung benötigt die Metadaten in Form von JSON-Dateien, die Generierung dieser Dateien könnte jedoch ausserhalb der PdfGenerator Klasse erfolgen.

[j3nsch]

Ob das sinnvoll ist, hängt davon ab, wie das JSON aussieht, ob es nur für den Latex-Generator Sinn macht, oder ob es allgemein genug ist auch als Grundlage für andere Generatoren zu dienen.

[j3nsch]

Ich glaube am wichtigsten ist im Augenblick, dass die beiden Klassen, DefaultCoverGenerator und DefaultPdfGenerator nicht wirklich unabhängig voneinander sind und beide ausgetauscht werden müssten, um die Methode für die PDF-Generierung zu wechseln. Da ist es besser, wenn die beiden Klassen zusammengefasst werden. Das ist für den Augenblick die bessere Lösung und kann als Zwischenschritt dienen. Der allgemeine Code geht in die Basisklasse. Wir können später sehen, ob sich der Latex-spezifische Code soweit isolieren lässt, dass er wieder als unabhängige Klasse ausgelagert werden kann.

[j3nsch]

Issue #53 macht auch noch mal klar, dass genau überlegt werden muss, was die Rolle der einzelnen Klassen ist.