• Die Vorlagen sind web-fähig. Das bedeutet, dass Benutzer Dokumente aus primedocs Web, einer Web-Applikation, die im Browser aufgerufen wird (https://your-domain/app), generieren können. Dabei werden die Dokumente in primedocs Web zusammengestellt und danach vom Browser heruntergeladen.

• Die classic-Vorlagenwelt ist nicht web-fähig.

• Dokumente können über primedocs Connect von Fremdapplikationen aus über primedocs erzeugt werden.

• Dokumente können über OneOffixx Connect von Fremdapplikationen (z.B. Sharepoint) aus über primedocs erzeugt werden. Connect bietet auch den Aufruf der Vorlagen über die Shell oder den Protokoll-Handler (als Link).

• Dokumente aus primedocs Vorlagen können über eine Web API generiert werden. primedocs Web kann in folgenden Applikationen integriert werden:

  • Microsoft Teams

  • Microsoft SharePoint

  • CMI Web

• OneOffixx bietet keine Web API an.

• Der Vorlagenerstellungsprozess basiert auf der Vererbung von Style über Layout zum Inhalt. Dabei wird die ganze Dokumentgenerierungs-Pipeline validiert.

• Der Vorlagenerstellungsprozess basiert auf der Vererbung von Style über Layout zum Inhalt (bis zu Funktion) sowie der Dokumentfunktionen in der jeweiligen Hierarchiestufe. Vererbte Dokumentfunktionen können in jeder Hierarchiestufe ergänzt oder überschrieben werden.

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 drei Ebenen: Style, Layout und Inhalt, wobei der Style die für alle Vorlagen zugrundeliegende Ebene ist.

Die Vorlagenhierarchie besteht aus den drei Ebenen: 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.

Die Ebene Style vererbt
die Styles / Word Formatvorlagen definiert in der Word-Vorlage.

Die Ebene Style vererbt

• die Styles / Word Formatvorlagen definiert in der Word-Vorlage

• die Themes (siehe oben)

Die Ebene Layout vererbt

• die Kopf- und Fusszeilen in der Word-Vorlage

• die in der Platzhalterdefinition erstellten Platzhalter

Die Ebene Layout vererbt

• die Kopf- und Fusszeilen in der Word-Vorlage

• jede konfigurierte Dokumentfunktion

Die Ebene Inhalt

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

• definiert Daten

Die Ebene Inhalt

• erbt alles von der Layout

• definiert den Vorlageninhalt

• definiert neue Daten (z.B. DP-Felder oder CustomDataNodes)

• überschreibt ggf. Daten (z.B. DP-Felder, DP-View oder CustomDataNodes)

Es gibt keinen Vorlagentyp Funktion.

Die Ebene Funktion

• erbt alles von der Inhalt

• definiert neue Daten (z.B. DP-Felder oder CustomDataNodes)

• überschreibt ggf. Daten (z.B. DP-Felder, DP-View oder CustomDataNodes)

Eine Funktionsvorlage ohne angehängte Dokumentfunktionen erbt alles von der Inhalt und kann dadurch als Verknüpfung in 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 in einer tieferen Hierarchiestufe (z. B. Inhalt) nicht ergänzt werden. Eine View, die in der Inhaltsvorlage konfiguriert wurde, ersetzt daher eine View, die in der Layoutvorlage gesetzt wurde.

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 (ein CustomDataNode) konfiguriert, erbt die Funktionsvorlage 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 Funktionsvorlage.

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, ob 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 Troubleshooting selbständig betreiben.

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).

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.

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

Ein Beispiel: Vorlage Protokoll: je ein Schema für

• “Teilnehmende”, Felder: Vorname, Name, Abteilung, Hat Leitung, Macht Protokoll

• “Kopie An”, Felder: Vorname, Name, E-Mail

• “Entschuldigt”, Felder: Vorname, Name, E-Mail, Erhält Kopie

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

Ein Beispiel: Vorlage Protokoll: die Kategorien werden zu “Teilnehmende“, “Kopie An” und “Entschuldigt” umbenannt

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.

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

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

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

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

Es können zusätzliche Felder (“ExtendedFields“) konfiguriert werden.

Da bei Objekten die Felder individuell erstellt werden, gibt es solch einen Automatismus nicht.

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

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

Scripts werden vererbt.

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

Scripts werden überschrieben.

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

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.

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

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

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

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

Es gibt zwei Textbaustein-Typen:

1. Word Inhalt, WordContent: Pendant zum classic-Textbaustein vom Typ “Formatierter Text (Open XML)“ (siehe Punkt 1. in der rechten Spalte)

2. 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.

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

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

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

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 von Layouter zur Dynamisierung der Vorlagen sowie von Benutzern ohne Admin-Rechte für als private oder gemeinsam genutzte Textbausteine erstellt.

Textbausteine werden via Fields in eine Vorlage geholt.

Textbausteine werden via Scripts in eine Vorlage geholt.

In einem WordContent können nicht alle Inhalte abgespeichert werden. Inhalte werden von unserer Entwicklung bewusst freigeschaltet - so können allfällige Probleme kontrolliert werden.
z. B. daher können zur Zeit keine Bilder in WordContents abgespeichert werden; die erlaubten Inhalte werden jedoch laufend erweitert.

In einem Textbaustein ist praktisch jeder Inhalt erlaubt. Einzige bekannte Probleme gibt es bei Abschnittswechseln und eingebetteten Objekten wie z. B. Excel-Mappen.

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

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

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

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

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.

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

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