Typo3 Extbase 1.3 Extension zu Extbase 6.2

Immer mehr Webseiten werden nun umgestellt. Es ist die neue Typo3 LTS Version erschienen. Ob es Sinn macht jetzt schon umzustellen muss jeder für sich selber entscheiden. Ich arbeite schon mit der neuen LTS Version und habe meine Projekte einem Update unterzogen. Die alte LTS Version 4.5 wird noch bis zum Oktober mit regulären Updates versorgt. Danach wird es reguläre Updates nur noch für die dann gültigen Versionen geben. Wir haben hier also eine Überschneidung der Versionen von ca. 5 Monaten. (Quelle: Typo3 Roadmap)

Typo3 Extbase Extension Update

So… die ersten Typo3 Extbase Extensions haben ein Update erfahren. Es sind alle samt Extensions gewesen, die für Typo3 4.5 LTS mit Extbase 1.3 entwickelt wurden. Ich möchte hier nun ein kleinen Überblick geben, was ich getan hab, damit die Extensions weiterhin funktionieren. Einen Post (Repository Error) über einen auftretenden Fehler habe ich ja schon veröffentlicht.  Hier nun der Generische zum Update 🙂

Das Repository

Das Repository darf jetzt initialisiert werden. Das heisst man kann seine Konfiguration auf die eigenen Bedürfnisse einfach anpassen. Ich mache dies in allen meinen Repositories, dann sehe ich gleich was in dem Repository Sache ist.

Hier ein Beispiel:

public function initializeObject() {
         /** @var $querySettings \TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings */
         $querySettings = $this->objectManager->get('TYPO3\\CMS\\Extbase\\Persistence\\Generic\\Typo3QuerySettings');
                 
         $querySettings->setRespectStoragePage(FALSE);
         

         $querySettings->setIgnoreEnableFields(TRUE);       
 

         $querySettings->setIncludeDeleted(FALSE);
 

         $querySettings->setRespectSysLanguage(FALSE);
 
         $this->setDefaultQuerySettings($querySettings);
     }

Die Konfig ist eigentlich selbsterklärend, oder?

Formulare und andere Objekte

Sollen in Formulare andere Objekte referenziert werden, so war es bisher möglich in Fluid einfach das Objekt als solches einzutragen. Fluid hat daraus dann das _identity – Feld gerendert und beim Absenden daraus wieder das Objekt generiert. Ich hatte nun das Problem, dass dieses _identity-Feld nicht validiert werden konnte, vermutlich, weil es ein sollches nicht im Objekt gab.  Es hat aber da schon gereicht, explizit die uid des objektes rendern zu lassen und nicht das komplette Objekt.

//Aus 
<f:form.hidden property="meinAnderesObjekt" value="{meinAnderesObjekt}" />

//wurde
<f:form.hidden property="meinAnderesObjekt" value="{meinAnderesObjekt.uid}" />

danach war die Validierung kein Problem mehr.

Reihenfolge der Parameter

Das war wirklich eine nervige Sachen. Ich hatte bei einer Action plötzlich Validierungsprobleme, die sich mit einer Exception äußerten. Konkret konnte ein String nicht zu dem geforderten Objekt konvertiert werden. Das Problem war, dass die Exception dazu nicht ganz so aussagekräftig war.  Aber ich hab es ja gefunden.

Es ist extrem wichtig, dass die Reihenfolge der Parameter in der Annotation die Selbe ist wie bei den Methodenparametern.

//Falsch:

/**
* @param string $arg1
* @param \Argument $arg2
*/
public function showAction(\Argument $arg2, arg1){
....
}


//RICHTIG:

/**
* @param string $arg1
* @param \Argument $arg2
*/
public function showAction(arg1, \Argument $arg2){
....
}

So das ist mir nun nachträglich wieder eingefallen. Leider hab ich mir nicht alles notiert. Ihr könnte aber gerne eure Probleme in die Kommentare posten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.