Hi David,
danke für die lange Antwort!
den Weg habe ich beschritten, als ich die Spaltenstruktur generell
beibehalten, aber FCEs ermöglichen wollte.
Wenn man auf diese Art ausschließlich neue Spalten anlegt ist es jedoch
uneffektiv und mit allen Nachteilen von TV behaftet.
Das wäre noch einen anderen Post wert ;) Ich habe bislang nur mit TV
gearbeitet und habe gar keine Vorstellung davon, welche Vorteile eine
Non-TV-Variante bieten könnte ;)
Vielleicht habe ich mich falsch ausgedrückt: Ich meinte den
"klassischen" Content Bereich bei z.B. einem deispaltigen Layout.
Dieser ist als "Content-Elements" angelegt...
Wenn ich es richtig verstehe, wird die Zahl für "oldStyleColumnNumber",
die ich in der DS des "Seiten-Templates" definiere, bei den in diesem
Bereich über das Backend angelegten Inhaltselementen in tt_content dann
in der Spalte "colPos" gespeichert, oder?
Wenn Du jetzt mehr Spalten haben möchtest (Ich habe manchmal mehr definiert,
sie auf der Webseite aber als Bereiche genutzt und nicht als Spalten), kannst
Du die im Page-TS definieren:
mod.SHARED.colPos_list = 0,1,2,3,4,5,6,7,8,9,10,123
D.h., in der DS kann ich ohne das obige Setup nur eine begrenzte Anzahl
von "Columns" verwenden? D.h. ein "oldStyleColumnNumber=999" in der DS
würde in der Spalte "colPos" in tt_content dann gar keine 999 erzeugen,
wen ich die 999 nicht mit "mod.SHARED.colPos_list" vorher setze? Jetzt
mal unabhängig von der Funktionalität des klassischen Page-Modules,
rein auf die Datensätze bezogen...
Hintergrund ist, daß es schwierig ist TV-CEs per TS zu adressieren, wenn sie
*nicht* als TypoScript-Objekt definiert sind wie z.B. *lib.meinElement*
Typoscript-Object Pfad ist klar, das ist ja kein Problem. Was heißt
schwierig? Meinst Du eher unmöglich? Gibts doch eigentlich nicht ;)
Gruss, Jan
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
