TYPO3 Extbase - jak używać rdzenia Signal/Sloty

Question

Mam działające rozszerzenie Extbase w TYPO3 V6.2, które przechowuje Produkty. Teraz chcę się nauczyć o użyciu Signal/Slot (Extbase variant of Hooks). Zastanawiam się, dlaczego ten przykład nie działa. Kiedy aktualizuję produkt w module List w Backend TYPO3, zapisuje się poprawnie, ale nie pojawia się żaden komunikat.

pliku typo3conf/ext/myext/ext_localconf.php

$signalSlotDispatcher = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Extbase\\SignalSlot\\Dispatcher'); 
$signalSlotDispatcher->connect(
    'TYPO3\\CMS\\Extbase\\Persistence\\Generic\\Backend', 
    'afterUpdateObject', 
    'MyVendor\\MyExt\\Service\\Signalservice',  
    'myAfterUpdate', 
    FALSE 
); 

pliku typo3conf/ext/myext/Serwis/Signalservice.php

namespace MyVendor\MyExt\Service; 

class Signalservice implements \TYPO3\CMS\Core\SingletonInterface { 

    /** 
    * @param \TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface $object 
    */ 
    public function myAfterUpdate(\TYPO3\CMS\Extbase\DomainObject\DomainObjectInterface $object){ 

      if ($object instanceof \MyVendor\MyExt\Domain\Model\Products) { 

       // check if we come to this point 
       \TYPO3\CMS\Extbase\Utility\DebuggerUtility::var_dump('Successfully hooked - I am a slot.'); 
       die(); 

      } 

    } 

} 

Aktualizacja 15.06 .2015
Wskazówka od Patricka Lobachera zauważyła, że ​​nie możemy używać metody die() w tym kontekście. Zamiast tego powinniśmy zapisać plik dziennika. Ale to też nie działa dla mnie. No plik został napisany:

pliku typo3conf/ext/myext/ext_localconf.php

/** 
* @var \TYPO3\CMS\Extbase\SignalSlot\Dispatcher $signalSlotDispatcher 
* */ 
$signalSlotDispatcher = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Extbase\\Object\\ObjectManager')->get('TYPO3\\CMS\\Extbase\\SignalSlot\\Dispatcher'); 
$signalSlotDispatcher->connect(
    'TYPO3\\CMS\\Extbase\\Persistence\\Generic\\Backend', 
    'afterUpdateObject', 
    function ($payload) { 

     $logfile = "fileadmin/test/logfile.txt"; 
     $handle = fopen($logfile, "a+"); 
     fwrite ($handle, 'Hi. I was written by ext_localconf.php. ' . time()); 
     fclose ($handle); 

    }); 

Aktualizacja 29.06.2015
Na https://forge.typo3.org/issues/61979 Francois napisał, że „Menedżer obiekt może używaj tylko w kontekście Extbase, a nie w ext_localconf.php ". Jednak podana odpowiedź nawet nie działa dla mnie. Ale może to pomaga komuś innemu.

Answer 1

Obecnie nie ma oficjalnej dokumentacji, ale w tej kwestii można znaleźć nieoficjalne dokumenty: https://forge.typo3.org/issues/59089

Problem polega na tym, że używasz sygnałów szczelin Extbase na liście Module. W wersji 6.2 lista modułów nie jest zaimplementowana przy użyciu Extbase. Więc nie ma automatów, których możesz użyć. Zamiast tego trzeba przestrzegać starych, udokumentowana, sposób używając Haki: https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Hooks/Concept/Index.html

w Twoim przypadku, następujący kod powinien działać jako punkt wyjścia:

ext_localconf.php:

$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass'][$_EXTKEY] 
    = 'Vendor\ExtName\Hook\DataMapHook'; 

Nie można skonfigurować klasa, która będzie używać jako starej nazwy klasy, zanim TYPO3 6.2 będzie obsługiwać więcej niż tylko dane dla widoku listy.

Wewnątrz klasy można wdrożyć swój kod jak już zrobione przez Ciebie:

Classes/Hook/DataMapHook.php:

<?php 
namespace Vendor\ExtName\Hook; 

/** 
* Hook to process updated records. 
* 
* @author Daniel Siepmann <d.siepmann@web-vision.de> 
*/ 
class DataMapHook 
{ 

    /** 
    * Hook to add latitude and longitude to locations. 
    * 
    * @param string $action The action to perform, e.g. 'update'. 
    * @param string $table The table affected by action, e.g. 'fe_users'. 
    * @param int $uid The uid of the record affected by action. 
    * @param array $modifiedFields The modified fields of the record. 
    * 
    * @return void 
    */ 
    public function processDatamap_postProcessFieldArray(
     $action, $table, $uid, array &$modifiedFields 
    ) { 
     if(!$this->executeHook($table, $action)) { 
      return; 
     } 

     // check if we come to this point 
     \TYPO3\CMS\Extbase\Utility\DebuggerUtility::var_dump('Successfully hooked - I am a slot.'); 
     die(); 
    } 

    /** 
    * Check whether to execute hook or not. 
    * 
    * @param string $table 
    * @param string $action 
    * @param array $modifiedFields 
    * 
    * @return bool 
    */ 
    protected function executeHook($table, $action) 
    { 
     // Do not process if foreign table, unintended action, 
     // or fields were changed explicitly. 
     if ($table !== 'tx_extname_domain_model_modelname' || $action !== 'update') { 
      return false; 
     } 

     return false; 
    } 
} 

I tak, można użyć die w tym kontekście do debugowania i takie. Jako TYPO3 po prostu będzie iterować nad skonfigurowanymi hakami i wywoływać metody. Nic więc dziwnego. Otrzymujesz niektóre parametry zdefiniowane przez implementację i możesz z nimi pracować.

W powyższym przykładzie jest jedna kontrola, aby wykonać tylko hak, jeśli tabela i akcja są zgodne. Ponieważ ten kod jest wywoływany z wielu powodów, upewnij się, że chcesz go umieścić na białej liście, aby działał tylko w znanych Ci środowiskach. Ze względów bezpieczeństwa i wydajności.