Vorlagenerstellung classic vs. webfähig

Sie möchten ein Update von OneOffixx auf primedocs machen oder haben dies bereits gemacht und interessieren sich nun für die Möglichkeiten, die die webfähige Vorlagenwelt in primedocs mit sich bringt? Lesen Sie weiter! Denn insbesondere bei Word haben Sie die Wahl zwischen zwei unterschiedlichen Vorlagenbauarten. Was sind die Unterschiede zwischen der webfähigen Vorlagenwelt und der classic-Welt?

Jede primedocs-Lösung kommt auf den konkreten Anwendungsfall Ihres Unternehmens an. Lassen Sie sich von unseren Produktspezialisten beraten!


Zuerst werden die wichtigsten Hauptunterschiede zwischen den beiden Vorlagenwelten herausgehoben. Anschliessend geht es technisch in die Tiefe und es werden die Unterschiede auf Ebene der Vorlagenerstellung beleuchtet. Zuletzt werden die Unterschiede von konkreten Features verglichen:


Hauptunterschiede

Folgende sind die wichtigsten Hauptunterschiede zwischen der webfähigen (primedocs) Vorlagenwelt und der classic-Vorlagenwelt (Vorlagentypen mit “classic” Suffix).

primedocs

classic (OneOffixx)

primedocs

classic (OneOffixx)

  • 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:

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


Vorlagenerstellungsprozess

Von beiden Vorlagenwelten wird hier der Vorlagenerstellungsprozess und dessen Logik erläutert. Dieser Abschnitt ist sehr technisch und wird nur Vorlagenerstellern empfohlen, die regelmässig Vorlagen bearbeiten und sich mit dem Layouting in OneOffixx/primedocs auseinandersetzen.

Im untenstehenden Text ist in der Vorlagenhierarchie mit “Inhalt” die Ebene “Inhaltsvorlage” gemeint, mit “Layout” die Ebene “Layoutsvorlage” und mit “Funktion” die Ebene “Funktionsvorlage”. Zur Übersicht werden diese Begriffe jedoch abgekürzt mit “die Inhalt/Layout/Funktion”.

primedocs

classic (OneOffixx)

primedocs

classic (OneOffixx)

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 Ebene Layout vererbt

  • die Kopf- und Fusszeilen in der Word-Vorlage

  • jede konfigurierte Dokumentfunktion

Die Ebene Inhalt

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: Globale Konfigurationen | Wieso eine Typisierung?

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.


Vergleich von Dokumentfunktionen und Features

Vorlagentypen

primedocs

Word

  • Inhalt

  • Layout

  • Style

PowerPoint & Excel

  • Excel-Vorlage

  • PowerPoint-Master-Vorlage

  • PowerPoint-Folienvorlage

  • PowerPoint-Vorlage

  • Bildergalerie

  • Diagrammvorlage

Outlook

  • E-Mail-Vorlage

  • Signatur

 

classic (OneOffixx)

Word

  • Inhalt (classic)

  • Funktion (classic)

  • Layout (classic)

  • Theme (classic)

  • Adressdeckblatt (classic)

  • Etiketten (classic)

  • Kampagne (classic)

PowerPoint & Excel

  • Excel-Vorlage (classic)

  • PowerPoint-Vorlage (classic)

Outlook

  • Kampagne

  • E-Mail

  • Signatur

  • Disclaimer

  • E-Mail-Theme

Siehe aktuelle Liste hier: https://primesoft-group.atlassian.net/wiki/x/AQBKAw

Dateneingabemasken: Dokument-Parameter (DP) | Formulare (Forms)

primedocs

  • Mögliche Felder: Textbox, Datumsfeld, Checkbox, Dropdown

  • Einfache Strukturen und Abhängigkeiten zwischen Feldern auf einer Ebene abbildbar.

 

Beispiel:

Forms-Letter-20240510-101215.PNG

classic (OneOffixx)

  • Mögliche Felder: Textbox, Datumsfeld, Checkbox, Dropdown, Radiobutton

  • Komplexe Strukturen und Abhängigkeiten zwischen Feldern abbildbar.

Beispiel:

DP-Letter-20240510-101154.PNG

Objekterfassungsmasken: Empfängerdialog | ObjectCollections/Objects

primedocs

classic (OneOffixx)

primedocs

classic (OneOffixx)

Die ObjectCollections haben kein Standard-Schema. Dieses kann pro Forms-Definition völlig individuell definiert werden (siehe Formulare (Forms) | Inhalte für 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.

Dynamische Inhalte: Scripts | Fields

primedocs

classic (OneOffixx)

primedocs

classic (OneOffixx)

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.

Textbausteine

primedocs

classic (OneOffixx)

primedocs

classic (OneOffixx)

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.

Globale Konfiguration: typisiert | untypisiert

primedocs

Gemäss oben: 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: Globale Konfigurationen | Wieso eine Typisierung?

 

Dadurch ist eine Validierung der ganzen Dokumentgenerierungs-Pipeline möglich.

classic (OneOffixx)

Gemäss oben: 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.

 

Dadurch ist keine Validierung möglich, d.h. in einem generierten Dokument können die Daten allenfalls inkorrekt sein.

 

Beachten Sie, dass die beiden Vorlagenwelten nicht gemischt werden können. Folgende Beispiele sind technisch nicht möglich:

  • WordContents können nicht in classic Scripts (CustomDataNode) verwendet werden.

  • In primedocs Vorlagen können keine untypisierte globale Einträge referenziert werden.

  • In classic-Vorlagen können keine Fields erstellt werden.

 


FAQ: Wechsel von OneOffixx auf primedocs

Können unsere OneOffixx Vorlagen noch verwendet werden?

Ja, das können Sie! Ihre OneOffixx Word-, PowerPoint- und Excel-Vorlagen sowie Ihre Outlook-Vorlagen für Outlook (solange nicht die neue Ansicht in Outlook 365) können genau gleich weiterverwendet werden.

Einzige Einschränkung gibt es bei den PowerPoint- und Excel-Vorlagen, die Sie mit OneOffixx erstellt haben: diese bedürfen zur Anpassung einen OneOffixx Client. Wir empfehlen Ihnen daher, die PowerPoint- und Excel-Vorlagen mit der primedocs Vorlagenwelt zu erstellen (wobei Ihre Benutzer von tollen Features profitieren).

Können wir unsere classic-Vorlagen web-fähig machen?

Ja, das ist möglich. Beachten Sie hier, dass die Webfähigkeit nur durch die webfähige Vorlagenwelt zustande kommt. Aufgrund der vielen Unterschiede zwischen den beiden Vorlagenwelten müssen daher alle Vorlagen exklusive Style-Vorlage von Grund auf neu erstellt werden mit den webfähigen (nicht-classic) Vorlagenypen. Hierbei übernehmen wir natürlich die erforderliche Logik von classic (Dokument-Parameter, Skripte und Textbausteine) in die neue Vorlage (Forms, Fields und je nach dem FormattedTexts oder WordContents). Die Vorlagen können je nach Fall anders gelöst werden als in classic.

Auch ist zu beachten, dass allfällige Adresssschnittstellen neu als Datenschnittstellen zu konfigurieren sind, was zusätzlichen Aufwand für die Umsetzung bedeutet.

Wir empfehlen, von Anfang an festzulegen, welche Vorlagen genau web-fähig sein müssen und welche nicht.

Können beide Vorlagenwelten in unserer Datenbank koexistieren?

Ja, das geht problemlos. Es ist dabei einfach wichtig, dass man z. B. Einträge in der Globalen Konfiguration klar benennt bzw. gruppiert, so dass man weiss, in welchen Einträgen es um Fields (primedocs) und in welchen es um Scripts (classic) geht.


Ihre Fragen sind noch nicht geklärt? Schauen Sie noch auf dieser Seite nach: https://www.primedocs.io/de/news/migration-primedocs-oneoffixx-brandic oder kontaktieren Sie unseren Support.

PrimeSoft AG, Bahnhofstrasse 4, 8360 Eschlikon, Switzerland