SystemExecute-Prozeduren

Der System-Execute-Mechanismus des Content Managers und der Template Engine dient dazu, beim Export (und beim Content Manager auch bei der Vorschau) Datei- oder Versionsdaten zu exportieren, die nicht mit NPSOBJ-insertvalue-Anweisungen ermittelt werden können. SystemExecute-Prozeduren werden folgendermaßen aufgerufen:

<npsobj insertvalue="systemExecute" name="procAlias">content</npsobj>

Diese Anweisung führt die Prozedur mit dem Alias procAlias aus und fügt den Rückgabewert anstelle der Anweisung in die Exportdatei ein. System-Execute-Alias-Namen werden im Systemkonfigurationseintrag export als Wert von tclSystemExecuteCommands registriert. Der entsprechende Eintrag in der Konfigurationsdatei des Content Managers oder der Template Engine hat folgendes Format:

<tclSystemExecuteCommands>
  <procAlias>sysExecProc</procAlias>
</tclSystemExecuteCommands>

Die Angabe name="procAlias" in der NPSOBJ-Anweisung bewirkt bei obiger Konfiguration, dass die Prozedur sysExecProc aufgerufen wird. SystemExecute-Prozeduren müssen im instanzenspezifischen Verzeichnis script/cm/serverCmds abgelegt werden. Dadurch werden sie beim Start des Content-Managers und der Template-Engine eingelesen. Beachten Sie bitte, dass der Tcl-Code von Systemprozeduren nur lesenden Zugriff auf die CMS-Daten hat.

Einer SystemExecute-Prozedur wird als erstes Argument die ID der Datei oder Links übergeben, in deren Kontext die Anweisung ausgeführt wird. Als zweites Argument erhält sie den ausgewerteten Inhalt des aufrufenden NPSOBJ-Elements. Die folgende Beispielprozedur sysExecProc gibt als Ergebnis einen formatierten Text zurück, der diese beiden Werte enthält.

proc sysExecProc {objId content} {
  set result "<b>ObjId: $objId</b>\n"
  append result "<pre>$content</pre>\n"
  return $result;
}

Datei-Abhängigkeiten auf dem Live-Server

SystemExecute-Prozeduren haben lesenden Zugriff nicht nur auf die gerade exportierte Datei, sondern auch auf beliebige andere Dateien. Wenn Sie die Template Engine einsetzen und eine referenzierte Datei aktualisiert wurde, so ist möglicherweise auch die Datei, das den SystemExecute-Aufruf enthält, nicht mehr aktuell und muss neu exportiert werden. Diese Datei hängt von der referenzierten Datei ab.

Wenn beispielsweise eine systemExecute-Prozedur aufgerufen wird, während Datei A exportiert wird, und diese Prozedur Versionsfelder von B ausliest und in das Exportergebnis von A aufnehmen lässt, dann sollte nicht nur die Webseite von B, sondern auch die von A ungültig werden, sobald Versionsfelder von B geändert werden. Dies würde bewirken, dass A neu exportiert wird, wenn ein Website-Besucher die zu Datei A gehörende Webseite anfordert. Indem man eine Abhängigkeit definiert, lässt sich die Webseite von A aktuell halten, auch wenn die Datei A selbst nicht geändert wird.

Abhängigkeiten können der Template Engine in der SystemExecute-Prozedur mit Hilfe der globalen Variablen additionalDependencies bekannt gemacht werden. In additionalDependencies können Sie eine Liste speichern, die Wertepaare, bestehend aus einem Abhängigkeitstyp und einer Datei-ID, enthält. Das folgende Beispiel drückt aus, dass die gerade exportierte Datei vom Inhalt der Datei mit dem Pfad /pfad/zur/datei abhängt:

global additionalDependencies
  set additionalDependencies [list content [obj withPath /pfad/zur/datei]]

Der Abhängigkeitstyp legt fest, welche Änderung an der angegebenen Datei dazu führt, dass die abhängige Datei aus dem Cache gelöscht und neu exportiert wird. In der folgenden Übersicht sind die verfügbaren Abhängigkeitstypen und ihre Änderungsbedingungen aufgeführt: