Teil 4:

Implementierung Kunden Model

Es kann darüber diskutieren werden, ob man den Kunden als eine Instanz des Frontend-Users behandelt und entsprechend diese Tabelle und das von Extbase mitgelieferte Model benutzt. Falsch ist das sicher nicht, aber ich neige dazu den Frontend-User fest mit der Funktion Login zu verknüpfen. Unsere Kunden sollen sich nirgends anmelden, darum wäre das hier falsch. Wie gesagt, es ist Auslegungssache und es mag passieren, dass ich mich hier belehren lassen muss. Am Ende des Tages bevorzuge ich ein eigenes Kunden Model, dem ich im Bedarfsfall eine Instanz eines Frontend-Users über eine Relation mitgebe. Also spielen wir jetzt wieder das Spiel Model, TCA, SQL, Labels und Icons.

Client Model, wieder ohne getter und setter:

<?php
namespace Typovision\Biblio\Domain\Model;
/** copyright notice **/
use TYPO3\CMS\Extbase\DomainObject\AbstractEntity;

/**
 * Client model representing a natural person using the service of the biblio
 */
class Client extends AbstractEntity {

	/**
	 * @var string
	 */
	protected $name;

	/**
	 * @var string
	 */
	protected $address;

	/**
	 * @var string
	 */
	protected $city;

	/**
	 * @var string
	 */
	protected $zip;

	/**
	 * @var string
	 */
	protected $telephone;

	/**
	 * @var string
	 */
	protected $email;

	/**
	 * the identifier used in the system for this special person
	 * @var string
	 */
	protected $identifier;

 

Der zugehörige Teil aus ext_tables.sql:

#
# Table structure for table 'tx_biblio_domain_model_client'
#
CREATE TABLE tx_biblio_domain_model_client (

  uid int(11) NOT NULL auto_increment,
  pid int(11) DEFAULT '0' NOT NULL,

  name varchar(255) DEFAULT '' NOT NULL,
  address varchar(255) DEFAULT '' NOT NULL,
  city varchar(255) DEFAULT '' NOT NULL,
  zip varchar(255) DEFAULT '' NOT NULL,
  telephone varchar(255) DEFAULT '' NOT NULL,
  email varchar(255) DEFAULT '' NOT NULL,
  identifier varchar(255) DEFAULT '' NOT NULL,

  << system felder und index keys wie oben >>
);

 

Diese beiden dürften keine Überraschungen bergen, außer dass ich gegenüber dem eingangs gezeigten Domain Model die property adresse etwas besser verteilt habe auf address (Straße und Hausnummer), Stadt und Postleitzahl. Abgefragt werden auch Telefonnummer und E-mail. Die TCA-Definition sollte kein Problem darstellen. Alle Felder werden als Standard Input Felder angelegt.

 

Keine Validierung?

Bisher habe ich vollständig auf die Definition von Validatoren verzichtet. Keine der Properties muss einen Wert enthalten oder einem bestimmten Format genügen – noch. Validation (also die Gültigkeitsprüfung) ist ein wichtiges und komplexes Thema, ich widme ihm daher ein eigenes Kapitel.

Im Laufe der Entwicklung einer Extension verlagert sich die Aufmerksamkeit weg von den Models in die Repositories und vor allem in die Controller. Das ist nur logisch, denn an einem gewissen Punkt sollte das Domain Model so stabil sein, dass man darauf die Funktionalität entwickeln kann. Leider bürgert sich eine gewisse ‘fire and forget’ Mentalität gegenüber den Model-Dateien ein, die eigentlich nicht wünschenswert ist. Das Domain Model ändert sich, wenn sich Anforderungen ändern. Damit ändert sich dann auch die Implementierung. Wenn man also gleich zu Anfang die Domain schon so weit abstecken kann, dass man genau zu wissen meint, welche Felder welchem Schema folgen sollen, manövriert man sich auch gern einmal in eine Sackgasse.

Zu beachten ist, dass in der Extbase Extension-Entwicklung die Validierung zweimal erfolgen und damit synchron gehalten werden muss, nämlich einmal am TCA und einmal in den Models selbst. Ein im TCA als required (Pflichtfeld) gekennzeichnetes Feld, das im Model keine derartige Prüfung enthält, kann zum Verlust von Daten führen, da der Datensatz nicht gespeichert wird aufgrund des nicht ausgefüllten Feldes. Eine Typ-Vorgabe von integer im TCA und float im Model führt unter Umständen zum Verlust der Nachkommastellen. Meine Vorgehensweise ist es deshalb, die Validierung nach und nach an die Models anzufügen, so wie sie sich im Laufe der Entwicklung ergeben. Wenn Daten nur über das Backend eingegeben werden, kann ich mir das Annotieren in den Models sparen, denn auf die Anzeige hat das keinen Einfluss. Erlaube ich die Datenpflege im Frontend (oder in einem eigenen Backend-Modul), müssen die Restriktionen gleichzeitig auf Model und TCA angewendet werden.

Um zum Abschluss wieder zurück zum Thema zu kommen: sobald wir in der Implementierung zum ersten Mal die Anforderung erleben, eine Property einer Prüfung zu unterziehen, werde ich dem Thema die verdiente Aufmerksamkeit widmen. Bis dahin ignoriere ich es.

Weiter geht´s im nächsten Beitrag mit dem Model Bibliothek, ^[1] gefolgt vom Bibliothekscontroller. ^[2]

 

Start verpasst?
Blogreihe Extension-Entwicklung mit TYPO3 Extbase & Fluid
Teil 1: Entstehung der Blogreihe, Idee & Datenmodellierung
Teil 2: Das Grundgerüst
Teil 3: Implementierung ^[3]