Monday, October 29, 2012

Integrating TYPO3 Flow commands to the PhpStorm command line tool

Last week I read about the possibility to integrate composer to the PhpStorm command line tool. Inspired by this article, I created a configuration file for TYPO3 Flow commands.

TYPO3 Flow command line integration in PhpStorm
I published the configuration file on github, so it can easily be shared, extended, forked or whatever.

Sadly I did'nt get the Quick Definition View to work as it was described in the original article from Jetbrains.

Configuration:
  1. Navigate to Settings | Command Line Tool Support and add custom configuration
  2. Add the Framework Name (e.g. "TYPO3 Flow"), the Tool path (e.g. "./flow") and the Alias (e.g. "flow")
  3. Import the XML configuration file available here: https://github.com/derhansen/typo3-flow-phpstorm-cl-xml
Be sure to check, that the Tool path doesn't contain an absolute path to the flow executable.

How to use it?
  1. Open a TYPO3 Flow project in PhpStorm and press CTRL + SHIFT + X
  2. Check, that the current directory contains the TYPO3 Flow executable (in Linux systems you can use pwd to check the current directory). If not, navigate to that directory.
  3. Enter a TYPO3 Flow command by using the alias defined in the configuration (in this example "flow")

FlashMessages in TYPO3 Flow überschreiben

In TYPO3 Flow kann man Domain-Models sehr einfach per Annotations validieren. So definiert man in seinem Domain Model lediglich die Eigenschaften und die dazugehörigen Validierungsregeln. Will man nun über ein Formular Daten speichern, gibt TYPO3 Flow wie erwartet Fehlermeldungen passend zu den definierten Validierungsregeln aus.

Beispiel:

/**
 * The firstname
 *
 * @var string
 * @Flow\Validate(type="String")
 * @Flow\Validate(type="NotEmpty")
 */
 protected $firstname;

Die Eigenschaft "firstname" muss ein String und darf nicht leer sein. Erstellt man dafür nun ein Formular, würde das so aussehen.

<f:form action="create" controller="Register">
  <label for="firstname">Firstname:</label>
  <f:form.textfield=" id="firstname" name="data[firstname]" property="firstname" />
  <f:form.submit value="Submit" />
</f:form>

Um die Validierungsergebnisse auszugeben, muss das Formular wie folgt ergänzt werden.

<f:flashMessages />
<f:form.validationResults for="data">
    <f:if condition="{validationResults.flattenedErrors}">
        <div class="error">
            <f:for each="{validationResults.flattenedErrors}" key="propertyPath" as="errors">{propertyPath}: <f:for each="{errors}" as="error">{error}</f:for></f:for>
        </div>
    </f:if>
</f:form.validationResults>

Wenn man die das Formular nun absendet, erhält man in den validationResults die Meldungen bzgl. des Domain-Models. Aber im flashMessage Container erscheint noch eine nicht sehr schöne Fehlermeldung von TYPO3 Flow.
An error occurred while trying to call Your\Package\Controller\RegisterController->createAction()

Diese Meldung kann man überschreiben, indem man im Controller die Methode getErrorFlashMessage() überschreibt.

/**
 * @return \TYPO3\Flow\Error\Message
 */
protected function getErrorFlashMessage() {
 switch ($this->actionMethodName) {
  case 'createAction' :
   return new \TYPO3\Flow\Error\Message('Could not save form, because some fields are not filled out correctly');
  default:
   return parent::getErrorFlashMessage();
 }
}

Abhängig von der aufgerufenen Action, kann man die ausgegebene Fehlermeldung überschreiben.

Thursday, October 18, 2012

TYPO3 Flow 1.2 - Kickstarter Package über Composer installieren

Heute wollte ich mal die aktuelle Developer Version von TYPO3 Flow 1.2 installieren nachdem ich ein Tweet von Robert Lemke über TYPO3 flow und Composer gelesen hatte. Da mir Composer nicht nicht sehr geläufig ist, habe ich etwas länger gebraucht um das alles zum laufen zu bekommen.

Die Installation von TYPO3 Flow über Composer ist wirklich sehr einfach und mit einem simplen Befehl erhält man (fast) alle benötigten Dateien und Abhängigkeiten

composer create-project typo3/flow-base-distribution

Wer nun erwartet, dass man wie in Flow 1.1 einfach mit dem Kickstarter loslegen und Packages erstellen kann, der wird  feststellen, dass der TYPO3 Kickstarter gar nicht in der flow-base-distribution enthalten ist.

Nachdem ich dann etwas in der composer.json Datei reingeschaut hatte, fiel mir die Zeile "require-dev" auf. Dort stand unter anderem etwas vom TYPO3 Kickstarter. Die dort erwähnten Pakete installiert man mit folgendem Befehl:

composer install --dev

Nun kann man mit dem TYPO3 Kickstarter neue Packages erstellen.

Wednesday, October 3, 2012

Mapping anderer Tabellen in Extbase

Neulich stand ich vor der eigentlich recht simplen Aufgabe aus einer Extbase Extension heraus auf die erzeugten Daten einer anderen Extbase Extension zuzugreifen. Im Web gibt es auch einige Tutorials, welche beschreiben wie man dieses macht, aber fast alle zeigen, wie man auf die Tabellen fe_users und fe_groups zugreift, welche beide schon als Domain-Model bei Extbase mitgeliefert werden. Ein funktionierendes Praxisbeispiel für den Zugriff auf eigene Datenstrukturen konnte ich leider nicht finden.

In diesem Beitrag zeige ich deshalb, wie man aus einer Extbase Extension heraus auf die Daten einer anderen Extbase Extensions zugreifen kann.

Ausgangssituation:

In einer TYPO3 Installation wurden 2 Extbase Extensions (testext1 und testext2) eingerichtet, welche jeweils eigene Repositories und Storagefolder haben. Die Typoscript Constants der Extensions sind wie folgt eingerichtet:

plugin.tx_testext1 {
  persistence {
    storagePid = 5
  }
}

plugin.tx_testext2 {
  persistence {
    storagePid = 6
  }
}

Die Datensätze von testext1 werden also im Sysordner mit der Pid 5 abgelegt und die Datensätze von testext2 im Sysordner mit der Pid 6. In testext1 gibt es ein Domainmodel mit dem Namen Testext1Table und in testext2 gibt es ein Domainmodel mit dem Namen Testext2Table.

Ziel ist es nun, aus einem Controller in testext2 auf die angelegten Daten von testext1 zuzugreifen.

Vorgehensweise:

Als erstes muss in testext2 ein Domainmodel angelegt werden, welches das Domainmodel von textext1 extended. Also wird in textext2\Classes\Domain\Model\ die Datei Testext1Table.php angelegt.

class Tx_Testext2_Domain_Model_Testext1Table extends Tx_Testext1_Domain_Model_Testext1Table {

}

Somit wurde der testext2 schon mal das Domainmodel aus testext1 bekannt gemacht. Damit wir auf die Daten aus testext1 zugreifen können, wird noch ein entsprechendes Repository benötigt. Dieses wird in  textext2\Classes\Domain\Repository\Testext1TableRepository.php definiert.

class Tx_Testext2_Domain_Repository_Testext1TableRepository extends Tx_Extbase_Persistence_Repository {

}

Nun kennt die Extension testext2 das Domainmodel und hat auch ein entsprechendes Repository. Das neue Repository wird in einem Controller von testext2 per Dependency Injection implementiert.

/**
 * testext1TableRepository
 *
 * @var Tx_Testext2_Domain_Repository_Testext1TableRepository
 */
protected $testext1TableRepository;

/**
 * injectTestext1TableRepository
 *
 * @param Tx_Testext2_Domain_Repository_Testext1TableRepository $testext1TableRepository
 * @return void
 */
public function injectTestext1TableRepositoryRepository(Tx_Testext2_Domain_Repository_Testext1TableRepository $testext1TableRepository) {
 $this->testext1TableRepository = $testext1TableRepository;
}

Wer an dieser Stelle jetzt schon erste Ergebnisse aus dem implementierten Repository erwartet, wird enttäuscht und bekommt beim Versuch Daten aus dem Repository abzufragen/anzuzeigen eine Exception vom Typ Tx_Extbase_Persistence_Storage_Exception_SqlError, welche besagt, dass eine Tabelle nicht existiert.

Die Extension testext2 weiß also anscheinend noch gar nicht, aus welcher Tabelle die Daten des neuen Repositories abgefragt werden sollen. Um dieses einzurichten, muss man im Typoscript Setup von testext2 ein Mapping einrichten.

config.tx_extbase {
 persistence {
    classes { 
        Tx_Testext2_Domain_Model_Testext1Table {
            mapping.tableName = tx_testext1_domain_model_testext1table
        }
    }
 }
}

An dieser Stelle ist es wichtig, dass das Mapping direkt auf den Tabellennamen in der Datenbank stattfindet.

Auch jetzt erhalten wir über das neue Repository in testext2 noch keine Daten, da die testext2 noch nicht weiß, in welcher StoragePid die Datensätze von testext1 liegen. Hierzu ergänzt man lediglich die Typoscript Constants von testext2 wie folgt.

plugin.tx_testext2 {
  persistence {
    storagePid = 6,5
  }
}

Die StoragePid von testext1 wurde hinter der StoragePid von testext2 angehängt. Nun kann das neue Repository in testext2 angesprochen und die erwarteten Daten erfolgreich zurückgeliefert werden.