Migration und Änderungen in 2.0

Im Entwickler-Forum können Implementierungsdetails sowie Alternativen der Umsetzung diskutiert werden. // Here, developers can discuss implementation details of features of their projects.
Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Migration und Änderungen in 2.0

Beitrag von jwlighting » 20.04.2013, 18:11:14

Hallo beisammen ;)

Mit den Namespaces sind für die Migration zu Version 2.0 ja zahlreiche Änderungen verbunden.
Ich möchte hiermit einen Sammelthread für Probleme und Fragen rund um die Migration und die Änderungen in 2.0 bereitstellen.

Für mich wäre zum Beispiel interessant, wie ich die Migrationsskripte anwenden muss. Dafür wäre sicherlich ein Abschnitt im Wiki-Artikel zur Migration eine tolle Sache.
Da ich für das Testen des APFelSMS (und andere sicherlich auch für ihre Komponenten) meine Testanwendung migrieren möchte, bräuchte ich die Migrationsskripte schon jetzt.

LG :)
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Migration und Änderungen in 2.0

Beitrag von dr.e. » 20.04.2013, 23:11:10

Hallo Jan,

ich habe unter http://wiki.adventure-php-framework.org ... 17_auf_2.0 angefangen einige Punkte zu dokumentieren. Allerdings ist die Seite bisher nur mit rudimentären Inhalten gefüllt. Einen eigenen Thread hierzu eröffnen halte ich für eine gute Idee und nehme diese mit deinen Fragen gleich auf:
Für mich wäre zum Beispiel interessant, wie ich die Migrationsskripte anwenden muss.
1) Anwendung der Migrationsskripte:
Unter https://sourceforge.net/p/adventurephpf ... /migration bzw. im Snapshot-Release im Ordner migration sind verschiedene Skripte zur Migration eine bestehenden Code-Basis enthalten. Die Skripten gehen davon aus, dass die Schritte zur Migration auf die Version 1.17 bereits ausgeführt sind und die Anwendung vollständig auf Version 1.17 basiert.

Sind alle Vorbedingungen erfüllt, kann die Migration auf die Version 2.0 (teil-)automatisiert vorgenommen werden. Es gilt jedoch zu beachten, dass keine 100%-ige Migration gewährleistet werden kann, da sich die use-Statements nicht komplett automatisiert generieren lassen.

Bitte vor der Ausführung der Migrationsskripte ein komplettes Backup des Projektes anfertigen!

Um die Migration vorzunehmen, einfach eine Shell öffnen und die folgenden Befehle ausführen:

Code: Alles auswählen

# Wechselt in den apps-Ordner der Applikation
$ cd /path/to/my/application/apps

# Führt die Namespace-Deklaration ein und schreibt import() auf use um
$ /path/to/php migration/migrate_import_calls.php

# Migriert die vorhandene Klassen-Dokumentation
$ /path/to/php migration/migrate_code_documentation.php

# Migriert Tag-Deklaration
$ /path/to/php migration/migrate_document_controller_statements.php
$ /path/to/php migration/migrate_taglib_declaration.php
$ /path/to/php migration/migrate_taglib_statements.php

# Migriert ServiceManager-/DIServiceManager-Nutzung
$ /path/to/php migration/migrate_di_configuration.php
$ /path/to/php migration/migrate_sm_calls.php

# Migriert Registry-Nutzung
$ /path/to/php migration/migrate_core_registry_calls.php

# Migriert Konfiguration
$ /path/to/php migration/migrate_config_calls.php
$ /path/to/php migration/migrate_db_config.php
$ /path/to/php migration/migrate_cache_configuration.php
$ /path/to/php migration/migrate_fc_configuration.php
$ /path/to/php migration/migrate_gorm_configuration.php
$ /path/to/php migration/migrate_pager_configuration.php
$ /path/to/php migration/migrate_umgt_configuration.php
Anschließend ist der Großteil der Applikation auf die Syntax von 2.0 umgeschrieben. Nun muss der Quelltext noch nach fehlenden use-Statements durchsucht werden. Hier hilft die IDE oder das Testen der Anwendung, da sich PHP mit einem
Fatal error:
beschwert, wenn Klassen nicht gefunden werden.

Ich hoffe das hilft dir schon mal weiter. Das APFelSMS habe ich im 2.0-Branch schon weitestgehend migriert, allerdings noch nicht getestet.
Viele Grüße,
Christian

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Migration und Änderungen in 2.0

Beitrag von dr.e. » 25.04.2013, 23:42:08

Hi Jan,

hast du die Skripten schon getestet? Falls ja, wie sind deine ersten Erfahrungen?
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: Migration und Änderungen in 2.0

Beitrag von jwlighting » 26.04.2013, 15:24:43

Hallo Christian,

danke der Nachfrage ;)

Nein, ich bin bisher nicht dazu gekommen.
Außerdem plane ich ein kleines Bash-Skript, was all das in einem Abwasch erledigt. Düfte ja nicht so schwer sein. Mit ein paar Parametern zur Konfiguration.
Den Windows-Part kann ich leider nicht übernehmen.

Um noch mal auf dieses Thema zurück zu kommen:
viewtopic.php?f=7&t=1406

Fehler können noch entstehen, wenn bei der Migration use-Statements erzeugt werden, die Klassen aus dem selben Namespace einbinden, richtig?
D.h. hier könnte die letzte Zeile einfach manuell gelöscht werden:

Code: Alles auswählen

<?php
namespace APF|extensions|apfelsms|biz|sites;

use APF|core|pagecontroller|APFObject;
use APF|extensions|apfelsms|biz|SMSManager;
use APF|extensions|apfelsms|biz|SMSWrongParameterException;
use APF|extensions|apfelsms|biz|pages|SMSPage;
use APF|extensions|apfelsms|biz|sites|SMSSite;
 
Laut PhpStrom ist das aber kein Fehler!

Sonst noch etwas, was ich manuell fixen muss?

LG :)
Jan
Zuletzt geändert von jwlighting am 26.04.2013, 15:26:56, insgesamt 1-mal geändert.
Grund: Ich hasse Backslashes... \-)

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Migration und Änderungen in 2.0

Beitrag von dr.e. » 26.04.2013, 17:34:28

Hallo Jan,
Außerdem plane ich ein kleines Bash-Skript, was all das in einem Abwasch erledigt. Düfte ja nicht so schwer sein. Mit ein paar Parametern zur Konfiguration.
Den Windows-Part kann ich leider nicht übernehmen.
Fein. Ich hatte mir ebenso überlegt noch ein Wrapper-Skript zu schreiben das alle zusammenfasst. Aktuell sind die Skripten noch vereinzelt um besser testen zu können.
Fehler können noch entstehen, wenn bei der Migration use-Statements erzeugt werden, die Klassen aus dem selben Namespace einbinden, richtig?
D.h. hier könnte die letzte Zeile einfach manuell gelöscht werden:
An sich ja. Magst du hierzu noch ein zusätzliches Skript schreiben?
Sonst noch etwas, was ich manuell fixen muss?
Es fehlen sicher noch ein paar use-Statements, die die Skripten nicht erfassen. Das lässt sich aber i.d.R. recht schnell manuell erledigen.
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: Migration und Änderungen in 2.0

Beitrag von jwlighting » 26.04.2013, 21:57:40

Auweia... :cry:

Ich hab die Migrationsskripte jetzt mal laufen lassen...

Nicht funktioniert hat:
  • Das Umschreiben von <*:addtaglib />-Tags
  • Die Migration von Document-Controllern. Es fehlt ein use APF\core\pagecontroller\BaseDocumentController. Vielleicht lässt sich das ja noch zu den Migrationsskripten hinzufügen.
  • Die Migration von @var-PhpDoc: Zu dem Klassennamen muss der voll qualifizierte, absolute (führender Backslash) Namespace mit angegeben werden.
  • Bezug des GORM: $orm = $ormf->getGenericORMapper('modules::gorm', 'news', 'local--apf-devel');
Ansonsten, und das soll auch erwähnt werden: Top! Das ist schon einmal eine große Erleichterung beim Migrieren. Danke!

Dann habe ich bei einigen Dateien in tools\string fehlende use-Statements ergänzt, u.a für die Registry. Checkin folgt noch.

Außerdem haben wir ein Problem mit Document::getChildNodes(), festgestellt jetzt beim ersetzen von Placeholdern:

Code: Alles auswählen

   public function &getChildNodes($attributeName, $value, $tagLibClass) {
      $children = & $this->getChildren();

      if (count($children) > 0) {
         $result = array();
         foreach ($children as $objectId => $DUMMY) {
            if ($children[$objectId] instanceof $tagLibClass) {
               if ($children[$objectId]->getAttribute($attributeName) == $value) {
                  $result[] = & $children[$objectId];
               }
            }
         }
         if (count($result) == 0) {
            throw new InvalidArgumentException('[' . get_class($this) . '::getChildNodes()] No child nodes with type "'
                  . $tagLibClass . '" and attribute selector ' . $attributeName . '="' . $value . '" composed in current '
                  . 'document!', E_USER_ERROR);
         } else {
            return $result;
         }
      }

      throw new InvalidArgumentException('[' . get_class($this) . '::getChildNodes()] Current node has no children!', E_USER_ERROR);
   }
 
$tagLibClass wird bisher nur der Klassenname übergeben, für instanceof ist aber der voll qualifizierte Pfad notwendig.

EDIT: Das betraf nur noch die StringPlaceHolder. Ist angepasst und eingecheckt.

Soweit (erstmal) von mir. Wir kommen ja in kleinen Schritten vorwärts ;)

LG :)
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Migration und Änderungen in 2.0

Beitrag von dr.e. » 28.04.2013, 12:22:20

Hi Jan,

danke für deinen Tests, das hilft mir schon mal weiter.
Das Umschreiben von <*:addtaglib />-Tags
Was genau hat hier nicht funktioniert? In migrate_taglib_statements.php gibt es dazu einen expliziten Teil, der sich um das Umschreiben kümmert.
Die Migration von Document-Controllern. Es fehlt ein use APF\core\pagecontroller\BaseDocumentController. Vielleicht lässt sich das ja noch zu den Migrationsskripten hinzufügen.
Das ist korrekt. Das fällt unter die 10%, die noch manuell zu tun sind. Eine Möglichkeit wäre natürlich ein use hinzuzufügen, sofern noch keines existiert. Ähnlich geht ja auch der Code in migrate_import_calls.php vor.
Die Migration von @var-PhpDoc: Zu dem Klassennamen muss der voll qualifizierte, absolute (führender Backslash) Namespace mit angegeben werden.
Da bin ich etwas anderer Meinung. Sofern ein use existiert, ist das nicht nötig, es sei denn es existieren Klassen mit dem selben Namen.
Bezug des GORM: $orm = $ormf->getGenericORMapper('modules::gorm', 'news', 'local--apf-devel');
Was genau hat hier nicht funktioniert?
Ansonsten, und das soll auch erwähnt werden: Top! Das ist schon einmal eine große Erleichterung beim Migrieren. Danke!
Freut mich! :)
Dann habe ich bei einigen Dateien in tools\string fehlende use-Statements ergänzt, u.a für die Registry. Checkin folgt noch.
Sehr schön, danke!
EDIT: Das betraf nur noch die StringPlaceHolder. Ist angepasst und eingecheckt.
Korrekt, hier muss der aufrufende Code entsprechend angepasst werden. Einige Bereiche wie z.B. <form:addfilter /> schreibe ich das in den Skripten schon um. Vielleicht kannst du mal die betroffenen Stellen analysieren und überlegen, ob ein automatisiertes Umschreiben möglich ist.
Soweit (erstmal) von mir. Wir kommen ja in kleinen Schritten vorwärts ;)
Das denke ich auch. Ich habe die Skripten bei mir inzwischen an der Sandbox, der APF-Doku-Seite und an zwei weiteren Projekten getestet. Je mehr Projekte wir haben, desto besser/einfacher wird die Migration am Ende.
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: Migration und Änderungen in 2.0

Beitrag von jwlighting » 28.04.2013, 13:47:42

Was genau hat hier nicht funktioniert? In migrate_taglib_statements.php gibt es dazu einen expliziten Teil, der sich um das Umschreiben kümmert.
Ich habe in allen Seitentemplates mit den Inhalten der Website (sites\content\template) ein AddTaglibTag, welches das SMSAddAllTag einbindet. Hier wurde nichts umgeschrieben, das AddTaglibTag blieb also unverändert:

Code: Alles auswählen

<core:addtaglib namespace="extensions::apfelsms::pres::taglibs" prefix="sms" name="addAll" class="SMSAddAllTag"/><sms:addAll/>
<h2><sms:pageTitle /></h2>
Eine Möglichkeit wäre natürlich ein use hinzuzufügen, sofern noch keines existiert. Ähnlich geht ja auch der Code in migrate_import_calls.php vor.
Wenn ich das richtig verstehe, ist das mit verhältnismäßig wenig Aufwand zu machen, richtig? Dann lass es uns tun. ;)
Da bin ich etwas anderer Meinung. Sofern ein use existiert, ist das nicht nötig, es sei denn es existieren Klassen mit dem selben Namen.
Ich meine Fälle, in denen kein use existiert, z.B. hier:

Code: Alles auswählen

/** @var $orm GenericORRelationMapper */
$orm = $ormf->getGenericORMapper('APF\modules\gorm', 'news', 'local--apf-devel');
 
Im PhpDoc wird GenericORRelationMapper nicht erkannt. So funktioniert es, und die IDE erkennt $orm korrekt. Diesen Fehler habe ich schon an zahlreichen Stellen gesehen.

Code: Alles auswählen

/** @var $orm \APF\modules\genericormapper\data\GenericORRelationMapper */
$orm = $ormf->getGenericORMapper('APF\modules\gorm', 'news', 'local--apf-devel');
 
Vielleicht kannst du mal die betroffenen Stellen analysieren und überlegen, ob ein automatisiertes Umschreiben möglich ist.
Das betraf jetzt nur noch Document::setStringPlaceholder(). Die anderen Methoden sind schon migriert. Weitere Stellen habe ich bisher noch nicht entdeckt.
Ich checks jetzt ein.
Je mehr Projekte wir haben, desto besser/einfacher wird die Migration am Ende.
Ich schau mal, was meine Zeit so hergibt ;) Ich fürchte mich schon vor der Migration der THW-Jugend Website - die läuft noch mit 1.13 :o

LG :)
Jan
Ist nicht funktionsrelevant, nimmt einem aber die Unterstützung der IDE.

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Migration und Änderungen in 2.0

Beitrag von dr.e. » 28.04.2013, 19:54:14

Hallo Jan,
Ich habe in allen Seitentemplates mit den Inhalten der Website (sites\content\template) ein AddTaglibTag, welches das SMSAddAllTag einbindet. Hier wurde nichts umgeschrieben, das AddTaglibTag blieb also unverändert:
Klar! :) Die Reihenfolge der Attribute wird im RegExp anders erwartet. Dies sollten wir in den Migrationshinweisen vermerken, denn für alle diese Fälle eigene RegExps zu schreiben wird aufwändig. Was meinst du?
Wenn ich das richtig verstehe, ist das mit verhältnismäßig wenig Aufwand zu machen, richtig? Dann lass es uns tun. ;)
OK. Du oder ich?
Im PhpDoc wird GenericORRelationMapper nicht erkannt. So funktioniert es, und die IDE erkennt $orm korrekt. Diesen Fehler habe ich schon an zahlreichen Stellen gesehen.
OK, dann waren es schon die Fälle, die ich meinte. Hier braucht es einfach ein use. Btw: Die GenericORRelationMapperFactory ist deprecated und sollte durch den DIServiceManager ersetzt werden.
Das betraf jetzt nur noch Document::setStringPlaceholder(). Die anderen Methoden sind schon migriert. Weitere Stellen habe ich bisher noch nicht entdeckt.
Ich checks jetzt ein.
Perfekt!
Ich schau mal, was meine Zeit so hergibt ;) Ich fürchte mich schon vor der Migration der THW-Jugend Website - die läuft noch mit 1.13 :o
Das wird vermutlich nicht 100%ig funktonieren, da 1.13 im 1.Xer-Zweig schon 4 Versionen alt ist. :roll: :D
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: Migration und Änderungen in 2.0

Beitrag von jwlighting » 28.04.2013, 20:28:33

Die Reihenfolge der Attribute wird im RegExp anders erwartet. Dies sollten wir in den Migrationshinweisen vermerken, denn für alle diese Fälle eigene RegExps zu schreiben wird aufwändig. Was meinst du?
Ich glaube, wir sparen uns und allen Anwendern am meisten Arbeit, wenn wir alle Fälle abdecken? Im Regex müssen ja nur zwei Parameter berücksichtigt werden, richtig?
(Die anderen können dazwischen, davor und dahinter stehen und müssen ja nicht gematched werden). Also lässt sich das mit zwei Regex abdecken, einmal namespace vor class und einmal class vor namespace.
Korrigiere mich, wenn ich falsch liege.
OK. Du oder ich?
Du :? Ich hab noch ein Übungswochenende für's THW zu organisieren und brüte darüber, wie ich eine Vererbung für's APFelSMS am Besten = Performantesten realisieren kann. Außerdem steckst du im Thema (und vor allem den Regex) schon drin. Ich verspreche dir aber, das Bash-Skript noch vor Himmelfahrt abzuliefern, OK? Soll ich das einfach in den migrate-Ordner ins SVN aufnehmen?
Hier braucht es einfach ein use
Klar, du kannst das sicherlich mit einem use erledigen. Allerdings lässt du dann PHP rechnen. Den Pfad einfach im PhpDoc anzugeben dürfte performanter sein. Sicher bin ich mir allerdings nicht.
Vorteil ist wiederum, dass einem die use-Statements einen Überblick über die verwendeten Komponenten geben.
Auf jeden Fall sollten wir uns auf einen gemeinsamen Nenner einigen ;)
Die GenericORRelationMapperFactory ist deprecated und sollte durch den DIServiceManager ersetzt werden.
:D Ich schau's mir für's nächste produktive System mal an, OK? ;)
Das wird vermutlich nicht 100%ig funktonieren, da 1.13 im 1.Xer-Zweig schon 4 Versionen alt ist.
Also doch zahlreiche Module neu schreiben? Dann gibt es vielleicht bald auch ein Gallery-Modul dass qualitativ ausreichend ist, um ins APF integriert zu werden ;)
Und die Umstellung auf die Verwendung des APFelSMS steht eh an :P

LG :)
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Migration und Änderungen in 2.0

Beitrag von dr.e. » 28.04.2013, 21:32:12

Hi Jan,
Ich glaube, wir sparen uns und allen Anwendern am meisten Arbeit, wenn wir alle Fälle abdecken?
Ja, sehe ich auch so.
Im Regex müssen ja nur zwei Parameter berücksichtigt werden, richtig? (Die anderen können dazwischen, davor und dahinter stehen und müssen ja nicht gematched werden). Also lässt sich das mit zwei Regex abdecken, einmal namespace vor class und einmal class vor namespace.
Korrigiere mich, wenn ich falsch liege.
Jein. Es müssen 3 Parameter zu 2en umgeschrieben werden. Dies lässt sich mit ReExps so nicht einfach abbilden. Sofern die Parameter in wild gewürfelter Reihenfolge vorkommen können, müssten wir mit dem XmlParser arbeiten und die Inhalte so dynamisch ersetzen.
Du :? Ich hab noch ein Übungswochenende für's THW zu organisieren und brüte darüber, wie ich eine Vererbung für's APFelSMS am Besten = Performantesten realisieren kann. Außerdem steckst du im Thema (und vor allem den Regex) schon drin. Ich verspreche dir aber, das Bash-Skript noch vor Himmelfahrt abzuliefern, OK? Soll ich das einfach in den migrate-Ordner ins SVN aufnehmen?
OK, mache ich. Das Bash-Skript kannst du einfach ins SVN einchecken.
Klar, du kannst das sicherlich mit einem use erledigen. Allerdings lässt du dann PHP rechnen. Den Pfad einfach im PhpDoc anzugeben dürfte performanter sein. Sicher bin ich mir allerdings nicht.
Vorteil ist wiederum, dass einem die use-Statements einen Überblick über die verwendeten Komponenten geben.
Auf jeden Fall sollten wir uns auf einen gemeinsamen Nenner einigen ;)
Performance-technisch ist das kein Problem. Der ClassLoader wird nur dann aufgerufen, wenn die Klasse noch nicht geladen wurde - lazy sozusagen. Insofern kostet ein use effektiv keine Performance ermöglicht dagegen statischen Code-Analyse-Werkzeugen ihre Arbeit zu tun. Insofern plädiere ich für use. :)
:D Ich schau's mir für's nächste produktive System mal an, OK? ;)
ACK!
Also doch zahlreiche Module neu schreiben? Dann gibt es vielleicht bald auch ein Gallery-Modul dass qualitativ ausreichend ist, um ins APF integriert zu werden ;)
Neu nicht, ich denke einfach, dass du zuvor einfach die Migrationsschritte bis 1.17 ausführen solltest.
Und die Umstellung auf die Verwendung des APFelSMS steht eh an :P
Na dann ist jetzt die ultimative Gelegenheit zu aktualisieren. ;)
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: Migration und Änderungen in 2.0

Beitrag von jwlighting » 01.05.2013, 14:40:17

Kurze Info: Ich habe das Migrations-bash-Script und eine neue README-Datei ins SVN hochgeladen.
Das Script lässt sich noch verfeinern. Schau mal bitte in die README rein, mein Englisch ist bekanntermaßen nicht das Beste ;)

Schönen 1. Mai!

LG :)
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Migration und Änderungen in 2.0

Beitrag von dr.e. » 01.05.2013, 23:12:21

Thx, schau's mir an.
Schönen 1. Mai!
Dito! :)
Viele Grüße,
Christian

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: Migration und Änderungen in 2.0

Beitrag von Megger » 13.05.2013, 17:34:57

Was mich ein bisschen bei der Migration stört ist, dass man bei einer Exception, wenn eine Klasse nicht gefunden wurde, eigentlich nur noch "ClassLoader" im StackTrace hat! Das macht das debugging doch irgendwie ein bisschen schwerer :lol:

Ich weiß zwar aktuell, woran es liegt, dass er BaseDocumentController nicht findet und ich das entsprechende use Statement in allen Dateien einbauen muss, aber bei anderen nicht gefundenen Klassen kann ich mir durchaus vorstellen, dass es schwieriger ist, dort einen Fehler zu finden!

Edit:
Hat das ganze schon mal jemand mit der HTMLHeader Erweiterung probiert?
z.B. in HtmlHeaderManager

Code: Alles auswählen

$this->getNodesByType('CssNode');
 
Funktioniert so bei mir nicht, da ja mit instanceOf geprüft wird um welche Art von Node es sich handelt

Code: Alles auswählen

$this->getNodesByType('APF\extensions\htmlheader\biz\CssNode');
 
Funktioniert wie es soll! Die entsprechenden Dateien werden aber nicht korrekt geladen, da kommt bei mir ein ERR_CONTENT_DECODING_FAILED

Edit2:
Ich glaube ich habe das Problem gefunden
Ich vermute durch die Migrationsskripte wurde bei htmlheader::addcss der Namespace entsprechend ersetzt! Allerdings darf kein APF\ am Anfang des Namespaces stehen, da die HTMLHeader Erweiterung den Namespace direkt in einen Pfad unterhalb des apps Ordners umsetzt und wenn da kein APF Ordner ist, dann wird auch nichts gefunden

Edit3:
Bei mir wurde auch vieles nicht durch die Migrationsskripte abgearbeitet! Ich vermute es liegt an der Funktion filterApfDirectories? Weil meine Dateien meistens unter megger/modules megger/tools usw. liegen! Kann das sein?
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: Migration und Änderungen in 2.0

Beitrag von jwlighting » 21.07.2013, 13:56:58

Nur kurz zur Info:
Habe mit Rev#2412 das verbesserte Migrations Bash-Skript eingecheckt. Schaut mal drauf!

LG :)

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste