Migration von 1.15 auf 1.16

Auf dieser Seite werden werden alle notwendigen Code-Änderungen für den Umstieg von Version 1.15 auf 1.16 beschrieben.

1. Refactoring APF-Parser

1.1. Einleitung

Im Release 1.16 wurde die interne Repräsentation einer APF-Taglib und die zugehörigen Mechanismen des APF-Parser einer Überarbeitung unterzogen.

Ein Negativpunkt der bisherigen Implementierung war die Konvention der Tag-Klassen-Namen. Diese sind streng an Präfix und Klasse- bzw. Tag-Name gebunden. Die neue Implementierung ermöglicht dagegen

  • die Wiederverwendung einer identischen Tag-Klasse Klasse in tieferen Hierarchien unter anderem Tag-Präfix bzw. -Namen und
  • die Benennung der Tag-Klasse nach UCC-Schreibweise.

Nebenbei müssen weniger Klassen geladen werden und die Performance der Gesamtanwendung kann gesteigert werden. Details zur Diskussion können unter http://forum.adventure-php-framework.org/viewtopic.php?f=10&t=1131 eingesehen werden.

1.2. Migration

Bestehende Applikationen können nahezu ohne Anpassung weiterverwendet werden, da die Tag-Implementierung von <core:addtaglib /> die neue Schreibweise sowie die alte (Version <= 1.15) Form der Benutzung unterstützt. Die alte wird gemäß einer Konvention in die neue übersetzt.

Die Migration besteht damit aus zwei Teilen, von denen die erste zunächst optional ist.

1.2.1. Anpassung der <core:addtaglib /> Tags

In APF-Versionen <= 1.15 konnten (eigene) Tags dem APF-Parser mit Hilfe von

APF-Template
<core:addtaglib namespace="tools::form::taglib" prefix="html" class="form" />

bekannt gemacht werden. Ab der Version 1.16 bestimmt der Entwickler den Namen der Tag-Implementierung selbst. Daher erwartet der Tag nun im Attribut class den Namen der Tag-Implementierung und mit name lässt sich der Namen des Tags angeben.

Die Einbindung des <html:form />-Tags kann daher nun per

APF-Template
<core:addtaglib namespace="tools::form::taglib" class="html_taglib_form" prefix="html" name="form" />

erledigt werden.

In Version 1.16 werden beide Schreibweisen unterstützt um bestehende Anwendungen ohne Anpassung weiter verwenden zu können. In Folgeversionen wird dieser Fallback-Mechanismus wieder entfernt. Es ist daher ratsam, diesen Migrationsschritt trotzdem durchzuführen.

In Version 1.16 werden die bestehenden Tag-Klassen noch nicht oder nur teilweise an die UCC-Schreibweise angepasst.

Sofern die Klassen-Namen von bestehenden Anwendungen nicht geändert werden, lässt sich die Anpassung z.B. mit Hilfe von regulären Ausdrücken automatisieren:

Code
Suchmuster: <core:addtaglib\W*?namespace="([A-Za-z0-9:\-_]+)"\W*?prefix="([A-Za-z0-9:\-_]+)"\W*?class="([A-Za-z0-9:\-_]+)"\W*?/> Ersetzung: <core:addtaglib namespace="$1" class="$2_taglib_$3" prefix="$2" name="$3" />
1.2.2. Anpassung der Definition von bekannten TagLibs

Ein zentraler Bestandteil des APF-Parsers ist die Definition eines Tags. In Version 1.16 wurde die Signatur der Klasse TagLib wie folgt geändert:

PHP-Code
final class TagLib { public function __construct($namespace, $class, $prefix, $name) { } }

Die Klasse erwartet nun 4 statt 3 Parameter. Dabei muss zwingend der Name der Implementierung ($class) angegeben werden. Der neue Parameter $name trägt den Namen des Tags in APF-Templates. $namespace enthält weiter den Namespace, in dem sich die Tag-Implementierung (siehe $class) befindet und $prefix definiert den Tag-Präfix.

Sofern die Klassen-Namen von bestehenden Anwendungen nicht geändert werden, lässt sich die Anpassung z.B. mit Hilfe von regulären Ausdrücken automatisieren:

Code
Suchmuster: new TagLib\('([A-Za-z0-9:\-_]+)', '([A-Za-z0-9:\-_]+)', '([A-Za-z0-9:\-_]+)'\) Ersetzung: new TagLib('$1', '$2_taglib_$3', '$2', '$3')

2. Verändertes Verhalten von ServiceManager und DIServiceManager

2.1. Berücksichtigung von Context und Sprache

Der ServiceManager sowie der DIServiceManager berücksichtigen ab Version 1.16 Kontext und Sprache beim Beziehen von Objekten als Singleton oder SessionSingleton. Es gibt also eine Instanz pro Kontext-Sprach-Kombination, anstelle einer einzigen Instanz im aktuellen Scope.

Dieses Verhalten zeigt sich jedoch nur, solange keine eigene $instanceId vom Anwender vorgegeben wird.

2.2. Singletons ohne Berücksichtigung von Context und Sprache

Um Singletons, die im gesamten Scope ohne Berücksichtigung von Kontext und Sprache einmalig sind zu beziehen, empfiehlt sich, die $instanceId vorzugeben:

PHP-Code
// innerhalb einer Klasse, die von APFObject erbt... $namespace = 'my::namespace'; $serviceName = 'ExampleClass'; $instanceId = $namespace . '::' . $serviceName; $ECO = $this->getServiceObject($namespace, $serviceName, APFService::SERVICE_TYPE_SINGLETON, $instanceId);

Diese Vorgehensweise verlangt, dass die $instanceId an jeder Stelle, an der der Service bezogen wird, als 4ter Parameter übergeben wird (wie im Beispiel).

Vor Version 1.16. steht der Parameter $instanceId noch nicht zur Verfügung.
Es wird darauf hingewiesen, dass bei auf diese Weise erzeugten Services Probleme mit nicht zur aktuellen Umgebung passendem Kontext und Sprache auftreten könnten! Näheres ist in der Diskussion nachzulesen: http://forum.adventure-php-framework.org/viewtopic.php?f=5&t=1146.

2.3. Neues Verhalten des Caches beim DIServiceManager

Der DIServiceManager hat einen internen Cache, der einmal erzeugte und vollständig initalisierte Objekte zur Verfügung stellt. Ist ein Service bereits im Cache vorhanden, wird er aus diesem bedient.

In Version 1.16 berücksichtigt dieser Cache analog zum ServiceManager Kontext und Sprache. Zudem werden Services vom Typ NORMAL nicht mehr aus dem Cache bedient, um wirklich verschiedene Instanzen pro Aufruf ausliefern zu können.

Bei Services, die nicht durch die Klassen Singleton oder SessionSingleton verwaltet werden sollen, bei denen das Caching jedoch erwünscht oder nicht schädlich ist (es werden nicht mehrere Instanzen benötigt), sollte der neue ServiceType CACHED verwendet werden. Dieser entspricht dem alten Verhalten des Service-Typs NORMAL. Die Verwendung von CACHED wird aus Performance-Gründen ausdrücklich empfohlen!

3. Anpassung XmlParser

Im Rahmen der Feature-Diskussion Unterstützung " und ' als Attribut-Abgrenzung wurde die Performance des XmlParsers nochmals verbessert. Dieser filtert ab 1.16 keine Leerzeichen mehr in Attribut-Werten und gewinnt dadurch knapp 20% an Performance.

Bei der Umstellung auf die Version 1.16 wird es daher bei der Definition eines Platzhalters der Form

APF-Template
<html:placeholder name=" Foo" />

beim Zugriff per

PHP-Code
$this->setPlaceHolder('Foo', 'Bar');

zu einem Fehler (Platzhalter nicht gefunden) kommen. Bitte beachten Sie dies bei einem Update auf die Version 1.16 und korrigieren etwaige Stellen in Ihren Templates.

Die Attribut-Namen hingegen werden weiterhin von Leerzeichen befreit.

4. Anpassung Konfiguration StringEncryptor

In der Version 1.16 wurde ein Tippfehler in der {ENVIRONMENT}_encryption.ini korrigiert. Der Inhalt der Konfiguration muss beim Update auf die neue Version daher von

APF-Konfiguration
[Standard] PasswortSalt = ""

auf

APF-Konfiguration
[Standard] PasswordSalt = ""

angepasst werden. Die Datei findet sich im Ordner config/tools/string/{CONTEXT} ihres Projekts.

Kommentare

Möchten Sie den Artikel eine Anmerkung hinzufügen, oder haben Sie ergänzende Hinweise? Dann können Sie diese hier einfügen. Die bereits verfassten Anmerkungen und Kommentare finden Sie in der untenstehenden Liste.
Für diesen Artikel liegen aktuell keine Kommentare vor.