webag automat
web content management

webag automat 6.4 - was ist neu?

Versionsverwaltung

Die verschiedenen Versionen einer Seite können jetzt detaillierter verglichen werden. Bislang konnte man in der Anzeige der Veränderungen zwischen zwei Versionen lediglich erkennen, dass ein gesamter Absatz verändert worden war. Oftmals war das nicht ausreichend, denn viele Änderungen – wie z.B. das Zielfenster eines Hypelinks – kann man bei einer reinen Textdarstellung nicht erkennen.

Ab Automat 6.4 kann man beim Vergleich zweier Versionen mit dem Link „Exakter Zeilenvergleich“ auf HTML-Sourcecode-Ebene exakt sehen, was genau in diesem Absatz geändert worden ist.


Anmelde-Alias

Benutzer können sich selbst einen Anmelde-Alias vergeben, um sich mit diesem Alias anstelle des Benutzernamens anmelden zu können. Der Vorteil für die Benutzer ist, dass sie einen vertrauten Benutzernamen zusammen mit dem selbst gewählten Passwort verwenden können, denn in vielen Projekten werden die Benutzernamen nach Konventionen automatisch vergeben.

Dieses Feature kann in der globalen Einstellung mit dem Parameter LOGON_ALIAS_ALLOWED = 0 abgeschaltet werden, wenn die Verwendung von Aliasen unerwünscht ist.

Benutzerverwaltung

In der Benutzerverwaltung kann der Administrator den Alias für einen Benutzer ändern. Das geht auch, wenn der Parameter LOGON_ALIAS_ALLOWED die Benutzung von Aliasen abschaltet. Auf diese Weise können z.B. Aliase vorbereitet werden, die später freigeschaltet werden.

Der Automat merkt sich ab jetzt, an welchem Tag ein Benutzer zum letzten mal im System aktiv war und zeigt den Zeitpunkt in der Benutzerverwaltung an.

Eine Gesamtliste aller Benutzer mit den Angaben Benutzername, Voller Name, E-Mail-Adresse, letzte Aktivität, User-ID kann wahlweise als HTML- oder Excel-Tabelle abgerufen werden.

Design-Steuerung mit IF-Anweisungen

Mit <AUTOMAT_TRIGGER>-XML-Tags konnte man bislang im Sourcecode der HTML-Trigger Bereiche ein- oder ausblenden. Dazu wurden die Attribute SHOW/HIDE=“YES“ und eines der Attribute MLC_LANG_CODE, CATEGORY_ID oder CLASSIFICATION_ID angegeben. In Schablonen konnten die AUTOMAT_TRIGGER-Tags nicht verwendet werden. Statt dessen wurden für leicht unterschiedliche Seitentypen jeweils eigene Schablonen definiert.

Ab diesem Release können AUTOMAT_TRIGGER-Tags auch in Schablonen genutzt werden. Dadurch wird die Anzahl der benötigten Schablonen reduziert und die Programmierung der Designsteuerung vereinfacht.

Die Funktionalität der AUTOMAT_TRIGGER-Tags wurde erweitert durch das Attribut „IF“. Mit diesem Attribut können boolsche PL/SQL-Ausdrücke verwendet werden, die TRUE oder FALSE ergeben. Beispiel:
 

<AUTOMAT_TRIGGER SHOW="YES" IF="'$MLC_LANG_CODE'='de'">
   (…)
</AUTOMAT_TRIGGER>


Erklärung: Die mit dem AUTOMAT_TRIGGER-Tag umschlossene HTML-Passage wird nur dann ausgegeben (SHOW=“YES“), wenn die angegebene IF-Anweisung TRUE ergibt. Vor der Übergabe der IF-Anweisung an die Oracle PL/SQL-Engine werden die $-Variablen ersetzt, so dass sich z.B. bei einer englischen Seite die Zeichenkette 'en' = 'de' für die IF-Anweisung ergibt, also FALSE. Als Ergebnis wird diese Passage nur auf einer deutschen Seite zu sehen sein.

Ein großer Vorteil der IF-Anweisung in PL/SQL-Syntax ist die Flexibilität für Programmierer. Man kann seine eigenen Funktionen schreiben, die TRUE oder FALSE zurückgeben und diese Funktionen im Web-Design verwenden. Beispiel:
 

<AUTOMAT_TRIGGER SHOW="YES"
      IF="is_important_page(i_text_id => '$TEXT_ID')">
   (…)
</AUTOMAT_TRIGGER>

Hier entscheidet die eigene PL/SQL-Function is_important_page, ob die Seite so wichtig ist, dass die entsprechende Passage im HTML-Code angezeigt werden kann. Als „ELSE“-Zweig (also in diesem Beispiel für die Ausgabe des HTML-Codes für nicht so wichtige Seiten) kann man einfach das PL/SQL-Schlüsselwort „NOT“ verwenden. Beispiel:

 
<AUTOMAT_TRIGGER SHOW="YES"
  IF="NOT (is_important_page(i_text_id => '$TEXT_ID'))">
    (…)
</AUTOMAT_TRIGGER>


Einschränkung: AUTOM
AT_TRIGGER-Tags dürfen keine Schablonen-Autorenfelder (also AUTOMAT_STENCIL-Tags) umschließen, sondern sollen ausschließlich das Webdesign dynamisch erzeugen.

Event-Trigger

Mit Event-Triggern können Programmierer in Zukunft die Funktionalität des Automat nach eigenen Wünschen erweitern. Für verschiedene Ereignisse können Event-Trigger geschrieben werden, die vor oder nach dem Ereignis aufgerufen werden. In dieser Versionen startet die neue Event-Trigger-Funktion mit drei Trigger-Typen:
  • BEFORE_SESSION_START - feuert, bevor ein Benutzer zum ersten mal an diesem Tag aktiv ist, auch wenn er sich aufgrund einer dauerhaften Cookie-Anmeldung nicht neu anmelden musste. Mit diesem Event-Trigger kann man z.B. eigene Tracking-Funktionen über die Aktivität der Benutzer schreiben.
  • BEFORE_PUBLISH_PAGE – feuert, bevor eine neue Version einer Seite veröffentlicht wird. Nützlich, um z.B. eigene Prüfungen zu schreiben, die u.U. die Veröffentlichung durch eine Exception verhindern sollen.
  • AFTER_PUBLISH_PAGE – feuert direkt nach der Veröffentlichung einer Seite. Mit diesem Trigger kann man z.B. eigene Nachbearbeitungen der Inhalte formulieren.
Event-Trigger werden im linken Navigationsbaum unter „System / Allgemein / Event-Trigger“ verwaltet. Ein Event-Trigger wird definiert, indem man einen Namen und den PL/SQL-Code eingibt. Es ist sinnvoll, in das mehrzeilige Eingabefeld des PL/SQL-Codes einen kurzen Package.Procedure-Aufruf zu schreiben und den Rest der Funktionalität in seinem eigenen Package zu programmieren.

Im PL/SQL-Code des Event-Triggers dürfen die bekannten $-Variablen wie $WEB_ID oder $TEXT_ID verwendet werden. Z.B. kann man mit einer einleitenden IF-Abfrage zur definieren, dass dieser Trigger nur bei der Veröffentlichung einer Seite aus einem bestimmten Web feuern soll.

Man kann beliebig viele Trigger für jeden Trigger-Typ anlegen. Sie feuern in der Reihenfolge der vergebenen Trigger-Namen. Durch die geschickte Vergabe der Namen können Sie also die Ausführreihenfolge selbst steuern.


Systemmeldungen

Die Ausgabe der Systemmeldungen kann der Administrator ab jetzt durch die Eingabe vorn Suchbegriffen filtern.

Die neue Meldung „Session started by user ...“ protokolliert ab jetzt, dass ein autorisierter Benutzer an diesem Tag zu ersten mal im System aktiv war. Bislang konnte die Aktivität eines Benutzers nicht mehr nachvollzogen werden, wenn er sich zuvor mit einem dauerhaft gespeicherten Cookie angemeldet hatte und ab dann keine Anmeldung mehr erforderlich war.


Zugriffsstatistiken


Die Anzahl der Requests je Seite kann ab jetzt nach Monaten und Jahren gruppiert abgefragt werden. Bislang wurde die Anzahl Aufrufe pro Seite nur über den gesamten Zeitraum der Erfassung angeboten.

Die Erkennung von Suchmaschinen-Spidern wurde verbessert, so dass ab jetzt weniger Zugriffe protokolliert werden, bei den kein echter Benutzer, sondern eine Suchmaschine aktiv war.


Weitere Verbesserungen

  • Nach der Passworteingabe kann man die “Erfolgreich angemeldet“-Zwischenseite mit der ENTER-Taste quittieren, weil der Eingabefokus auf dem "Weiter"-Button liegt. Bislang musste man dazu nach der Passworteingabe zur Maus greifen.
  • Autoren können nun mit sehr viel weniger Mausklicks ernannt werden. Die Autorenrechte Seiten zur Veröffentlichung freigeben, Seiten und Unterordner einfügen, Seiten und Unterordner löschen und Leserechte vergeben sind vorausgewählt und müssen bei neuen Autoren nicht mehr einzeln aktiviert werden. Außerdem ist die Option Rechte gelten auch für Unterordner initial aktiviert.
  • Performance: Das Versionierungssystem wurde verbessert. Die Berechnung der Referenzen zwischen Automatseiten wurde beschleunigt, so dass in Systemen mit mehreren tausend Dokumenten keine Wartezeiten beim Speichern und Veröffentlichen mehr auftreten.
  • Design-Administration: Die Eingabefelder für die Eingabe des HTML-Codes in HTML-Triggern und Schablonen passen ihre Breite automatisch an die Größe des Browserfensters an.



Behobene Fehler

  • Im Autorensystem zeigt die Übersichtsseite keine gelöschten Seiten mehr an, die sich eigentlich im Papierkorb befinden.
  • Benutzer, die offene Online-Formulare haben, können gelöscht werden. Die Formulareingaben werden zusammen mit dem Benutzer entfernt.
  • Benutzerverwaltung: Die Eingabe von falschen Werten für die Parameter ADMIN, ADMIN_USER oder ADMIN_DESIGN führt nicht mehr dazu, dass der entsprechende Benutzer nicht mehr bearbeitet werden kann.
  • In manchen Konstellationen konnte es passieren, dass ein Webmaster in seinem Web keine Autoren ernennen konnte, sondern nur der zentrale Administrator.