Dadurch ist es möglich einen Teaserport direkt per Typoscript einzubinden und zum Beispiel einem Marker zuzuweisen. Außerdem kann man mit dieser praktischen Extension jede beliebige Tabelle auslesen!

Einbindung über Typoscript

Nach der Installation steht im Typoscript das Objekt plugin.tx_kiwiteaser_pi1 bereit. Das kann einem Marker zugewiesen werden und über die Eigenschaften content und ports mit Inhalt befüllt werden.

page.10.marks.CONTENT < plugin.tx_kiwiteaser_pi1

page.10.marks.CONTENT {

  content = pages_21, tt_content_123, pages_22, tx_kiwiteaser_content_2

  ports = 4

}

Und zack findet sich im Frontend statt ###CONTENT### ein cooler Kiwi Teaser mit vier Slots und den ausgelesenen Datensätzen, angegeben in content. Das Format ist simpel: Name der Datenbank - Unterstrich - UID des Datensatzes. Extra angelegten Teaserinhalte befinden sich in der Datenbank tx_kiwiteaser_content.

Ansprechen von beliebigen Datenbanken

Wenn man die Inhalte einfach per Typoscript beschreibt, lässt sich natürlich jede beliebige Datenbank ansprechen. Ja, das funktioniert! Damit die Extension weiß, welche Spalten sie auslesen soll, muss man diese per Typoscript bekannt geben. Zum Beispiel könnte man die besten Frontend Benutzer teasern:

plugin.tx_kiwiteaser_pi1 {

tables.fe_users {

  title = name

  content = address

  image = image

}

}

Das Format sollte eigentlich selbsterklärend werden. Der Inhalt aus der Spalte name landet im Marker ###TITLE### usw. Anschließend muss der Datensatz nur noch dem Teaser zugewiesen werden. Dem Beispiel von oben folgend so:

page.10.marks.CONTENT.content = fe_users_1, fe_users_3, pages_12, tt_content_21

Nett, oder?

Mehr Komfort für Redakteure

Um weitere Tabellen im Teaser zu erlauben, und diese vorallem im Backend auszuwählen muss man im Moment leider noch hart an den Quelltext ran. In der Datei typo3conf/ext/kiwi_teaser/ext_tables.php wird im Array $tempColumns ab Zeile 33 das Feld tx_kiwiteaser_teasers als Datenbankrelationsfeld definiert. In Zeile 41 werden unter dem Schlüssel allowed alle erlaubten Datenbanknamen aufgezählt. Um den Redakteuren die Auswahl von Benutzern zu erlauben, muss der Eintrag erweitert werden:

$tempColumns['tx_kiwiteaser_teasers']['allowed'] = 'tx_kiwiteaser_content,pages,tt_content,fe_users';

Ausblick und Weiterentwicklung

Der aufmerksame Betrachter wird die auskommentierte Zeile 40 bemerken, in der tt_news noch erlaubt war. Daran arbeiten wir im Moment. Verbessert werden muss die Verlinkung auf ausgewählte Inhalte.

Außerdem auf der Liste steht eine dynamische Darstellung von Teaserinhalten. Das bedeutet zum Beispiel das auslesen aller Seiten ab einem Einstiegspunkt, oder die Angabe von verschiedenen Bedingungen.

Wer diese Funktionen für sein Projekt gut gebrauchen kann oder mehr Ideen hat, ist natürlich herzlich eingeladen mit uns darüber zu reden.

Aber damit ist jetzt Schluss! Die neue Version legt ihre Container unabhängig von den Rahmen um den Inhalt. Zeitnah im Repository verfügbar. Auf meiner privaten Seite gibt es eine Demonstration und im folgenden Eintrag ein paar technische Erklärungen.

Für Redakteure

Die Funktionsweise für Redakteure ist sehr einfach. Über die Seiteneigenschaften lässt sich bestimmen, ob mehrere Panels gleichzeitig offen sein dürfen.

Jedes Inhaltselement wiederum hat zwei Eigenschaften, Aufklappbar und Offen.

Die erste Option initalisiert den Effekt, die zweite öffnet das Inhaltselement beim laden der Seite. Das wars! Eine Beispiel gibt es auf meiner privaten Seite.

Für Techniker

Der kleinere Teil der Arbeit wird vom mitgelieferten Typoscript übernommen. Über die Eigenschaft tt_content.stdWrap.innerWrap.prepend und append wird ein DIV Container um den Inhalt gelegt (div.ka-panel) und je nach gewählten Eigenschaften die Klasse open oder close hinzugefügt.

In Version 4.3 hat sich dieser Teil grundlegend geändert. Inhaltselemente werden jetzt immer innerhalb eines DIV Containers ausgegeben was ich wesentlich besser finde als die nervigen Links ala <a href="#c123"></a>. Das hat leider zur Folge, dass in älteren Versionen der tt_content.stdWrap.innerWrap nur ausgeführt wird, wenn ein Rahmen ausgewählt wurde. Um das zu verhindern fügt die Extension einen Standardwert hinzu, damit die Eigenschaft aufjedenfall greift. Möglich wird das über die Abfrage der eingestellten TYPO3 Version.

[compatVersion < 4.3]

tt_content.stdWrap.innerWrap.cObject.default = TEXT

tt_content.stdWrap.innerWrap.cObject.default.value = |

[end]

Der größere Teil der Arbeit erfolgt als jQuery Script. Das Kiwi Accordion arbeitet mit jQuery, bringt das Framework aber selbst nicht mit. Ich bin bei der Entwicklung davon ausgegangen, dass es in jedem Projekt integriert ist.

Im Script wird jeder Container mit der Klasse ka-panel untersucht und für die weitere Verwendung angepasst. Dabei wird mit $(':header:first', '.ka-panel') die erste Überschrift gesucht und als Handler benutzt. Alle Elemente nach der Überschrift werden mit einem Container umschlossen (div.ka-content) und bei Klick ein- oder ausgeblendet.

Bei Mauskontakt erhält das Panel zusätzlich die Klasse hover, damit lassen sich dann Pfeile anzeigen oder Farben ändern, je nach Vorgabe.

Wenn bei der Initialisierung etwas nicht funktioniert, gibt die Extension ein paar Hinweise in der Firebug Konsole aus. Ich hoffe das hilft weiter. Ansonsten sei auf die Demo auf meiner Seite verwiesen.

Getestet hab ich die Extension mit TYPO3 Version 4.3, 4.3.1 und 4.2.6. Über weitere Kompatibilitätshinweise, Fragen und Anregungen freue ich mich natürlich sehr.

• Kiwi Accordion im TYPO3 Repository
• Kiwi Accordion 1.6.0
• Demonstration auf paul-lunow.de

Danke für die ganzen Mails und die netten Worte! Frohes rumklappen.

Die Teaser sind entweder Teaserdatensätze (mit Titel, Inhalt, Bild und Link), ganze Seiten oder einzelne Inhaltselemente. Fertig! Auf der Startseite kann der Redakteur jetzt ganz genau bestimmen, auf welche Inhalte die Benutzer aufmerksam gemacht werden sollen und in welcher Reihenfolge.

Die Extension gibts im TYPO3 Repository oder auf GitHub - live im Einsatz bisher auf unserer Firmenpräsenz.

Berechtigung

Es liegt natürlich nahe tt_news einzusetzen. Aber erst sagt der Redakteur mir, ich soll das Datum ausblenden, denn regelmäßige News gibt es  gar nicht. Als nächstes will er die Reihenfolge ändern und ich sage, pass doch einfach das Datum entsprechend der Reihenfolge an. Klar, das geht aber so richtig genial ist das nicht.

Zumal die meisten Hinweise sich auf entsprechende Seiten in der Präsenz beziehen, auf externe Links oder einfach nur einen kurzen Hinweis darstellen. Das geht jetzt eleganter.

Inhalte

Es können verschiedene Inhalte vorgestellt werden. Die Extension bringt eigene Datensätze mit welche Titel, Inhalt, Bild und einen Link aufnehmen. Es können aber auch Seiten oder Seiteninhalte angeteast werden.

Installation

Entweder man holt sich die stabile Version aus dem Repository oder die aktuellste, brandheiße aus meinem ersten Projekt auf GitHub. Ein großartiges Portal!

Die restliche Installation ist alt bekannt und ganz normal. Der Kiwi Teaser bindet standardmäßig jQuery ins Projekt ein um ein paar coole Extras zu ermöglichen.

Konfiguration

Über Typoscript hat man viele Einstellungsmöglichkeiten. Alles natürlich unter plugin.tx_kiwiteaser_pi1 im Template - das schreibe ich jetzt nicht jedesmal mit auf. Die angegebenen Typoscriptschnipsel stellen jeweils die Standardeinstellung dar.

include.css.standard = 1

Mit dieser Anweisung wird ein minimales Stylesheet geladen welches dafür sorgt das die Boxen nebeneinander stehen und einen Abstand zueinander haben.

include.javascript.jquery = 1

Bindet die aktuelle jQuery Version ein. Hat man diese schon im Projekt sollte man diese Eigenschaft unbedingt mit include.javascript.jquery > löschen (auf diese Art kann man jeden include verhindern).

include.javascript.clickbox = 1

Holt mein Plugin Clickbox ins Projekt, welches die komplette Teaserbox klickbar macht und nicht nur den kleinen Link. Mehr zur Clickbox gibts hier.

include.javascript.height = 1

Bindet ein Script ein, welches dafür sorgt das alle Teaserboxen die gleiche Höhe haben. Besonders praktisch wenn man einen Rahmen oder eine Hintergrundfarbe gesetzt hat.

template.file = EXT:kiwi_teaser/res/html/template.html

Der Pfad zum HTML Template. Das Standardtemplate sollte man sich unbedingt angucken und die Klassennamen beibehalten, denn sonst kriegen die oben erwähnten Scripte Schwierigkeiten.

stdWrap

Der StandardWrap ist eine richtig schöne Sache! Damit kann man jeden Inhalt mit Typoscript bearbeiten bevor er ausgegeben wird. Dieser kann auf alle Felder angewendet werden: title, image, link und content. Zum Beispiel:

stdWrap.title.wrap = <b>|</b>

Außerdem kann man für verschiedene Quellen verschiedene Optionen angeben. Seiten kommen aus der Tabelle pages, Seiteninhalte aus tt_content und die Standardinhalte aus tx_kiwiteaser_content. Mit diesem Wissen kann man die Ausgabe je nach Datenbank bestimmen. Möchte man also die Überschriften von Seiten nicht fett sondern kursiv darstellen, reicht folgende Anweisung:

stdWrap.title.pages.wrap = <i>|</i>

Besonders wichtig ist diese Möglichkeit für den Linktext. Dieser wird über die Eigenschaft link.value gesetzt.

stdWrap.link.value = Mehr...

Die Extension setzt den generierten oder angegebenen Wert vor der Verarbeitung in das Feld stdWrap.link.typolink.parameter. Das typolink Objekt lässt sich natürlich trotzdem noch erweitern. Will man alle Teaserlinks in einem neuen Fenster öffnen geht das ganz einfach:

stdWrap.link.typolink.target = _blank

Mapping der Inhalte

Um zu entscheiden, welche Daten aus einem Datensatz den Titel und welche z.B. den Inhalt darstellen, gibt es eine Mappingtabelle im Typoscript. In der Standardkonfiguration wird der Untertitel einer Seite als Inhalt benutzt. Das passiert über folgende Angabe:

tables.pages.content = subtitle

Dabei bezeichnet der Schlüssel das Feld im Teaser und der Wert das Feld in der Zieltabelle. Das lässt sich je nach Anforderung beliebig anpassen. Wenn die Eigenschaft link leer ist, erzeugt die Extension den Link je nach Tabelle automatisch.

Template

Im Template stehen verschiedene Marker zur Verfügung:

• ###TITLE### Ein Beispieltitel
• ###IMAGE### uplodas/media/picture.jpg
• ###CONTENT### Das ist je nach eingabe verschieden.
• ###LINK### <a href="index.php?id=123">Mehr...</a>
• ###CLASS### teaser-first port1

Image beinhaltet den originalen Inhalt aus der Datenbank, also im Idealfall den Pfad zum Bild, sollte also noch mit einem <img> Tag gewrappt oder per Javascript weiter verarbeitet werden.

Link ist ein kompletter <a> Tag - generiert über Typoscript.

Class wird automatisch gesetzt, je nach Position des Teasers steht da first-teaser oder last-teaser drin. Außerdem kriegt jeder Teaser die Klasse portX wobei das X für die aktuelle Position steht. So kann man also den zweiten Teaser gezielt ansprechen:

.tx-kiwiteaser-pi1 .port2 {

  font-size:200%;

}

Alpha

Heute, am 17.12.2009 habe ich die erste Version fertig gestellt und in meinem Projekt eingesetzt. Als nächstes wird sie in Kundenprojekt eingesetzt und die Redakteure darauf losgelassen. Dabei werde ich sicher noch die eine oder andere Erweiterung entwickeln, mit mehreren Updates ist also zu rechnen. Auf dem neusten Stand ist man natürlich bei Twitter.

Ausblick

Der wichtigeste Punkt auf meiner Liste ist die Unterstützung von tt_news. Damit ist es dann auch möglich eine schön ausgearbeitete Nachricht zu teasern. Natürlich muss sich das nicht auf tt_news beschränken, sondern kann im Prinzip jeden beliebigen Datensatz beinhalten!

Darüber hinaus sind die Pläne natürlich groß und die Möglichkeiten auch. Ich denke an jQuery Effekte wie das faden von Inhalten, die Integration vom Kiwi Slider oder das dynamische Anpassen der Inhalte.

Da wird noch einiges passieren!

Fazit

Ich möchte kein zweites tt_news programmieren, hier geht es wirklich nur um das Teasern von eigenen und fremden Inhalten. So bequem und einfach für die Redakteure wie möglich.

Ich hoffe ihr könnt die Extension gut einsetzen - über Ideen, Fragen und Anregungen in den Kommentaren freue ich mich natürlich. Und wenn jemand per GitHub mitarbeiten möchte, ist er hiermit herzlich eingeladen.

Ganz unauffällig sei auch noch auf meine Firma hingewiesen - wenn du die Extension oder ähnliches für dein Projekt brauchst, aber nicht selbst programmieren möchtest oder kannst, dann ist der Kiwi Service ein verantwortungsbewusster und kompetenter Partner!

Wenn dir der Artikel gefällt und du mit uns zusammen mehr solche Lösungen entwickeln möchtest, an das Internet und OpenSource glaubst und einen Job in Berlin suchst, dann bewirb dich bei uns. Wir suchen neue Freunde!

Danke fürs lesen, und fröhliches teasen!

Dieses Tutorial bezieht sich auf TYPO3 Version 4.3, aber ich vermute es funktioniert in allen neueren Versionen. Los gehts!

Vorbereitungen

Eine aktuelle TYPO3 Installation mit benötigten Extensions (RealURL vorallem) und ein paar Domains die alle in das gleiche Verzeichnis zeigen. Das reicht.

Die Seitenstruktur

Direkt unter die Weltkugel kommt die Root Seite. Diese beinhaltet ein grundlegendes Typoscript, dass sich alle Domains teilen. Es lohnt sich ein einfaches Layout aufzubauen und alle benötigten Marker anzulegen, dann kann man später schnell etwas zeigen. Auch tt_news, mailformplus, kiwi_slider oder was auch immer kann man hier schonmal gut Vorkonfigurieren.

Unter Root kriegt jede Domain eine eigene Seite. Die besitzen folgende Eigenschaften:

• Typ: Verweis - auf erste Unterseite
• Im Menü verbergen
• Seitentitel wie die Domain
• Nicht in sprechende URL aufnehmen

Jeder Seite müssen über Liste > Neuer Datensatz > System Records > Domäne die entsprechenden Domains zugewiesen werden. Am besten man legt als erstes die Hauptdomain an, zum Beispiel www.kiwi-service.de - ohne Umleitung.

Ein zweiter Datensatz kriegt dann die Domäne kiwi-service.de mit Umleitung auf www.kiwi-service.de. Die Checkbox Parameter zur Umleitungs-URL übertragen sollte man anschalten und speichern.

Typoscript

Auf der Root Seite lohnt es sich ein fertiges Template aufzubauen. Die wichtigesten Marker, wie Menü, Inhalt und Sidebar empfehle ich als COA Elemente anzulegen, wobei der Hauptinhalt immer auf Ebene 50 eingebunden wird. Damit kann man auf den Unterseiten einfach die Marker erweitern.

Über Konstanten lässt sich sehr viel steuern. Zum Beispiel die Start ID für das Menü. Dazu legt man in den Konstanten einen beliebigen Namen fest:

menu.special.value = 123

Im Typoscript kann man auf diese Eigenschaften dann über die Syntax {$NAME} zugreifen. Vereinfacht könnte das dann so aussehen:

MENU = COA

MENU.50 = TMENU

MENU.50.special.value = {$menu.special.value}

Mit diesem Vorgehen kann dann jede Seite grundlegend über Konstanten steuern. Man sollte es aber nicht übertreiben. Ideal sind die Grundeinstellungen damit man etwas sieht und klicken kann, alle Strukur- und Layoutanpassungen passieren dann gezielt im Extensiontemplate der Seite.

Am wichtigesten ist die Bekanntmachung der BaseURL. Entweder über Konstanten oder direkt im Template:

config.baseURL = http://www.kiwi-service.de

RealURL

Jetzt zum schönsten Teil (leichte Ironie), damit man sich über die netten Domains freuen kann: RealURL. Installiert, ohne automatische Konfiguration ist die wichtigste Aufgabe, für jede Domain die richtige rootpage_id zu setzen.

Um sowenig wie möglich doppelt zu schreiben, legt man dafür als erstes eine Standardkonfiguration an:

$tx_realurl_config = array(

'init' => array(

'enableCHashCache' => true,

'appendMissingSlash' => 'ifNotFile',

'enableUrlDecodeCache' => true,

'enableUrlEncodeCache' => true,

'emptyUrlReturnValue' => '/',

),

'preVars' => array(),

'postVarSets' => array(

'_DEFAULT' => array(),

),

'pagePath' => array(

'type' => 'user',

'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main',

'spaceCharacter' => '_',

'languageGetVar' => 'L',

'expireDays' => 3,

),

);

Die ist für alle gleich und sollte auch Konfigurationen für tt_news und andere Extensions beinhalten. Diese wird jetzt jeder Hauptdomain zugewiesen.

$TYPO3_CONF_VARS['EXTCONF']['realurl'] = array(

  'www.alexandrepeschel.de' => $tx_realurl_config,

  'www.kiwi-service.de' => $tx_realurl_config,

);

Die Aufrufe ohne www kann man vernachlässigen, weil TYPO3 sie weiterleitet. Als nächstes wird für jede Domain die UID der entsprechenden TYPO3 Einstiegsseite angegeben. Damit versteht RealURL dann, welcher Teil des Seitenbaums zu welcher Domain gehört.

$TYPO3_CONF_VARS['EXTCONF']['realurl']['www.kiwi-service.de']['pagePath']['rootpage_id'] = 12;

$TYPO3_CONF_VARS['EXTCONF']['realurl']['www.alexandrepeschel.de']['pagePath']['rootpage_id'] = 34;

Beim rumprobieren sollte man daran denken, dass man mit dem Leeren vom Frontend-Cache nicht den RealURL-Cache löscht! Das passiert über Info > Root Seite > RealURL-Verwaltung. Da sind sehr interessante Informationen drin versteckt!

Fazit

Das war schnell und effektiv! Wer sich das in Aktion ansehen will, geht auf unsere neue Firmenseite www.kiwi-service.de und auf www.alexandrepeschel.de, die Seite meines lieben Kollegen. Im Moment ist das zum Teil im Aufbau und demnächst wird meine persönliche Seite auch dahin umziehen. Aber erst wenn die Seite auf dem neuen Server liegt!

Wenn du Spaß an diesem Tutorial hattest, und Lust hast mit uns noch viel mehr geilen Scheiß zu entwickeln, dann bewirb dich bei uns! Wir suchen Webentwickler mit Ideen und Tatendrang!

Wenn aber das unbedingt nur von einer Lightbox kommt, dann sollte man sich kurz hinsetzen, einen geeigneten Klon aussuchen (hier ist die große Lightbox Matrix) und die Klickvergrößerung von TYPO3 damit ersetzen. Das ist schnell, effektiv und in diesem Beitrag erklärt.

Vorbereitungen

Für mein aktuelles Projekt habe ich mich für den Lightbox Clone TopUp entschieden. Sieht sehr vielversprechend aus. Also welcher Klone auch immer: Daten herunterladen und ins Projekt einbinden. Dazu gehören mind. jQuery und das entsprechende Plugin, in vielen Fällen auch noch eine CSS Datei. Firebug verrät im Script Reiter ob es funktioniert hat.

TopUp benötigt keine CSS Datei, dafür aber einen Bilder- und einen Players-Ordner in dem SWF Dateien gespeichert sind um verschiedene Medien wiederzugeben. Per JavaScript können die Pfade angepasst werden:

TopUp.host = 'http://www.kiwi-service.de/';

TopUp.images_path = 'fileadmin/template/img/topup/';

TopUp.players_path = 'fileadmin/template/flash/';

JavaScript einbinden

Eine Besonderheit bringt TopUp mit: Es lädt dynamisch die benötigten JavaScriptdateien nach. Dafür braucht er den kompletten javascripts/jquery Ordner. Dieser muss im gleichen Ordner liegen wie top_up-min.js.

fileadmin/template/js/top_up-min.js

fileadmin/template/js/jquery/...

Test

Alle benötigten Dateien sind eingebunden und in Firebug sichtbar. Um zu testen ob es funktioniert, füge ich ein Inhaltselement vom Typ HTML ein und schreibe mein eigenes Bild rein. Testbilder sind im Images Ordner vorhanden.

<a href="fileadmin/template/img/topup/photos/1.jpg" class="top_up">

  <img src="fileadmin/template/img/topup/thumbnails/1.jpg">

</a>

Funktioniert, wunderbar! Wenn nicht, dann die eigene Seite mit den Beispielen vergleichen.

Typoscript

Nun muss man TYPO3 noch das hässliche JavaScript PopUp austreiben. Hier mein Konfiguration für Version 4.3

temp.imageLinkWrap = 1

temp.imageLinkWrap {

enable = 1

typolink {

parameter.cObject = IMG_RESOURCE

parameter.cObject.file.import.data = TSFE:lastImageInfo|origFile

parameter.cObject.file.maxW = {$styles.content.imgtext.maxW}

parameter.override.listNum.stdWrap.data = register : IMAGE_NUM_CURRENT
title.field = imagecaption // title

title.split.token.char = 10

title.if.isTrue.field = imagecaption // header

title.split.token.char = 10

title.split.returnKey.data = register : IMAGE_NUM_CURRENT

parameter.cObject = IMG_RESOURCE

parameter.cObject.file.import.data = TSFE:lastImageInfo|origFile

ATagParams = target="_blank"

}

}
tt_content.image.20.1.imageLinkWrap >

tt_content.image.20.1.imageLinkWrap < temp.imageLinkWrap 

Als erstes wird das temporäre Objekt temp.imageLinkWrap erzeugt und konfiguriert. Interessant ist die letzte Angabe ATagParams - darüber gibt man jedem Link die Klasse top_up mit, damit das Plugin sich um die Bilder kümmert.

Anschließend wird die Standardvergrößerung in tt_content.image.20.1.imageLinkWrap überschrieben. Cache leeren und Seite neuladen, fertig!

TopUp Spezialitäten

Dieses TopUp ist wirklich ein schönes Teil. Mit der Funktion addPresets() lassen sich für Links in DOM Bereichen Voreinstellungen treffen. Zum Beispiel alle Bilder die über ein Inhaltselement eingestellt sind, zu einer Gruppe zusammenfassen:

TopUp.addPresets({

".csc-textpic-imagewrap a": {

group: "images"

}

});

Das bedeutet alle TopUp-Links im Div .csc-textpic-imagewrap werden der Gruppe images zugewiesen. Im Overlay gibts dann Vor- und Zurückpfeile.

Fazit

Die Initialisierung und Einstellungen einer Lightbox variieren natürlich. Es gibt aber ein paar schöne und elegante Tools deren Einsatz sich lohnen. Vorallem im Zusammenspiel mit der brand neuen TYPO3 Version 4.3 - ein großartiger Schritt mit schönen Verbesserungen. Unbedingt ansehen. Und TopUp einbinden!

Zum Beispiel in einem Tool welches umfangreiche Exportmöglichkeiten besitzt und gerade von einer jungen, dynamischen Agentur entwickelt wird. In dem Programm legt man ein Exportscript an und kann diesem verschiedene Exportdateien zuweisen die beim durchlaufen dynamisch erstellt werden.

Diese einfache 1:n Beziehung ist mit Cake schnell gebacken, mit ein paar Zeilen erweitert und läuft. Allerdings verteilt auf mehreren Seiten. Zum Glück gibt uns Cake einfache Möglichkeiten an die Hand um das zu verhindern.

In diesem Artikel will ich aufschreiben wie man praktisch jedes Cake Projekt zusammen mit dem Lieblings-Javascriptframework jQuery in eine coole Web 2.0 Anwendung verwandeln kann.

Grundlagen

Ich gehe mal von einer laufenden Cakeanwendung aus. Da gibt es die Tabelle Export und die Tabelle Exportfiles. Die beiden sind über eine 1:n Beziehung verknüpft, die Anwendung wurde gebacken und man verfügt über die normalen CRUD Funktionen.

Wenn Interesse an einem Tutorial dazu besteht, wäre ein kurzer Hinweis in den Kommentaren oder per Mail nett.

Der AppController

Den schönsten Teil bringt Cake schon mit: den RequestHandler. Mit dessen Hilfe kann man auf Ajaxanfragen reagieren. Als erstes muss er in der Datei app/app_controller.php eingebunden werden:

$components = array('RequestHandler');

Anschließend stehen in jedem Controller über $this->RequestHandler umfangreiche Möglichkeiten zur Verfügung. Besonders toll wirds im Callback beforRender(). Dieser wird im AppController definiert und von Cake automatisch aufgerufen, wenn die Logik im entsprechenden Controller abgearbeitet wurde.

So sieht die Killerfunktion aus:

function beforeRender() {

  if($this->RequestHandler->isAjax()) {

     Configure::write('debug', 0);

     if($this->RequestHandler->prefers() == 'json') {

        die(json_encode($this->viewVars));

     }

     else {

        $this->layout = 'ajax';

     }

  }

}

Was hier passiert ist so gut wie selbsterklärend: Wenn es sich um eine asynchrone Anfrage handelt if($this->RequestHandler->isAjax()), dann wird als erstes jegliche Debugausgabe verboten. Das muss man sich unbedingt merken, sonst besteht die Gefahr auszuflippen weil debug() "aufeinmal" nichts mehr ausgibt. Auf der anderen Seite kann man aber nicht mit einem JSON String in Javascript weiterarbeiten, wenn dem ein Datenbanklog am Hintern an der schließenden Klammer klebt. Also nicht vergessen!

Nach dem Cake weiß, das es eine Ajaxanfrage bearbeitet, wird geprüft, welche Rückantwort erwartet wird $this->RequestHandler->prefers(). Wenn diese JSON ist, werden alle viewVars, dass sind alle Variablen die über $this->set() im Controller gesetzt wurden, als JSON Objekt zurück gegeben. Damit stehen dem Javascript alle Informationen zur Verfügung die sonst im View verarbeitet werden. Toll oder?

Dieses die(json_encode()) finde ich noch nicht ganz so elegant wie der ganze Rest von Cake, tut aber seine Arbeit. Vielleicht hat jemand einen schöneren Ansatz?!

Wenn die Anfrage kein JSON erwartet, wird nicht das Standardlayout genutzt, sondern auf das Ajax umgeschaltet. Das befindet sich in der Datei app/views/layouts/ajax.ctp und besteht nur aus einer Zeile:

<?php echo $content_for_layout; ?>

Standardlayout

Um Probleme beim ändern der BaseURL zu vermeiden habe ich mir angewöhnt im Standardlayout das Tag base zu verwenden um mit jQuery schnell auf die URL zugreifen zu können. In der Datei app/views/layouts/default.ctp muss dafür folgende Zeile hinzugefügt werden:

<base href="http://<?=$_SERVER['HTTP_HOST']?><?=$this->base?>/" host="http://<?=$_SERVER['HTTP_HOST']?>" />

Ich weiß, das Attribut host verhindert eine komplette Validierung, allerdings brauche ich in einigen Fällen nur den Host und in anderen die komplette BaseURL, da zum Beispiel die erstellen Formulare mit $form->create(...) schon die BaseURL enthalten.

Das wird man gleich sehen.

jQuery Action

Da sind jetzt in wenigen Zeilen mächtige Grundlagen gelegt worden, die man mit jQuery an seiner Seite ausnutzen möchte. Im Formular zur Erstellung eines neuen Exports habe ich ein Button "Neue Exportdatei", die bei Klick in den Container div#new das Formular lädt um eine neue Datei zu speichern. Nichts leichter als das:

$ajax({

  url: $('base').attr('href')+'exportfiles/add/export:'+$('#ExportEditForm').attr('rel'),

  dataType: 'html',

  success: function(form) {

      $('#new').html(form);

  }

};

Als benannten Parameter wird die ID des aktuellen Exports übergeben. Im Controller steht diese Information im Array $this->params['named'] zur Verfügung. Von da wird sie an den View übergeben und hier wird, sofern gesetzt ein verstecktes Formularfeld erzeugt, anstatt der gebackenen Liste der vorhandenen Exports.

Mit der Verwendung des Ajax-Layouts und der Angabe dataType: 'html' steht in der Variable form der Success Funktion genau das Formular zur Verfügung, welches im View definiert wurde.

JSON benutzen

Wenn das Formular ausgefüllt wurde, muss man das Abschicken abfangen. Leider unterstützt die Live Funktion noch nicht den Event submit, deshalb muss man sich mit einem Klick auf den Submitbutton helfen.

$('#new .submit input').live('click', function() { ... });

Das wirklick spannende ist natürlich auch hier die Ajaxanfrage und das Geheimnis liegt im dataType: 'json'.

$.ajax({

  url: $('base').attr('host')+$form.attr('action'),

  data: $form.serialize(),

  type: 'POST',

  dataType: 'json',

  success: function(content) {

    if(content.saved) {

        $form.closest('fieldset').prev().find('ul')

            .find('li.empty').remove().end()

            .append('<li>Neuer Eintrag <b>'+$form.find('input[type=text]:first').val()+'</b> angelegt.</li>');

    }

    else {

        alert("Leider ist ein Fehler beim speichern aufgetreten.");

    }

  }

});

In der Variable $form ist das jQuery Objekt gespeichert, welches das Formular widerspiegelt, dass gerade abgeschickt wurde. Da man immer wieder darauf zugreifen muss, macht es Sinn das in eine Variable zu legen um Zeit bei der Abarbeitung zu sparen.

In der Variable content stehen jetzt dank AppController und RequestHandler alle View-Variablen zur Verfügung. Über das Auslesen des Attributs Action des Formulars muss man sich nicht mal mehr Gedanken machen wo das Formular überhaupt abgearbeitet wird. Wichtig ist nur das in der entsprechenden Funktion ein Status gesetzt wird:

$this->set('saved', true);

Fazit

Nach genau dem gleichen Prinzip funktioniert auch das Löschen oder jeder andere Anwendungsfall der einem einfällt. Ich bin im Moment mal wieder begeistert von diesen beiden tollen Frameworks und den schier unerschöpflichen Möglichkeiten.

Demnächst gibt es dann hoffentlich mal die Vorstellung von einem fertigen Tool. Bis dahin freue ich mich auf Fragen und Verbesserungsvorschläge. Vielen Dank fürs lesen!

Eine von vielen schönen Kleinigkeiten ist Olis Notziblog auf der rechten Seite. Es handelt sich um ein Widget in dem immer mal wieder, unkompliziert neue Inhalte eingetragen werden sollen. Das Besondere ist, dass ein Inhalt aus einem Bild (der Handschrift) und der Abschrift besteht. Sprich Text mit Bild. Das kommt dem geschulten TYPO3 Ohr natürlich bekannt vor. Und genauso werden die Daten vorgehalten. In Contentelementen.

Dieses Tutorial beschreibt die Einrichtung, Verwaltung und Ausgabe eines Miniblogs, der einfach zu pflegen ist und Informationen ohne große Funktionen zur Verfügung stellt.

Backend

Es wird eine nicht im Menü sichtbare Seite angelegt, dem Redakteur freigegeben und die ID (z.B. 50) notiert. Hier sollte man jetzt testweise einen Inhalt anlegen. Soweit sehr einfach.

Typoscript

Entweder wird ein eigener Marker im Template festgelegt, oder, was ich empfehlen würde, der Marker für die rechte Spalte wird als COA angelegt. COA beschreibt eine Sammlung von Objekten die nacheinander ausgegeben werden. Im ersten Schritt soll schlicht der Inhalt der rechten Spalte aus dem Backend ausgegeben werden:

page.10.marks.RIGHT = COA

page.10.marks.RIGHT.50 = CONTENT

page.10.marks.RIGHT.50 {

  table = tt_content

  select.orderBy = sorting

  select.where = colPos = 2

  select.languageField = sys_language_uid

}

Mit dieser Struktur, die man auch bedenkenlos für die linke und die Hauptspalte benutzen kann, hat man absolute Flexibilität auf den Unterseiten. Olis Blog erscheint nur auf der Startseite. Also wird ein Extensiontemplate angelegt und der Marker RIGHT erweitert:

page.10.marks.RIGHT.40 = PHP_SCRIPT

page.10.marks.RIGHT.40.file = fileadmin/template/scripts/olis_notizblog.php

Vor dem Menü wird dem Marker ein PHP Script hinzugefügt.

PHP Script

Jetzt ist es nicht mehr weit. Hinter oben angegebenen Pfad erstellt man eine Datei. Zwei Dinge muss man beachten:

1. Alle Inhalte die später im Marker erscheinen sollen, müssen in die Variable $content geschrieben werden
2. Auch wenn der Testserver die PHP Kurzschreibweise <? ... ?> unterstützt, sollte man diese nicht mehr verwenden! In PHP 6 soll sie abgeschafft werden und etliche Konfigurationen verbieten sie jetzt schon, was zur Folge hat, dass der Code einfach als Text ausgegeben wird.

Die erste Aufgabe besteht darin, das neuste Element aus der tt_content Tabelle auszulesen. Es muss also nach Zeit sortiert werden und das Element muss auf der richtigen Seite gespeichert werden (ID 50). Das erreicht man über die Abfrage der Spalte PID.

$posts = $GLOBALS['TYPO3_DB']->exec_SELECTgetRows(

  'uid, header, bodytext, image',

  'tt_content',

  'pid = "50" AND deleted = "0" AND hidden = "0"',

  '',

  'sorting ASC',

  1

);

Der äußerst praktische Befehl exec_SELECTgetRows erwartet folgende Parameter: auszulesende Felder, gewünschte Tabelle, WHERE-Bedingung, eventuell Gruppierung, Bedingung zum Sortieren und die Anzahl der erwarteten Ergebnisse.

Das kann man sich natürlich nur schwer merken, aber dafür gibt es zum Glück eine Dokumentation zum nachsehen.

exec_SELECTgetRows liefert im Gegensatz zu exec_SELECTquery keine Datenbankressource zurück, sondern ein Objekt über alle gefundenen Zeilen. In unserem Fall ist das nur eine und es wird auch immer eine bleiben, deshalb kann man immer so an sie herankommen:

$post = $posts[0];

Jetzt ist es nur noch eine Frage der Anforderung und einer testweisen Ausgabe mit print_r($post) um ein Ergebnis zu erhalten:

$content = '<div class="blog">';

$content.= '<h3>'.$post['header'].'</h3>';

$content.= '<p>'.$post['bodytext'].'</p>';

$content.= '</div>';

Fazit

Fertig ist der Lack/Blog! Über dem Hauptmenü erscheint jetzt immer das neuste Element aus der versteckten Seite. Sicher hätte man das ganze auch mit puren Typoscript lösen können, aber meiner Ansicht nach ist diese Lösung flexibler. Eventuell sollen die Inhalte demnächst auf Twitter, Facebook, MySpace und SpiegelOnline erscheinen. Da ist es dann schön ein Script zur Verfügung zu haben, in dem man sich austoben kann.

Bleibt noch zu sagen, hört mehr Hörbücher!!!

Legt der Redakteur eine neue Seite Namens "Zimmerschlacht" an, könnte er anschließend in die Listenansicht wechseln und eine neue News Kategorie anlegen. Aber mach das mal einem DAR (analog zu DAU) klar. Und warum den Mund fusselig reden, wenn das auch automatisch geht?!

Es gibt in TYPO3 eine Möglichkeit mit einem Hook in das Speichern von Datensätzen einzugreifen. Da kann man sich dann austoben. Es funktioniert auch mit DAM Kategorien und jeder anderen vorstellbaren Datenbankanforderung.

Vorbereitung

Wenn der Redakteur in einem bestimmten Zweig des Seitenbaums eine Aktion auslöst (neue Seite erstellen, bearbeiten oder löschen) muss mit einem Script darauf reagiert werden. Dafür legt man an seinem Lieblingsplatz eine Datei an und merkt sich sowohl Pfad und Namen. Mein Vorschlag:

fileadmin/template/hooks/class.tx_createCategories_tcemainprocdm.php

In dieser Datei sucht TYPO3 später eine Klasse deren Namen wir auch selbst bestimmen können.

class tx_createCategories_tcemainprocdm {

}

Hooks verstehen

Hooks sind Funktionen die während der Abarbeitung eines Scripts aufgerufen werden. Meistens erstellt TYPO3 ein Objekt von der übergebenen Klasse und das Script sucht nach einer passenden Funktion mit fest definiertem Namen.

Hooks suchen

Google ist natürlich Anlaufpunkt Nummer eins, aber auch der Quelltext der betreffenden Datei bietet gute Anhaltspunkte. Wie die Vorschläge oben schon deutlich machen geht es mir um class.t3lib_tcemain.php welches sich um sämtliche Datenbankoperationen kümmert. Die Core API bietet einen guten Anlaufpunkt. Nach einigem hin und her weiß man dann, dass man den Hook Namens processDatamap_afterDatabaseOperations braucht.

Hooks registrieren

Über die Datei localconf.php wird das $GLOBALS Array erweitert. Die genauen Bezeichnungen findet man meistens in der Dokumentation oder dem Quelltext. Um auf das verändern von Seiten zu reagieren muss man folgende Zeile hinzufügen:

$GLOBALS["TYPO3_CONF_VARS"]["SC_OPTIONS"]["t3lib/class.t3lib_tcemain.php"]["processDatamapClass"][] = "fileadmin/template/hooks/class.tx_createCategories_tcemainprocdm.php:tx_createCategories_tcemainprocdm";

Der Inhalt dieser Angabe ist in zwei Teile durch ein Doppelpunkt geteilt: Der erste gibt den Pfad zur Datei an, der zweite den Namen der zu initalisierenden Klasse.

Nicht vergessen den Cache zu löschen!!! Sonst ärgert man sich zu tode!

Logik hinzufügen

Bis hierher alles klar? TYPO3 erstellt eine neue Seite, initalisiert anschließend das eben angegebene Objekt und sucht darin die Funktion processDatamap_afterDatabaseOperations und führt sie aus. In dem Script im fileadmin legt man also los und führt aus was man ausführen muss:

class tx_createCategories_tcemainprocdm {

  function processDatamap_afterDatabaseOperations($status, $table, $id, $fieldArray, &$reference) {

  }

}

Spannend sind die Parameter:

• $status gibt an, was der User getan hat. z.B. "new"
• $table sagt, in welcher Tabelle der User es getan hat. z.B. "pages"
• $id beinhaltet die UID des Datensatzes (aber mit Einschränkungen! Siehe unten).
• $fieldArray enthält die neuen Felder. Wenn der Redakteur nur den Titel geändert hat, dann steht hier nur der neue Titel in einem assoziativen Array drin.
• $reference ist ein Objekt und beinhaltet die ggf. schon vorhandenen Inhalte.

Mit diesen Informationen ausgerüstet kann man schon eine ganze Menge erreichen. Mit einem echo kann man sich auch ohne Probleme Daten ausgeben. Die erscheinen dann über dem Formular im Backend. Sieht nicht schön aus, aber man kann etwas lesen.

Die richtige UID erkennen

Das Problem ist, dass bei einem neuen Datensatz im Parameter $id eine temporäre UID gespeichert ist. Irgendwas wie NEW_2352. Also definitiv keine Integer sondern ein String. Der Hook wird aber nach dem Speichern ausgeführt, deshalb muss man sich über $reference die richtige UID besorgen:

if(!is_numeric($id)) {

  $id = $reference->substNEWwithIDs[$id];

}

Das habe ich auch nur in irgendeiner Mailingliste aufgeschnappt. Selbsterklärend ist etwas anderes.

Neue Kategorien anlegen

Zurück zur Anforderung. Wenn ein Redakteur eine neue Seite anlegt, muss eine neue Kategorie angelegt werden. Dafür muss als erstes geprüft werden, ob überhaupt eine Seite angelegt wurde und der Titel geändert wurde:

if($table == 'pages' && $id > 0 && !empty($fieldArray['title']) {

  //hier gehts weiter

}

In dieser Abfrage muss auch noch geklärt werden, ob sich die Seite an der richtigen Stelle befindet. Das kann man über die PID erreichen oder wie in meinem Fall über einen eigenen Seitentyp. Beide Angaben findet man im Array $reference->checkValue_currentRecord.

if($status == 'new')

Endlich mal wieder etwas schönes. Alternativ könnte man auch mit Switch auf die verschiedenen Operationen reagieren. Je nach Vorliebe. Wurde also eine neue Seite an der richtigen Position angelegt, wird nichts weiter getan als eine Zeile in der Tabelle tt_news_cat zu speichern:

$GLOBALS['TYPO3_DB']->exec_INSERTquery(

  'tt_news_cat',

  array(

  [tab]'pid' => 194,

  [tab]'title' => $fieldArray['title'],

  [tab]'shortcut' => $id

  )

);

Seiten und Kategorien umbenennen

Da kommt nochmal das Array $reference->checkValue_currentRecord zum Einsatz. Wird eine Seite aktualisiert steht dort der alte Titel drin und im $fieldArray der neue. Schöne Sache das und nur eine handvoll Zeilen um die entsprechende Kategorie zu identifizieren und umzubenennen:

$GLOBALS['TYPO3_DB']->exec_UPDATEquery(

  'tt_news_cat',

  'title = "'.$reference->checkValue_currentRecord['title'].'"',

  array(

  [tab]'title' => $fieldArray['title']

  )

);

Nach diesen beiden Beispielen sollte das Löschen auch keine Schwierigkeiten mehr bereiten. Der Redakteur wird es gar nicht bemerken, aber der effektive Teil vom Webentwicklerherz schlägt jetzt schon schneller.

Mit ein bisschen PHP Erfahrung sollte man sich unbedingt mit den Hooks auseinander setzen.

Mit ein paar Zeilen mehr im Plugin läufts auch mit beliebig vielen Objekten. So funktionierts:

Die Anforderung

...ist alt bekannt. Folgendes HTML liegt vor:

<div class="test">

  Wir sind <strong>wichtig</strong>

</div>

Wenn man dieses HTML auslesen will und nur weiß, dass das Zielelement die Klasse test hat, schlägt folgender Versuch fehl:

$('.test').html(); //funktioniert nicht

Funktioniert nicht, weil das Ergebnis nicht komplett ist.

Wir sind <strong>wichtig</strong>

Mein kleines Plugin entireHtml hilft weiter, und liefert wie erwartet das komplette HTML. So wirds allerdings nervig:

<div class="test">

  Wir sind <strong>wichtig</strong>

</div>

<div class="test">

  und das ist <strong>schön</strong>.

</div>

Die Funktion entireHtml liefert nur das HTML des ersten divs zurück.

Die Lösung

Im Plugin stehen alle Objekte in der Variable this zur Verfügung. Das Plugin muss, wenn mehr als ein Element im Stack liegt, jedes Element durchgehen und das komplette HTML zurückgeben.

Und ohne große Worte folgt jetzt das komplette Plugin:

/*
 *  entireHtml
 *  Ein kleines, nettes Plugin um das komplette HTML eines Selectors zu bekommen.
 *
 *  Mehr Infos unter http://www.interaktionsdesigner.de
 */

(function($) {
  jQuery.fn.entireHtml = function() {
    if(this.length == 1) {
      return this.clone().wrap('<div></div>').parent().html();
    }
    else {
      var html = '';
      $(this).each(function() {
        html+= $(this).entireHtml();
      });
      return html;
    }
  }
})(jQuery);

Fazit

Schön, oder? Funktioniert wie erwartet. Noch eine Antwort: Wozu braucht man das? Im Moment arbeiten wir an einem interaktiven Tool um PDFs zu erstellen. Das Formular kommt aus der Extension Powermail für TYPO3 und wird von einem Redakteursteam gepflegt. Im Frontend sollen aber bestimmte Optionen erst auf Nachfrage sichtbar sein.

Redakteur fügt also Dateiuploadfelder hinzu und speichert. jQuery "merkt" das, nimmt das komplette HTML raus, packt es in eine Box, versteckt die Felder und legt einen Link ala "Klicken Sie hier, wenn Sie eine Datei hochladen möchten".

Ich sach nur: Kundenprojekte...

Das Problem mit den Dingern, ist die dynamische Veränderung. Ein einfaches $("select").find("option:first").remove(); funktioniert zwar zum entfernen, aber das hinzufügen von Options ist schon schwieriger (-böser Blick zum Internet Explorer-). Und wenn die Selectbox sich dann an einer weiteren orientieren soll, dann wirds haarig.

Die Lösung ist das Klonen und verstecken der "originalen" Box. Aus dem Klon kann man dann die überflüssigen Auswahlmöglichkeiten entfernen.

Und jetzt folgt der Artikel wie man das effizient anstellen könnte. Natürlich Hand in Hand mit jQuery.

Das Problem

Folgende Anforderung bestand im aktuellen Projekt: In der ersten Selectbox wird die Frequenz gewählt (monatlich, vierteljährlich usw.). Die zweite Box bietet eine Auswahl an Monaten zur Angabe der Dauer.

<select name="frequency" class="frequency">

  <option value="1">monatlich</option>

  <option value="3">vierteljährlich</option>

  <option value="6">halbjährlich</option>

  <option value="12">jährlich</option>

</select>

<select name="months" class="months">

  <option value="0">0</option>

  <option value="1">1</option>

  <option value="2">2</option>

  <option value="3">3</option>

  <option value="4">4</option>

  <option value="5">5</option>

  <option value="6">6</option>

  <option value="7">7</option>

  <option value="8">8</option>

  <option value="9">9</option>

  <option value="10">10</option>

  <option value="11">11</option>

</select>

Theoretisch

Sehr einfach zu erklären: Der Anwender wählt in der ersten Auswahl "halbjährlich" - darauf hin stehen in der Monatsauswahl nur noch "0" und "6" zur Verfügung. Welcher Monat angezeigt wird, kann ganz einfach mit der Modulo-Operation berechnet werden. Darüber hatte ich mich auch schon im Blog ausgelassen.

Der Klon wird mit der Klasse active gekennzeichnet und muss vor der nächsten Veränderung entfernt werden.

Praktisch

Jetzt wirds nett. jQuery ist natürlich im Projekt eingebunden. Sobald das Dokument geladen wurde, muss ein Eventhandler auf die Frequenzauswahl gelegt werden.

jQuery(function($) {

  $("select.frequency").onChange(function() {

  //hier gehts weiter!!

  });

});

Diese Form ist besser als das überall gesehene $(document).ready(function() {}), denn die $ Funktion muss nicht mehr zwangsläufig von jQuery besetzt sein, sondern wird dem eigenen Code als Parameter übergeben.

Als nächstes beschreibe ich alle Schritte zum Ändern der Selectbox $("select.months") einzelnd. Anschließend gibts nochmal die komplette Funktion unkommentiert im Ganzen.

new_frequency = $(this).val();

$form = $(this).parents("form:first");

Die Auswahl wird in new_frequency zwischengespeichert und das umfassende Formular in der Variable $form abgelegt, um später schneller darauf zugreifen zu können.

Die Variable $form beginnt mit einem Dollarzeichen. Damit kennzeichne ich Variablen, die ein jQuery-Objekt enthalten. So ist es leicher, diese im weiteren Verlauf zu erkennen. Dieses Vorgehensweise kann ich wärmstens empfehlen.

if($("select.months.active", $form).length > 0) {

  $("select.months", $form).filter(".active").remove().end().show();

}

Mit der Anweisung $("select.months.active", $form).length werden alle Selectboxen mit der Klasse active gesucht. Sind diese vorhanden, werden beide Selectboxen (die ggf. versteckte und der Klon) selektiert.

Mit der Funktion filter(".active") wird davon die aktive Selectbox ausgewählt und entfernt. Das end() setzt die Auswahl von filter() zurück und show() zeigt die übrig gebliebene Selectbox an.

jQuery Power in einer einzigen Zeile! Aber es wird noch besser...

Die Selectbox mit der Klasse .months muss geklont werden, verändert, angezeigt und die ursprüngliche Box versteckt werden. Zum Glück braucht man dazu auch nicht mehr als eine Zeile.

$("select.months", $form).clone().hide().insertBefore("select.months").end().addClass("active").find("option").filter(function(i) { return i%new_frequency == 0 ? false : true; }).remove();

Sieht komplizierter aus als es ist. Man kann es praktisch Stück für Stück lesen:

1. $("select.months", $form) sucht die Selectbox im aktuellen Formular mit der Klasse months.
2. clone() kopiert die aktuelle Auswahl und speichert sie irgendwo zwischen. Die Auswahl besteht nicht aus dem Klon, sondern der ursprünglichen Auswahl.
3. hide() - deshalb kann die Auswahl, also die erste Selectbox, auch einfach versteckt werden. Das passiert nach dem klonen, damit der Klon nicht extra wieder eingeblendet werden muss.
4. insertBefore("select.months") fügt den Klon vor der Selectbox ein.
5. end() setzt die Auswahl zurück. Damit besteht die Auswahl aus dem Klon und nicht mehr aus der ursprünglichen Selectbox.
6. addClass("active") fügt die Klasse hinzu damit der Klon später erkannt werden kann.
7. find("option") sucht alle Optiontags innerhalb der geklonten Selectbox.
8. filter(function(i) { return i%new_frequency == 0 ? false : true; })
   Ein großartiges Stück jQuery präsentiert hier die ganze Power der filter() Funktion. Dieser kann man nicht nur einen Tagnamen, eine ID oder eine Klasse übergeben, sondern auch eine anonyme Funktion! Anhand dieser wird jedes enthaltene Element überprüft. Gibt die Funktion true zurück, bleibt das Element in der Auswahl; ansonsten fliegt es raus.
   Diese Funktion besteht nur aus einer simplen Berechnung und schmeißt alle Monate raus, welche zur gespeicherten Frequenz passen.
   Schön, oder?
9. remove() entfernt dann die übrig gebliebenen Auswahlmöglichkeiten.

Fertig! Eine einzige Zeile klont und bearbeitet die Auswahlmöglichkeit. Und das sooft der Benutzer möchte. So sieht die Funktion im ganzen aus:

$(".frequency").change(function() {

  new_frequency = $(this).val();

  $form = $(this).parents("form:first");

  

  if($("select.months.active", $form).length > 0) {

    $("select.months", $form).filter(".active").remove().end().show();

  }

  

  $("select.months", $form)

      .clone().hide().insertBefore(".plan:visible select.months").end().addClass("active")

      .find("option").filter(function(i) { return i%new_frequency == 0 ? false : true; }).remove();

});

Fazit

Ich mag jQuery. Kennst du eine besser Lösung? Mal abgesehen von Plugins die das ganze mit einem unüberschaubaren Overhead erledigen?

Ansonten viel Spaß mit abhängigen Selectboxen.