Startseite / Vorlagenentwicklung / Debugging / Gibt es Fehler?

Gibt es Fehler? / Wie können Fehler vermieden werden?

Inhaltsverzeichnis

Fehler in der Programmierung von FirstSpirit-Vorlagen bzw. ungewünschte Auswirkungen oder Ergebnisse können an unterschiedlichen Stellen auftreten bzw. diagnostiziert und teilweise auch schon vermieden werden:

Phase

Kategorie

Hinweis auf Fehler

Entwicklung von Formularen und Regeln

Aussehen und Funktion / Vorschau

Ob Formulare mit ggf. zugehörigen Regeln (Ausnahme: ONSAVE und ONLOCK) das gewünschte Aussehen und die gewünschte Funktion haben, kann direkt in der integrierten Vorschau auf dem Register „Formular“ geprüft werden.

Syntaxfehler

Auf einige Syntaxfehler auf dem Formular- und Regel-Register wird bereits direkt beim Entwickeln hingewiesen: Werden beispielsweise Parameter oder Attribute falsch verwendet, lassen sich Vorlagen nicht speichern und es wird eine entsprechende Fehlerbegründung angezeigt.
Mithilfe der Code-Vervollständigung werden automatisch nur die Parameter und Tags verwendet, die für die jeweilige Eingabekomponente verfügbar sind.

Anleitung der Redakteure, Reduzierung von Fehleingaben

Die Formular-Definition ermöglicht es dem Entwickler bereits, beispielsweise, den Funktionsumfang einer Eingabekomponente an die Bedürfnisse des Projekts und der Redakteure anzupassen, Auswahlmöglichkeiten einzuschränken, Pflichtfelder, Vorbelegungen und Rückfallwerte zu definieren (siehe dazu auch Variablen in Vorlagen).

Mithilfe von Regeln können bestimmte Eigenschaften oder Elemente von Formularen beeinflusst werden. Sie ermöglichen beispielsweise die Prüfung von Eingaben und eine entsprechende Reaktion darauf. Siehe dazu das Kapitel Regeln.

Entwicklung der Ausgabe

Coding conventions

Um beispielsweise auch mit anderen Entwicklern effizient in einem Projekt zusammenarbeiten zu können, sollten für alle Vorlagen und Variablen möglichst „sprechende“ Namen verwendet und der eigene Code kommentiert (auf Vorlagensatz-Registern: $-- Kommentar --$) werden.

Um eine bessere Übersicht über die in einem Projekt verwendeten Variablen zu erhalten, wird empfohlen, ein Variablenpräfix in den Bezeichner zu integrieren, an der die Definitionsstelle abgelesen werden kann. Auf diese Weise wird auch gewährleistet, dass Variablen sich nicht überschreiben. Siehe dazu auch Coding conventions für Variablen.

Aussehen und Funktion / Vorschau

Um Eingaben auf den Vorlagensatz-Registern prüfen und ihre Auswirkung direkt anhand von bestehenden Inhalten sehen zu können, kann auf dem Register „Eigenschaften“ im Feld „Vorschau Seite“ (für Seitenvorlagen siehe Register Eigenschaften) eine Seitenreferenz definiert werden, die die Inhalte der betreffenden Vorlagen rendert und als Vorschau für die Ausgabe der Vorlage verwendet werden soll.

Eine Prüfung, wie Webseiten-Inhalte auf unterschiedlichen Displaygrößen, für spezielle Benutzergruppen oder zu bestimmten Zeitpunkten aussehen, ermöglicht die Funktionalität Multi Perspective Preview (MPP) (→Handbuch FirstSpirit SiteArchitect) („MPP“).

Syntaxfehler, logische Fehler, fehlender Referenzen

Im Projekt selbst können eventuelle Syntaxfehler in Vorlagen durch die Kontextmenü-Funktion „Fehler der Vorschau anzeigen“ auf Seiten und Seitenreferenzen im SiteArchitect angezeigt werden (siehe Kontextmenü Speziell (→Handbuch FirstSpirit SiteArchitect)). Per Klick kann direkt zur fehlerhaften Stelle in der betreffenden Vorlage springen.

Auch bei einer Generierung werden eventuelle Syntaxfehler festgehalten und zwar in einer gesonderten Log-Datei: fs-schedule.*.log.
Allgemeine Informationen zum Betrieb des FirstSpirit-Servers und auch zu Aktionen und Fehlern in Projekten enthalten die Datei fs-server.log („Server-Log“) und fs-wrapper.log, sowie weitere Log-Dateien, die im Verzeichnis ~\log liegen.

Anleitung der Redakteure, Reduzierung von Fehleingaben

Mithilfe von Anweisungen/Funktionen wie $CMS_IF(...)$, if(...) oder $CMS_FOR(...)$ kann auf die durch den Redakteur eingegebenen Werte reagiert werden, beispielsweise für Leer-/Nullprüfungen, Fallunterscheidungen usw.

Testen, Qualitätssicherung, Betrieb

 

Einige Fehler werden trotz aller Sorgfalt erst beim konkreten Anwenden der Vorlagen im Projekt herausgefunden. Daher ist es empfehlenswert, Vorlagen auf einem Testsystem zu entwickeln, sie zu testen und erst nach erfolgreichen Tests produktiv zu verwenden. Dabei wird der Vorlagenentwickler beispielsweise durch die Funktion ContentTransport oder Einleitung (→Dokumentation „External Synchronization“) unterstützt.

   

Fehlersuche und -analyse im Vorlagen-Code

Erweiterter Fehler-Protokollierungs-Modus

Zumindest für die Entwicklungsphase von Vorlagen können mithilfe von

$CMS_SET(#global.debugMode,true)$

auf dem Ausgabe-Register erweiterte Informationen zu Fehlern („Stacktrace“) im Log ausgegeben werden. Dies betrifft in erster Linie das Generierungs-Log (fs-schedule.*.log), in der Vorschau (Kontextmenüeintrag „Fehler der Vorschau anzeigen“ auf Seiten und Seitenreferenzen) sind diese zusätzlichen Informationen immer vorhanden.

Siehe Seite vorschaubezogene #global-Aufrufe

Der erweiterte Fehler-Protokollierungs-Modus kann auch in der Vorlage, die für die Projekteinstellungen (unterhalb des Knotens „Globale Einstellungen“ im SiteArchitect) verwendet wird, gesetzt werden. Die De-/Aktivierung des erweiterten Fehler-Protokollierungs-Modus kann beispielsweise über folgendes Formular abgefragt/gesteuert werden und wirkt sich dann auf das komplette Projekt aus:

<CMS_INPUT_TOGGLE name="ps_debugMode" type="radio">
<LANGINFOS>
<LANGINFO lang="*" label="Debug mode"/>
<LANGINFO lang="DE" label="Erweiterte Protokollierung"/>
</LANGINFOS>
<OFF>
<LANGINFO lang="*" label="Disabled"/>
<LANGINFO lang="DE" label="Deaktiviert"/>
</OFF>
<ON>
<LANGINFO lang="*" label="Enabled"/>
<LANGINFO lang="DE" label="Aktiviert"/>
</ON>
</CMS_INPUT_TOGGLE>

Der Status (Variable ps_debugMode) kann dann in der/den gewünschten Vorlage/n abgefragt werden:

$CMS_SET(#global.debugMode, ps_debugMode)$

Bei vielen Fehlern kann sich eine Aktivierung des erweiterten Fehler-Protokollierungs-Modus nachteilig auf die Performance auswirken. Um ihn zu deaktivieren kann #global.debugMode auf „false“ gesetzt oder aus den Vorlagen entfernt werden.

Fehlermeldung provozieren / Marker setzen

Für eine gezielte Fehlersuche kann in Vorlagen temporär auch folgende Zeile eingefügt werden:

$CMS_VALUE(#global.logError("Ein schwerer Fehler ist aufgetreten!"))$

Die Stelle, an der diese Fehlermeldung eingefügt wurde, kann im Log schnell identifiziert werden (z. B. fs-schedule.*.log oder „Fehler der Vorschau anzeigen“). Anstelle des Textes (in Anführungszeichen) können auch Variablen ausgeben werden, z. B.

$CMS_VALUE(#global.logError("id: " + #global.id))$

(liefert die ID des aktuell gerenderten Knotens, z. B. Seite, Absatz usw., zurück).

Über die Methoden

  • logInfo
  • logDebug
  • logWarning

können weitere Log-Level eingestellt werden.

In Skripten wird folgende Syntax verwendet:

context.logError("Ein schwerer Fehler ist aufgetreten!");

Die Protokollierung von Skripten kann über das Menü „Extras“ / „Erweiterte Protokollierung“ im SiteArchitect aktiviert werden. Siehe dazu Kapitel Scripting.

Client-Logging

Auch das Client-Log kann relevante Log-Meldungen enthalten. Es kann über das Menü „Hilfe“ geöffnet werden. Siehe auch Hilfe (→Handbuch FirstSpirit SiteArchitect).

Logfile der Vorschauseite anzeigen

Um sich das Logfile einer Vorschauseite anzeigen zu lassen, muss lediglich die Vorschauseiten-URL manuell um den Parameter /showLog=1 ergänzt werden.

Siehe dazu auch Seite Performance-Analyse.

© 2005 - 2024 Crownpeak Technology GmbH | Alle Rechte vorbehalten. | FirstSpirit 2024.4 | Datenschutz