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) |
---|---|
|
|
|
|
|
|
|
|
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) |
---|---|
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 Ebene Style vererbt
|
Die Ebene Layout vererbt
|
|
Die Ebene Inhalt
|
|
Es gibt keinen Vorlagentyp Funktion. | Die Ebene Funktion
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
Skripte
|
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 |
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:
classic (OneOffixx)
Mögliche Felder: Textbox, Datumsfeld, Checkbox, Dropdown, Radiobutton
Komplexe Strukturen und Abhängigkeiten zwischen Feldern abbildbar.
Beispiel:
Objekterfassungsmasken: Empfängerdialog | ObjectCollections/Objects
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
| 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) |
---|---|
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:
|
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) |
---|---|
Es gibt zwei Textbaustein-Typen:
| Es gibt drei Textbaustein-Typen:
|
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. | 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).
| 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 Item
s einer ComboBox
, Datanode
s 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