------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Dabei kommt uns eine Extension zugute, die seit TYPO3 4.5 im Core ist. Diese heißt “backend_layout” und als neuer Datensatz heißt er “Backend Layout”:

Backend Layout Datensatz

Ein neues Backend Layout können wir unsere eigene oder vom Kunden gewünschte Inhaltsstruktur mittels des Wizards erstellen. Wir erstellen heute ein Layout, welches in der oberen Hälfte aus zwei Spalten und in der unteren Hälfte aus einer Spalte über die gesamte Breite besteht:

Backend Layout Wizard

Hier sieht man schön die zukünftige Struktur. Man sieht auch, dass ich jeden Bereich mit einer Zahl fest definiert habe. Diese Zahlen müssen wir uns merken für das TypoScript später.

Nachdem wir das Backend Layout gespeichert haben, können wir uns sogleich mal an das TypoScript machen. Merken müssen wir uns noch die UID des Backend Layouts. Und so geht es los:

# Ein CASE Objekt schaut, welcher Fall eintritt und handelt dementsprechend.
temp.contentStructure = CASE
temp.contentStructure {
  # Durch den Key können wir festlegen, auf welches Feld er prüft, in diesem Fall das Feld
  # "backend_layout" im Seiten-Datensatz.
  key.field = backend_layout
  # Falls das Feld leer ist, schaut er rekursiv bis zur Root Page, ob irgendwo das Feld gesetzt ist.
  key.ifEmpty.data = levelfield:-2, backend_layout_next_level, slide
 
  # Die UID des Backend Layout Datensatzes, in unserem Falle die 1
  1 = COA
  1.10 = COA
  1.10.wrap = <div class="maincolumns">|<div class="clear"></div></div>
  # Spalte oben links 
  1.10.10 < styles.content.get 
  1.10.10.select.where = colPos = 1 
  1.10.10.wrap = <div class="column first">|</div>
  # Spalte oben rechts 
  1.10.20 < styles.content.get 
  1.10.20.select.where = colPos = 2 
  1.10.20.wrap = <div class="column second">|</div>
  # Spalte unten 
  1.20 < styles.content.get 
  1.20.select.where = colPos = 3 
  1.20.wrap = <div>|</div>
} 
 
# Wir kopieren das Objekt in die Variable content 
page.10.variables.content < temp.contentStructure

Damit setzen wir für jede Spalte (colPos = vorher gesetzte Spaltennummer) auch direkt das HTML. Mit den verschiedenen Klassen können wir dann auch im Frontend per CSS die Struktur nachbauen, wie wir sie im Backend erstellt haben:

div.first {
  float: left;
  width: 50%;
}
div.second {
  float: right;
  width: 50%;
}
div.clear {
  clear: both;
}

Natürlich hat man Unmengen von Möglichkeiten, um sich mittels der Spalten verschiedene Backend Layouts zusammenzustellen.
Ach, und die Auswahl erfolgt über den Seiten-Datensatz im Backend. Dort gibt es die Möglichkeit ein Backend Layout für die Seite, aber auch rekursiv für alle darunterliegenden Seiten zu setzen:

Backend Layout Auswahl

Viel Spaß beim Probieren!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Angefangen wird mit dem neuen TypoScript Objekt FLUIDTEMPLATE.

Als Alternative zum Marker Based Templating (richtig Old School) und dem teils gehasstem, teils verehrtem TemplaVoilá gibt es nun seit TYPO3 4.5 das FLUIDTEMPLATE. Es ist keine Installation nötig, man kann es direkt per TypoScript initialisieren:

page = PAGE
page.10 = FLUIDTEMPLATE
page.10.file = fileadmin/template/my_template.html

Hiermit haben wir dem System gesagt, dass das Template my_template.html genutzt werden soll.

Wie üblich, werden verschiedene Elemente des Templates im TypoScript zusammengebaut, wie z.B. verschiedene Menus. Diese speichern wir in temporären Objekten namens temp.mainMenu, temp.subMenu oder auch temp.footerMenu.

Ich gehe jetzt mal davon aus, dass jeder weiß, wie man ein Menu im TypoScript erstellt, daher kopieren wir das fertige Objekt direkt in das FLUIDTEMPLATE:

page.10.variables {
  mainMenu < temp.mainMenu
  subMenu < temp.subMenu
  footerMenu < temp.footerMenu
}

Wir kopieren unsere erstellen Menustrukturen in Variablen im FLUIDTEMPLATE, um sie dann im HTML direkt anzusprechen:

<div id="mainMenu">
  <f:format.html>{mainMenu}</f:format.html>
</div>

Man sieht an dem Tag, dass ein Fluid Tag genutzt wird. “format.html” ist ein ViewHelper, der die Ausgabe in reinem HTML ausgibt. Die vorher definierte Variable wird mittels den geschweiften Klammern {variable} angesprochen, die wir ja vorher im TypoScript mit einem MENU Objekt gefüllt haben.

Das Gesamte kann jetzt natürlich mit allen möglichen TypoScript Objekten gefüllt werden. Auch Partials und Sections sind nutzbar, doch der Einfachheit halber soll dieses Beispiel ausreichen.

Natürlich kann man auch das HTML je nach TypoScript Objekt abhängig machen, indem man die Wenn-Abfrage von Fluid nutzt. So kann ich die HTML-Struktur abhängig von einem möglichen zweiten Menu machen und die Ebenen jeweils benennen:

<f:if condition="{submenu}">
  <f:then>
    <div id="content_wrap">
      <div id="submenu">
        <f:format.html>{subMenu}</f:format.html>
      </div>
      <div id="content">
        <f:format.html>{content}</f:format.html>
      </div>
    </div>
  </f:then>
  <f:else>
    <div id="content_wide">
      <f:format.html>{content}</f:format.html>
    </div>
  </f:else>
</f:if>

Im zweiten Teil erkläre ich, wie man die backend_layouts nutzen kann, um den Content Bereich gemütlich mit verschiedenen Layouts zu füttern.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Ablauf der Abmeldung
Im Formular ist nur die E-Mail Adresse anzugeben, die aus dem Newsletterverteiler entfernt werden soll. Nach dem Absenden wird die eingetragenen E-Mail Adresse zunächst validiert (Tx_Formhandler_Validator_Default (gültige E-Mail Adresse und ob sie in der Tabelle tt_address existiert)) und bei Erfolg wird in der Tabelle tt_address für den existierenden Datensatz, basierend auf der angegebenen E-Mail Adresse, das Feld hidden auf 1 gesetzt (Finisher_DB).

Alle weiteren Schritte, wie versenden von E-Mails an User und Admin, habe ich in diesem Tutorial weggelassen, da sie genau wie im Tutorial Newsletteranmeldung, umgesetzt werden können.

plugin.Tx_Formhandler.settings.predef.newsletter {
	# Common configuration
	name = Newsletterabmeldung
	addErrorAnchors = 1
	templateFile = fileadmin/templates/formhandler/newsletter_unsubscribe.html
	langFile.1 = fileadmin/templates/formhandler/newsletter_unsubscribe.xml
	cssFile.1 = fileadmin/css/my.css
	formValuesPrefix = formhandler
 
	requiredSign = TEXT
	requiredSign.value = *
	requiredSign.wrap = <span style="color: #DF9707;">|</span>
 
	#isErrorMarker.default = class="errorField"
	isErrorMarker.default =
 
	# HTML wrapping by validation error
	errorListTemplate {
		totalWrap = <div class="error">|</div>
		singleWrap = &nbsp;|&nbsp;
	}
 
	#PreProcessors
	preProcessors {
		1.class = PreProcessor_LoadGetPost
	}
 
	# Validators configuration
	validators {
		1 {
			class = Tx_Formhandler_Validator_Default
			config {
				fieldConf {
					emailunsubscribe {
						errorCheck.1 = required
						errorCheck.2 = email
						errorCheck.3 = isInDBTable
						errorCheck.3 {
							table = tt_address
							field = email
							fields {
								email.mapping = emailunsubscribe
							}
						}
					}
				}
			}
		}
	}
 
	# Finishers configuration
	finishers {
		1.class = Finisher_DB
		1.config {
		  debug = 1
			table = tt_address
			updateInsteadOfInsert = 1
			key = email
			key_value = TEXT
			key_value.data = GPvar:formhandler|emailunsubscribe
			fields {
				hidden.ifIsEmpty = 1
				email.mapping = emailunsubscribe
			}
		}
		2.class = Finisher_Redirect
		2.config {
			redirectPage = 97
		}
	}
}

<!-- ###TEMPLATE_FORM1### begin -->
<div id="formhandler_newsletter_unsubscribe_form">
	<form method="post" action="###REL_URL###">
	<table>
		<tr>
			<td>###LLL:newsletter_intro_unsubscribe###</td>
		</tr>
		<tr>
			<td>
				<table>
					<tr>
						<td class="newsletterlabel">###LLL:emailunsubscribe### ###required_emailunsubscribe###</td>
						<td><input type="text" ###is_error_emailunsubscribe### name="formhandler[emailunsubscribe]" id="emailunsubscribe" value="###value_emailunsubscribe###" size="30" class="newsletterinput"/></td>
					</tr>
			  </table>
			</td>
		<tr>
			<td class="newslettertext">###LLL:required_fields###</td>
		</tr>
		<tr>
			<td class="newslettertext">###LLL:newsletter_text_1###</td>
		</tr>
    <tr>
    	<td>&nbsp;</td>
    </tr>
    <tr>
    	<td><input type="submit" value="###LLL:submit###" ###submit_nextStep###/></td>
	  </tr>
    <tr>
    	<td>###ERROR###</td>
	  </tr>
	</table>
	</form>
</div>
<!-- ###TEMPLATE_FORM1### end -->
 
<!-- ###TEMPLATE_SUBMITTEDOK### begin -->
<table>
  <tr>
    <td>###LLL:emailunsubscribe###</td>
    <td>###value_emailunsubsrcibe###</td>
  </tr>
</table>
<!-- ###TEMPLATE_SUBMITTEDOK### end -->

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
	<data type="array">
		<languageKey index="default" type="array">
 
			<label index="emailunsubscribe">E-Mail</label>
 
			<label index="required_fields">* Pflichtfelder</label>
			<label index="newsletter_text_1">Die Daten werden nicht an Dritte weitergegeben.</label>
			<label index="submit">Formular senden</label>
 
			<label index="error_emailunsubscribe_required">Gültige E-Mail Adresse bitte eingeben.</label>
			<label index="error_emailunsubscribe_email">Gültige E-Mail Adresse bitte eingeben.</label>
			<label index="error_emailunsubscribe_isInDBTable">Diese E-Mail Adresse ist nicht registriert.</label>
		</languageKey>
	</data>
</T3locallang>

Dies ist ein Gast-Beitrag von Alois Rainbacher. Vielen Dank dafür.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Heute möchte ich eine für den Integrator einfache und für den Redakteur übersichtliche Methode zeigen, um solche Effekte ohne Extension und ohne die teils nervigen Updates nachzubauen.

Einzige Bedingung hierfür ist die TYPO3 Version >= 4.6 und die Extension “gridelements“.
Einfach über den Extension Manager installieren und – nicht vergessen – die statischen Templates einbinden.

Als Beispiel habe ich mir heute den Effekt “Accordion” ausgesucht.

Wir beginnen damit, ein Grid Element anzulegen mit dem redakteursunterstützenden Namen Accordion. Im Wizard für die Elemente sind wir schnell fertig, da wir nur diesen einen Kasten benötigen. Wir geben der “Spalte” auch den Namen Accordion und die Spaltennummer ist die “1″.

Nachdem wir das Grid Element gespeichert haben, müssen wir nur noch das TypoScript einfügen:

tt_content.gridelements_pi1.20.10.setup {
  # ID of gridelement
  1 < temp.gridelements.defaultGridSetup
  1 {
    columns {
      # colPos ID
      1 < .default
      1.wrap = <div class="accordion">|</div>;
    }
  }
}

Die HTML-Grundstruktur haben wir jetzt. Nun brauchen wir das nötige JavaScript. Das finden wir unter http://jqueryui.com. Dort können wir für das Accordion nötige JS zusammenstellen lassen. Dieses müssen wir herunterladen, entpacken und in unsere TYPO3 Instanz hochladen.
Dann die nötigen TypoScript-Befehle:

# CSS von Accordion / Theme ui-lightness
page.includeCSS.accordion = fileadmin/res/css/ui-lightness/jquery-ui-1.8.18.custom.css
# jQuery Source
page.includeJSFooterlibs.jquery = fileadmin/res/js/jquery-1.7.1.min.js
# jQuery UI Accordion Source
page.includeJSFooter.accordion = fileadmin/res/js/jquery-ui-1.8.18.custom.min.js
# jQuery UI Accordion Init
page.includeJSFooter.accordion_init = fileadmin/res/jquery-accordion.js

Die letzte Datei jquery-accordion.js müssen wir selbst erstellen und den initialisierenden Code hineinschreiben:

$(function() {
  $( ".accordion" ).accordion();
});

Da laut Dokumentation der Standard-Header ein <h3> ist, wir in unserem Beispiel aber die css-styled-content Erweiterungen nutzen, müssen wir den Code anpassen:

$(function() {
  $( ".accordion" ).accordion({ header: 'div.csc-header' });
});

Weitere Anpassungen von Accordion kann man auf der Seite von jQuery UI einsehen.

Somit müssten wir jetzt ein schönes Resultat finden, wenn wir Inhaltselement in das Grid Element hineinziehen (Drag’n'Drop möglich):

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

GEO Position

Für die Ermittlung einer GEO Position anhand einer IP Adresse, gibt es natürlich auch Erweiterungen, welche diese Aufgabe erfüllen. Diese müssen jedoch gewartet werden, weil die IP-Bereichs-Datenbanken aktuell gehalten werden müssen. Wer einmal “zwischendurch” eine Position einer IP benötigt, dem ist vielleicht schon mit dieser Methode geholfen.

    /**
     * @param string $ip
     * @return array|null
     */
    public function getPosition($ip = NULL) {
        if ($ip === NULL)
            $ip = t3lib_div::getIndpEnv('REMOTE_ADDR');
        try {
            $urlService = 'http://www.geoplugin.net/php.gp?ip=' . $ip;
            $content = unserialize(t3lib_div::getURL($urlService));
        } catch (Exception $exc) {
            return NULL;
        }
 
        return sizeof($content) ? $content : NULL;
    }

Aktuellen Tabellennamen im ExtBase Repository

Der Abstraktionlayer von ExtBase abstrahiert die Datenbank von TYPO3 vollständig. Wenn jedoch individuelle Abfragen (Statements) aus einem “generellen” Repository abgeschickt werden sollen, dann wird der Tabellenname benötigt – und das natürlich dynamisch! Diese Methode holt sich den Tabellennamen aus den DataMappern, sodass sich auch Abfragen, mit von Hand geschriebenen SQL Queries, ein bisschen besser abstrahieren lassen (wenn überhaupt möglich ).

    /**
     * Return the current tablename
     *
     * @return string
     */
    protected function getTableName() {
        return $this->persistenceManager->getBackend()->getDataMapper()->getDataMap($this->getRepositoryClassName())->getTableName();
    }

Fluid Label mit Error Klasse

Mit diesem ViewHelper könnt ihr auch für eure Labels in Formularen eine ErrorClass definieren. Einfach mit…

<yourkey:form.label property="yourProperty">Name</yourkey:form.label>

… auch das Label-Tag an die Property binden. Wenn die Eigenschaft eures Model dann im Validator zu einem Fehler führt, wird neben dem Formular-Feld auch das Label-Tag mit der passenden errorClass versehen.

class Tx_YourExtensionName_ViewHelpers_Form_LabelViewHelper extends Tx_Fluid_ViewHelpers_Form_AbstractFormFieldViewHelper {
 
    /**
     * @var string
     */
    protected $tagName = 'label';
 
    /**
     * Initialize the arguments.
     *
     * @return void
     */
    public function initializeArguments() {
        parent::initializeArguments();
        $this->registerArgument('errorClass', 'string', 'CSS class to set if there are errors for this view helper', FALSE, 'f3-form-error');
        $this->registerUniversalTagAttributes();
    }
 
    /**
     * Renders the textfield.
     *
     * @return string
     */
    public function render() {
        if (strlen($this->arguments['property'])) {
            $this->setErrorClassAttribute();
            $this->tag->addAttribute('for', $this->arguments['property']);
        }
        $this->tag->setContent($this->renderChildren());
        return $this->tag->render();
    }
 
}

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Hier möchte ich euch gerne mit den häufigst gebrauchten Snippets Abhilfe verschaffen.

Das wichtigste zuerst: sämtliche Konfigurationen der Dateiliste sind per TypoScript im Setup-Teil des Templates vorzunehmen und finden im tt_content.uploads.20 Bereich statt. Dank des mittlerweile standardmäßig vorhandenen TypoScript Editor im Backend sind zwar schon viele Einstellungen per “Suggest Drop-Down” zu erahnen, aber halt doch nicht immer so durchsichtig.

Sinnvolle Dateigrößen-Bezeichnungen einpflegen:

tt_content.uploads.20.itemRendering.30.bytes.labels = Byte | KB | MB | GB

Dateiendung (*.pdf, *.doc, etc.) verstecken:

tt_content.uploads.20.stripFileExtensionFromLinkText = 1

Thumbnail-Generierung beeinflussen:

tt_content.uploads.20.linkProc.iconCObject.file.maxH = 100 #maximale Höhe der Thumbnails
tt_content.uploads.20.linkProc.iconCObject.file.maxW = 100 # maximale Breite der Thumbnails
# etc.

Bestimmen welches Frame eines GIFs bzw. welche Seite eines PDFs angezeigt werden soll:

tt_content.uploads.20.linkProc.iconCObject.file.maxH = 100 #maximale Höhe der Thumbnails
tt_content.uploads.20.linkProc.iconCObject.file.frame = 2 # zweite Seite eines PDFs als Thumbnail generieren

Viel Spaß beim Experimentieren!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Man lädt sich also die Erweiterung “gridelements” aus dem TER, installiert sie und bindet die “Statischen Templates” ein. Danach den System-Ordner, den man als “Allgemeine Datensatzsammlung” angegeben hat öffnen und dort einen neuen Datensatz vom Typ “CE Backend Layout” anlegen. Die Funktionsweise ist hier die gleiche wie bei den Backend Layouts. Danach lässt sich das neu angelegte Element auf einer Seite einfügen. Man findet es in der Rubrik “Raster-Elemente”. Hat man z. B. ein zweispaltiges Element angelegt, sieht das Backend ungefähr so aus:

Nachdem das erfreulicherweise schon alles war, kümmern wir uns um die Ausgabe auf der Webseite. Dazu kann man per Typoscript definieren, wie dieses Element ausgegeben werden soll. Für das zweispaltige Element könnte das so aussehen:

tt_content.gridelements_pi1.20.10.setup {
	# ID of gridelement
	1 < temp.gridelements.defaultGridSetup
	1 {
		columns {
			# colPos ID
			11 < .default
			11.wrap = <div class="firstcol">|</div>
			# colPos ID
			12 < .default
			12.wrap = <div class="secondcol">|</div>
		}
		wrap = <div class="element2cols">|</div>
	}
}

Wichtig sind hier die verwendeten Zahlen. Die “1″ entspricht der ID des angelegten “gridelements”. Darin befinden sich die “columns”, die anhand ihrer colPos mit einem “wrap” versehen werden können. Der “wrap” am Ende umschließt das komplette Element. Zusätzliche Elemente können nach dem gleichen Schema hinzugefügt werden.

Selbst wenn man keine Raster-Elemente benötigt, empfiehlt es sich, die Erweiterung gridelements zu installieren. Denn man erhält mit dieser Extension auch eine Drag&Drop-Funktionalität für die Inhaltselemente, wie man sie von Templavoila kennt.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

1. Backend-Layout anlegen

Als erstes im System-Ordner, den man bei “Allgemeine Datensatzsammlung” der Root-Seite angegeben hat, einen neuen Datensatz vom Typ “Backend-Layout” anlegen. Man vergibt einen Titel (z. B. Startseite oder Unterseite) und  öffnet über “Konfiguration” den sog. “Grid wizard”. Dort lässt sich dann ein Backend-Layout zusammen klicken, das in meinem Fall auch die Ausgabe im Frontend widerspiegelt.

Die einzelnen Bereiche lassen sich noch benennen und mit Spaltennummern (colPos) versehen.

2. Backend-Layout auswählen

Nach dem Speichern, kann dieses Backend-Layout bereits in den Seiteneigenschaften einer Seite ausgewählt werden. Dazu einfach den Reiter “Erscheinungsbild” anklicken.

Man kann das Backend-Layout für die aktuelle Seite und für deren Unterseiten einstellen. Nach der Auswahl zeigt das Backend direkt die vorher getroffene Konfiguration an – und zwar in korrekter Spalten- und Zeilen-Aufteilung.

Somit wäre das Backend schon mal fertig konfiguriert. Bei Bedarf kann man sich natürlich noch weitere Backend-Layouts bzw. Seiten-Templates anlegen.

3. Die Verknüpfung mit dem Frontend

Um die angelegten Backend-Layouts mit der Ausgabe zu verknüpfen, benötigt man nur folgendes Typoscript Setup:

page = PAGE
page.10 = FLUIDTEMPLATE
page.10 {
	file.stdWrap.cObject = CASE
	file.stdWrap.cObject {
		# slide the template
		key.data = levelfield:-1, backend_layout_next_level, slide
		key.override.field = backend_layout
		# default template file
		default = TEXT
		default.value = fileadmin/templates/index.html
		# template file for backend-layout with ID 2
		2 = TEXT
		2.value = fileadmin/templates/subpage.html
	}
}

Im obigen Beispiel wird abhängig vom gewählten Backend-Layout, eine entsprechendes Template-Datei verwendet. Ich habe ein Standard-Template (default) angegeben und ein Template für das Backend-Layout mit der ID 2. Bei weiteren vorhanden Backend-Layouts, kann diese Liste natürlich erweitert werden. Dazu nur die korrekte ID benutzen.

4. Inhalte für die Ausgabe im Template bereitstellen

Wer von Templavoila kommt, dürfte z. B. die Navigation immer per “TypoScript Object Path” eingebunden haben. Die gute Nachricht: diese können beibehalten und direkt im Template aufgerufen werden. Aber wie kommt man an die Inhaltsbereiche? Mit Templavoila wurden diese als “Content Elements” gemapped. Jetzt benötigt man hier ein wenig Typoscript. (Ich gehe davon aus, dass CSS Styled Content benutzt wird.)

lib.field_content < styles.content.get
lib.field_content.select.where = colPos = 2

Hier auf die korrekte Angabe der colPos achten. Je nach Anzahl der Inhaltsbereiche, muss diese Anweisung natürlich “vervielfältigt” werden.

5. Die Template-Datei

Die Template-Datei, die im “fileadmin” liegt, beinhaltet dann vom Prinzip nur noch den Inhalt des <body> Bereichs. Den Rest baut TYPO3 ja automatisch drum herum. Das HTML-Template könnte dann z. B. so aussehen:

<div id=”header”>
<f:cObject typoscriptObjectPath=”lib.field_navmain” />
</div>
<div id=”content”>
<f:cObject typoscriptObjectPath=”lib.field_content” />
</div>

In diesem Beispiel benutze ich nur den <f:cObject> View-Helper von Fluid, um direkt auf die im Typoscript angelegten Content-Objekte zuzugreifen. Fluid aber auch Fluidtemplate bieten natürlich noch viele weitere Möglichkeiten, mit denen man sein Template anreichern kann.

Und hier sind wir schon am Ende. Mehr ist nicht nötig.

Fazit

Im Vergleich zu Templavoila bin ich mit dieser Template-Methode um einiges schneller, da das aufwändige Mapping wegfällt. Und das Anlegen der extra Backend-Layouts für Templavoila-Templates spart man sich dadurch auch.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

<!--[if lt IE 7]> <html lang="de" class="no-js ie6"> <![endif]-->
<!--[if IE 7]> <html lang="de" class="no-js ie7"> <![endif]-->
<!--[if IE 8]> <html lang="de" class="no-js ie8"> <![endif]-->
<!--[if gt IE 8]><!--> <html lang="de" class="no-js"> <!--<![endif]-->

Je nach eingesetztem Browser hat man also zusätzliche CSS-Klassen im <html> Tag, anhand derer man seine Seite für verschiedene IE-Browser-Versionen anpassen kann. Dieser Ansatz hat den Vorteil, dass man alle CSS-Angaben in einer CSS-Datei machen kann und dazu keine CSS-Hacks benötigt, um die unterschiedlichen IEs anzusprechen. Und da das alles in einer Datei machbar ist, spart man sich auch noch ein paar HTTP-Requests – im Vergleich zur Einbindung von versionsspezifischen Stylesheets per Conditional Comment.

Aber wie bekommt man das jetzt in eine TYPO3-Seite?

Nur mit der Angabe von “config.doctype = html5″ ist es hier natürlich nicht getan. Es gibt meines Wissens auch keine Standard-Typoscript-Anweisung, mit der man den obigen Code in die Webseite bekommt. Aber für solche Fälle gibt es ja Extensions! Und hier hilft die Extension “html5boilerplate“. Nach der Installation dieser Extension lässt sich der obige Code wie folgt einfügen:

config.html5boilerplate {
 htmlTag (
    <!--[if lt IE 7]> <html lang="de" class="no-js ie6"> <![endif]-->
    <!--[if IE 7]> <html lang="de" class="no-js ie7"> <![endif]-->
    <!--[if IE 8]> <html lang="de" class="no-js ie8"> <![endif]-->
    <!--[if gt IE 8]><!--> <html lang="de" class="no-js"> <!--<![endif]-->
  )
}

Somit hätte man den kompliziertesten Teil der HTML5 Boilerplate in TYPO3 integriert. Alles andere lässt sich im Prinzip mit hinlänglich bekannten TYPO3-Boardmitteln erledigen.

Die Extension liefert dazu auch Statische Templates (Typoscript) zum Einbinden mit, in denen neben dem obigen Snippet auch viele andere Anweisungen definiert sind. Es wird z. B. Modernizr im <head> eingebunden und alle anderen Skripte per “page.includeJSFooter” in den Footer geladen. Es lohnt sich also, einen Blick in die TS-Templates zu werfen, selbst wenn man die Extension eigtl. nur für das Setzen des HTML-Tags verwenden möchte.

Einer Webseite nach HTML5 Boilerplate Prinzipien steht dank dieser Extension nichts im Wege.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Genauso wie der Hook besteht das Signal/Slot Pattern aus zwei Bausteinen. Auf der einen Seite sind die Slots (Connector, Listener) und auf der anderen Seite die Signale (Dispatcher). Beide Funktionalität sind über die Klasse “Tx_Extbase_SignalSlot_Dispatcher” erreichbar, welche wir uns zuerst erstellen müssen. Dies geht entweder über Dependency Injection (z.B. im Controller):

/** 
 * @var Tx_Extbase_SignalSlot_Dispatcher
 */  
protected $signalSlotDispatcher;  
 
/** 
 * @param Tx_Extbase_SignalSlot_Dispatcher $signalSlotDispatcher 
 */  
public function injectSignalSlotDispatcher(Tx_Extbase_SignalSlot_Dispatcher $signalSlotDispatcher) {  
    $this->signalSlotDispatcher = $signalSlotDispatcher;  
}

oder aber auch über einfaches erstellen der Instanz:

$this->signalSlotDispatcher = t3lib_div::makeInstance('Tx_Extbase_Object_Manager')->get('Tx_Extbase_SignalSlot_Dispatcher');

Im Anschluss verfügt ihr über ein “Tx_Extbase_SignalSlot_Dispatcher” Objekt mit dem ihr nun Signale senden oder Slots registrieren könnte. Im Folgenden nun die beiden Sichten, welche möglich sind.

Dispatch / Signal

Beispiel: Am Ende eurer Action stellt ihr alle nötigen Variablen der View bereit. Nun befindet ihr euch an einer Stelle, welcher gern erweitert wird, weshalb ihr euch für ein “Signal” entscheidet. Das Signal wird über den Signal/Slot-Dispatcher getriggert und kann von anderen Extensions benutzt werden, um die eigene Action zu ergänzen. Hier der Beispielcode:

$this->signalSlotDispatcher->dispatch(__CLASS__, 'beforeRenderView', array($data, $this));

Die Funktion hat drei Parameter “Klassenname”, “Signalname” und “Parameter”. Der Klassennamen ist ähnlich einem Namespace zu betrachten. “__CLASS__” macht hier meistens Sinn – möglich wäre aber auch “get_class($this)”. Achtung/Tipp: Letzteres hat einen interessanten Vererbungseffekt, sodass eine vererbte Klasse automatisch andere Signale schickt als die Klasse von der geerbt wurde. Evtl. Tricky, deshalb empfehle ich anfangs “__CLASS__”.
Der Signalname ist frei wählbar und sollte die Position und Funktion beschreiben. Bei den Parametern sollten alle nötigen Parameter übergeben werden, sodass diese von einem Externen gut verarbeitet werden können.

Connect / Slot

Beispiel: Wir haben die Action (oben) gesehen und wollen die von außen (aber auch in der selben Extension wäre es möglich!) bearbeiten. Dazu erstellen wir uns ebenfalls den Signal/Slog-Dispatcher und registrieren eine Callback-Function (Slot / Listener) für das Signal. Hierzu gibt es verschiedene Möglichkeiten:

Anonym mit einem Closure,

$this->signalSlotDispatcher->connect(  
      'Tx_Extension_Controller_NameController', 'beforeRenderView', function($data, $obj) { /* ... */ }, NULL, FALSE  
);

eine Methode aus dem aktuellen Objekt oder

$this->signalSlotDispatcher->connect(  
     'Tx_Extension_Controller_NameController', 'beforeRenderView', $this, 'addInformation', FALSE  
);

eine Methode aus einem anderen Objekt.

$this->signalSlotDispatcher->connect(  
     'Tx_Extension_Controller_NameController', 'beforeRenderView', 'Tx_OtherExtension_Controller_NameController', 'addOtherInformation', FALSE  
);

Wie ihr seht sind die ersten beiden Parameter identisch zu dem “Signal-Aufruf”. Diese diesen der Identifikation des Signals. Über die beiden folgenden Parameter wird die Callback-Funktion gesteuert. Der letzte Parameter (welcher hier auf FALSE steht) kann auf TRUE gesetzt werden, wenn ihr in der Slot-Klasse zusätzliche Informationen über das Signal benötigt. Diese stehen dann als erster Parameter in der Zielfunktion zur Verfügung.

Fazit

Ein wirklich schönes Pattern – sauberer und einheitlicher als die “üblichen” Hooks. Gerade bei den Hooks war störend, das viele mit “User”-Functions benutzt werden mussten, weshalb die Klassen mit “user_” beginnen mussten. Das neue Pattern ist leicht zu bedienen und schlank im Einsatz. Felix, Vielen Dank dafür. Weitere Informationen bekommt ihr in der API.

Vielen Dank für die Inspiration: blog.tolleiv.de und blog.foertel.com

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Im folgenden Tutorial werden wir kaum Angaben im Plugin vom Formhandler machen. Alles was wir benötigen sind 4 Dateien und eine Zeile TypoScript. Vor- und zugleich Nachteil von Formhandler ist, dass jegliche Konfiguration in Dateien ausgelagert werden muss/sollte, was dann aber wiederum den Vorteil hat, dass diese Konfiguration sehr schnell auf ein anderes System portieren kann. Nach der Einbindung der TypoScriptzeile erscheint im Plugin ein neuer Eintrag in der Selectbox für “Vordefinierte Formulare”. Einfach auswählen. Fertig.

Ich werde hier nicht auf jede einzelne Option von Formhandler eingehen, das würde den Rahmen sprengen. Wenn es Euch interessiert, dann könnt Ihr die Webseite von Formhandler oder auch mein erstes Tutorial lesen, dass ich auf meiner Webseite präsentiere: Stefans TYPO3-Seite.

Ablauf der Anmeldung

Wir erstellen eine Seite mit einem Formular auf dem sich die beiden Felder name und email befinden. Nach dem Absenden werden die eingetragenen Daten zunächst validiert (Tx_Formhandler_Validator_Default) und bei Erfolg in die Tabelle tt_address abgespeichert (Finisher_DB). Hier setze ich die Spalte hidden per default auf 1, damit der User nicht sofort aktiv ist. Natürlich wäre auch eine Speicherung in fe_users möglich, aber dann müssten wir dem Datensatz noch eine Gruppe, einen Benutzernamen und ein Passwort zuordnen. Zu viel für meinen Geschmack. Nach der Speicherung wird aus den gesammelten Daten ein AuthCode erstellt (Finisher_GenerateAuthCode) und per Mail an der User und als Info auch an den Admin geschickt (Tx_Formhandler_Finisher_Mail). Klickt der User den Link mit dem enthaltenen AuthCode an, wird der PreProcessor aktiv (PreProcessor_LoadGetPost) und läd sich die benötigten Daten aus der URL in den Speicher. An Hand dieser Daten kann der AuthCode-Validator aktiv werden (PreProcessor_ValidateAuthCode). Dieser überprüft, ob der AuthCode gültig ist und setzt den Datensatz bei einer erfolgreichen Überprüfung automatisch auf visible (hidden=0). Außerdem können hier je nach Gültigkeit Page-UIDs angegeben werden auf die weitergeleitet wird.

newsletter.ts

plugin.Tx_Formhandler.settings.predef.newsletter {
	# Common configuration
	name = Newsletterregistrierung
	addErrorAnchors = 1
	templateFile = fileadmin/templates/formhandler/newsletter.html
	langFile.1 = fileadmin/templates/formhandler/newsletter.xml
	cssFile.1 = fileadmin/templates/formhandler/newsletter.css
	formValuesPrefix = formhandler
 
	requiredSign = TEXT
	requiredSign.value = *
	requiredSign.wrap = <span style="color: #DF9707;">|</span>
 
	isErrorMarker.default = class="errorField"
 
	# HTML wrapping by validation error
	errorListTemplate {
		totalWrap = <div class="error"><ul>|</ul></div>
		singleWrap = <li>|</li>
	}
 
	#PreProcessors
	preProcessors {
		1.class = PreProcessor_LoadGetPost
		2.class = PreProcessor_ValidateAuthCode
		2.config {
			redirectPage = 234
			errorRedirectPage = 235
			hiddenField = hidden
		}
	}
 
	# Validators configuration
	validators {
		1 {
			class = Tx_Formhandler_Validator_Default
			config {
				fieldConf {
					name {
						errorCheck.1 = required
					}
					email {
						errorCheck.1 = required
						errorCheck.2 = email
					}
				}
			}
		}
	}
 
	# Finishers configuration
	finishers {
		1.class = Finisher_DB
		1.config {
			table = tt_address
			key = uid
			fields {
				email.mapping = email
				name.mapping = name
				pid.ifIsEmpty = 57
				hidden.ifIsEmpty = 1
				module_sys_dmail_html.ifIsEmpty = 1
			}
		}
		2.class = Finisher_GenerateAuthCode
		2.config {
			table = tt_address
		}
		3.class = Tx_Formhandler_Finisher_Mail
		3.config {
			limitMailsToUser = 5
			admin {
				to_email = AdminEmailAdresse
				to_name = DeinNamw
				subject = Neue Newsletterregistrierung auf [webseite]
				sender_email = webmaster@xxx
				sender_name = Webmaster
				htmlEmailAsAttachment = 0
			}
			user {
				to_email = email
				to_name = name
				subject = Dein Anliegen von [webseite]
				sender_email = webmaster@xxx
				sender_name = Webmaster
				replyto_email = DeineEmailAdresse
				replyto_name = TEXT
				replyto_name.value = Deine Name
				htmlEmailAsAttachment = 0
		 	}
		}
		4.class = Finisher_Redirect
		4.config {
			redirectPage = 233
		}
	}
}

newsletter.xml

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
	<data type="array">
		<languageKey index="default" type="array">
			<label index="name">Name</label>
			<label index="email">E-Mail</label>
			<label index="submit">Send</label>
			<label index="is_error">One or more errors occoured while filling the form!</label>
			<label index="error_name_required">Enter your name!</label>
			<label index="error_email_required">Enter your E-mail address!</label>
			<label index="error_email_email">E-mail address must be valid syntax!</label>
			<label index="required_fields">Fields marked with * are required!</label>
		</languageKey>
		<languageKey index="de" type="array">
			<label index="name">Name</label>
			<label index="email">E-Mail</label>
			<label index="submit">Absenden</label>
			<label index="is_error">Beim Absenden des Formulars sind ein paar Fehler aufgetreten:!</label>
			<label index="error_name_required">Bitte gib Deinen Namen an!</label>
			<label index="error_email_required">Bitte gib Deine E-Mail-Adresse an!</label>
			<label index="error_email_email">Die eingetragene E-Mail-Adresse ist ungültig!</label>
			<label index="required_fields">Felder mit * sind Pflichtfelder!</label>
		</languageKey>
	</data>
</T3locallang>

newsletter.html

<!-- ###TEMPLATE_FORM1### begin -->
<div id="formhandler_newsletter_form">
	###ERROR###
	<form method="post" action="###REL_URL###">
		<p>###LLL:required_fields###</p>
		<input type="hidden" name="formhandler[submitted]" value="1" />
		<dl>
			<dt><label for="name">###LLL:name### ###required_name###</label></dt>
			<dd><input type="text" ###is_error_name### name="formhandler[name]" id="name" value="###value_name###"/></dd>
		</dl>
		<dl>
			<dt><label for="email">###LLL:email### ###required_email###</label></dt>
			<dd><input type="text" ###is_error_email### name="formhandler[email]" id="email" value="###value_email###"/></dd>
		</dl>
		<dl>
			<dd><input type="submit" value="###LLL:submit###" ###submit_nextStep###/></dd>
		</dl>
	</form>
</div>
<!-- ###TEMPLATE_FORM1### end -->
 
<!-- ###TEMPLATE_EMAIL_USER_PLAIN### begin -->
Hallo ###value_name###,
 
Du hast Dich soeben für meinen Newsletter auf [webseite] angemeldet.
Bitte klicke auf den folgenden Link, um die Registrierung abzuschließen:
 
###value_authCodeUrl###
<!-- ###TEMPLATE_EMAIL_USER_PLAIN### end -->
 
<!-- ###TEMPLATE_EMAIL_USER_HTML### begin -->
<p>Hallo ###value_name###</p>
<p>Du hast Dich soeben für meinen Newsletter auf [webseite] angemeldet.<br />
Bitte klicke auf den folgenden Link, um die Registrierung abzuschließen:</p>
<p><a href="###value_authCodeUrl###" target="_blank">Newsletteranmeldung bestätigen</a></p>
<!-- ###TEMPLATE_EMAIL_USER_HTML### end -->
 
<!-- ###TEMPLATE_EMAIL_ADMIN_PLAIN### begin -->
Hallo Admin,
 
Soeben hat sich ###value_name### (###value_email###) für den Newsletter auf [webseite] angemeldet.
 
Dein Server
<!-- ###TEMPLATE_EMAIL_ADMIN_PLAIN### end -->
 
<!-- ###TEMPLATE_EMAIL_ADMIN_HTML### begin -->
<p>Hallo Admin,</p>
<p>Soeben hat sich ###value_name### (###value_email###) für den Newsletter auf [webseite] angemeldet</p>
<p>Dein Server</p>
<!-- ###TEMPLATE_EMAIL_ADMIN_HTML### end -->
 
<!-- ###TEMPLATE_SUBMITTEDOK### begin -->
<table>
  <tr>
    <td>###LLL:name###</td>
    <td>###value_name###</td>
  </tr>
  <tr>
    <td>###LLL:email###</td>
    <td>###value_email###</td>
  </tr>
</table>
<!-- ###TEMPLATE_SUBMITTEDOK### end -->

newsletter.css

#formhandler_newsletter_form {
	width: 100%;
}
 
#formhandler_newsletter_form .error ul {
	margin: 0;
}
 
.errorField {
	background-color: #FF0000;
}

Die eine Zeile TypoScript

<INCLUDE_TYPOSCRIPT: source="FILE:fileadmin/templates/formhandler/newsletter.ts">

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Die Google Wetter API ist leider nicht dokumentiert, ist eigentlich auch nur für die Weather-Widgets in iGoogle gedacht. Die Standard-API liefert zudem nicht unbedingt hübsche Icons. Vorteil ist allerdings, dass Sie eine Wetter-Vorhersage über mehrere Tage liefert. Glücklicherweise ist es nicht so schwer die Wetter-Vorhersage auf der eigenen TYPO3-Website anzuzeigen und dazu eigene Symbole zu verwenden.

Man kann natürlich extra eine kleine TYPO3-Extension schreiben, ist aber unnötig, da ja keine Daten (in der Datenbank) gespeichert werden müssen. Es genügt, wenn man eine sogenannte User-Function schreibt und diese per Marker in die Website einfügt. Unsere User-Function ist auch schon so vorbereitet, dass man eigene Wetter-Icon verwenden und die Location einfach im TYPOscript editieren kann, aber dazu später mehr.

Schritt 1: Marker in HTML-Template einfügen

An die Stelle wo später das Wetter-Modul ausgegeben werden soll, wird ein Marker im Template angelegt, z.B.:

<div>###WETTER###</div>

Schritt 2: Marker im TYPOscript enbinden

In dem Tutorial verwenden wir ein klassisches TYPO3 Marker-Template und fügen den Marker im page-Objekt hinzu, in meinem Fall:

page.10 = TEMPLATE
page.10 {
  ...
  marks {
    WETTER < lib.weather
    ...
  }
}

Schritt 3: Die PHP User-Funktion für die Google-Wetter API Abfrage

Zwingend notwendig für das Einbinden einer eigenen PHP-Datei über eine User-Function in TYPO3 sind folgende 3 Punkte:

•    Dateiname beginnt mit “user_”
•    Die PHP-Datei enthält eine Klasse die mit “user_” beginnt
•    die PHP-Funktion übergibt mit “return” die Inhalte an TYPO3

Schritt 4: User-Function in TYPO3 einbinden

Die User-Function wird jetzt in TYPO3 eingebunden und über die Variablen konfiguriert

/**
* lib.weather
* @description:    wetter ausgabe in html
*/
includeLibs.weather = fileadmin/scripts/user_weather.php
 
lib.weather = USER
lib.weather {
  userFunc = user_weather->get
  poi = Hamburg
  path = /fileadmin/templates/img/wetter-icons/
  png = 1
}

Im cObject USER können wie schon erwähnt Variablen definiert werden. Für die Location, für den das Wetter über die Weather-API abgerufen werden soll, füllt man die Variable “poi” mit dem Ort, in unserem Fall “Hamburg”. Zudem kann man in “path” den Pfad zu den eigenen Wetter-Symbolen angeben. Ist die Variable nicht gefüllt, werden die Standard Wetter-Symbole von Google verwendet.

Folgende Wetter-Zustände kennt die Google Wetter API (Quelle: www.web-spirit.de):

chance_of_rain
sunny
mostly_sunny
partly_cloudy
mostly_cloudy
chance_of_storm
showers
rain
chance_of_snow
cloudy
mist
storm
thunderstorm
chance_of_tstorm
sleet
snow
icy
dust
fog
smoke
haze
flurries

Wir haben unsere eigenen Wetter-Icons als PNG-Grafiken mit Alpha-Transparenz abgespeichert. In diesem Fall muss die Variable “png” auf 1 gesetzt werden, weil dann die Wetter-Dateiendungen von GIF auf PNG in der user_weather.php umgeschrieben wird.

Ein schönes Wetter-Icon Set findet man bei graphicriver.net.

Demo-Screenshot

Nachdem das fertige Wetter-Modul mit CSS gestaltet wurde, sieht es so aus:

Download

PHP-Datei als TXT-Version zum Download: user_weather.php.txt

Hinweis

Da es keine offizielle Google API ist, ist es nicht sicher wie lange die API noch zur Verfügung steht und ob die Verwendung für die eigene Website erlaubt ist. Bisher sind im Web dazu weder positive noch negative Meinungen zu finden. Wer dazu mehr weiß, kann gerne einen Kommentar posten. Habt ihr die Google Weather API schon in Projekten eingesetzt? Wer Verbesserungsvorschläge für die PHP-Userfunc hat, bitte kommentieren! Ich hatte dabei Unterstützung von Anja, danke dafür!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Das TypoScript trennt dann mit dem “substring” den alten Pfad ab und setzt mit dem “innerWrap” einen neuen Pfad vor das Bild. Mit dem HTMLParser werden dann die “height” und “width” Attribute gelöscht, sodass die Größe durch die Datei selbst bestimmt wird. Auch wenn das Auseinanderschneiden des HTML nicht sauber ist, war es die einzig funktionierende Möglichkeiten eigene Icons für verschiedene Datei-Typen bereitzustellen (nur für tt_news).

plugin.tt_news.newsFiles {
  target = _blank
  size.wrap = <span>|</span>
  stdWrap {
    substring = 49
    innerWrap = <img src="fileadmin/images/icons/ |
    HTMLparser = 1
    HTMLparser {
      allowTags = a,img,span
      tags.img.fixAttrib.width.unset = 1
      tags.img.fixAttrib.height.unset = 1
    }
  }
}

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Dieser Artikel soll einen kurzen Einblick geben, wie leicht sich das Modul um eigene Berichte erweitern lässt.

Die System Extension reports liefert zwei Interfaces mit, je nach dem, was man tun möchte.

interface tx_reports_StatusProvider { }

tx_reports_StatusProvider wird verwendet, wenn man sich in den bestehenden Statusbericht einklinken möchte und diesen um einen eigenen Test erweitern möchte.

interface tx_reports_Report { }

Mit tx_reports_Report kann ein komplett eigenständiger Bericht erstellt werden.

Statusbericht erweitern

In der eigenen Extension wird eine Datei class.tx_myext_report_mystatus.php angelegt, der Ordnung halber idealerweise in einem Unterordner “reports”. Die Grundstuktur kann so aussehen:

class tx_myext_report_MyStatus implements tx_reports_StatusProvider {
	/**
	 * Constructor for class tx_myext_report_MyStatus
	 */
	public function __construct() {
		$GLOBALS['LANG']->includeLLFile('EXT:myext/report/locallang.xml');
	}
 
	/**
	 * do custom check
	 *
	 * @see typo3/sysext/reports/interfaces/tx_reports_StatusProvider::getStatus()
	 * @return array
	 */
	public function getStatus() {
		$reports = array();
 
		$status = t3lib_div::makeInstance('tx_reports_reports_status_Status',
			$GLOBALS['LANG']->getLL('title'),
			$GLOBALS['LANG']->getLL('value'),
			$GLOBALS['LANG']->getLL('message'),
			tx_reports_reports_status_Status::OK
		);
 
		$reports[] = $status;
 
		return $reports;
	}
}

Außer der im Beispiel verwendeten Severity OK gibt es noch WARNING, ERROR, INFO und NOTICE.
Damit die neue Klasse von TYPO3 erkannt wird, muss noch eine ext_autoload.php erstellt werden. Über die Extension extdeveval kann man das auch automatisch erledigen lassen.

Zum Schluss muss nur noch in ext_tables.php der neue Status Provider registriert werden:

if (TYPO3_MODE == 'BE') {
	$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']['tx_reports']['status']['providers']['myext'] = array('tx_myext_report_MyStatus');
}

eigenständiger Bericht

Für einen neuen Bericht muss ext_tables.php wie folgt erweitert werden:

if (TYPO3_MODE == 'BE') {
	$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['reports']['tx_myext']['myreport'] = array(
		'title'       => 'LLL:EXT:myext/locallang.xml:report_myreport_title',
		'description' => 'LLL:EXT:myext/locallang.xml:report_myreport_description',
		'report'      => 'tx_myext_report_MyReport',
		'icon'        => 'EXT:myext/reports/tx_myext_report.gif'
	);
}

Die dazugehörige class.tx_myext_report_myreport.php sieht dann so aus:

class tx_myext_report_MyReport implements tx_reports_Report {
 
	protected $reportsModule;
 
	/**
	 * constructor for class tx_myext_report_MyReport
	 */
	public function __construct(tx_reports_Module $reportsModule) {
		$this->reportsModule = $reportsModule;
 
		$this->reportsModule->doc->addStyleSheet(
			'tx_myext',
			'../' . t3lib_extMgm::siteRelPath('myext') . 'resources/css/reports/myreport.css'
		);
	}
 
	public function getReport() {
		$content = 'Content of my report';
 
		return $content;
	}
}

Auch hier muss die ext_autoload.php entsprechend angepasst werden.

Fazit

Mit wenigen Zeilen Code können der Statusbericht erweitert oder eigenständige Berichte erstellt werden. Für die Admins von TYPO3 Webseiten bieten die Berichte einen großen Mehrwert, da sie so schnell neue oder geänderte Zustände erkennen können.

Die eingangs genannten Extensions bieten Inspirationen, was man alles machen kann. Viel Spaß beim ausprobieren!

(Achtung: in meinen Code Beispielen hat es die Pfeile zerlegt. &gt; muss entsprechend durch einen Pfeil nach rechts ersetzt werden!)

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!