Migration von 1.16 auf 1.17

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

1. Umbenennung von Tag-Klassen

Durch die in Version 1.16 eingeführte neue Art der Tag-Definition wurde die Benennung und Wiederverwendbarkeit von Tag-Implementierungen deutlich verbessert. XML-Präfix und -Namen können nun frei gewählt und Tags in unterschiedlichen Hierarchien eingesetzt werden. Dies wurde in der Version 1.17 dazu genutzt, die Benennung der Tag-Klassen zu optimieren.

Bei der Aktualisierung auf die Version 1.17 müssen die im folgenden aufgeführten Klassen in Ihrer Applikation auf die neuen Namen umbenannt werden. Dabei wird im weiteren zwischen relevanten und internen Umbenennungen unterschieden. Eine Umbenennung ist für Sie jeweils nur relevant, wenn Sie basierend auf mit dem APF ausgelieferten Komponenten eigene Tags oder Komponenten erstellt haben. Andernfalls ist keine Änderung notwendig.

Das aktuelle Kapitel listet diejenigen Änderungen auf, die Sie beim Update auf die neue Version auf jeden Fall vornehmen müssen.

Eine wichtige Voraussetzung für die Migration auf Release 1.17 ist die Durchführung aller Schritte aus der Migrationsdokumentation für Release 1.16 (siehe Migration von 1.15 auf 1.16).

Der in Release 1.16 eingeführte Fallback-Mechanismus zur Nutzung der alten Form des <core:addtaglib/>-Tags wurde mit 1.17 entfernt. Der Tag erwartet nun zwingend die 4 Attribute namespace, class, prefix und name).

1.1. Tags im Namespace core

Folgende Änderungen im core-Namespace können Sie per Suchen&Ersetzen vornehmen:

Alter Klassen-Name Neuer Klassen-Name
core_taglib_addtaglib AddTaglibTag
core_taglib_importdesign ImportTemplateTag
core_taglib_appendnode AppendNodeTag
html_taglib_template TemplateTag
html_taglib_placeholder PlaceHolderTag
html_taglib_getstring LanguageLabelTag
html_taglib_getstring LanguageLabelTag

Neben den Umbenennungen wurde die Klasse core_taglib_appendnode in die Datei pagecontroller.php integriert. Sie muss daher nicht mehr extra per <core:addtaglib/> eingebunden werden.

1.2. Tags im Namespace tools

Im Bereich des tools-Namespace können Sie folgende Änderungen per Suchen&Ersetzen vornehmen:

Alter Klassen-Name Neuer Klassen-Name
a_taglib_getstring LinkLanguageLabelTag
html_taglib_a HtmlLinkTag
ui_mediastream / html_taglib_mediastream / template_taglib_mediastream MediaInclusionTag
media_taglib_getstring UmgtMediaInclusionLanguageLabelTag
doc_taglib_createobject CreateDocumentFromFileTag
fcon_taglib_importdesign FrontControllerImportTemplateTag
generic_taglib_importdesign GenericImportTemplateTag
html_taglib_fallbackimport FallbackImportTemplateTag
lang_taglib_importdesign LanguageDependentIncParamImportTemplateTag
lngtmpl_taglib_importdesign LanguageDependentImportTemplateTag
html_taglib_iterator HtmlIteratorTag
iterator_taglib_item HtmlIteratorItemTag
Anmerkung: MediaInclusionTag ist im Gegensatz zu ui_mediastream in Version 1.16 keine abstrakte Klasse und kann daher direkt als Tag verwenden werden.

Im Bereich der APF-Formular-Umterstützung wurden folgende Änderungen vorgenommen:

Alter Klassen-Name Neuer Klassen-Name
form_control AbstractFormControl
html_taglib_form HtmlFormTag
form_taglib_addfilter AddFormControlFilterTag
form_taglib_addvalidator AddFormControlValidatorTag
button_taglib_getstring ButtonLanguageLabelTag
form_taglib_button ButtonTag
form_taglib_checkbox CheckBoxTag
form_taglib_csrfhash CsrfProtectionHashTag
form_taglib_date DateSelectorTag
form_taglib_marker DynamicFormElementMarkerTag
form_taglib_file FileUploadTag
form_taglib_addtaglib FormAddTaglibTag
form_control_observer FormControlObserverBase
form_taglib_error FormErrorDisplayTag
form_getstring FormLanguageLabelTag
form_taglib_placeholder FormPlaceHolderTag
form_taglib_success FormSuccessDisplayTag
form_taglib_hidden HiddenFieldTag
form_taglib_imagebutton ImageButtonTag
form_taglib_multiselect MultiSelectBoxTag
form_taglib_password PasswordFieldTag
form_taglib_radio RadioButtonTag
form_taglib_reset ResetButtonTag
form_taglib_select SelectBoxTag
select_taglib_group SelectBoxGroupTag
select_taglib_option SelectBoxOptionTag
form_taglib_area TextAreaTag
form_taglib_text TextFieldTag
form_taglib_timecaptcha TimeCaptchaTag
form_taglib_time TimeSelectorTag
form_taglib_listener ValidationListenerTag
form_taglib_multifileupload MultiFileUploadTag
form_taglib_mediastream FormMediaInclusionTag
Anmerkung: FormLanguageLabelTag ist im Gegensatz ui_getstring in Version 1.16 keine abstrakte Klasse und kann daher direkt als Tag verwenden werden.
Für die Implementierung von eigenen Formular-Elementen nutzen Sie bitte ab Version 1.17 die Klasse AbstractFormControl (extends) oder implementieren das Interface FormControl um bestehende Tags für die Nutzung in Formularen vorzubereiten.

1.3. Tags im Namespace modules

Im Namespace modules wurden folgende Tag-Klassen umbenannt:

Alter Klassen-Name Neuer Klassen-Name
umgt_taglib_importdesign UmgtImportTemplateTag
umgt_taglib_logoutlink UmgtLogoutLinkTag
umgt_taglib_template UmgtTemplateTag
umgt_taglib_includecss UmgtIncludeCssTag
umgt_taglib_media UmgtMediaInclusionTag
social_taglib_bookmark SocialBookmarkBarTag
form_taglib_langlabel GuestbookFormLanguageLabelTag
gb_taglib_import GuestbookImportTemplateTag
form_taglib_captcha SimpleCaptchaTag

1.4. Tags im Namespace extensions

Im Bereich der APF-Extensions wurden ebenfalls Umbenennungen vorgenommen um die Möglichkeiten des in 1.16 eingeführte Tag-Definition zu nutzen:

Alter Klassen-Name Neuer Klassen-Name
news_taglib_media NewsMediaInclusionTag
form_taglib_addclientvalidator AddFormControlClientValidatorTag
form_taglib_clientlistener ClientValidationListenerTag
form_taglib_clienterror FormClientErrorDisplayTag
form_taglib_getclientvalidator GetClientFormValidationTag
html_taglib_addforwardmessage AddForwardMessageTag
html_taglib_getforwardmessages DisplayForwardMessagesTag
htmlheader_taglib_gethead HtmlHeaderGetHeadTag
htmlheader_taglib_getbodyjs HtmlHeaderGetBodyJsTag
htmlheader_taglib_addcss HtmlHeaderAddCssTag
htmlheader_taglib_addcsscontent HtmlHeaderAddCssContentTag
htmlheader_taglib_addcssimage HtmlHeaderAddCssImageTag
htmlheader_taglib_addjs HtmlHeaderAddJsTags
htmlheader_taglib_addjscontent HtmlHeaderAddJsContentTag
htmlheader_taglib_addmeta HtmlHeaderAddMetaTag
htmlheader_taglib_addpackage HtmlHeaderAddPackageTag
htmlheader_taglib_addstaticcss HtmlHeaderAddStaticCssTag
htmlheader_taglib_addstaticjs HtmlHeaderAddStaticJsTag
htmlheader_taglib_addtitle HtmlHeaderAddTitleTag
Allgemeine Form: SMS*Taglib SMS*Tag

2. Umbenennung von allgemeinen Klassen

Die Klasse base_controller wurde in BaseDocumentController umbenannt, damit Controller-Klassen in Zukunft auch nach dem UCC-Schema benannt werden.

2.1. Controller im Namespace extensions::apfelsms

Alter Klassen-Name Neuer Klassen-Name
SMSBreadcrumbNavTaglibController SMSBreadcrumbNavTagController
SMSNavTaglibController SMSNavTagController

3. Löschung von Klassen

Die Klasse iteratorBaseController wurde gelöscht und Funktionalität in BaseDocumentController integriert. Sofern Sie den Iterator-Tag (siehe Spezielle Tags) nutzen, muss die Abhängigkeit zu iteratorBaseController entfernt und durch BaseDocumentController ersetzt werden. Die Methode getIterator() wurde nicht geändert.

4. Umbenennung von Methoden und Klassen-Variablen

Neben der Umbenennung von Tag-Klassen wurden im Release 1.17 einige Benennungsaltlasten beseitigt. Bitte entnehmen Sie der folgenden Tabelle die in 1.17 geänderten Methoden und Klassen-Variablen:

4.1. Umbenannte Methoden

Alter Methoden-Name Neuer Methoden-Name
AbstractFormControl::__presetValue() AbstractFormControl::presetValue()
Document::__loadContentFromFile() Document::loadContentFromFile()
Document::__extractDocumentController() Document::extractDocumentController()
Document::__extractTagLibTags() Document::extractTagLibTags()
Bitte beachten Sie, dass __loadContentFromFile()/loadContentFromFile() und __extractTagLibTags()/extractTagLibTags() zu den zentralen Methoden des APF-Parsers zählen. Bei der Migration auf die neue Version muss daher insbesondere in eigenen Tags auf die korrekte bzw. neue Schreibweise geachtet werden.

4.2. Umbenannte Klassen-Variablen

Alter Variablen-Name Neuer Variablen-Name
APFObject::$__Attributes APFObject::$attributes
APFObject::$__Context APFObject::$context
APFObject::$__Language APFObject::$language
Document::$__ObjectID Document::$objectId
Document::$__ParentObject Document::$parentObject
Document::$__Content Document::$content
Document::$__TagLibs Document::$tagLibs
Document::$__Children Document::$children
BaseDocumentController::$__Document BaseDocumentController::$document
AbstractFormFilter::$__Control AbstractFormFilter::$control
AbstractFormFilter::$__Button AbstractFormFilter::$button
AbstractFormControl::$__ControlIsValid AbstractFormControl::$controlIsValid
AbstractFormControl::$__ControlIsSent AbstractFormControl::$controlIsSent
AbstractFormValidator::$__Control AbstractFormValidator::$control
AbstractFormValidator::$__Button AbstractFormValidator::$button
Bitte beachten Sie, dass die in den Klassen APFObject und Document enthaltenen Variablen zu den zentralen Klassen-Variablen zählen. Bei der Migration auf die neue Version muss daher insbesondere in eigenen Tags und Controllern auf die korrekte bzw. neue Schreibweise geachtet werden.

5. Konfiguration des Log-Verzeichnis

Der Logger wurde in Release 1.17 überarbeitet, damit zum einen der Name der Log-Datei für Framework-interne Meldungen konfiguriert als auch verschiedene LogWriter definiert werden können. Da die Neu-Implementierung/Erweiterung des Logger alle Funktionen des AdvancedLoggers beinhaltet wurde letzterer als veraltet gekennzeichnet.

Mit der Änderung der Persistenz-Mechnanismen des Loggers ändert sich auch die Konfiguration des Log-Verzeichnises. Dieses konnte bisher über einen Registry-Key konfiguriert werden. Dies erfolgt seit Release 1.17 nun über die Parametrisierung des entsprechenden LogWriters - dem FileLogWriter.

Die Definition des Log-Verzeichnisses muss damit in der Bootstrap-Datei von

PHP-Code
Registry::register('apf::core', 'LogDir', '/Pfad/zu/meinem/Log/Verzeichnis');

auf

PHP-Code
/* @var $logger Logger */ $logger = & Singleton::getInstance('Logger'); $target = Registry::retrieve('apf::core', 'InternalLogTarget'); $writer = $logger->getLogWriter($target); /* @var $writer FileLogWriter */ $writer->setLogDir('/Pfad/zu/meinem/Log/Verzeichnis'); $logger->addLogWriter($target, $writer);

geändert werden. Das das Framework intern selbst Fehlermeldungen über den Logger erzeugt wurde zudem das Standard-Ziel über den Registry-Key InternalLogTarget konfigurierbar gestaltet.

6. Konfiguration Logger für Framework-Komponenten

Mit der im vorangegangenen Kapitel beschriebenen Änderungen des Loggers ändert sich auch die Konfiguration der Log-Ziele für die Framework-Komponenten selbst. Dies betrifft in erster Linie die Datenbank-Connection-Implementierungen, die folgende Log-Ziele definieren:

  • sqlite für SQLiteHandler
  • pdo für PDOHandler
  • mysqlx für MySQLxHandler
  • mysqli für MySQLiHandler

Um die - je nach Anwendungsfall - notwendigen Log-Ziele zu konfigurieren, können Sie folgenden Code-Block nutzen:

PHP-Code
include('../apps/core/pagecontroller/pagecontroller.php'); import('core::frontcontroller', 'Frontcontroller'); ... // zusätzlich hinzufügen zur Bootstrap-Datei: import('core::logging', 'Logger'); $l = & Singleton::getInstance('Logger'); $dbWriter = clone $l->getLogWriter( Registry::retrieve('apf::core', 'InternalLogTarget') ); $l->addLogWriter('mysqlx', clone $dbWriter); // und/oder $l->addLogWriter('mysqli', clone $dbWriter); // und/oder $l->addLogWriter('pdo', clone $dbWriter); // und/oder $l->addLogWriter('sqlite', clone $dbWriter);

Bitte beachten Sie, dass die aufgeführten Zeilen in der Boostrap-Datei vor dem Starten des Frontcontroller hinzugefügt werden müssen.

7. Entfernen des direkten Zugriffs auf Document Attribute im Controller

In den Versionen bis einschließlich 1.16 wurden die Attribute einer Document-Instanz bei der Transformation in den zuständigen Document-Controller injiziert um den Zugriff zu erleichtern. Dieses nicht dokumentierte Feature wurde in Version 1.17 im Zuge der Einführung eines Interfaces für Document-Conroller (DocumentController) entfernt.

Stellen innerhalb von Document-Controller-Klassen, die mit

PHP-Code
$this->getAttribute(...)

oder

PHP-Code
$this->attributes[...]

auf interne Attribute eines Dokuments zugreifen, müssen auf

PHP-Code
$this->getDocument()->getAttribute(...)

umgestellt werden.

8. Umstellung des UMGT auf alphanummerische Proxy-IDs

Mit dem Release 1.17 ist es möglich, Stellvertreter-Objekte (=Referenzen auf Objekte in Ihrer konkreten Anwendung) im Benutzer-Verwaltungs-Modul zu definieren, die eine alphanummerische ID (AppObjectId) besitzen.

Hierzu wurde die GUI und die Objekt-Definition erweitert. Um das neue Feature auch für bestehende Anwendungen nutzen zu können, muss die Objekt-Definition in der Datei DEFAULT_umgt_objects.ini angepasst werden. Der Wert der Eigenschaft AppObjectId in der Objekt-Definition AppProxy ist nun wie folgt:

APF-Konfiguration
[AppProxy] AppObjectId = "VARCHAR(50)" ...

Damit die Änderungen auch im Datenmodell wirksam werden, führen Sie anschließend das GenericORMapperUpdate-Tool aus. Dies können Sie z.B. mit einer PHP-Datei mit folgendem Inhalt erledigen:

PHP-Code
require('./apps/core/pagecontroller/pagecontroller.php'); import('modules::genericormapper::data::tools', 'GenericORMapperManagementTool'); $update = new GenericORMapperManagementTool(); $update->setContext('{CONTEXT}'); $update->addMappingConfiguration('modules::usermanagement::data', 'umgt'); $update->addRelationConfiguration('modules::usermanagement::data', 'umgt'); $update->setConnectionName('Sandbox-UMGT'); $update->run();

9. Erstellen und Aktualisieren von GORM-basierten Datenbanken

Mit dem Release 1.17 wurden die beiden Tools GenericORMapperSetup und GenericORMapperUpdate zusammengefasst. Ab diesem Release können Sie mit dem GenericORMapperManagementTool sowohl Datenbanken anlegen als auch aktualisieren (siehe vorangegangenes Kapitel). Bitte beachten Sie, dass ab dem Release 1.17 GenericORMapperSetup und GenericORMapperUpdate nicht mehr zur Verfügung stehen.

Beim Wechsel auf die aktuelle APF-Version ist es daher notwendig, vorhandene Setup- und Update-Skripten anzupassen. Beispiele für die neue Vorgehensweise finden Sie im aktuellen apf-codepack-*-Release unter apps/modules/genericormapper/data/tools/. Die beiden Skripten setup.php und update.php stellen Ihnen ein Template zur Verfügung, das nur noch an den aktuellen Anwendungsfall angepasst werden muss.

Details zur Erstellung und Aktualisierung von Datenbanken entnehmen Sie bitte der Dokumentation unter Generischer O/R-Mapper.

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.