Hallo und danke für die Antwort,
dasselbe passiert auch bei vorhandenen Objekten. Wir benutzen ja extra
diesen Hook, weil nur bei diesem sichergestellt ist, dass der Datensatz
sich schon in der DB befindet. Zuvor habe ich es mit diesem Hook:
"processDatamap_afterDatabaseOperations" probiert - dort war Deine
Vermutung auch zutreffend (was uns aufgefallen ist, als wir auf
Relationen von $event, z.B. $eventCategories, zugreifen wollten und die
noch nicht da waren.
Mit dem aktuellen Hook kann ich z.B. das Folgende problemlos ausführen:
foreach ($eventCategories as $eventCategory) {
if ($eventCategory->getNeedsApproval()) {
$approvalIsNeeded = TRUE;
}
}
Ich bekomme eine Liste der Objekte. Auch Aufrufe wie getUid() usw.
funktionieren einwandfrei.
Das heißt, dass das Problem irgendwo anders liegen muss.
Im Tx_Extbase_Persistence_Repository wird nach meinem update()-Aufruf
die Funktion replace($existingObject, $newObject) aufgerufen, welche
wiederum diesen Aufruf starten will (und scheitert):
$this->backend->replaceObject($existingObject, $newObject);
Mit "non-object" in der Fehlermeldung ist also $this->backend gemeint,
welches in der Repository.php aus irgend einem Grund nicht verfügbar ist...
Am 23.01.2013 15:29, schrieb conPassione gmbh:
Hallo Thomas
mir scheint, dass Du etwas updaten willst, was noch gar nicht in die DB
geschrieben wurde.... d.h. wenn der User speichern will, wird zuerst
Deine Funktion aufgerufen, ohne den Datensatz zu speichern. Deshalb
funktioniert dann das Update nicht (keine ID ...). Oder passiert das bei
bereits vorhandenen Datensätzen auch?
Gruss Renzo
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
