Release Notes

FirstSpirit ist als Enterprise Content Management System für den Einsatz in komplexen IT-Landschaften konzipiert und unterstützt eine Vielzahl von Betriebssystemen, Java-Laufzeitumgebungen und Datenbanken. Um eine hohe Softwarequalität zu gewährleisten und sicherzustellen, dass FirstSpirit in allen unterstützten Konfigurationen lauffähig ist, werden im Rahmen der Qualitätssicherung regelmäßige Tests durchgeführt. Die Fülle an unterstützten Fremdkomponenten, kurze Release-Zyklen sowie Kombinations- und Konfigurationsmöglichkeiten der Fremdkomponenten führen jedoch zu einer extrem hohen Testkomplexität.

Aufgrund dessen gilt: generell unterstützt FirstSpirit immer die aktuellste Version einer Fremdkomponente. Sie werden seitens der e-Spirit AG regelmäßig getestet und Maßnahmen zur Behebung eventueller Fehler und Inkompatibilitäten ergriffen. Bei der Betrachtung und Auswahl der für den Betrieb mit FirstSpirit unterstützten Fremdkomponenten berücksichtigt e-Spirit darüber hinaus verstärkt Komponenten, die möglichst große Marktanteile abdecken und bei vielen Kunden erfolgreich eingesetzt werden.

Dies betrifft auch Browser zur Verwendung der FirstSpirit Web Apps: Aufgrund der sukzessiven Ablösung des Microsoft Internet Explorer durch Microsoft Edge wird der Support für Microsoft Internet Explorer seitens FirstSpirit zukünftig entfallen. Stattdessen werden Google Chrome und Microsoft Edge Chromium empfohlen. Die Entwicklung des neuen ContentCreator orientierte sich bereits stark an diesen beiden Browsern: aus technologischen Gründen ist der neue ContentCreator daher nicht mehr mit Microsoft Internet Explorer kompatibel.

Der Entfall des Support von Microsoft Internet Explorer für alle FirstSpirit Web Apps ist für FirstSpirit 2020-07 geplant. Mit diesem Release wird auch der „alte“ ContentCreator planmäßig entfallen.

Referenz ist hingegen immer der aktuellste Chrome-Browser, der auf dem jeweiligen Betriebssystem verfügbar ist. Für diesen Browser-Typ werden regelmäßige Tests durchgeführt und Schritte zur Fehlerbeseitigung auf der Basis von Fehlermeldungen unternommen.
Darüber hinaus werden auch Chrome-nahe Browser (wie Apple Safari) unterstützt und getestet, allerdings kann es dort zu Einschränkungen kommen (z. B. eingeschränkter SVG-Support).

Eine Übersicht der geplanten Browser-Kompatibilitäten ab FirstSpirit 2020-07:

Empfohlene Browser / Referenz:

• Google Chrome
• Microsoft Edge

Kompatible Browser:

• Mozilla Firefox
• Apple Safari (mit Einschränkungen)

Nicht kompatibel:

• Microsoft Internet Explorer
• Opera und andere

Das „FirstSpirit Technische Datenblatt“ wurde entsprechend angepasst (https://docs.e-spirit.com/odfs/edocs/admi/technische-vora/index.html).

FirstSpirit verwendet mehrere Standard-Webanwendungen (fs5root, fs5webedit, fs5webmon, fs5preview, fs5staging) sowie eventuell weitere, projektlokale Webanwendungen (fs5webedit_PROJECTID und fs5preview_PROJECTID). Zur Authentifizierung der Webanwendungen (WebAuthentication) am FirstSpirit-Server wird eine Technologie eingesetzt, die zufällig generierte Session Cookies verwendet. Durch die Verwendung der Session Cookies müssen die Anmeldedaten des Benutzers nur einmalig vom Webbrowser zum FirstSpirit-Server übermittelt werden. Nach dem erfolgreichen Login verwendet der Webbrowser ausschließlich das zeitlich begrenzt gültige, eindeutige Session Cookie, dass dann bei jeder weiteren Serveranfrage, anstelle der Anmeldedaten, vom Webbrowser zum Server gesendet wird, um den Benutzer dort zu authentifizieren.

Das Session Cookie ist integraler Bestandteil der Servlet-API und wird neben der Authentifizierung noch für viele weitere Anwendungsfälle verwendet.

Viele Browser (u.a. Chrome 80) schränken seit Anfang des Jahres Cookies von Drittanbietern massiv ein. Alle Cookies, die nicht das Attribut SameSite=None tragen, werden automatisch auf First-Level-Domains beschränkt. Dieses Verhalten führt zu Problemen, wenn FirstSpirit-Webanwendungen in andere Webanwendungen integriert werden (z. B. als IFrame). In diesem Fall sorgt das neue Standardverhalten der Browser dafür, dass die FirstSpirit Session Cookies vom Browser blockiert werden und die Benutzer in der eingebetteten FirstSpirit-Webanwendung beispielsweise nicht mehr über das Session Cookie authentifiziert werden können.

Für diesen Anwendungsfall kann mit dem aktuellen FirstSpirit Release das Session Cookie um das Attribut SameSite=None erweitert werden. SameSite ist ein Standard, der Verhindern soll, dass Cookies bei sogenannten Cross-Site Requests automatisch vom Browser mitgesendet werden und bietet damit einen Schutz vor Cross-Site-Request-Forgery (CSRF). Neben diesem Sicherheitsaspekt ermöglicht das Attribut SameSite zu definieren, welche Cookies in welchem Kontext ausgelesen werden können.

Der Wert für die FirstSpirit Session Cookies kann über die Konfigurationsdatei fs-server.conf gesetzt werden, sowohl global über den Parameter servletSessionCookieSameSite als auch einzeln für bestimmte WebApp-Pfade, z. B. servletSessionCookieSameSite.fs5webmon=None für das FirstSpirit ServerMonitoring. Eine WebApp-spezifische Konfiguration überschreibt dabei die globale Einstellung servletSessionCookieSameSite für diesen WebApp-Pfad.

In der Standardkonfiguration (der Konfigurationsdatei fs-server.conf) wird kein globaler Wert für servletSessionCookieSameSite gesetzt.

# Servlet engine session cookie SameSite attribute. If left empty, the 
# SameSite attribute for the session cookie is not
# set and the servlet engine defaults apply.
# Supported values: None, Strict, Lax
servletSessionCookieSameSite=
# Servlet engine session cookie SameSite attribute for a specific webapp context path.
# 'ROOT' is the reserved name for the root webapp context path.
# servletSessionCookieSameSite.ROOT=None
# servletSessionCookieSameSite.fs5webmon=None
# servletSessionCookieSameSite.webappContextPath=None

Mögliche Werte des Attributs SameSite:

• Strict:
  • Das Session Cookie wird nur im First-Party-Kontext gesendet (also nur, wenn die Seite für den Cookie mit der URL im Browser übereinstimmt) und
  • nicht zusammen mit Cross-Site-Requests, die von Websites Dritter initiiert werden.
• Lax:
  • Das Session Cookie wird nur im First-Party-Kontext gesendet (also nur, wenn die Seite für den Cookie mit der URL im Browser übereinstimmt) und
  • nur zusammen mit Cross-Site-Requests, die als „sicher“ angesehen werden. Dies betrifft die sicheren HTTP-Methoden (GET, HEAD, OPTIONS und TRACE) und die Top-Level-Navigation (Aktionen, die eine Änderung der URL in der Adressleiste des Browsers veranlassen, wie z. B. Links). SameSite=Lax ist die Standardeinstellung in modernen Browsern.
• None:
  • Das Session Cookie wird in allen Kontexten (also auch im Third-Party-Kontext) gesendet, d.h. das Senden ist ursprungsübergreifend erlaubt.
  • In dieser Einstellung bietet das Attribut keinen zusätzlichen Schutz gegen CSRF. Diese Einstellung kann aber sinnvoll sein, wenn eine FirstSpirit-Webanwendung in eine andere Webanwendung integriert werden soll.
• Wert nicht gesetzt (FirstSpirit Standardeinstellung):
  • Ist der Wert nicht gesetzt, werden die Standardeinstellungen der Servlet Engine verwendet.
  • Ist hier kein Wert für das Attribut SameSite konfiguriert, wird die Standardeinstellung des Browsers verwendet. Moderne Browser interpretieren ein nicht gesetztes SameSite-Attribut als SameSite=Lax.

Für Arbeitsabläufe kann ein Termin angegeben werden, bis zu welchem der gesamte Arbeitsablauf durchlaufen sein muss. Der durch den Redakteur wählbare Termin wird dem nächsten Bearbeiter im entsprechenden Aktionsfenster angezeigt. Darüber hinaus wird der Termin im Report-Bereich für Aufgaben angezeigt.

Bisher konnte nur ein Datum für den Termin ausgewählt werden. Mit dem aktuellen Release kann jetzt zusätzlich eine Uhrzeit ausgewählt werden.

Die Eingabeelemente „Kontrollkästchen“ (CMS_INPUT_CHECKBOX), „Optionsfeld“ (CMS_INPUT_RADIOBUTTON) und „Umschalter“ (CMS_INPUT_TOGGLE) erlauben die Auswahl von Werten, die der Projektentwickler vorgibt. Dabei kann bei einem „Optionsfeld“ und beim „Umschalter“ genau ein Wert ausgewählt werden, beim „Kontrollkästchen“ können mehrere Werte gewählt werden. Beim „Optionsfeld“ und beim „Umschalter“ wird durch das Aktivieren eines Feldes ein zuvor gewähltes deaktiviert, beim „Kontrollkästchen“ ist dies nicht der Fall.

Im neuen FirstSpirit ContentCreator sind diese Eingabeelemente jetzt wieder besser voneinander unterscheidbar. Der Redakteur kann wieder besser erkennen, wie der Zustand dieser Eingabeelemente in einem Formular ist und wie sie bedient werden können: „Optionsfelder“ werden jetzt durch Kreise visualisiert, „Kontrollkästchen“ durch Kästchen.

Diese neue Visualisierung wirkt sich auch Dialoge des ContentCreator aus, z. B. den Dialog „Neue Seite anlegen“:

Im FirstSpirit ContentCreator kann für Inhalte in Tabellen (CMS_INPUT_DOM / „Inline-Tabellen“ und CMS_INPUT_DOMTABLE) jetzt auch die vertikale Ausrichtung bestimmt werden. Dazu kann – analog zum bereits bestehenden Attribut align für die horizontale Ausrichtung – das neue Attribut valign verwendet werden. Die vorgegebenen Schlüsselbegriffe für die verschiedenen Ausrichtungen sind

• top (oben)
• middle (Mitte / zentriert, Standardeinstellung)
• bottom (unten)

1) Beispiel CMS_INPUT_DOM / Inline-Tabellen:

Über Stilvorlagen werden Tabellenlayoutmerkmale von Inline-Tabellen, z. B. Hintergrundfarbe, Textausrichtung usw., festgelegt. Das Formular für die Erfassung der vertikalen Textausrichtung in einer Stilvorlage (z. B. in der „Standard-Stilvorlage“) muss den Bezeichner valign erhalten.

Beispiel:

<CMS_INPUT_RADIOBUTTON name="valign" gridHeight="1" useLanguages="no">
     <ENTRIES>
       <ENTRY value="top">
         <LANGINFOS>
           <LANGINFO lang="*" label="Top"/>
           <LANGINFO lang="DE" label="Oben"/>
         </LANGINFOS>
       </ENTRY>
       <ENTRY value="middle">
         <LANGINFOS>
           <LANGINFO lang="*" label="Centre"/>
           <LANGINFO lang="DE" label="Zentriert"/>
         </LANGINFOS>
       </ENTRY>
       <ENTRY value="bottom">
         <LANGINFOS>
           <LANGINFO lang="*" label="Bottom"/>
           <LANGINFO lang="DE" label="Unten"/>
        </LANGINFOS>
       </ENTRY>
     </ENTRIES>
     <LANGINFOS>
       <LANGINFO lang="*" label="Vertical alignment"/>
       <LANGINFO lang="DE" label="Vertikale Ausrichtung"/>
     </LANGINFOS>
</CMS_INPUT_RADIOBUTTON>

Darstellung im ContentCreator:

Die Ausrichtung, die durch den Redakteur im entsprechenden Dialog „Zelleigenschaften bearbeiten“ festlegt, kann beispielsweise im HTML-Ausgabekanal der Stilvorlage, und damit in der Vorschau sowie auf der generierten Seite ausgegeben werden, z. B.

...
style='
   ...
   $CMS_VALUE(if(!valign.isEmpty, "vertical-align:" + valign + ";"))$
   ...
      '

2) Beispiel CMS_INPUT_DOMTABLE:
Für CMS_INPUT_DOMTABLE erfolgt die Definition von Zelleigenschaften durch den Redakteur über einen Dialog, der über das Attribut propertyConfig konfiguriert werden kann. Die vertikale Ausrichtung von Inhalt kann dabei ebenfalls über den Schlüsselbegriff valign aktiviert werden, z. B.

<CMS_INPUT_DOMTABLE name="table" 
         propertyConfig="
         valign:Vertikale Ausrichtung:
           [top:Oben|middle:Zentriert|bottom:Unten],
         align:Horizontale Ausrichtung:
           [left:Linksbündig|center:Zentriert|right:Rechtsbündig]">
     <LANGINFOS>
       <LANGINFO lang="*" label="Table"/>
       <LANGINFO lang="DE" label="Tabelle"/>
     </LANGINFOS>
</CMS_INPUT_DOMTABLE>

Darstellung im ContentCreator:

Die durch den Redakteur definierten Eigenschaften einer Zelle einer CMS_INPUT_DOMTABLE können über den HTML-Ausgabekanal der Standard-Formatvorlage „Tabellenzelle“ ausgewertet und ausgegeben werden. Dazu steht das Systemobjekt #cell zur Verfügung.
Beispiel:

<td..
   ...
   $CMS_VALUE(if(!#cell.valign.isEmpty, " valign='" + #cell.valign + "'"))$
   $CMS_VALUE(if(!#cell.align.isEmpty, " align='" + if(#cell.align == "block", 
        "justify", #cell.align) + "'"))$
   ...
</td>

Hinweis: Für den FirstSpirit SiteArchitect ist eine entsprechende Unterstützung für das Attribut valign nicht geplant.

Für weitere Informationen siehe

• Inline-Tabellen-Vorlagen: https://docs.e-spirit.com/odfs/vorlagen-grundl/aufbau-vorlagen/inline-tabellen/index.html
• CMS_INPUT_DOMTABLE: https://docs.e-spirit.com/odfs/vorlagenentwick/formulare/eingabekomponen/domtable/index.html
• Systemobjekt #style: https://docs.e-spirit.com/odfs/vorlagenentwick/vorlagensyntax/systemobjekte/style/index.html
• Systemobjekt #cell: https://docs.e-spirit.com/odfs/vorlagenentwick/vorlagensyntax/systemobjekte/cell/index.html

Über die Funktionalitäten „FirstSpirit External Synchronization“ und „FirstSpirit Content Transport“ können, unter anderem, Datenbank-Inhalte (Datensätze) und die zugehörigen Datenbank-Strukturen (Schemata, Tabellen, Spalten) eines FirstSpirit-Projekts (Quellprojekt) exportiert und in weitere FirstSpirit-Projekte (Zielprojekte) importiert werden. Die dbnames der Spaltennamen und Tabellen werden beim Synchronisieren neu berechnet. Dieses Verhalten kann, unter den folgenden Voraussetzungen, dazu führen, dass in den Zielprojekten, Spalten und Tabellen der Datenbank nicht gefunden werden können:

• die FirstSpirit-Schemata der beteiligten Projekte referenzieren dieselben Datenbanktabellen (und zeigen nicht auf jeweils eigene Datenbank-Tabellenräume) und
• die dbnames entsprechen nicht den automatisch berechneten dbnames

Für diesen speziellen Anwendungsfall kann jetzt beim Exportieren und Importieren von Datenbank-Schemata eine zusätzliche Mapping-Datei (Mapping.xml) verwendet werden, in der die Datenbanknamen des Quellprojekts zusammen mit den FirstSpirit-eigenen, eindeutige Bezeichnern (UUIDs) gespeichert werden, z. B.:

<xs:gid dbName="j_categories_spalte_x" uuid="66843bbe-da0d-46e3-a136-76bd93d782bb"/>
<xs:gid dbName="j_categories_spalte_y" uuid="4ba29641-26af-4edd-bac0-5a352913974d"/>
...

Über diese eindeutige Zuordnung ist es nun möglich, die Datenbank-Schemata von lesend angebundenen Datenbanken („Kein Schema Sync“) über „External Synchronization“ oder „Content Transport“ wie folgt zu synchronisieren:

• Wird ein Schema im Quellprojekt geändert und über eine der beiden Funktionalitäten in weitere FirstSpirit-Projekte synchronisiert, so werden die Namen von Datenbanktabellen und Datenbankspalten aus dem Quellprojekt in die Zielprojekte übernommen.
• Werden Datenbanktabelle oder Datenbankspalte im Zielprojekt neu angelegt, so wird nun bevorzugt der entsprechende dbname des Ursprungsschemas verwendet.

Bei einer Verwendung von „FirstSpirit External Synchronization“ kann die Mapping-Datei (Mapping.xml) über eine neue Option im Interface ExportOperation.SchemaOptions (setExportGidMapping=true) zur Export-Datei hinzugefügt werden:

ExportOperation exportOperation = ... // get the export operation via agent;
ExportOperation.SchemaOptions schemaOptions = exportOperation.addSchema(schema);
schemaOptions.setExportGidMapping(true);
ExportOperation.Result result = exportOperation.perform(...);

Für die neue Funktionalität musste das bisherige Export-Format nicht erweitert werden. Es kann weiterhin das Export-Format in der Version 3.2 eingesetzt werden.

Ohne Mapping-Datei (Standardverhalten beim Einsatz von „FirstSpirit External Synchronization“) werden die dbnames der Spaltennamen und Tabellen wie bisher beim Synchronisieren neu berechnet. Bei den regulären Anwendungsfällen wird es bei der Neuberechnung keine Abweichung geben, so dass der Einsatz einer Mapping-Datei nicht notwendig ist.

Bei einer Verwendung der Funktionalität „FirstSpirit Content Transport“ wird die Mapping-Datei (Mapping.xml) automatisch erzeugt und verwendet.

Folgende Modul-Versionen für „FirstSpirit Content Experience Tools“ werden von FirstSpirit 2020-05 unterstützt:

* Diese Module benötigen ab dieser Version FirstSpirit 2020-03 oder höher.

Bislang konnten MicroApps im MicroApp Framework als modaler Dialog per MicroApps API aufgerufen werden (CxtMicroApps.getButtons(context)).
Mit dem aktuellen Release wurde die MicroApps API um die Methode CxtMicroApps.embedMicroApp erweitert, mit der MicroApps jetzt direkt in eine HTML-Seite eingebettet werden können („Widget“).
Die API bietet darüber hinaus die Möglichkeit, Handler hinzuzufügen und zu benutzen und auf Events zu reagieren.

Hinweis: Die Verwendung der API ist aktuell noch für den internen Gebrauch bestimmt und wird intern sowie durch Partner getestet. Zukünftig soll sie auch für externe Kunden bereitgestellt werden.

Bislang konnten im Report des Fragment DAP (<SOURCE name="FirstSpiritFragmentAccess/FSFAConnector">) die angezeigten Fragmente nach Remote-Projekt oder durch Angabe eines Suchbegriffs gefiltert werden. Mit dem aktuellen Release werden die Optionen zum Filtern um die Kategorie erweitert, zu der die angezeigten Fragmente gehören.

Wenn der Fragmente-Report im ContentCreator geöffnet wird, ist als Standard kein Filter ausgewählt. Anders als zuvor können somit sämtliche Fragmente aus allen verknüpften Projekten gleichzeitig eingesehen werden.

Der Report des Fragment DAP ohne Filter

Zusätzlich zu den bisherigen Filtern nach einem spezifischen Projekt und per Suchbegriff, steht nun auch ein Filter nach Kategorien als Dropdown-Menü zur Auswahl. Hier kann aus allen Kategorien der verknüpften Projekte eine ausgewählt werden, um die angezeigten Fragmente einzuschränken.

Kommt eine gleichnamige Kategorie in mehreren Projekten vor, so werden beim Filtern nach dieser Kategorie zunächst projektübergreifend alle Fragmente aus der Kategorie angezeigt. Die Ergebnisse können wie zuvor auch noch weiter eingeschränkt werden, indem nach einem bestimmten Projekt oder Suchbegriff gefiltert wird.

Im Rahmen der Überarbeitung und Zusammenführung der technischen Basis für FirstSpirit ContentCreator und FragmentCreator wurde die graphische Oberfläche des FragmentCreator überarbeitet und an die Designprinzipien des ContentCreator angepasst.

Mit dem Design-Update sind grundsätzlich keine funktionalen Änderungen für Redakteure oder Entwickler verbunden. Alle Funktionen in den Oberflächen stehen prinzipiell an den bekannten Positionen zur Verfügung. Weder entwicklungs- noch betriebsseitig fallen Aufwände mit dem Update des Designs an.

Die Änderungen des aktuellen Releases betreffen in erster Linie die Eingabefelder für Text und Auswahl sowie die Tags (CMS_INPUT_TEXT, CMS_INPUT_CHECKBOX, CMS_INPUT_COMBOBOX, CMS_INPUT_RADIOBUTTON, FS_TAGGING u.a.).

Die Anpassung der Dokumentation hinsichtlich des Designs erfolgt sukzessive, daher entspricht die Darstellung in der Dokumentation potenziell nicht mehr dem aktuellen Software-Stand.

Ressourcen eines Moduls haben einen bestimmten Gültigkeitsbereich. Das bedeutet, die entsprechenden Jars und Verzeichnisse können entweder nur innerhalb des Moduls (modul-lokal) oder serverweit (global) erreichbar sein. Globale Ressourcen (scope=„global“) stehen auch anderen Modulen auf dem Server zur Verfügung. Allerdings liegen dabei alle Klassen in einem Namensraum, und damit kann es jede Klasse nur einmal geben. Die Verwendung verschiedener Versionen einer Klasse ist damit ausgeschlossen.

Classloading und Versionierung von Ressourcen: Werden die gleichen globalen Ressourcen von mehreren Modulen in jeweils unterschiedlichen Versionen mitgebracht, kann nur eine dieser globalen Ressourcen von allen Modulen verwendet werden. Um Konflikte zwischen verschiedenen Modulen zu vermeiden, werden die Klassen – soweit wie möglich – über einzelne, voneinander getrennte Modul-Classloader geladen. Bei globalen Ressourcen wird dann eine dieser Klassen über den kombinierten, globalen Classloader zur Verfügung gestellt.

Bei identischen Namen wird versucht herauszufinden, ob Ressourcen miteinander kompatibel sind. Dazu werden neben dem eindeutigen Bezeichner („name“) in der Ressourcendefinition (module.xml) auch die mitgelieferte Version der Ressource („version“) sowie (optional) die Angabe der minimal kompatiblen Version („minVersion“) und der maximal kompatiblen Version („maxVersion“) benötigt, z. B.:

<web-resources>
 <resource name="..." version="4.4" minVersion="4.4" maxVersion="4.5.2">
     lib/httpclient-compatibility.jar
 </resource>
</web-resources>

Bisheriges Verhalten

Bisher konnte nicht sichergestellt werden, dass immer die neueste Version einer globalen Ressource verwendet wurde. Die modul-lokalen Ressourcen wurden über den jeweiligen Modul-Classloader geladen und dann wurde eine von diesen Ressourcen über den kombinierten, globalen Classloader zur Verfügung gestellt. Dabei wurde zwar berücksichtigt, dass die Version kompatibel zu den anderen Modulen war (basierend auf „name“ und „maxVersion“ bzw. „minVersion“), es wurde aber nicht immer auch die neueste Version (also die Version mit der höchsten Versionsnummer) verwendet.

Bei einer Modulaktualisierung konnte dieses Verhalten Probleme verursachen, weil beispielsweise Dienste, die auf diese globalen Ressourcen zugreifen, mit einer anderen Version nicht mehr funktionierten.

Neues Verhalten

Mit dem aktuellen FirstSpirit-Release wird sichergestellt, dass beim normalen Betrieb immer die neueste Version (also die Version mit der höchsten Versionsnummer) einer globalen Ressource verwendet wird, auch wenn diese zuvor über verschiedene Modul-Classloader geladen wurden. Stellen mehrere Module die gleiche Version einer globalen Ressource zur Verfügung, wird ebenfalls immer die globale Ressource aus dem gleichen Modul geladen. Dabei wird natürlich weiterhin berücksichtigt, ob die Versionen kompatibel zu den anderen Modulen sind (basierend auf „name“ und „maxVersion“ bzw. „minVersion“).

Es gilt: Stellen mehrere Module die gleiche globale Ressource zur Verfügung und sind die Versionen kompatibel zueinander, wird immer die Version mit der höchsten Versionsnummer verwendet.

Damit steigt die Stabilität bei der Auflösung von Abhängigkeiten nach einer Modulaktualisierung. Module, die globale Ressourcen enthalten, die von unterschiedlichen Diensten verwendet werden, bleiben jetzt mit einer größeren Wahrscheinlichkeit nach einer Modulaktualisierung funktionsfähig. In Einzelfällen kann aber weiterhin ein Neustart des FirstSpirit-Servers notwendig sein.

Weiterführende Dokumentation:

• Modulentwicklung (Versionierung von Ressourcen)
• Moduldefinition
• Modulaktualisierung

Mit dem aktuellen FirstSpirit-Release unterstützt die JSON-Funktion auch referenzierte Objekte der Eingabekomponente FS_REFERENCE.

Für diese Änderung wird keine neue Version des JSON-Ausgabeformats veröffentlicht, die Änderungen fließen in die aktuelle Formatversion 1.1. ein.

Übersicht der Änderungen in Formatversion 1.1

Die Eingabekomponente FS_REFERENCE dient zur Aufnahme einer beliebigen Referenz. Der Typ des referenzierten Objekts ist dabei nicht festgelegt: es können Referenzen zu Medien (Bilder und Dateien), zu Seitenreferenzen, Ordnern, Absätzen der aktuellen Seite und vielen weiteren Objekten festgelegt werden.

Über die JSON-Funktion können die referenzierten FirstSpirit-Objekte der Eingabekomponente FS_REFERENCE nun in eine JSON-Objektstruktur überführt werden (bisher wurden die referenzierten Objekte nicht gerendert). Dabei wird nicht das Objekt selbst, sondern nur die Daten gerendert, die zur Referenzierung notwendig sind.

Beispiel: Eine Eingabekomponente vom Typ FS_REFERENCE verweist über den Modus sections=„only“auf die Absätzen der aktuellen Seite.

Die Ausgabe der Seitenreferenz (oder der Seite) im Format 1.1 enthält dann den neuen Bereich „section“: mit den Daten zu den referenzierten Absätzen („fsType“: „Section“)

"st_reference_pageref": {
   "fsType": "FS_REFERENCE",
   "name": "st_reference_pageref",
   "value": {
      "fsType": "PageRef",
      "name": "test",
      "identifier": "c88bc52c-aab9-4f66-870c-1354ca73fcb1",
      "uid": "test",
      "uidType": "SITESTORE_LEAF",
      "url": "http:\/\/www.myurl.de\/external_sync_DE\/test.json",
      "section": {
            "fsType": "Section",
            "name": "cms_input_text",
            "displayName": "CMS_INPUT_TEXT",
            "identifier": "c56cbc16-e70d-426d-af0f-16de05578922"
         }
      }
   }
}

Weiterführende Dokumentation:

• JSON-Konfiguration (ServerManager)
• JSON-Ausgabe (Vorlagen)
• Eingabekomponente FS_REFERENCE

Hinweise zur Formatversion

Die Formatversion kann über die JSON-Einstellungen explizit gesetzt werden:

$CMS_SET(#global.json.formatVersion, "1.1")$

Wenn über FirstSpirit-Updates hinweg eine unveränderte JSON-Ausgabe benötigt wird, sollte die Formatversion explizit in den Projekteinstellungen unter Globale Einstellungen gesetzt werden.

Wenn die Formatversion nicht explizit eingestellt wird, dann wird immer die aktuelle JSON-Formatversion (1.1) verwendet.

Pop-up-Dialoge, die mithilfe des Interfaces RequestOperation (FirstSpirit Developer-API, Package de.espirit.firstspirit.ui.operations) erstellt werden, können jetzt über Enum RequestOperation.Kind (FirstSpirit Developer-API, Package de.espirit.firstspirit.ui.operations) auch als Warnhinweis erzeugt werden:

Beispiel:

import de.espirit.firstspirit.agency.OperationAgent;
import de.espirit.firstspirit.ui.operations.RequestOperation;
import de.espirit.firstspirit.ui.operations.RequestOperation.Kind;

opAgent = context.requireSpecialist(OperationAgent.TYPE);
if (opAgent != null) {
      RequestOperation requestOp = opAgent.getOperation(RequestOperation.TYPE);
      requestOp.setKind(Kind.WARN);
      requestOp.setTitle("Whoa, there!");
      requestOp.perform("Once you delete this content, there's no getting it back. 
         Make sure you want to do this!");
  } else {
   context.logInfo("...");
  }

Mögliche Typen (RequestOperation.Kind):

• WARN (Neu)
• INFO
• QUESTION
• ERROR

Im SiteArchitect und ServerManager werden Pop-up-Dialoge vom Typ WARN mit einem Ausrufezeichen-Symbol angezeigt und Pop-up-Dialoge vom Typ INFO mit einem „i“-Symbol.

Der ContentCreator unterscheidet bei der Darstellung nicht zwischen Pop-up-Dialogen vom Typ WARN oder vom Typ INFO. Beide Arten werden identisch mit einem Ausrufezeichen-Symbol angezeigt.

FirstSpirit stellt API-Schnittstellen und eine Referenz-Implementierung („Advanced URL Creator“) zur Verfügung, um benutzerspezifische Pfadstrategien zur URL-Erzeugung in FirstSpirit einzubinden. Sämtliche Konfigurationsparameter (sowohl die von FirstSpirit ausgewerteten Standard-Parameter als auch benutzerdefinierte Parameter) müssen dabei entweder über ein Auftrags-Skript definiert werden, das vor dem eigentlichen Generierungsauftrag ausgeführt wird oder über die Konfigurationseinstellungen in der module.xml-Datei.

Das FirstSpirit-Framework wertet einige vorgegebenen Standard-Parameter direkt aus, u.a.:

• useWelcomeFileNames (zur Konfiguration von Startseitenreferenzen)
• stripWelcomeFileNames (entfernt die Extension /index.* aus der Advanced URL)

Weitere Standard-Parameter siehe FirstSpirit-Dokumentation: Standard-Konfigurationsparameter.

Für alle Parameter gilt: Die Groß- bzw. Kleinschreibung der Parameter ist nicht relevant, d. h. useWelcomeFileNames, USEWELCOMEFILENAMES oder usewelcomefilenames sind gültige Bezeichnungen für ein und denselben Parameter.

Die Parameter „useWelcomeFileNames“ und „stripWelcomeFilenames“, die zur Konfiguration benutzerspezifischer Pfadstrategien zur URL-Erzeugung eingesetzt werden, bieten mit dem aktuellen FirstSpirit-Release neue Konfigurationsmöglichkeiten an.

Änderung für den Parameter „useWelcomeFileNames“

Der Parameter „useWelcomeFileNames“ kann zur Konfiguration von Startseitenreferenzen verwendet werden.

context.setProperty("#urlCreatorSettings", 
Collections.singletonMap("usewelcomefilenames", "true"));

Bisheriges Verhalten:

Mögliche Werte:

• true oder yes oder Wert nicht gesetzt (Standardwert)
• false oder no

true oder yes (Standardwert): Wird der Parameter mit dem Wert „true“ übergeben (Standardwert), wird für Seitenreferenzen, die als Startseite eines Ordners der Struktur-Verwaltung markiert sind, immer der Dateiname index.* beim Erzeugen einer Advanced URL geliefert (unabhängig vom Anzeigenamen oder dem Dateinamen aus dem Eigenschaftsdialog).

Aus

../en/startpage/mithras_home.html

bei der Standard-URL-Erzeugung wird im Advanced-Modus mit „useWelcomeFileNames“ (true):

../Startpage/index.html

Für Seitenreferenzen, die nicht als Startseite gekennzeichnet sind, wird dagegen weiterhin der Anzeigename beim Erzeugen der Advanced URL verwendet.

false oder no: Wird der Parameter mit dem Wert „false“ übergeben, werden für alle Seitenreferenzen, unabhängig ob Startseite oder nicht, die URLs basierend auf dem Anzeigenamen der Seitenreferenz erzeugt (wobei die Leerzeichen durch ein „-“-Zeichen ersetzt werden):

../Startpage/Mithras-Homepage.html

Neues Verhalten:

Mögliche Werte:

• true oder yes oder Wert nicht gesetzt (Standardwert): Nur der erste HTML-Ausgabekanal verwendet Welcomefilenames.
• false oder no: Es werden keine Welcomefilenames verwendet.
• all: Alle HTML-Ausgabekanäle verwenden Welcomefilenames. (Eine solche Konfiguration kann zu identischen URLs führen, siehe (*)).
• Kommaseparierte Liste von Ausgabekanälen: Alle aufgelisteten Kanäle verwenden Welcomefilenames. (Eine solche Konfiguration kann zu identischen URLs führen, siehe (*)).

true oder yes: Wird der Parameter mit dem Wert „true“ übergeben (Standardwert), wird für Seitenreferenzen, die als Startseite eines Ordners der Struktur-Verwaltung markiert sind, der Dateiname index.* beim Erzeugen einer Advanced URL geliefert (unabhängig vom Anzeigenamen oder dem Dateinamen aus dem Eigenschaftsdialog) - aber nur noch für den ersten HTML-Ausgabekanal (z.B. „html“), während für alle weiteren Ausgabekanäle (z.B.„ php“), die URLs weiterhin basierend auf dem Anzeigenamen der Seitenreferenz erzeugt werden (wobei die Leerzeichen durch ein „-“-Zeichen ersetzt werden).

../Startpage/index.html

false oder no: Wird der Parameter mit dem Wert „false“ übergeben, werden für alle Seitenreferenzen, unabhängig ob Startseite oder nicht, die URLs basierend auf dem Anzeigenamen der Seitenreferenz erzeugt (wobei die Leerzeichen durch ein „-“-Zeichen ersetzt werden):

../Startpage/Mithras-Homepage.html

all: Wird der Parameter mit dem Wert „all“ übergeben, wird für Seitenreferenzen, die als Startseite eines Ordners der Struktur-Verwaltung markiert sind, der Dateiname index.* beim Erzeugen einer Advanced URL geliefert (unabhängig vom Anzeigenamen oder dem Dateinamen aus dem Eigenschaftsdialog) - für alle im Projekt vorhandenen HTML-Ausgabekanäle. (Eine solche Konfiguration kann zu identischen URLs führen, siehe (*)).

Liste von Ausgabekanälen: Wird dem Parameter eine Liste von Ausgabekanälen übergeben, wird für Seitenreferenzen, die als Startseite eines Ordners der Struktur-Verwaltung markiert sind, der Dateiname index.* beim Erzeugen einer Advanced URL geliefert (unabhängig vom Anzeigenamen oder dem Dateinamen aus dem Eigenschaftsdialog) - für alle HTML-Ausgabekanäle, die in der Liste angegeben sind. Angegeben wird hier der Name des Vorlagensatzes („Vorlagensatz-Name“: siehe FirstSpirit-Produktdokumentation unter Vorlagensätze eines Projektes). (Eine solche Konfiguration kann zu identischen URLs führen, siehe (*)).

Änderung für den Parameter „stripWelcomeFileNames“

Der Parameter „stripWelcomeFileNames“ ist nur relevant, wenn die verwendete URL-Pfadstrategie auch den Konfigurationsparameter „useWelcomeFileNames“ verwendet.

Mithilfe des Parameters „stripWelcomeFileNames“ kann die durch „useWelcomeFileNames“ ergänzte Extension „/index.*“ aus der Advanced URL entfernt werden (aber nicht aus dem Dateinamen, unter dem die Seite im Dateisystem abgelegt wird).

factorySettings = new HashMap(); 
factorySettings.put("usewelcomefilenames", "true");  
factorySettings.put("stripwelcomefilenames", "true");  
context.setProperty("#urlCreatorSettings", factorySettings);  

Bisheriges Verhalten:

Mögliche Werte:

• true oder yes oder Wert nicht gesetzt (Standardwert)
• false oder no

Werden die Parameter „useWelcomeFileNames“ und „stripWelcomeFileNames“ mit dem Wert „true“ übergeben (Standardwert), wird für Seitenreferenzen, die als Startseite eines Ordners in der Struktur-Verwaltung markiert sind, der Anzeigename der Startseite aus der Advanced URL entfernt.

Aus

../en/startpage/mithras_home.html

bei der Standard-URL-Erzeugung wird im Advanced-Modus mit „useWelcomeFileNames“ und „stripWelcomeFileNames“ (im Dateisystem):

../Startpage/index.html

Und die Advanced URL:

../Startpage

Damit wird die Startseite des Ordners „Startpage“ im Dateisystem zwar mit der Extension „/index.*“ angelegt, kann aber (bei passender Webserver-Konfiguration) über die URL „/Startpage/“ angefragt werden.

Sind im Projekt mehrere Vorlagensätze vorhanden, wird über „stripWelcomeFileNames“ nur „index.{master extension}“ entfernt. „Master extension“ ist die Dateierweiterung aus dem ersten Vorlagensatz (üblicherweise „html“).

Wird der Parameter „stripWelcomeFileNames“ mit dem Wert „false“ übergeben, bleibt für alle Startseitenreferenzen die Extension „/index.*“ im Dateisystem und in der Advanced URL erhalten.

Neues Verhalten:

Mögliche Werte:

• true oder yes oder Wert nicht gesetzt (Standardwert): „/index.*“ (üblicherweise „/index.html“) wird gekürzt.
• false oder no: URL wird nicht gekürzt
• Liste von Erweiterungen: Alle aufgelisteten Erweiterungen (z. B. „/index.html“ und „/index.php“) werden gekürzt.

true oder yes: Wird der Parameter „stripWelcomeFileNames“ mit dem Wert „true“ übergeben (Standardwert), wird die Startseite des Ordners „Startpage“ im Dateisystem zwar mit der Erweiterung „/index.*“ angelegt, kann aber (bei passender Webserver-Konfiguration) über die URL „/Startpage/“ angefragt werden.

false oder no: Wird der Parameter „stripWelcomeFileNames“ mit dem Wert „false“ übergeben, bleibt für alle Startseitenreferenzen die Erweiterung „/index.*“ im Dateisystem und in der Advanced URL erhalten.

Liste von Erweiterungen: Wird dem Parameter eine Liste von Erweiterungen übergeben, wird für Seitenreferenzen, die als Startseite eines Ordners der Struktur-Verwaltung markiert sind, die Extension „/index.*“ beim Erzeugen einer Advanced URL gekürzt und kann, bei entsprechender Webserver-Konfiguration, über die jeweilige URL angefragt werden (analog zum Verhalten beim Wert „true“). Angegeben werden hier die Namen der Erweiterungen („Zieldatei-Erweiterung:“: siehe FirstSpirit-Produktdokumentation unter Vorlagensätze eines Projektes).

Ein Arbeitsablauf ist eine Abfolge von Aufgaben, die nach einer fest vorgegebenen Struktur abgearbeitet werden. Diese besteht in FirstSpirit aus Status, Aktivitäten und Transitionen, wobei Transitionen die Verbindung zwischen Aktivität und Status bilden.

Projektspezifische Arbeitsabläufe können über einen grafischen Editor im FirstSpirit SiteArchitect („Vorlagen“ / „Arbeitsabläufe“) erstellt werden. Instanzen dieser Arbeitsabläufe können anschließend kontextgebunden auf jedem Element innerhalb des FirstSpirit-Projekts (SiteArchitect: Kontextmenü in der Baumansicht / „Arbeitsablauf“ und im ContentCreator über den Element-Status) oder kontextfrei über die FirstSpirit-Menüleiste („Aufgaben“ / „Arbeitsablauf“ bzw. im ContentCreator über „Aktionen“) gestartet werden. Jede Instanz eines Arbeitsablaufs muss entsprechend der im Arbeitsablauf festgelegten Regeln durchlaufen werden. Dabei wird bei jeder Aktivität ein Dialog geöffnet, der dem Bearbeiter die Möglichkeit gibt, den Arbeitsablauf über die Auswahl einer Transition (über eine Schaltfläche im Dialog) weiterzuschalten.

Mit dem aktuellen FirstSpirit-Release kann die Reihenfolge für die Anzeige der Transitionen auf einer Aktivität im Arbeitsablauf konfiguriert werden.

Die Konfiguration erfolgt auf dem Arbeitsablauf im FirstSpirit SiteArchitect „(Vorlagen“ / „Arbeitsabläufe“) im Register „Zustandsdiagramm“. Wird im grafischen Editor eine manuelle Aktivität selektiert, erscheint in der Eigenschaften-Ansicht (rechts) unter „Allgemeines“ die neue Eigenschaft „Transitionen“, die alle ausgehenden Transitionen der selektierten Aktivität anzeigt. Über das Icon

Reihenfolge ausgehender Transitionen ändern

Die geänderte Reihenfolge wirkt sich auf die Anzeige der Schaltflächen im Dialog aus.

Geänderte Reihenfolge der Transitionen im Dialog

Weiterführende Informationen:

• Konfiguration von Arbeitsabläufen (Vorlagen)
• Arbeitsabläufe im SiteArchitect
• Arbeitsabläufe im ContentCreator
• Arbeitsabläufe im FragmentCreator

Mit dem aktuellen FirstSpirit-Release wurde folgende intern verwendete Software aktualisiert:

ASM (Bibliothek für die Analyse und Modifikation von Java-Bytecode)

Aktualisierung von Version 7.3.1 auf Version 8.0.1.

In E-Mails, die durch Arbeitsabläufe versendet werden, können spezielle Platzhalter verwendet werden, die vom System automatisch kontextbezogen, ersetzt werden. Auf diese Weise kann beispielsweise ein Link zur Vorschau der Seite, auf der der Arbeitsablauf aktiv ist, und viele weitere Informationen in der E-Mail ausgegeben werden.

Die Platzhalter können auf den Eigenschaften einer Aktivität oder einer Transition im Register „E-Mail“ konfiguriert werden „(Vorlagenverwaltung“ / „Arbeitsabläufe“ / „Zustandsdiagramm“). Beim Schalten einer Transition oder Aktivität werden dann automatisch die E-Mails mit den entsprechenden Informationen versendet.

Die Platzhalter werden, mit dem aktuellen FirstSpirit-Release, um folgende Möglichkeiten erweitert:

• %DATE_TIME% = Fälligkeitsdatum (nur wenn gesetzt) mit Uhrzeit. Das Format ist lokalisiert, z. B. in der englischen Version: „February 25, 1986 at 11:04:37 AM CET“.
• %HISTORY_SHORT% = Historie der Instanz des Arbeitsablaufs, nur die letzten drei Einträge werden angezeigt, in aufsteigender Reihenfolge (z. B. Eintrag: 8, 9, 10).
• %HISTORY_LAST% = Historie der Instanz des Arbeitsablaufs, nur der letzte Eintrag wird angezeigt (z. B. Eintrag: 10).
• %HISTORY_DESC% = Historie der Instanz des Arbeitsablaufs, alle Einträge werden angezeigt, in absteigender Reihenfolge (z. B. Eintrag: 10, 9, 8, 7, 6, 5, 4, 3, 2, 1).
• %HISTORY_SHORT_DESC% = Historie der Instanz des Arbeitsablaufs, nur die letzten drei Einträge werden angezeigt, in absteigender Reihenfolge (z. B. Eintrag: 10, 9, 8).
• %LAST_USER_FULLNAME% = letzte bearbeitende Person, es wird der volle Name ausgegeben (ist dieser nicht bekannt, wird der Anmeldename ausgegeben).
• %NEXT_USER_FULLNAME% = Name der Personen, die den Arbeitsablauf im nächsten Schritt bearbeiten dürfen. Es werden die vollen Namen ausgegeben (sind diese nicht bekannt, werden die Anmeldenamen ausgegeben).

Alle bisherigen Platzhalter werden wie zuvor unterstützt:

• %FIRSTspiritURL% = Verbindungsmodus HTTP (Standardmodus; Mastersprache)
• %FIRSTspiritSOCKETURL% = Verbindungsmodus SOCKET (Mastersprache)
• %PAGESTORE_PREVIEW_URL% = Vorschau-URL einer Seite aus der Inhalte-Verwaltung (Mastersprache)
• %SITESTORE_PREVIEW_URL% = Vorschau-URL einer Seitenreferenz aus der Struktur-Verwaltung (Mastersprache)
• %WF_NAME% = Name des Arbeitsablaufs
• %CREATOR% = Name der Person, die den Arbeitsablauf erzeugt hat. Es wird der volle Name ausgegeben (ist dieser nicht bekannt, wird der Anmeldename ausgegeben).
• %LAST_USER% = Name der Person, die den Arbeitsablauf zuletzt bearbeitet hat. Es wird der Anmeldename ausgegeben.
• %LAST_COMMENT% = letzter Kommentar
• %NEXT_USER% = Name der Personen, die den Arbeitsablauf im nächsten Schritt bearbeiten dürfen. Hier werden die Anmeldenamen ausgegeben.
• %PRIORITY% = Priorität
• %DATE% = Fälligkeitsdatum (nur wenn gesetzt)
• %HISTORY% = Historie der Instanz des Arbeitsablaufs, alle Einträge werden angezeigt, in aufsteigender Reihenfolge (z. B. Eintrag: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10).
• %WEBeditURL% = WebEdit Link auf die Vorschau der Seite (Mastersprache)

Weiterführende Dokumentation:

• Arbeitsabläufe / Eigenschaften einer Aktivität / Register E-Mail
• Arbeitsabläufe / Eigenschaften einer Transition / Register E-Mail