Hallo Michael,
Am 12.03.2016 um 08:51 schrieb Michael Kasten:
Hallo Dieter,
Am 11.03.2016 um 23:36 schrieb Dr. Dieter Porth:
Hallo Michael,
die Fluid-Variablen habe ich in meinen letzten Aufsetzungen nie benutzt.
Dann wird es aber schwer die Frage zu beantworten :)
Stimmt. Aber vor drei Jahren, als ich mit TYPO3 anfing, habe ich sie
benutzt. ich empfand sie aber als unübersichtlich.
Es ist aber einfach schöner, wenn man das HTML möglichst nur im Template
findet und möglichst wenig HTML ins TypoScript auslagert.
(Insbesondere aber auch, weil TypoScript auch nicht sehr debug
freundlich ist. ;-) )
Zur Performance: Ich rechne über'm dicken Daumen geschätzt mit 80 bis 150ms
pro Partialaufruf.
Solange die Zahl der Partials pro Seite gut unter 50 bleibt, ziehe ich den
systematischen Aufbau
der Fluid-Templates dem TypoScript-Gefrickel vor, selbst wenn das Typoscript um
einiges schneller
ist.
Hast du in Bezug auf die Zeiten entsprechende Erfahrungswerte gemacht oder gibt
es dazu irgendwelche
Quellen?
Ja. Ich hatte mal eine längtere größere Liste ausgegeben, die viele
Partials (über 500) benutzte, welche ihrereseits einige Viewhelper noch
nutzten. Daher die Erfahrungswerte von 80-150ms.
Explizite systematische Messungen und standardisierte Benchmark-Tests
habe ich allerdings nie gemacht.
Droht die Zahl der Partialaufrufe pro Seitenaufruf auf über 50 zu steigen, ist
zu überlegen, ob
man nicht mit einem eigenen Service die Daten direkter zusammenstellt oder ob
man nicht eine
Extension mit geeigneten Datenstrukturen anlegt. In diesem Fall ist
eigenständiges Programmieren
meist performanter als die TypoScript-Lösung
Ich denke das kommt auf den Anwendungsfall an, bei 50 Partials je Seite wäre
ich wahrscheinlich eher
geneigt meine Templatestruktur einzudampfen. Wenn ich mal 100ms je Partial bei
durchschnittliche 30
Partials annehme (ich müsste mal durchtesten was in unseren Projekten da so im
Schnitt verwendet
wird) dann habe ich ja schon stattliche 3 Sekunden nur für das Templating bei
einer Seite die nicht
aus dem Cache kommt, da kann man ja mal drüber reden.
Da stimme ich dir zu. 50 Partials kommen zum Beispiel schnell zustande,
wenn man Schleifen nutzt.
Bei der Wahl zwischen TypoScript und Fluid-Templates ist die Frage nach der
Performance eher
kontraproduktiv. Wichtigere Kriterien sind meines Erachtens Übersichtlichkeit,
Lesbarkeit und
natürliche Datenstrukturen
Deine Kriterien setze ich einfach mal bei einer Projektumsetzung voraus,
beantworten aber leider
auch nicht die Frage ob es Differenzen zwischen den beiden hinterfragen
Einbindungsmethoden gibt und
ich verstehe auch nicht warum eine Frage nach der Performance als
kontraproduktiv zu werten ist?
Sie ist nicht kontraproduktiv. Ich würde das Kriterium nur nicht an die
erste Stelle setzen. Wenn Performance kritisch wird, dann gibt es viele
andere Stellschrauben, an welchen man zuerst drehen sollte, denke ich.
Man kann die Infrastruktur optimieren (Verteilter Server, Image-Server,
Varnisch, ...) oder man speckt das template ab. Mehr Javascript auf der
Seite (AJAX, dynamische Layouts + JSON, ...)
Offensichtlich war meine Fragestellung doch sehr unklar, mir geht es ja nicht
um die Frage wo ich
Funktionalitäten umsetze (also in deinem Beispiel ob ich das Menü in TS
erstelle und anschließend
einbinde oder alternativ direkt ein Fluidmenü benutze)
Sondern ob es Erfahrungen gibt hinsichtlich von Performanceunterschieden bei
der Verwendung von
Fluidtemplate variables oder von TS lib Objekten innerhalb von Fluid.
Im obigen Project habe ich dann die Datensätze (500) per Controller
direkt in eine Variable schreiben lassen und diese dann im
Extensiontemplate per f-Viewhelper gerendert. Dies kommt der Zuweisung
im Fluid-Template sehr nahe und war damals ein echter Performance-Sprung.
Folgendes zur Überlegung:
Nach meinen Erfahrungen und meinem Bild im Kopf ist das Ausgabereultat
eine Scriptes in TypoScript immer ein String. Die Übergabe eine Strings
an eine Template-Variable ist ein Zuweisungsvorgang
Jeder Viewhelper ist dagegen als Klasse definiert. Die Nutzung von
Klassen bringt im Vergleich zu einer Zuweiisung immer einen
bürokratischen Overhead mit sich. (Klasseninstanzierung,
Methodenaufrufe, ...).
Auszug aus einer Cache-Datei aus dem typo3temp-Ordner. (Ich vermute,
dass $currentVariableContainer auch die zugewiesenen Template-Variablen
enthalten könnte - habe es aber nicht getestet.)
/**
* Main Render function
*/
public function
render(\TYPO3\CMS\Fluid\Core\Rendering\RenderingContextInterface
$renderingContext) {
$self = $this;
$currentVariableContainer =
$renderingContext->getTemplateVariableContainer();
$output0 = '';
// Rendering ViewHelper
TYPO3\CMS\Fluid\ViewHelpers\Format\HtmlspecialcharsViewHelper
$arguments1 = array();
$arguments1['value'] =
\TYPO3\CMS\Fluid\Core\Parser\SyntaxTree\ObjectAccessorNode::getPropertyPath($currentVariableContainer->getOrNull('menu'),
'label', $renderingContext);
$arguments1['keepQuotes'] = false;
$arguments1['encoding'] = NULL;
$arguments1['doubleEncode'] = true;
$renderChildrenClosure2 = function() {return NULL;};
$value3 = ($arguments1['value'] !== NULL ? $arguments1['value'] :
$renderChildrenClosure2());
$output0 .= (!is_string($value3) ? $value3 : htmlspecialchars($value3,
($arguments1['keepQuotes'] ? ENT_NOQUOTES : ENT_COMPAT),
($arguments1['encoding'] !== NULL ? $arguments1['encoding'] :
\TYPO3\CMS\Fluid\Core\Compiler\AbstractCompiledTemplate::resolveDefaultEncoding()),
$arguments1['doubleEncode']));
$output0 .= ' <select class="form-control t3-js-jumpMenuBox" name="';
// Rendering ViewHelper
TYPO3\CMS\Fluid\ViewHelpers\Format\HtmlspecialcharsViewHelper
...
Mit besten Grüßen
Dieter
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
