[TYPO3-german] TS Inhalt der Spalten beeinflusst Template

Stephan Schuler stephan.schuler at netlogix.de
Sat Aug 7 14:39:20 CEST 2010


Es gibt Tage an denen sollte man besser im Bett bleiben.
Der Inhalt meiner E-Mail für die von mir grade Korrektur und Entschuldigung
kamen wurde grade mit "you are not allowed ..." abgelehnt. Deshalb hier
nochmal, als Absender die richtige E-Mail-Adresse und die in meiner vorher
genannten Dinge habe ich bereits korrigiert ...


Hallo Marco.



   - Das TYPO3 Content-Object TEMPLATE hat ein Attribut "template".
   - Im Innhalt dieses "template"-Attributs kannst du Marker und Subparts
   verwenden die du dann über die entsprechenden Attribute des TEMPLATE-Objekts
   austauschst.
   - Das "template"-Attribut selbst ist wieder ein Content-Objekt. Du kannst
   also TEXT, COA, USER, FILE oder wiederum TEMPLATE verwenden für das
   "template"-Attribut verwenden.


Ein kleines Beispiel (ohne es auszuprobieren):

lib.content = CONTENT
lib.content {

table = tt_content
pidInList = this
orderBy = sorting

}
page = PAGE

page.10 = TEMPLATE
page.10 {

template = COA

template {

10 = TEXT

10 {

value = Ich bin die Überschrift von ###PAGETITLE###

wrap = <h1>|</h1>

}

20 = TEXT

20.value(

Und hier kommt der Inhalt:<br />

###CONTENT###

<hr />

Ich bin der Footer.

)

}

marks {

PAGETITLE = TEXT

PAGETITLE.data = page:title

CONTENT < lib.content

}

}

}

http://typo3.org/documentation/document-library/references/doc_core_tsref/4.1.0/view/8/9/
http://typo3.org/documentation/document-library/references/doc_core_tsref/4.1.0/view/8/26/



Du kannst das TEMPLATE-Objekt natürlich an jeder beliebigen Stelle verwenden
an der du grundsätzlich ein cObject hast.
Heißt: Du kannst auch als Renderingmechanismus für ein tt_content ein
TEMPLATE einspannen. Das ist zwar eine (in globaler Verwendung) eher
schlechte Idee weil das tt_content-Objekt (das Renderingvorschrift für alle
tt_content-Datensätze dient) ein recht ausgefeiltes Konstrukt an
CASE-Objekten ist; aber machbar ist das trotzdem.


Zu deiner Idee, abhängig von Spalteninhalten das Layout dynamisch
zu verändern:
Ich würde hier mit Registern arbeiten und den eigentlichen Switch dann mit
dem CASE-Objekt durchführen.

page = PAGE
page {

10 = LOAD_REGISTER
10 {

layoutType = COA

layoutType {

10 = TEXT

10.value = col

20 = TEXT

20 {

value = _1

if.isTrue.numRows < styles.content.getLeft

}

30 = TEXT

30 {

value = _2

if.isTrue.numRows < styles.content.get

}

40 = TEXT

40 {

value = _3

if.isTrue.numRows < styles.content.getRight

}

}

}
20 = CASE
20 {

key.data = register : layoutType


col_1 = TEXT

col_1.value = Ich bin nur die erste Spalte


col_2 < .col_1

col_2.value = Ich bin nur die zweite Spalte


col_3 < .col_1

col_3.value = Ich bin nur die dritte Spalte


col_1_2 < .col_1

col_1_2.value = Ich bin alles außer die dritte Spalte


col_2_3 < .col_1

col_2_3.value = Ich bin alles außer die erste Spalte


col_1_3 < .col_1

col_1_3.value = Ich bin alles außer die zweite Spalte


col_1_2_3 < .col_1

col_1_2_3.value = Ich bin alle Spalten


}
30 = RESTORE_REGISTER

}


Ich schiebe also zunächst einen String der inhaltsabhängig "col_1", "col_2",
"col_3", "col_1_2", "col_2_3", "col_1_3" oder  col_1_2_3" lautet in das
Register "layoutType" und wende abhängig vom berechneten String ein
vollständig anderes Layout an. Das ich hier keine TEMPLATEs sondern TEXTe
verwendet hab ... spielt ja keine Rolle.

http://typo3.org/documentation/document-library/references/doc_core_tsref/4.1.0/view/8/18/
http://typo3.org/documentation/document-library/references/doc_core_tsref/4.1.0/view/8/17/



Ich glaube aber, dass du ein eher konzeptionelles Problem hast. Wenn du die
Spalten 1-4 verwendetst dann hat jede Spalte ihren Platz. Es gibt Seiten auf
denen du dem Redakteur in die Spalten 1 und 4 Inhalt eingeben lassen willst.
Die Seiten sollen im Frontend genauso aussehen wie Seiten die der Redakteur
mit den Spalten 1-4 gefüllt hat, nur dass in die Spalten 2 und 3 per
Typoscript irgend welche Inhalte kommen.
Es gibt also Situationen in denen eine automatische Berechnung
welche Spalten grade verwendet werden sollen nicht das gewünschte
Ergebnis liefern.

Ich würde dir hier eher zu Templavoila raten.
Zunächst malt dir dein Grafiker ein paar coole Layoutvarianten in Photoshop.
Einspaltig, zweispaltig, dreispaltig, mit oder ohne Teaser, Teaser über
Spalte eins und zwei mit danebenstehnder dritter Spalte, Teaser über alle
drei Spalten, und so weiter. Du und dein Grafiker, ihr überlegt euch also
vorher sehr sehr genau, welche unterschiedlichen Layoutvarianten ihr
eigentlich haben wollt.
Dann werden die einzelnen Layoutvarianten in ein HTML umgesetzt, jedes HTML
in ein Templavoila-Template-Objekt gemappt.
Der Redakteur wühlt ab jetzt im Seiten-Record, welche Layoutvariante er
grade verwenden möchte. Im Page-Module hat er dann auch wirklich nur die
Spalten zur Verfügung, die er auch wirklich verwenden kann.

Was ich an deinem Konzept überhaupt nicht mag: Das Layout könnte sich von
jetzt auf gleich alleine dadurch vollständig verändern dass ein Redakteur
Inhalt in eine zusätzliche Spalte schreibt.

Beispiel:
Ich habe ein zunächst zweispaltiges Layout. Der Redakteur schreibt Texte in
diese beiden Spalten und lässt die anderen leer. Weil das Redakteure gerne
so machen (jedenfalls die die aus der Werbebranche Bereich "Print" kommen)
passt er seinen Inhalt und seine Formulierungen so an, dass das Textbild als
zweispaltiges Layout schön aussehen. Jetzt kommt nach einer Woche ein
anderer Redakteur und schreibt in die dritte Spalte "besuchen Sie auch unser
Schwimmbad" weil er das da gerade für notwendig hält. Und was passiert
jetzt? Nicht nur dass jetzt aus zwei Spalten im Frontend plötzlich drei
werden, evtl. liegt jetzt (weil dein Layoutkonstrukt das eben so vorgibt)
die rechte Spalte des vorher zweispaltigen Textes unter der vorher linken
Spalte und hat eine leicht andere Hintergrundfarbe.

Oder der Redakteur will (weil er es schön findet) ein Gedicht dreispaltig in
der mittleren Spalte linksbündig anordnen, die linke und rechte Spalte
sollen bewusst leer bleiben. Zentrieren geht nicht weil zentrierter Text
schwer zu lesen ist, einspaltig linksbündig ist Mist weil sonst rechts so
ein enorm großer freier Kasten entsteht. Der Redakteur will hier ganz
bewusst zwei von drei Spalten leer angezeigt bekommen. Durch deinen
Automatismus kriegt er das aber nicht hin.


Grundsätzlich: Bitte bitte bitte nichts konfigurieren, das "Magic" tut die
der Redakteur im Zweifelsfall nicht versteht. Wenn es unterschiedliche
Layouts gibt dann sollte der Redakteur die auch selbst wählen können. Ein
Automatismus ist hier nur verwirrend.


Grüße,


Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Internet: http://media.netlogix.de




Am 7. August 2010 14:16 schrieb Stephan Schuler <stephan.schuler at netlogix.de
>:
> ... ich sollte mir angewöhnen, meine E-Mails vorher nochmal zu lesen
> bevor ich sie losschicke. Gerade wenn "so dass man es möglichst
> versteht" Ziel einer E-Mail ist stelle ich meine Sätze gerne x mal um.
> Gefahr, Gefahr.
>
> Inhaltlicher Fehler: ".layout1" im CASE ist natürlich ".col_1".
>
>
>
> Am 7. August 2010 14:10 schrieb Schuler, Stephan <mail at g4n.de>:
>> Hallo Marco.
>>
>>
>> Das TYPO3 Content-Object TEMPLATE hat ein Attribut "template".
>> Innhalt dieses "template"-Attributs kannst du Marker und Subparts
>> verwenden die du dann über die entsprechenden Attribute des
>> TEMPLATE-Objekts austauschst.
>> Das "template"-Attribut selbst ist wieder ein Content-Objekt. Du
>> kannst also TEXT, COA, USER, FILE oder wiederum TEMPLATE verwenden.
>>
>> Ein kleines Beispiel (ohne es auszuprobieren):
>>
>> lib.content = CONTENT
>> lib.content {
>>  table = tt_content
>>  pidInList = this
>>  orderBy = sorting
>> }
>> page = PAGE
>> page.10 = TEMPLATE
>> page.10 {
>>  template = COA
>>  template {
>>    10 = TEXT
>>    10 {
>>      value = Ich bin die Überschrift von ###PAGETITLE###
>>      wrap = <h1>|</h1>
>>    }
>>    20 = TEXT
>>    20.value(
>> Und hier kommt der Inhalt:<br />
>> ###CONTENT###
>> <hr />
>> Ich bin der Footer.
>>    )
>>  }
>>  marks {
>>    PAGETITLE = TEXT
>>    PAGETITLE.data = page:title
>>    CONTENT < lib.content
>>  }
>> }
>>
>>
http://typo3.org/documentation/document-library/references/doc_core_tsref/4.1.0/view/8/9/
>>
http://typo3.org/documentation/document-library/references/doc_core_tsref/4.1.0/view/8/26/
>>
>>
>>
>> Du kannst das TEMPLATE-Objekt natürlich an jeder beliebigen Stelle
>> verwenden an der du grundsätzlich ein cObject hast. Heißt: Du kannst
>> auch als Renderingmechanismus für ein tt_content ein TEMPLATE
>> einspannen. Das ist zwar eine (in globaler Verwendung) eher schlechte
>> Idee weil das tt_content-Objekt (das Renderingvorschrift für alle
>> tt_content-Datensätze dient) ein recht ausgefeiltes Konstrukt an
>> CASE-Objekten ist aber machbar ist das trotzdem.
>>
>>
>> Zu deiner Idee, abhängig von Spalteninhalten das Layout dynamisch zu
>> verändern: Ich würde hier mit Registern arbeiten und den eigentlichen
>> Switch dann mit dem CASE-Objekt durchführen.
>>
>> page = PAGE
>> page {
>>  10 = LOAD_REGISTER
>>  10 {
>>    layoutType = COA
>>    layoutType {
>>      10 = TEXT
>>      10.value = col
>>      20 = TEXT
>>      20 {
>>        value = _1
>>        if.isTrue.numRows < styles.content.getLeft
>>      }
>>      30 = TEXT
>>      30 {
>>        value = _2
>>        if.isTrue.numRows < styles.content.get
>>      }
>>      40 = TEXT
>>      40 {
>>        value = _3
>>        if.isTrue.numRows < styles.content.getRight
>>      }
>>    }
>>  }
>>  20 = CASE
>>  20 {
>>    key.data = register : layoutType
>>
>>    col_1 = TEXT
>>    col_1.value = Ich bin nur die erste Spalte
>>
>>    col_2 < .layout1
>>    col_2.value = Ich bin nur die zweite Spalte
>>
>>    col_3 < .layout1
>>    col_3.value = Ich bin nur die dritte Spalte
>>
>>    col_1_2 < .layout1
>>    col_1_2.value = Ich bin alles außer die dritte Spalte
>>
>>    col_2_3 < .layout1
>>    col_2_3.value = Ich bin alles außer die erste Spalte
>>
>>    col_1_3 < .layout1
>>    col_1_3.value = Ich bin alles außer die zweite Spalte
>>
>>    col_1_2_3 < .layout1
>>    col_1_2_3.value = Ich bin alle Spalten
>>
>>  }
>>  30 = RESTORE_REGISTER
>> }
>>
>>
>> Ich schiebe also zunächst einen String der inhaltsabhängig "col_1",
>> "col_2", "col_3", "col_1_2", "col_2_3", "col_1_3" oder "col_1_2_3"
>> lautet in das Register "layoutType" und wende abhängig vom berechneten
>> String ein vollständig anderes Layout an. Das ich hier keine TEMPLATEs
>> sondern TEXTe verwendet hab ... spielt ja keine Rolle.
>>
>>
http://typo3.org/documentation/document-library/references/doc_core_tsref/4.1.0/view/8/18/
>>
http://typo3.org/documentation/document-library/references/doc_core_tsref/4.1.0/view/8/17/
>>
>>
>>
>> Ich glaube aber, dass du ein eher konzeptionelles Problem hast. Wenn
>> du die Spalten 1-4 verwendetst dann hat jede Spalte ihren Platz. Es
>> gibt Seiten auf denen du dem Redakteur in die Spalten 1 und 4 Inhalt
>> eingeben lassen willst. Die Seiten sollen im Frontend genauso aussehen
>> wie Seiten die der Redakteur mit den Spalten 1-4 gefüllt hat, nur dass
>> in die Spalten 2 und 3 per Typoscript irgend welche Inhalte kommen. Es
>> gibt also Situationen in denen eine automatische Berechnung welche
>> Spalten grade verwendet werden sollen nicht das gewünschte Ergebnis
>> liefern.
>>
>> Ich würde dir hier eher zu Templavoila raten.
>> Zunächst malt dir dein Grafiker ein paar coole Layoutvarianten in
>> Photoshop. Einspaltig, zweispaltig, dreispaltig, mit oder ohne Teaser,
>> Teaser über Spalte eins und zwei mit danebenstehnder dritter Spalte,
>> Teaser über alle drei Spalten, und so weiter. Du und dein Grafiker,
>> ihr überlegt euch also vorher sehr sehr genau, welche
>> unterschiedlichen Layoutvarianten ihr eigentlich haben wollt.
>> Dann werden die einzelnen Layoutvarianten in ein HTML umgesetzt, jedes
>> HTML in ein Templavoila-Template-Objekt gemappt.
>> Der Redakteur wühlt ab jetzt im Seiten-Record, welche Layoutvariante
>> er grade verwenden möchte. Im Page-Module hat er dann auch wirklich
>> nur die Spalten zur Verfügung, die er auch wirklich verwenden kann.
>>
>> Was ich an deinem Konzept überhaupt nicht mag: Das Layout könnte sich
>> von jetzt auf gleich alleine dadurch vollständig verändern dass ein
>> Redakteur Inhalt in eine zusätzliche Spalte schreibt.
>> Beispiel:
>> Ich habe ein zunächst zweispaltiges Layout. Der Redakteur schreibt
>> Texte in diese beiden Spalten und lässt die anderen leer. Weil das
>> Redakteure gerne so machen (jedenfalls die die aus der Werbebranche
>> Bereich "Print" kommen) passt er seinen Inhalt und seine
>> Formulierungen so an, dass das Textbild als zweispaltiges Layout schön
>> aussehen. Jetzt kommt nach einer Woche ein anderer Redakteur und
>> schreibt in die dritte Spalte "besuchen Sie auch unser Schwimmbad"
>> weil er das da gerade für notwendig hält.
>> Und was passiert jetzt? Nicht nur dass jetzt aus zwei Spalten im
>> Frontend plötzlich drei werden, evtl. liegt jetzt (weil dein
>> Layoutkonstrukt das eben so vorgibt) die rechte Spalte des vorher
>> zweispaltigen Textes unter der vorher linken Spalte und hat eine
>> leicht andere Hintergrundfarbe.
>>
>> Oder der Redakteur will (weil er es schön findet) ein Gedicht
>> dreispaltig in der mittleren Spalte linksbündig anordnen, die linke
>> und rechte Spalte sollen bewusst leer bleiben. Zentrieren geht nicht
>> weil zentrierter Text schwer zu lesen ist, einspaltig linksbündig ist
>> Mist weil sonst rechts so ein enorm großer freier Kasten entsteht. Der
>> Redakteur will hier ganz bewusst zwei von drei Spalten leer angezeigt
>> bekommen. Durch deinen Automatismus kriegt er das aber nicht hin.
>>
>>
>> Grundsätzlich: Bitte bitte bitte nichts konfigurieren, das "Magic" tut
>> die der Redakteur im Zweifelsfall nicht versteht. Wenn es
>> unterschiedliche Layouts gibt dann sollte der Redakteur die auch
>> selbst wählen können. Ein Automatismus ist hier nur verwirrend.
>>
>>
>> Grüße,
>>
>>
>> Stephan Schuler
>> Web-Entwickler
>>
>> Telefon: +49 (911) 539909 - 0
>> E-Mail: Stephan.Schuler at netlogix.de
>> Internet: http://media.netlogix.de
>>
>>
>> Am 7. August 2010 09:49 schrieb Marco Brüggemann <marco at schauart.de>:
>>>
>>> Guten Morgen Bernd,
>>>
>>> Danke für deine frühe Antwort. ......
>>>
>>> bernd wilke schrieb:
>>>>
>>>> [...]
>>>>  das muss an etwas anderem liegen. vermutlich hast du keine
Einbindungen definiert?
>>>>
>>>>
>>>
>>> Ich habe eine Einbindung definiert ... Ich habe als Grundlage ein
funktionierendes Template Mit Datei genutzt ...
>>> ich hänge mal zwei Dateien an: einmal mein ausgelagertes TS mit Datei,
und einmal der Versuch mit mur TS
>>>
>>>> [...]
>>>>
>>>> dein Ansatz oben (Das was ich zitiert habe) ist schon ganz gut.
Natürlich gibt es dabei keine Marker/Subparts, sondern nur die Zahlen. Das
was normalerweise Marker sind ist hier 20 bis 90. [...]
>>>>
>>>
>>> ich habe damals recht viel an der Inhaltsausgabe von cssStyledContent
herrumgeschraubt (unprofessionell), dabei sind mir im TS Marker aufgefallen:
>>> bei tt_content.image.20.layout werden die Fälle für die Bildausrichtung
unterschieden und dann eine art Template mit Markern als TEXT genutzt
>>>
>>> 1 = TEXT
>>> 1.value = <div class="content_unit floatbox clearfix"><div
class="csc-textpic csc-textpic-right
csc-textpic-above###CLASSES###">###IMAGES## ####TEXT###</div><div
class="csc-textpic-clear"><!-- --></div></div>
>>>>
>>>> Etwas unschön sind deine unübersichtlichen DIV-tags. daher würde ich
folgende Struktur bevorzugen:
>>>>
>>>
>>> Diese Vielen DIV-tags finde ich auch nicht schön und sind einer
aufwendigen Schattenkonstruktion geschuldet die sich dynamisch an die
visuelle Page anpasst.
>>> Aber ich werde da noch was mit wraps machen.
>>> Am Rande: Wraps kann ich nicht direkt hintereinander verschachteln? also
>>>
>>> 10 = TEXT
>>> 10.value = Hallo
>>> 10.wrap = <div class="box01"> | </div>
>>> 10.wrap = <div class="box02"> | </div>
>>> [...]
>>> 10.wrap = <div class="box09"> | </div>
>>>
>>> die beste Lösung diese?
>>> 10 = TEXT
>>> 10.value = Hallo
>>> 10.wrap = <div class="box01"><div class="box02">[...]<div class="box09">
| </div></div></div></div></div></div></div></div></div>
>>>
>>> oder verschachteln mit Objekten? (weiss nicht genau ob die Syntax
stimmt)
>>> 10 = TEXT
>>> 10 {
>>>   10 = TEXT
>>>   10 {
>>>       10 = TEXT
>>>       10 {
>>>           10 = TEXT
>>>           10 {
>>>               10 = TEXT
>>>               10 {
>>>                   10 = TEXT
>>>                   10 {
>>> [...]
>>> 10 = TEXT
>>> 10.value = Hallo
>>> [...]
>>>                   }
>>>                   10.wrap = <div class="box04">
>>>               }
>>>               10.wrap = <div class="box05">
>>>           }
>>>           10.wrap = <div class="box06">
>>>       }
>>>       10.wrap = <div class="box07">
>>>   }
>>>   10.wrap = <div class="box08">
>>> }
>>> 10.wrap = <div class="box09">
>>>
>>> Oder was ich toll finden würde (wie bei den tt-content-markern)
>>> 10 = TEXT
>>> 10.value = <div class="box01"><div class="box02">[...]<div
class="box09"> ###MARKER###
</div></div></div></div></div></div></div></div></div>
>>> [...]
>>> irgendwo dann: nutze Objekt 10 als TEMPLATE und ersetze die MARKER mit
Inhalten. (weiss nicht wie)
>>>>
>>>> mitzählen geht vermutlich mit register-Variablen, Ich würde aber eher
passende wraps (spezielle CSS-Klassen) zuordnen, um einzelne 'Spalten' bzw.
Bereiche auszublenden. Oder das Layout wird nicht automatisch, sondern durch
den Redakteur in den Seiteneigenschaften festgelegt [2]
>>>>
>>>>
>>>
>>> Meine Vorstellungen sind ungefähr so:
>>>
>>> //Variablen
>>> Variable COUNTER = 0
>>> Variabel SPEICHER01 = leer
>>> Variabel SPEICHER02 = leer
>>> Variabel SPEICHER03 = leer
>>> Variabel SPEICHER04 = leer
>>>
>>> //Funktion um die Inhalte zwischenzuspeichern
>>> FUNKTION InhaltInSpeicher (INHALT, COUNTER){
>>>   wenn COUNTER == 1
>>>   DANN
>>>   SPEICHER01 < INHALT
>>>
>>>   wenn COUNTER == 2
>>>   DANN
>>>   SPEICHER02 < INHALT
>>>
>>>   wenn COUNTER == 3
>>>   DANN
>>>   SPEICHER03 < INHALT
>>>
>>>   wenn COUNTER == 4
>>>   DANN
>>>   SPEICHER04 < INHALT
>>> }
>>>
>>> //Prüfen ob Inhalte da sind und speichern in den Zwischenspeicher
>>> if.isTrue.numRows < styles.content.getRight
>>> DANN
>>> COUNTER = COUNTER+1
>>> InhaltInSpeicher (styles.content.getRight, COUNTER)
>>>
>>> if.isTrue.numRows < styles.content.get
>>> DANN
>>> COUNTER = COUNTER+1
>>> InhaltInSpeicher (styles.content.get, COUNTER)
>>>
>>> if.isTrue.numRows < styles.content.getLeft
>>> DANN
>>> COUNTER = COUNTER+1
>>> InhaltInSpeicher (styles.content.getLeft, COUNTER)
>>>
>>> if.isTrue.numRows < styles.content.getBorder
>>> DANN
>>> COUNTER = COUNTER+1
>>> InhaltInSpeicher (styles.content.getBorder, COUNTER)
>>>
>>> //Template auswählen und Speicher in Marker eintragen
>>> wenn COUNTER ==1
>>> dann nutze Template1
>>> füge in Marker ###SPALTE01### den Inhalt aus SPEICHER01
>>>
>>> wenn COUNTER ==2
>>> dann nutze Template2
>>> füge in Marker ###SPALTE01### den Inhalt aus SPEICHER01
>>> füge in Marker ###SPALTE02### den Inhalt aus SPEICHER02
>>>
>>> wenn COUNTER ==3
>>> dann nutze Template3
>>> füge in Marker ###SPALTE01### den Inhalt aus SPEICHER01
>>> füge in Marker ###SPALTE02### den Inhalt aus SPEICHER02
>>> füge in Marker ###SPALTE03### den Inhalt aus SPEICHER03
>>>
>>> wenn COUNTER ==4
>>> dann nutze Template4
>>> füge in Marker ###SPALTE01### den Inhalt aus SPEICHER01
>>> füge in Marker ###SPALTE02### den Inhalt aus SPEICHER02
>>> füge in Marker ###SPALTE03### den Inhalt aus SPEICHER03
>>> füge in Marker ###SPALTE04### den Inhalt aus SPEICHER04
>>>
>>>> Bernd
>>>> [1] http://ug.typo3-nrw.de/mastertemplate.html
>>>> [2] http://www.pi-phi.de/191.html
>>>>
>>>>
>>>
>>> Danke nochmal ... und auch Danke für die LINKS
>>>
>>> Marco
>>>
>>> _______________________________________________
>>> TYPO3-german mailing list
>>> TYPO3-german at lists.typo3.org
>>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
>>
>


More information about the TYPO3-german mailing list