1.) Mir gelingt es weder mit dem Standard Rendering, noch einem eigenen,
in col2 auf irgend welche Daten (oder Registereinträge) zuzugreifen, die
in col1 vorhanden sind (oder gesetzt werden). Dies kann aber durchaus
auch an meinem mangelnden Wissen über LOAD_REGISTER liegen. Nach
oberflächlichem Blick in den Quellcode wird jede "column" nach Auslesen
gelöscht, was möglicherweise das dort gesetzte Register mit betrifft.
Habt Ihr hier vielleicht tieferen Einblick?
Mit LOAD_REGISTER wirst Du in dem Fall keinen Erfolg haben, weil die
Elemente nicht zwingend spaltenweise abgearbeitet werden, sondern
einzeln gerendert und in die passende Spalte gefüllt werden.
Das Einzige, was dabei berücksichtigt wird ist die Reihenfolge beim
Sorting, weil die dadurch automatisch auch innerhalb der Spalten passt.
Je nach Sorting-Wert kann es dabei aber vorkommen, dass Du bei 2 Spalten
eine Reihenfolge 1,2,2,1,1,2,1,2,1 renderst.
Erst wenn die Spalten befüllt sind, werden sie dann selbst gerendert und
mit entsprechenden Wraps umgeben.
Was funktioniert, ist wie im Default-Setup gezeigt, per LOAD_REGISTER
bestimmte Register für den Rendering-Vorgang eines Elements zu
beeinflussen, wobei danach zwingend ein RESTORE_REGISTER erfolgen
sollte, damit die Register nach dem Rendern nicht bei anderen Elementen
dazwischenschiessen. Aber Du kannst keine Werte von der einen in die
andere Spalte übergeben.
Es stellt sich die Frage, was Du konkret erreichen willst und ob dafür
nicht ggf. wirklich ein FLUIDTEMPLATE der sinnvollere Ansatz wäre.
2) Im Forge/Issue Tracker zu Gridelements kam eine kurze Diskussion zum
Rendering mittels Fluid auf -- über FLUIDTEMPLATE. Soll gehen, gelingt
mir aber nicht -- bzw. gelingt mir nicht im einzig sinnigen
Anwendungsfall: Ein Template für das gesamte Element samt Subcontent.
Die Doku schweigt sich darüber leider aus. Irgendwelche Ideen?
In der Doku gibt es den Abschnitt TypoScript, in dem zu Anfang der
Default-Setup-Block von Gridelements aufgelistet ist.
Dort steht:
# if you want to provide your own templating, just insert a cObject here
# this will prevent the collected content from being rendered directly
# i.e. cObject = TEMPLATE or cObject = FLUIDTEMPLATE will be available
from the core
# the content will be available via fieldnames like
# tx_gridelements_view_columns (an array containing each column)
# or tx_gridelements_view_children (an array containing each child)
# tx_gridelements_view_column_123 (123 is the number of the column)
# or tx_gridelements_view_child_123 (123 is the UID of the child)
Weiter hinten in der TypoScript-Referenz sind die einzelnen virtuellen
Felder nochmals aufgeführt.
Das alles in einem FLUIDTEMPLATE abzufrühstücken macht aber IMHO wenig
Sinn, weil Gridelements bereits auf der PHP-Ebene deutlich performantere
Vorarbeit leistet, wobei Du für einzelne Spalten oder deren Elemente ja
ebenfalls mit FLUIDTEMPLATE arbeiten kannst und es nicht beim Default
tt_content-Rendering belassen musst.
Wenn Du alles wirklich in einem einzigen FLUIDTEMPLATE erledigen willst,
wäre am ehesten das Feld tx_gridelements_view_children zu empfehlen,
weil da ungerenderte Rohdaten der Kinder liegen, die Du mit
entsprechenden Viewhelpern beliebig verarbeiten kannst.
HDH
Joey
--
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
