Der Vorlagenerstellungsprozess basiert nicht auf Vererbung und Überschreibung. Das heisst, in einer Dokumentgenerierungs-Pipeline darf ein Feld genau 1x definiert werden.

Der Vorlagenerstellungsprozess basiert auf Vererbung und Überschreibung.

Die Vorlagenhierarchie besteht aus Style, Layout und Inhalt, wobei der Style die für alle Vorlagen zugrundeliegende Ebene ist.

Die Vorlagenhierarchie besteht aus Style, Layout, Inhalt und ggf. Funktion, wobei der Style die für alle Vorlagen zugrundeliegende Ebene ist.

Die Organisation, welcher ein Profil angehört, vererbt die Designs (Farben und Schriftarten sowie Aufzählungszeichen für PowerPoint & Excel).

Der Style vererbt über die Dokumentfunktion “Office-Themes“ Themes (Farben und Schriftarten) sowie Bilder (Logos) je Theme. Damit kann im Word-Ribbon ein Logo beispielsweise farbig oder schwarz-weiss ausgegeben werden.

Der Style vererbt die Styles definiert in der Word-Vorlage.

Der Style vererbt

• die Styles definiert in der Word-Vorlage

• die Themes (siehe oben)

Das Layout vererbt

• die Kopf- und Fusszeilen in der Word-Vorlage

• die in der Platzhalterdefinition erstellten Platzhalter.

Das Layout vererbt

• die Kopf- und Fusszeilen in der Word-Vorlage

• jede konfigurierte Dokumentfunktion

Die Inhalt

• füllt die Platzhalter des Layout mit Daten via Platzhalterzuordnung.

• definiert Daten.

Die Inhalt

• erbt alles von der Layout

• definiert den Vorlageninhalt

• definiert neue Daten (z.B. DP-DataNodes oder Skripte)

• überschreibt ggf. Daten (z.B. DP-DataNodes, DP-View oder Skripte)

Es gibt keine Ebene Funktion.

Die Funktion

• erbt alles von der Inhalt

• definiert neue Daten (z.B. DP-DataNodes oder Skripte)

• überschreibt ggf. Daten (z.B. DP-DataNodes, DP-View oder Skripte)

Eine Funktion ohne jegliche Konfiguration erbt alles von der Inhalt und kann dadurch als Verknüpfung in weiteren Vorlagenordnern abgespeichert werden.

Jede Dokumentfunktion gehört einer Ebene bzw. einem Vorlagentyp an und kann nur dort definiert werden.

Jedes Feld, egal ob aus der Dokumentfunktion Formulare oder Felder, kann genau 1x in der Dokumenterstellungs-Pipeline definiert sein. Eine Überschreibung ist somit nicht möglich.

Dokument-Parameter

• Wurde in einer Layoutvorlage ein DataNode konfiguriert, erbt die Inhalt dieses.

• In der Inhalt kann dieses DataNode überschrieben werden, indem dieselbe Id verwendet wird.

• Die View kann nicht überschrieben werden und muss immer ganz kopiert werden.

Skripte

• Wurde in einer Layoutvorlage ein Script, (ein CustomDataNode) konfiguriert, erbt die Inhalt dieses. Das gilt auch für Referenzen aus den Globalen Konfigurationen, z. B. {[Scripts.MeinScript]}.

• Wurde in einer Inhalt ein Script konfiguriert, erbt die Funktion dieses.

• In der Inhalt kann ein Script überschrieben werden, indem dieselbe Id verwendet wird. Das gilt ebenso zwischen Funktion und Inhalt.

• Wurde in einer Inhalt eine Referenz aus den Globalen Konfigurationen gemacht, z. B. {[Scripts.MeinScript]}, kann in derselben Konfiguration ein Script mit derselben ID nicht noch einmal erstellt werden. Das gilt auch für die Funktion.

Globale Konfigurationen sind typisiert, d.h. bei der Dokumentgenerierung wird zuerst geprüft, ob der entsprechende globale Eintrag überhaupt in der korrekten Dokumentfunktion referenziert wurde. Beispielsweise kann ein globaler Eintrag vom Typ “FieldsGlobalFields” nicht in der Dokumentfunktion Formulare (Forms) referenziert werden.

Mehr dazu in der Technischen Dokumentation: https://primesoft-group.atlassian.net/wiki/spaces/PDT/pages/31457334/Globale+Konfigurationen#Wieso-eine-Typisierung%3F

Globale Konfigurationen sind untypisiert, d.h. genau dort wo die Referenz gemacht wurde, wird bei der Dokumentgenerierung ohne jegliche Validierung der entsprechende Text eingefügt.

Bei diesem Text kann es sich um alles handeln: eine Dokument-Parameter-View, die Items einer ComboBox, Datanodes oder ein Script ein Ausschnitt dessen.

Die Konfiguration wird durch die ganze Vorlagenhierarchie hindurch von primedocs geprüft, validiert und somit Probleme verringert. Dadurch kann kontrolliert werden, dass es sich um eine korrekte, logische und sinnvolle Konfiguration handelt.

Die Konfiguration wird durch die ganze Vorlagenhierarchie von primedocs nicht geprüft - das Resultat, also was im generierten Dokument schlussendlich angezeigt wird, ist nur korrekt, wenn der Layouter alles korrekt konfiguriert hat.

Dadurch, dass ein Feld genau 1x in der Vorlagenhierarchie definiert werden darf und globale Einträge typisiert sind, kann die Software im Dokumentgenerierungsprozess eine genaue Validierung durchführen. Das bietet folgende Vorteile für Layouter:

Wurde ein Formular oder ein Field falsch konfiguriert, erfährt der Layouter bereits beim Klick auf “Dokument testen” davon. Ggf. kann das Dokument gar nicht erst erstellt werden, bevor der Fehler korrigiert ist.

Im Dokumentgenerierungsprozess wird keine Validierung durchgeführt. Das heisst, Inhalte von Scripts oder Dokument-Parametern werden nicht darauf geprüft, ob der Wert “Sinn macht”. Es werden auch keine Fehler oder Warnungen gegeben.

Scripts oder Dokument-Parameter, die falsch konfiguriert worden sind, werden in einem generierten Dokument leer angezeigt. Der Layouter ist für die korrekte Erstellung und verantwortlich.

Durch die software-seitige Validierung erhält der Layouter bei Problemen grosse Unterstützung beim Troubleshooting.

Aufgrund der fehlenden Validierung muss der Layouter bei Problemen die Vorlagenhierarchie durchgehen und selbständig Troubleshooting betreiben.

Der Empfängerdialog und dessen Schema ist von der Software vorgegeben, d.h. es gibt fix vorgegebene Felder mit ihren IDs und Bezeichnungen. Dieses Schema heisst Standard-Kontakt-Mapping.

Die ObjectCollections haben kein Standard-Schema. Dieses kann pro Forms-Definition völlig individuell definiert werden (siehe https://primesoft-group.atlassian.net/wiki/spaces/PDT/pages/57081857/Formulare+Forms#Inhalte-f%C3%BCr-Object-bzw.-ObjectCollection).

Ein Empfänger kann einer der Kategorien “An”, “Cc” und “Bcc” eingefügt werden.

Pro Typ wird eine eigene ObjectCollection mit den für den Typ notwendigen Feldern in einem Schema erstellt. Beispiele:

• Empfänger: je ein Schema für “An”, “Cc” und “Bcc”

• Protokolle: je ein Schema für “Teilnehmende”, “Kopie An” und “Entschuldigt”

• Projekterapporte: je ein Schema für “Einführungsprojekte”, “Supportprojekte”

Der Empfängerdialog ist aus obigem Grund nur für Adressen ausgelegt.

Die ObjectCollections können daher für alle Arten von Objekten, die in Dokumente reingeholt werden möchten, verwendet werden: Empfänger, Rechnungen, Projekte, etc.

Es können Adressschnittstellen definiert und global abgelegt werden, durch welche der Benutzer Adressen abgreifen kann.

Es können Datenschnittstellen definiert und global abgelegt werden, durch welche der Benutzer jegliche Daten abgreifen kann.

Es können zusätzliche Felder konfiguriert werden.

Durch die individuelle Definition des Schema werden die Felder konfiguriert, die für die jeweilige Vorlage gebraucht werden.

Der Empfängerdialog weisst je nach Vorname und Nachname automatisch die Anrede und die naheliegendeste Briefanrede zu.

Dies ist in Objekten nicht möglich, da sie zu generell formuliert sind.

Scripts werden vererbt.

Es gibt keine Vererbung, weil die Definierung ausschliesslich im Vorlagentyp “Inhalt” bzw. in den Globalen Konfigurationen passiert.

Scripts werden überschrieben.

In einer Dokumentgenerierungs-Pipeline gibt es jedes Field genau 1x.

Scripts erhalten ihre Dynamisierung mit XML. Dabei enthält das XML eine von PrimeSoft entwickelte Attribute, die nur eine begrenzte Implementation der Logik erlaubt. Beispielsweise sind keine Schlaufen (Loops) möglich wie in Java-Script.

Felder erhalten ihre Dynamisierung mit Java-Script. Java-Script erlaubt sehr viel komplexere Logik als das frühere XML.

Mögliche Scripts: CustomDataNode wobei folgende Arten möglich sind: Text-Script, Snippet-Script, Bilder-Script

Mögliche Field-Typen: Text, FormattedText (Textbaustein Art), WordContent (Textbaustein Art), Date, Picture, YesNo

Bei einer Dokumentaktualisierung werden Scripts je nach Komplexität innert 2-10 Sekunden aktualisiert.

Bei einer Dokumentaktualisierung werden Fields je nach Komplexität innert 1-2 Sekunden aktualisiert.

Es gibt drei Textbaustein-Typen:

1. Formatierter Text (Open XML) → Meistgenutzter Typ. Wir gehen vom Einsatz von diesem Textbausteintyp aus.

2. Formartierter Text (RichText) → wird praktisch nie eingesetzt

3. Unformatierter Text → wird praktisch nie eingesetzt

Es gibt zwei Textbaustein-Typen:

1. Formatierter Text → FormattedText: durch diesen Typ ist es erstmals möglich, einen dynamisierten Inhalt mit verschiedenen Formatierungen in ein Field zu packen. FormattedText kann auf zwei Arten erstellt werden:

   1. Abgespeichert als Textbaustein

   2. Abgespeichert als Globale Übersetzung vom Typ “FormattedText”, definiert mit HTML und Platzhaltern.

2. Word Inhalt → WordContent: Pendant zum classic-Textbaustein (linke Spalte die Nummer 1).

Textbausteine können in den Textbaustein-Gruppen “Gemeinsam genutzte Textbausteine”, “Vorlagen-Textbausteine” und “Private Textbausteine” abgespeichert werden.

Textbausteine können in der Textbaustein-Gruppen “Vorlagen-Textbausteine” abgespeichert werden.

Textbausteine werden von Layouter zur Dynamisierung der Vorlagen sowie von Benutzern ohne Admin-Rechte für als private oder gemeinsam genutzte Textbausteine erstellt.

WordContents werden zur Zeit nur von Layoutern zur Dynamisierung der Vorlagen verwendet.

Benutzer, die keine Templating-Administratoren sind, speichern ihre privaten oder gemeinsame Textbausteine nach wie vor als “Formatierter Text (Open XML, classic)” ab.

Textbausteine werden via Scripts in eine Vorlage geholt.

Textbausteine werden via Fields in eine Vorlage geholt.

In einem Textbaustein ist grundsätzlich jeder Inhalt erlaubt.

In einem WordContent sind nicht alle Inhalte erlaubt. Inhalte werden von unsere Entwicklung auf eine White-List gesetzt/aktiviert. z. B. können momentan keine Bilder in WordContents abgespeichert werden; die erlaubten Inhalte werden jedoch laufend erweitert.

Das Identifikationsmerkmal für in die Scripts ist die Textbaustein-Id.

Das Identifikationsmerkmal für in die Fields ist der Textbaustein-Schlüssel (Snippet key).

Felder in Snippets werden bei der Dokumentgenerierung nicht darauf geprüft, ob sie mit etwas gefüllt werden. D.h. sie werden bei einer fehlenden oder falschen Konfiguration allenfalls falsch oder gar nicht ausgegeben.

Somit können allfällige Fehler schlecht bis gar nicht nachvollzogen werden.

Die Definition der Felder in WordContents wird bei der Dokumentgenerierung geprüft. Text (SnippetPlaceholder).

Somit können allfällige Fehler schnell nachvollzogen werden.

Es ist möglich in Snippets alle Arten von Feldern (Dokument-Parameter-Felder, Scripts, Word-eigene Felder), ausser Snippet-Skripte einzufügen.

Es ist zur Zeit möglich in WordContent Word-eigene Felder und Plain Text auszugeben.