TEE-06 Backend Callbacks und Subpaletten - Versionsgeschichte

Stefan.sl: Formatierung Geshi

2011-02-05T18:12:34Z

Formatierung Geshi

Änderungen zeigen

Manitougs: div. Korrekturen

2010-07-13T17:52:01Z

div. Korrekturen

Schnippsel: hat „TEE-06 Callbacks und Subpaletten“ nach „TEE-06 Backend Callbacks und Subpaletten“ verschoben: Die Bennenungssystematik war nicht eingehalten.

2010-07-08T22:57:18Z

hat „TEE-06 Callbacks und Subpaletten“ nach „TEE-06 Backend Callbacks und Subpaletten“ verschoben: Die Bennenungssystematik war nicht eingehalten.

Schnippsel: Die Seite wurde neu angelegt: „{{stub}} Tagebuch einer Extension-Entwicklung Category:Tagebuch_einer_Extension-Entwicklung {{AppliesTo |Ext1=Extension Creator |TLVersion=ab TL 2.8}} =Von C…“

2010-07-07T10:45:09Z

Die Seite wurde neu angelegt: „{{stub}} Tagebuch einer Extension-Entwicklung Category:Tagebuch_einer_Extension-Entwicklung {{AppliesTo |Ext1=Extension Creator |TLVersion=ab TL 2.8}} =Von C…“

Neue Seite

{{stub}}
Tagebuch einer Extension-Entwicklung
[[Category:Tagebuch_einer_Extension-Entwicklung]]
{{AppliesTo
|Ext1=Extension Creator
|TLVersion=ab TL 2.8}}

=Von Callbacks und Subpaletten=
Nachdem auch das englische Sprachfile fertig ist, geht es nun an die letzte fehlende Funktionalität der Backend-Maske. Zunächst gibt es aber noch einige Detailkorrekturen.

Da MySQL keinen ''Boolean''-Datentyp bietet, hatte ich die Felder, die nur true/false sein können, als int(1) angelegt, mit den möglichen Werten 0/1. Das klappt auch prinzipiell, die Stati der Checkboxen werden gespeichert und wieder aus der Datenbank ausgelesen, aber ein Problem zeigt sich, wenn man nach so einem Feld filtern will: Ich will nach dem ''aktiv''-Feld filtern können. Häufig sind die die "aktiven" Turnierpaare von Interesse, die nicht mehr aktiven verstopfen aber die Liste.

Wählt man dieses Feld nun als Filter-Feld aus, werden in der DropDown-Liste als Filtermöglichkeiten aber nur "Ja" und nochmals "Ja" angezeigt. Das Filtern klappt damit auch, bei dem einen "Ja" werden nur die aktiven Paare angezeigt, beim anderen "Ja" die inaktiven. Aber das ist natürlich nicht so gewollt.

Durch Abschauen bei anderen Extensions bin ich darauf gekommen, die Checkbox-Felder durch ''char(1)'' statt ''int(1)'' abzubilden. Das klappt genau so gut, und auch das Filtern funktioniert mit "Ja" und "Nein". Alle ''int(1)''-Felder wurden entsprechend in ''char(1)'' verändert. Nach dem Anpassen der ''database.sql'' muss natürlich das Install-Tool ausgeführt werden, um die Änderungen in der Datenbank durchzuführen.

Die ''database.sql'' sieht jetzt so aus:

Code:

<pre>
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` char(1) NOT NULL default '',
`aktivseit` int(4) NULL default NULL,
`aktivbis` int(4) NULL default NULL,
`resetpassword` char(1) NULL default '',
`password` varchar(64) NULL default NULL,
`bild` varchar(255) NULL default NULL,
`anschrift` text NULL,
`zeigeanschrift` char(1) NOT NULL default '',
`telefon` varchar(32) NULL default NULL,
`zeigetelefon` char(1) NOT NULL default '',
`fax` varchar(32) NULL default NULL,
`zeigefax` char(1) NOT NULL default '',
`mobil` varchar(32) NULL default NULL,
`zeigemobil` char(1) NOT NULL default '',
`email` varchar(128) NULL default NULL,
`zeigeemail` char(1) NOT NULL default '',
`homepage` varchar(128) NULL default NULL,
`zeigehomepage` char(1) NOT NULL default '',
`beschreibung` text NULL,
PRIMARY KEY (`id`),
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
</pre>

Wer aufgepasst hat, dem ist auch noch ein neues Feld aufgefallen:

Code:

<pre>
`resetpassword` char(1) NULL default '',
</pre>

Das werde ich gleich für das Aktivieren einer Subpalette benötigen. Der Inhalt des Feldes in der Datenbank wird später nicht gebraucht, aber leider muss das Feld vorhanden sein, um es so nutzen zu können, wie ich es vorhabe.

Für das ''password''-Feld habe ich ich vor, dass ein dort eingegebenes Passwort SHA1-gehasht in der Datenbank abgelegt wird, nicht im Klartext. Dabei wird ein eventuell schon vorhandes Passwort natürlich überschrieben.

Um Fehleingaben zu verhindern, möchte ich eine Checkbox anzeigen, die defaultmäßig "aus" ist. Erst wenn die Checkbox aktiviert ist, soll per AJAX das Passwortfeld angezeigt werden.

Zunächst fügen die wir Definition für das Checkbox-Feld in die ''field''-Sektion des DCA-Records ein:

PHP-Code:

<pre>
'resetpassword' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_gw_turnierpaare']['resetpassword'],
'inputType' => 'checkbox',
'default' => '',
'eval' => array('mandatory'=>false, 'isBoolean' => true, 'submitOnChange' => true),
),
</pre>

''submitOnChange'' bewirkt, dass das Formular neu geladen wird, wenn das Feld angeklickt wird. nur dann wird das Passwortfeld nachgeladen.

Dafür benötigen wir eine sogenannte "Subpalette". Die Checkbox (bei mir "resetpassword") muss als "__selector__" angegeben werden im DCA-Record:

PHP-Code:

<pre>
// Palettes
'palettes' => array
(
'__selector__' => array('resetpassword'),
...
</pre>

In der ''default''-Sektion sieht die Palettendefinition so aus:

PHP-Code:

<pre>

.'{aktiv_legend:hide},aktiv,aktivseit,aktivbis;{password_legend:hide},resetpassword;'
</pre>

Hier steht also der Name der Subpalette. Der Name des Passwortfeldes steht hier nicht mehr. Das wird in der ''subpalettes''-Sektion angegeben:

PHP-Code:

<pre>
// Subpalettes
'subpalettes' => array
(
'resetpassword' => 'password'
),
</pre>

Dies bedeutet, dass das Feld ''password'' in die Subpalette ''resetpassword'' eingeblendet wird, wenn ''resetpassword'' aktiviert ist. Wird es deaktiviert, verschwindet die Subpalette wieder.

[[Datei:Attachment_016.png]]

[[Datei:Attachment_017.png]]

Die Texte hierzu wurden in den Sprachfiles entsprechend erweitert und angepasst.

Für beide Felder, ''resetpassword'' und ''password'', benötige ich besondere Funktionalitäten. ''resetpassword'' soll bei Öffnen der Backendmaske IMMER deaktiviert, das Passwort-Feld also versteckt sein - egal was in der Datenbank für das Feld steht. Dafür setze ich zunächst

PHP-Code:

<pre>
'default' => '',
</pre>

was dafür sorgt, dass beim Anlegen eines neuen Datensatzes die Checkbox deaktiviert ist. Und dann gibt es noch die Option ''load_callback'', in der eine Funktion angegeben werden kann, die beim Laden des Feldes aufgerufen wird (Zu den Details von Callbacks gleich mehr).

Hier habe ich versucht, durch ''return <nowiki>' '</nowiki>;'' immer den Defaultwert zurückzugeben. Leider klappt das nicht richtig, wenn der Datensatz mit "speichern" gespeichert wird, aber geöffnet bleibt. Obwohl die Checkbox dann deaktiviert dargestellt wird, bleibt das Passwort-Feld trotzdem angezeigt und wird nicht versteckt. Erst durch manuelles Aktivieren und erneutes Deaktivieren verschwindet das Passwortfeld wieder. Ich weiß nicht, ob das ein Bug oder gewollt ist, zumindest gefiel es mir nicht.

Ein weiterer Versuch scheiterte mit dem ''save_callback'': also einer Funktion, die aufgerufen wird, bevor das Feld in die Datenbank gespeichert wird. Hier versuchte ich ebenfalls durch ein ''return <nowiki>' '</nowiki>;'' zu erzwingen, dass immer ein deaktiviertes Feld gespeichert wird, und damit auch beim erneuten Anzeigen des Formulars deaktiviert bleibt.

Das funktioniert optisch auch sehr gut. Leider werden dann aber keine Eingaben im Passwort-Feld gespeichert.

Der Grund wird sehr wahrscheinlich sein, dass der ''save_callback'' auf dem ''resetpassword''-Feld ausgeführt wird, bevor der Input im ''password''-Feld verarbeitet wird. Mein ''Save-Callback'' deaktiviert die Checkbox, und damit auch die Subpalette, und das Feld in der Subpalette wird gar nicht mehr ausgewertet oder gespeichert. Auch die Reihenfolge der Felddefinitionen hat darauf keinen Einfluss, es kommt wohl auf die Reihenfolge in der Palettendefinition an, und die kann ich nicht umdrehen.

An der Stelle war tiefe Frustration angesagt, aber ich habe das Problem anders lösen können. Beim ''resetpassword''-Feld werden jetzt keine Callbacks verwendet.

Dafür aber beim ''password''-Feld, was jetzt in der Definition so aussieht:

PHP-Code:

<pre>
'password' => array
(
'label' => &$GLOBALS['TL_LANG']['tl_gw_turnierpaare']['password'],
'inputType' => 'text',
'eval' => array('mandatory'=>false, 'minlength' => 1, 'maxlength' => 64),
'load_callback' => array(array('tl_gw_turnierpaare','password_load_callback')),
'save_callback' => array(array('tl_gw_turnierpaare','password_save_callback'))
),
</pre>

Durch diese Definition wird beim Laden des Feldes die Funktion ''password_load_callback'' und beim Speichern ''password_save_callback'' aufgerufen, die sich in der Klasse ''tl_gw_turnierpaare'' befinden. Diese Klasse lege ich in der DCA-Definitions-Datei ''/modules/gw_turnierpaare/dca/tl_gw_turnierpaare.php'' an.

PHP-Code:

<pre>
class tl_gw_turnierpaare extends Backend
{
/**
* Import the back end user object
*/
public function __construct()
{
parent::__construct();
$this->import('BackendUser', 'User');
}

public function password_load_callback()
{
...
}

public function password_save_callback($var, $dc)
{
...
}
}
</pre>

Das Gerüst habe ich mir bei anderen Extensions abgeschaut, es scheint zumindest klug zu sein, von ''Backend'' zu erben, und den Konstruktur zu überschreiben. Vielleicht ist es auch nicht nötig, ich habe es nicht probiert. Ob der ''load_callback'' Parameter übergeben bekommt, weiss ich nicht, aber ich benötige keinen Parameter.

Der ''save_callback'' erhält den Wert des Feldes, das gespeichert werden soll ($var), und den DataContainer ($dc), der zu dem Formular gehört. Meist (wie auch hier) ist es DC_Table, der DataContainer für Datenbanktabellen.

Mein ''password''-Feld in der Datenbank wird den SHA1-Hash, also einen langen String unverständlicher hexadezimaler Zahlen enthalten. Es nützt nichts, wenn ich den im Backend im Passwort-Feld anzeige. Dort will der Admin Klartext-Passwörter eingeben. Im Load-Callback setze ich den Wert des ''password''-Felds also auf einen leeren String, egal was in der Datenbank steht:

PHP-Code:

<pre>
public function password_load_callback()
{
// Passwort-Feld immer leer anzeigen (Damit der User SHA1-Hash nicht sieht)
return '';
}
</pre>

Damit wird der User schon mal nicht vom "Müll" aus der Datenbank belästigt. Umgekehrt müssen wir aber nicht das Klartext-Passwort, sondern den Hash in die Datenbank schreiben. Das macht der ''save_callback'':

PHP-Code:

<pre>
public function password_save_callback($var, $dc)
{
// Kein neues PW angegeben: Feld nicht ändern
if(strlen($var) < 1) return '';
// Aktuellen Datensatz aus DB holen
$row = $this->Database->prepare("SELECT * FROM tl_gw_turnierpaare WHERE id=?")
->execute($dc->id);
// PW in Passwort und Salt aufspalten
list($strPassword, $strSalt) = explode(':', $row->password);
// Falls kein Salt vorhanden, dann erzeugen
if (!strlen($strSalt))
{
$strSalt = substr(md5(uniqid('', true)), 0, 23);
}
// SHA1-Hash aus Salt+neuem Passwort berechnen, Salt anhängen
$pwd = sha1($strSalt . $var) . ':' . $strSalt;
// Das resetpassword-Feld löschen
$this->Database->prepare("UPDATE tl_gw_turnierpaare SET resetpassword='' WHERE id=?")
->executeUncached($dc->id);
return $pwd;
}
</pre>

Falls kein Passwort angegeben wurde, macht der ''save_callback'' garnichts, und gibt einen leeren String zurück.

Das Feld ''Id'' des DataContainers enthält die ''id'' des aktuellen Datensatzes in der Datenbank. Um den Hash berechnen zu können, benötige ich das "alte" Passwort in der Datenbank. Darum hole ich mir erstmal den gesamten Datensatz mit der ID ab.

Die Hash-Erzeugung habe ich mir beim File ''/system/libraries/User.php'' abgeschaut und funktioniert genauso wie in der Userverwaltung von TYPOlight: Der Hash wird zusammen mit einem "Salt" erzeugt, der zusammen mit dem Hash (durch Doppelpunkt getrennt) im ''password''-Feld abgespeichert wird. Existiert noch kein Salt, wird er erzeugt. Existiert der Salt schon, wird er weiterverwendet (und dafür muss ich das alte Passwort aus der Datenbank auslesen - um an den evtl. schon vorhandenen Salt zu kommen). Die Hash-Erzeugung läuft dann ziemlich straight-forward ab.

Und fast ganz am Ende nochmal der Knackpunkt: Hier setze ich das ''resetpassword''-Feld in der Datenbank auf ''.

Das (und leider nur das) sorgt in allen Fällen dafür, dass beim Öffnen von Datensätzen die Subpalette für das ''password''-Feld geschlossen ist.

Abschließend gebe ich den berechneten Hash zurück. Er wird dann in die Datenbank eingetragen.

Wichtiger Hinweis noch: ''load_callback'' und ''save_callback'' müssen doppelt geschachtelte Arrays sein, weil es mehrere Callbacks geben kann, die nacheinander aufgerufen werden, der Feldwert wird jeweils durch alle durchgeschleust. Falls man aber z.B. einen ''onSubmitCallback'' für das ganze Formular vorgeben möchte, ist das nur ein einfaches Array mit Klassennamen und Methodenname, weil es hier nur einen Callback gibt. Das ist so leider in der Referenz der möglichen Callbacks nicht dokumentiert, und hat mir kurz graue Haare beschert.

Damit ist das Backend-Modul für die Turnierpaar-Tabelle erstmal fertig.

Weiter wird es dann (endlich) mit dem Frontendmodul für die Turnierpaarliste gehen.

@@ Zeile 64: / Zeile 64: @@
 Das werde ich gleich für das Aktivieren einer Subpalette benötigen. Der Inhalt des Feldes in der Datenbank wird später nicht gebraucht, aber leider muss das Feld vorhanden sein, um es so nutzen zu können, wie ich es vorhabe.
-Für das ''password''-Feld habe ich ich vor, dass ein dort eingegebenes Passwort SHA1-gehasht in der Datenbank abgelegt wird, nicht im Klartext. Dabei wird ein eventuell schon vorhandes Passwort natürlich überschrieben.
+Für das ''password''-Feld habe ich ich vor, dass ein dort eingegebenes Passwort SHA1-gehasht in der Datenbank abgelegt wird, nicht im Klartext. Dabei wird ein eventuell schon vorhandenes Passwort natürlich überschrieben.
 Um Fehleingaben zu verhindern, möchte ich eine Checkbox anzeigen, die defaultmäßig "aus" ist. Erst wenn die Checkbox aktiviert ist, soll per AJAX das Passwortfeld angezeigt werden.
-Zunächst fügen die wir Definition für das Checkbox-Feld in die ''field''-Sektion des DCA-Records ein:
+Zunächst fügen wir die Definition für das Checkbox-Feld in die ''field''-Sektion des DCA-Records ein:
 PHP-Code:
@@ Zeile 82: / Zeile 82: @@
 </pre>
-''submitOnChange'' bewirkt, dass das Formular neu geladen wird, wenn das Feld angeklickt wird. nur dann wird das Passwortfeld nachgeladen.
+''submitOnChange'' bewirkt, dass das Formular neu geladen wird, wenn das Feld angeklickt wird; nur dann wird das Passwortfeld nachgeladen.
 Dafür benötigen wir eine sogenannte "Subpalette". Die Checkbox (bei mir "resetpassword") muss als "__selector__" angegeben werden im DCA-Record:
@@ Zeile 119: / Zeile 119: @@
 Dies bedeutet, dass das Feld ''password'' in die Subpalette ''resetpassword'' eingeblendet wird, wenn ''resetpassword'' aktiviert ist. Wird es deaktiviert, verschwindet die Subpalette wieder.
-[[Datei:Attachment_016.png]]
+[[Datei:Attachment_016.png|Passwort Checkbox]]
-[[Datei:Attachment_017.png]]
+[[Datei:Attachment_017.png|Passwort neu eingeben]]
 Die Texte hierzu wurden in den Sprachfiles entsprechend erweitert und angepasst.
@@ Zeile 188: / Zeile 188: @@
 </pre>
-Das Gerüst habe ich mir bei anderen Extensions abgeschaut, es scheint zumindest klug zu sein, von ''Backend'' zu erben, und den Konstruktur zu überschreiben. Vielleicht ist es auch nicht nötig, ich habe es nicht probiert. Ob der ''load_callback'' Parameter übergeben bekommt, weiss ich nicht, aber ich benötige keinen Parameter.
+Das Gerüst habe ich mir bei anderen Extensions ab geschaut, es scheint zumindest klug zu sein, von ''Backend'' zu erben, und den Konstruktur zu überschreiben. Vielleicht ist es auch nicht nötig, ich habe es nicht probiert. Ob der ''load_callback'' Parameter übergeben bekommt, weiß ich nicht, aber ich benötige keinen Parameter.
 Der ''save_callback'' erhält den Wert des Feldes, das gespeichert werden soll ($var), und den DataContainer ($dc), der zu dem Formular gehört. Meist (wie auch hier) ist es DC_Table, der DataContainer für Datenbanktabellen.
@@ Zeile 244: / Zeile 244: @@
 Abschließend gebe ich den berechneten Hash zurück. Er wird dann in die Datenbank eingetragen.
-Wichtiger Hinweis noch: ''load_callback'' und ''save_callback'' müssen doppelt geschachtelte Arrays sein, weil es mehrere Callbacks geben kann, die nacheinander aufgerufen werden, der Feldwert wird jeweils durch alle durchgeschleust. Falls man aber z.B. einen ''onSubmitCallback'' für das ganze Formular vorgeben möchte, ist das nur ein einfaches Array mit Klassennamen und Methodenname, weil es hier nur einen Callback gibt. Das ist so leider in der Referenz der möglichen Callbacks nicht dokumentiert, und hat mir kurz graue Haare beschert.
+Wichtiger Hinweis noch: ''load_callback'' und ''save_callback'' müssen doppelt geschachtelte Arrays sein, weil es mehrere Callbacks geben kann, die nacheinander aufgerufen werden. Der Feldwert wird jeweils durch alle durchgeschleust. Falls man aber z.B. einen ''onSubmitCallback'' für das ganze Formular vorgeben möchte, ist das nur ein einfaches Array mit Klassennamen und Methodenname, weil es hier nur einen Callback gibt. Das ist so leider in der Referenz der möglichen Callbacks nicht dokumentiert, und hat mir kurz graue Haare beschert.
 Damit ist das Backend-Modul für die Turnierpaar-Tabelle erstmal fertig.
 Weiter wird es dann (endlich) mit dem Frontendmodul für die Turnierpaarliste gehen.

← Nächstältere Version	Version vom 8. Juli 2010, 22:57 Uhr
(kein Unterschied)