In der neuen TYPO3 Version werden die Formulare mit einem neuen Formularwizard erstellt. Im Vergleich zum alten Wizard kann man Felder mit Drag-and-Drop hinzufügen und diese mit Validierungsregeln überprüfen lassen, Felder in Fieldsets gruppieren und das Formular nicht nur per Mail verschicken, sondern mit eigenen Post-Prozessoren die Daten in die Datenbank speichern.
Im Frontend gefallen mir die neuen Formulare viel besser als die vom alten Wizard. Zum einen sind wir alle diese leidige Feld-Validierung mit JavaScript los, die mit einem alert etwas penetrant darauf hingewiesen hat, dass Felder nicht ausgefüllt sind. Zum zweiten kann man die Felder endlich gruppieren und dadurch das Formular evtl. individueller gestalten als vorher.
Leider ist der Wizard so neu, dass es dafür noch keine deutsche Übersetzung gibt. Zumindest habe ich keine gefunden. Und es gab noch keine Forumsbeiträge zu dem Thema. Ich hatte bei schlauen Leute nachgefragt, ob ich denn etwas übersehen hätte, aber sie hatten mir auch nur geraten, es so zu machen, wie ich es schon vorhatte: Die Übersetzung selbst im typo3conf/l10n Ordner einpflegen.
Die Übersetzungen mancher (vor allem neueren) Extensions befinden sich in Dateien, die im Order typo3conf/l10n gespeichert sind. Für jede Sprache und für jede Extension, zu der eine Übersetzung vorliegt, wird in diesem Ordner die folgende Struktur angelegt:
typo3conf/l10n/[sprache]/[extension]. So dass die Übersetzung für die Formularextension (alias der neue Form Wizard) in typo3conf/ext/de/form liegen müsste, dieser Ordner existiert aber nicht.
Und so übersetzt man selbst in freudiger Erwartung die Extension form wie folgt: Eine existierende Sprache für die Form-Extension aus dem TER laden (z.B. französisch). Dann den Ordner form aus typo3conf/ext/l10n/fr/ kopieren und in typo3ext/l10n/de einfügen. Im Ordner form navigiert man zu Resources/Private/Language und benennt die Dateien dort um, so dass sie mit de. anstatt fr. beginnen. Zum Testen kann man den Form-Wizard aufrufen und feststellen, dass alles auf französisch ist. Und dann kann man die Texte übersetzen. Die XML-Dateien sind die alte Art Extensions zu übersetzen, die XLF-Dateien die neue, die anscheinend bevorzugt wird. Daher die XML-Dateien ignorieren und nur die Labels in den XLF-Dateien anpassen.

<trans-unit id="title" xml:space="preserve" approved="yes">
    <source>Form Wizard</source>
<target state="translated">HIER DIE DEUTSCHE ÜBERSETZUNG REIN</target></trans-unit>

Ich bin nicht wirklich zufrieden mit dieser Übersetzungsmöglichkeit. Ein Update und die ganzen eingepflegten Texte sind hin, sie werden dann mit den Übersetzungen aus dem Repository überschrieben. Vielleicht gibt es ja eine Möglichkeit, die Texte per TypoScript zu setzen mit _LOCAL_LANG? Werde das mal weiter untersuchen.

Um im TemplataVoila für definierte Content Bereiche ein Layout in Backend zu definieren, gibt es zwei Möglichkeit. Die erste ist, das Layout im XML im DataStructure-Datensatz zu hinterlegen. Die zweite ist eine separate HTML-Datei, die die Layout-Information fürs Backend enthält. Variante eins ist dann sinnvoll, wenn jedes Data Structure nur einmal verwendet wird, außerdem spart man sich Dateien. Variante zwei ist dann sinnvoll, wenn die gleiche Data Structure mit unterschiedlichen Template Objects verwendet werden soll. In beiden Fällen muss man beachten, dass sich nur Inhaltscontainer layouten lassen (was schade ist).
Layout innerhalb der Data Structure:

<meta type="array">
	<langDisable>1</langDisable>
	<beLayout><![CDATA[
		<table border="0" cellpadding="2" cellspacing="2" width="100%">
			<tr>
				<td valign="top" width="65%">###field_column1###</td>
				<td valign="top" width="35%">###field_column2###</td>
			</tr>
		</table>
	]]></beLayout>
</meta>

Im Tag meta wird ein Tag beLayout definiert (Schreibweise beachten) und darin mit old school HTML (also Tabellen) das Layout im Backend definiert.
Layout innerhalb einer separaten Datei:

<table border="0" cellpadding="2" cellspacing="2" width="100%">
	<tr>
		<td valign="top" width="64%">###field_column1###</td>
		<td valign="top" width="34%">###field_column2###</td>
	</tr>
</table>

Es reicht aus, wenn die Datei nur das Layout enthält – keine zusätzlichen Tags. Dann speichert man es in eine HTML-Datei und wählt diese Datei im Feld BE Layout Template File im Template Object aus.

Die Überschriften in TYPO3 umzubenennen, so dass die Bezeichnungen für den Redakteur sprechender sind, ist recht einfach. Dazu braucht man folgenden Schnipsel im User oder Page-TS Config:

TCEFORM.tt_content.header_layout {
	altLabels.1 = H1: groß und blau
	altLabels.2 = H2: groß und schwarz
	altLabels.3 = H3: mittel und blau
	altLabels.4 = H4: mittel und grau
}

Natürlich wäre es schön, wenn die Überschriften im RTE auch die entsprechenden Bezeichnungen hätten, dazu einfach folgendes in die RTE Konfiguration rein und schon klappts (allerdings seit TYPO3 4.3).

RTE.default {
...
	buttons.formatblock.items {
		h1.label = H1: groß und blau
		h2.label = H2: groß und schwarz
		h3.label = H3: mittel und blau
		h4.label = H4: mittel und grau
	}
...

Wenn man eine ältere Version von tt_news installiert hat (z.B. 3.0.1) und dann auf TYPO3 Version 4.6. aktualisiert, dann werden keine News mehr angezeigt, es gibt keine Fehlermeldung, an der Stelle erscheint einfach keine Ausgabe. Zunächst habe ich selbst herausgefunden, dass das Plugin nicht mehr registriert wird in tt_content.list.20.9. Dann habe ich einen Forenthread gefunden zu dem Thema im typo3forum. Es hat geholfen, die neueste tt_news Version zu installieren.

Bisher hatte ich wenig Probleme TYPO3 auf Localhost schnell zu installieren. Gerade die neue Version 4.5.6 runtergeladen, ausgepackt und Fehlermeldung im Installtool – Modul openssl in PHP fehlt. Ich habe kurz in Google geschaut, aber keine genaue Fehlerbeschreibung gefunden.
Im Verzeichnis xampp/php/ liegen mehrere Konfigurationsdateien, in der php.ini-development findet sich der auskommentierte Verweis auf das fehlende Modul. In der php.ini hingegen nicht, das hat mich am Anfang ein bisschen verwirrt. Daher in der php.ini-development nach openssl suchen, die Zeile kopieren. In der php.ini nach der Windows-Extension-Liste suchen und dort diese Zeile reinkopieren und Kommentar entfernen (Kommentar ist ; am Anfang der Zeile)

;extension=php_openssl.dll

Über einer Navigation in der linken Spalte soll der Titel der übergeordneten Seite aus Level 1 dargestellt werden. Da im Web keine Silbentrennung existiert, habe ich mir gedacht, dass das Wort inklusive Silbentrennung in den subtitle geschrieben wird. Wenn das Feld subtitle befüllt ist, dann soll statt titel der Inhalt von subtitle ausgegeben werden. Hier ist mein TypoScript:

lib.navigation.sub = COA
lib.navigation.sub.10 = TEXT
lib.navigation.sub.10 {
	data = levelfield: 1, title
	wrap = <h3>|</h3>
	override.required = 1
	override.data = levelfield: 1, subtitle
}

Normalerweise inkludiert TYPO3 die JavaScript-Dateien in der Reihenfolge: zunächst was in den Extensions hinzugefügt wird, dann das was in page.includeJS definiert wurde und dann das, was über page.headerData hinzugefügt wurde. Man kann jedoch einzelne Dateien ganz an den Anfang dieser Kette setzen mit forceOnTop.

page.includeJS {
	jquery = fileadmin/path/to/jquery-1.6.2.min.js
	jquery.forceOnTop = 1
}

Ich hatte die letzten zwei Mal schwierigkeiten die neueste TYPO3 Version 4.5.x auf Localhost (XAMPP) zu installieren. In XAMPP ist der Datenbank-User, der bereits eingerichtet ist root ohne Passwort. Solange man lokal arbeitet ist es ja auch in Ordnung. Im Install-Tool kann man das Feld Passwort nicht einfach frei lassen, da es erforderlich ist. Also überspringe ich den 1-2-3-Modus und will die Datenbankzugangsdaten selbst in localconf.php eingeben. Das funktioniert aber auch nicht – TYPO3 Install Tool meldet noch immer “Keine Verbindung zur Datenbank”. Ich versuche einen neuen Datenbank-Benutzer über phpMyAdmin anzulegen – mit Passwort – und trage die Daten dann in localconf.php ein. Immer noch kein Erfolg. Nachdem ich schließlich den Datenbank-Namen in die Konfigurationsdatei geschrieben habe und eine Fehlermeldung auftauchte “ADONewConnection: Unable to load database driver”, hatte ich zumindest eine Fehlermeldung, nach der ich Suchen konnte.

Meine Recherche ergab, dass die Fehlermeldung auftaucht, wenn die Extensions adodb und dbal installiert sind, aber nicht korrekt konfiguriert sind (Quelle jweiland.net). Da es aber eine ganz neue TYPO3 Installation ist, konnte ich noch keine Extensions manuell aktivieren, also ist das wohl die Standardkonfiguration. Um die Extensions zu deaktivieren, habe ich in der localconf.php in der Extension Liste (extList) den Eintrag dbal entfernt. Und siehe da, es funktioniert sofort und die Verbindung zur Datenbank steht.

(attach object errors to a specific field)

Es gibt die Möglichkeit in Extbase Validatoren für Objekte zu definieren. Wenn man also ein Model mit dem Namen “Domain_Model_ObjectModel” hat, wird falls vorhanden der Validator mit dem Namen “Domain_Validator_ObjectValidator”. Dabei wird nachdem die einzelnen Felder geprüft wurden mit dem angegebenen Validator das komplette Objekt überprüft. So kann man wie in meinem Beispiel feststellen, ob der Titel bereits vergeben worden ist (Unique). Normalweise wird die Fehlermeldung bei einer nicht erfolgreichen Validierung an das Objekt drangehängt. Da ich die Fehlermeldungen neben dem Feld ausgebe (siehe dazu Fehlermeldung mit Fluid direkt neben dem Feld ausgeben), wollte ich den Fehler an das Attribut title dranhängen.

class Tx_MyExtension_Domain_Validator_ObjectValidator 
	extends Tx_Extbase_Validation_Validator_AbstractValidator
{
 
    /**
     * Check if there is a object with the same name
     * @param  Tx_MyExtension_Domain_Model_Object $object
     * @return bool
     */
	public function isValid($object) {
		$objectRepository = t3lib_div::makeInstance('Tx_MyExtension_Domain_Repository_ObjectRepository');
		$sameNameCount = $objectRepository->countByTitleExcludeUid($object->getTitle(), $object->getUid());
		if($sameNameCount > 0) {
			if (!isset($this->errors['title'])) {
				$this->errors['title'] = new Tx_Extbase_Validation_PropertyError('title');
			}
			$error = new Tx_Extbase_Validation_Error(Tx_Extbase_Utility_Localization::translate('error.object_title_exists', 'MyExtension'), '1312448731');
			$this->errors['title']->addErrors(array($error));
			return FALSE;
		}
		return TRUE;
    }
 
}

Leider kann der Fluid-ViewHelper keine Strings vergleichen. Ich habe ein wenig recherchiert und Lösungen gefunden.

Die erste ist ein eigener View Helper, der in der Lage ist, zwei Objekte (Strings z.B.) zu vergleichen.

<?php
 
class Tx_MyExt_ViewHelpers_CompareViewHelper extends Tx_Fluid_Core_ViewHelper_AbstractViewHelper {
 
    /**
     * Returns true if $a and $b are type-equal, false otherwise.
     *
     * @param mixed $a
     * @param mixed $b
     * @return boolean
     */
    public function render($a, $b) {
        return $a === $b;
    }
}
 
?>

Dann soll es laut dem Eintrag so funktionieren:

<f:if condition="{myext:compare(a: 'foo', b: 'bar')}">
  <f:then>...</f:then>
  <f:else>...</f:else>
</f:if>

Leider hat es bei mir nicht funktioniert.

Aber der Vorschlag zwei hat hingegen funktioniert. Es wird mit Fluid ein Alias für den zu vergleichenden String defininiert und dann verglichen:

<f:alias map="{foobar: 'myString'}">
<f:if condition="{object.property} ==  {foobar}"><!-- do something --></f:if>
</f:alias>