Tagebuch einer Extension-Entwicklung

Backend-Modul registrieren

Jetzt geht es also an die Files, die uns der Extension-Creator im letzten Schritt erzeugt hat.

Zunächst will ich mein Backend-Modul in TYPOlight bekannt machen. Dafür öffne ich /system/modules/gw_turnierpaare/config/config.php.

Im Skelett dieser Datei sind schon Abschnitte für die Eintragung von Backend-Modulen, Front-Modulen, Content-Elementen, Hooks und noch viel mehr vorgesehen. Ich orientiere mich am CD-Collection-Tutorial und trage im Abschnitt für Backend-Module folgendes ein:

PHP-Code:

$GLOBALS['BE_MOD']['content']['gw_turnierpaare'] = array 
( 
    'tables' => array('tl_gw_turnierpaare','tl_gw_meldungen'), 
    'icon'   => 'system/modules/gw_turnierpaare/icons/turnierpaare.png' 
);  

Hiermit registriere ich ein Modul mit dem Bezeichner gw_turnierpaare, das sich auf die Datenbanktabellen tl_gw_turnierpaare und tl_gw_meldungen stützt (wie im Extension-Generator angegeben). In der Liste der Backend-Module (linke Spalte im Backend) soll ein Icon vor dem Bezeichner angezeigt werden, dessen Pfad ich unter 'icon' angegeben habe. Das Icon, was ich mir ausgesucht habe, ist an diesen Post angehängt.

Ich habe mich für ein eigenes Unterverzeichnis für mögliche weitere Icons entschieden, und deshalb manuell das Unterverzeichnis "icons" angelegt und mein Icon dort hoch geladen.

Im Backend-Modul soll der Berechtigte (also der Sportwart) die Daten anlegen/löschen/ändern dürfen.

Ich speichere die Datei zunächst, und lade meine Backend-Ansicht (als Administrator!) neu. Nun sehe ich in der linken Spalte unter "Inhalte" den neuen Eintrag gw_turnierpaare mit meinem Icon. Ein Klick darauf führt leider noch zu einer Fehlermeldung, da die SQL-Tabellen tl_gw_turnierpaare und tl_gw_meldungen noch nicht angelegt sind.

SQL-Tabellenstruktur anlegen

Also, die Tabellen anlegen: Ich öffne /system/modules/gw_turnierpaare/config/database.sql , in der mir der Extension-Generator schon ein Skelett für meine beiden Tabellen vorgegeben hat. In beiden Tabellen sind id, pid, sorting und tstamp vorgegeben, sowie der primary key id und der key pid. Ich vermute, dass pid die "Parent ID" ist. Meine Turnierpaare haben keinen parent, darum lösche ich die Definition von pid und die Festlegung von pid als Key.

Ich füge meine restlichen Felder hinzu, ohne so recht zu wissen, mit welcher Syntax genau. Ich habe mal was von SQL92-Syntax gelesen, aber die kenne ich nicht. Gibt es BOOLEAN-Datentypen? Char vs. Varchar? Sicherheitshalber halte ich mich erst mal an die MySQL-Syntax. Im Endeffekt sieht der Abschnitt für tl_gw_turnierpaare in database.sql so aus:

Code:

CREATE TABLE `tl_gw_turnierpaare` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `sorting` int(10) unsigned NOT NULL default '0',
  `tstamp` int(10) unsigned NOT NULL default '0',
  `partnernachname` varchar(64) NOT NULL default '_',
  `partnervorname` varchar(64) NULL,
  `partnerinnachname` varchar(64) NULL,
  `partnerinvorname` varchar(64) NULL,
  `startgruppe` varchar(32) NOT NULL default '_',
  `startklasselatein` varchar(12) NULL,
  `startklassestandard` varchar(12) NULL,
  `aktiv` int(1) NOT NULL default '0',
  `aktivseit` int(4) NULL,
  `aktivbis` int(4) NULL,
  `password` varchar(32) NULL,
  `bild` varchar(255) NULL,
  `anschrift` text NULL,
  `zeigeanschrift` int(1) NOT NULL default '0',
  `telefon` varchar(32) NULL,
  `zeigetelefon` int(1) NOT NULL default '0',
  `fax` varchar(32) NULL,
  `zeigefax` int(1) NOT NULL default '0',
  `mobil` varchar(32) NULL,
  `zeigemobil` int(1) NOT NULL default '0',
  `email` varchar(128) NULL,
  `zeigeemail` int(1) NOT NULL default '0',
  `homepage` varchar(128) NULL,
  `zeigehomepage` int(1) NOT NULL default '0',
  `beschreibung` text NULL,
  PRIMARY KEY  (`id`),
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Man kann sich hier jetzt beliebige Gedanken über die Datenstruktur, Abstraktion, Normalisierung usw machen. Ich möchte es jetzt so lösen.

Meine Meldungen in tl_gw_meldungen sollen parents haben (nämlich die Turnierpaare), darum lasse ich das Skelett so, und erweitere um meine eigenen Felder. Für meinen Fall kommt das hier heraus:

Code:

CREATE TABLE `tl_gw_meldungen` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `pid` int(10) unsigned NOT NULL default '0',
  `sorting` int(10) unsigned NOT NULL default '0',
  `tstamp` int(10) unsigned NOT NULL default '0',
  `datum` date NOT NULL default '1900-01-01',
  `startgruppe` varchar(32) NOT NULL default '_',
  `startklasse` varchar(12) NOT NULL default '_',
  `lat_std` char(1) NOT NULL default '_',
  `turnierort` varchar(128) NOT NULL default '_',
  `turnierart` varchar(64) NULL,
  `anzahlpaare` int(4) NULL,
  `platz_von` int(4) NULL,
  `platz_bis` int(4) NULL,
  `bemerkung` text NULL,
  PRIMARY KEY  (`id`),
  KEY `pid` (`pid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Ich speichere database.sql und rufe /typolight/install.php in meiner TYPOlight-Installation auf. TYPOlight bemerkt, dass die Datenbankstruktur nicht mehr aktuell ist, und schlägt mir vor, meine Tabellen anzulegen. Ich bestätige das.

Was dann kommt, erstaunt mich dann aber doch etwas: Die Datenbankstruktur soll weiterhin nicht aktuell sein:

Auch wenn ich diese Vorschläge bestätige, ändert sich nichts. Ein Blick in die Datenbank zeigt aber, dass die Tabellen wie von mir gewünscht angelegt wurden. Irgendwie kommt TYPOlight dort ins Schleudern. Ein Klick auf gw_turnierpaare im Backend verläuft jetzt aber ohne Fehlermeldung, auch wenn in diesem Backend-Modul noch nichts "passiert".

Meine Frage an dieser Stelle also an die erfahrenen Entwickler: Was ist an meiner SQL-Definition "falsch", dass die Tabellen zwar richtig angelegt werden, das TYPOlight-Install-Tool aber damit nicht zurecht kommt?

SQL reloaded

Nach kleinem Kampf mit dem Install-Tool - dokumentiert in der Diskussion weiter unten - sieht das SQL für meine beiden Tabellen in database.sql nun so aus:

Code:

CREATE TABLE `tl_gw_turnierpaare` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `sorting` int(10) unsigned NOT NULL default '0',
  `tstamp` int(10) unsigned NOT NULL default '0',
  `partnernachname` varchar(64) NOT NULL default '',
  `partnervorname` varchar(64) NULL default NULL,
  `partnerinnachname` varchar(64) NULL default NULL,
  `partnerinvorname` varchar(64) NULL default NULL,
  `startgruppe` varchar(32) NOT NULL default '',
  `startklasselatein` varchar(12) NULL default NULL,
  `startklassestandard` varchar(12) NULL default NULL,
  `aktiv` int(1) NOT NULL default '0',
  `aktivseit` int(4) NULL default NULL,
  `aktivbis` int(4) NULL default NULL,
  `password` varchar(32) NULL default NULL,
  `bild` varchar(255) NULL default NULL,
  `anschrift` text NULL,
  `zeigeanschrift` int(1) NOT NULL default '0',
  `telefon` varchar(32) NULL default NULL,
  `zeigetelefon` int(1) NOT NULL default '0',
  `fax` varchar(32) NULL default NULL,
  `zeigefax` int(1) NOT NULL default '0',
  `mobil` varchar(32) NULL default NULL,
  `zeigemobil` int(1) NOT NULL default '0',
  `email` varchar(128) NULL default NULL,
  `zeigeemail` int(1) NOT NULL default '0',
  `homepage` varchar(128) NULL default NULL,
  `zeigehomepage` int(1) NOT NULL default '0',
  `beschreibung` text NULL,
  PRIMARY KEY  (`id`),
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

CREATE TABLE `tl_gw_meldungen` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `pid` int(10) unsigned NOT NULL default '0',
  `sorting` int(10) unsigned NOT NULL default '0',
  `tstamp` int(10) unsigned NOT NULL default '0',
  `datum` date NOT NULL default '1900-01-01',
  `startgruppe` varchar(32) NOT NULL default '',
  `startklasse` varchar(12) NOT NULL default '',
  `lat_std` char(1) NOT NULL default '',
  `turnierort` varchar(128) NOT NULL default '',
  `turnierart` varchar(64) NULL default NULL,
  `anzahlpaare` int(4) NULL default NULL,
  `platz_von` int(4) NULL default NULL,
  `platz_bis` int(4) NULL default NULL,
  `bemerkung` text NULL,
  PRIMARY KEY  (`id`),
  KEY `pid` (`pid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

und wir merken uns:

• NOT NULL-Felder mit default (logisch)
• NULL-"text"-Felder OHNE default
• Sonstige NULL-Felder mit "default NULL"
• default _KLEIN_ schreiben
• Und falls man da was verändert: _2_ Leerzeichen zwischen PRIMARY KEY und (`id`)

Und hier nochmal der Link zum Thread, der das erklärt:

Tipps zur SQL Dump Syntax in TYPOlight

So, das Install-Tool ist zufrieden, die Datenbank-Tabellen angelegt - es kann weiter gehen!

Diskussionsbeiträge aus dem Forum

user: Seitengestalter

Hallo, jeweils am Ende der Zeile das >NULL< durch >< (das sind zwei einfache Striche, nicht der Doppelte - und ohne die spitzen Klammern) ersetzen.

user: dl1ely

leider Nein... Das Install-Tool schlägt dann ein Anpassen der Datenbankstruktur z.B. wie folgt vor:

Code:

ALTER TABLE `tl_gw_turnierpaare` CHANGE `partnervorname` `partnervorname` varchar(64) '';

Wenn man das bestätigt, erntet man nur eine SQL-Fehlermeldung (von MySQL). Code:

Fatal error: Uncaught exception Exception  with message Query error: You have an error in 
your SQL syntax; check the manual that corresponds to your MySQL server version for the 
right syntax to use near '''' at line 1 (ALTER TABLE `tl_gw_turnierpaare` CHANGE 
`partnervorname` `partnervorname` varchar(64) '';)

Noch jemand eine Idee?

Im o.g. CD-Collection-Tutorial wird es in einer Zeile der database.sql bei einem NULL-Feld auch so gemacht (also mit "NULL" am Ende der Zeile). Lasse ich "NULL" komplett weg, will mir das Installationstool weiterhin die Datenbankstruktur anpassen, obwohl sie eigentlich schon korrekt ist.

user: Seitengestalter

Sorry, mein Fehler. Muss heißen >default <. Meiner Erfahrung nach mag Tl kein varchar mit dem Default NULL

user: BugBuster

Siehe hier zum Thema "wie erstelle ich die sql richtig":

Tipps zur SQL Dump Syntax in TYPOlight

Vereinfacht gesagt, vollständige MySQL Syntax.

user: dl1ely

OK, wir kommen der Sache näher, aber für mich bleibt es mysteriös...

• NOT NULL Felder sind kein Problem - Man gibt den Default an, und alles ist OK.
• varchar-Felder mit NULL werden geschluckt (also funktionieren), wenn man "default " anhängt, also

z.b.

Code:

`name` varchar(32) NULL default ''

• int- oder text-Felder mit NULL werden vom Install-Tool nicht geschluckt, wenn "default '0'" (für int)

oder "default " (für text) anhängt, also z.B.

Code:

`flag` int(1) default '0'

Das Install-Tool meint weiterhin, die Datenbankstruktur würde nicht stimmen, und lässt sich auch nicht davon abhalten.

Ich habe mal in das database.sql der Extension "twitterreader" geschaut, dort steht ein NON-NULL text-Feld als

Code:

`feld` text NULL,

eingetragen, und dort funktioniert das offensichtlich auch. Warum bei mir nicht? Help!

P.S.: Meine verbleibenden Problem-Felder sind:

Code:

ALTER TABLE `tl_gw_turnierpaare` CHANGE `aktivseit` `aktivseit` int(4) NULL default '0000';
ALTER TABLE `tl_gw_turnierpaare` CHANGE `aktivbis` `aktivbis` int(4) NULL default '0000';
ALTER TABLE `tl_gw_turnierpaare` CHANGE `anschrift` `anschrift` text NULL default '';
ALTER TABLE `tl_gw_turnierpaare` CHANGE `beschreibung` `beschreibung` text NULL default '';
ALTER TABLE `tl_gw_meldungen` CHANGE `bemerkung` `bemerkung` text NULL default '';

user: BugBuster

 Zitat von Seitengestalter   
 Meiner Erfahrung nach mag Tl kein varchar mit dem Default NULL

Doch, sieht komisch aus, aber so gehts:

Code:

 `varchar_null_demo` varchar(32) NULL default NULL,

Siehe Link von mir weiter oben.

user: BugBuster

Mal einfach gefragt, wenn ein Feld NULL sein darf, wozu dann ein Default? 
Wenn ein Default eingetragen werden soll, wenn nichts übergeben wurde, dann muss NOT NULL definiert werden.
Textfelder dürfen kein Default haben, bei INT und NULL gilt: 

Code:

 ALTER TABLE `tl_gw_turnierpaare` CHANGE `aktivseit` `aktivseit` int(4) NULL default NULL;
 ALTER TABLE `tl_gw_turnierpaare` CHANGE `aktivbis` `aktivbis` int(4) NULL default NULL;
 ALTER TABLE `tl_gw_turnierpaare` CHANGE `anschrift` `anschrift` text NULL;
 ALTER TABLE `tl_gw_turnierpaare` CHANGE `beschreibung` `beschreibung` text NULL;
 ALTER TABLE `tl_gw_meldungen` CHANGE `bemerkung` `bemerkung` text NULL;

user: dl1ely

Halleluja, es ist gelöst!

Wenn man genau nach Tipps zur SQL Dump Syntax in TYPOlight

arbeitet, dann geht es:

• NOT NULL-Felder mit default
• NULL-Felder mit "NULL default NULL"
• NULL-text-Felder ohne default!

user: dl1ely

Zitat von BugBuster   

Mal einfach gefragt, wenn ein Feld NULL sein darf, wozu dann ein Default? Einfache Antwort: Weil Roland mich drauf brachte und es (komischerweise) funktioniert. Ich hätte mir sowas nicht ausgedacht ;-). "NULL default NULL" ist aber auch eine gewisse Tautologie. Anyway, es funktioniert...und "NULL default NULL" gefällt mir auch besser, darum habe ich es jetzt darauf geändert.