[TYPO3-german] Menügenerierung: Performancevergleich Datenprozessor - Viewhelper

[Stefan Padberg]

Hallo in die Runde,

Bejamin Kott hat den DataProcessor für das Menü im Wesentlichen
entwickelt. Das Hauptmotiv war eine saubere Trennung zwischen
Frontend-Entwicklung und Backend-Entwicklung. Die Frontentwickler kamen
mit Typoscript nicht zurecht. Sie haben jetzt die Möglichkeit, sich mit
den menu-Fluidvariablen ihren eigenen Navi-HTML-Code zu schreiben.

Benjamin Kott erzählte auf dem TYPO3 Camp RheinRuhr letztes Jahr, dass
es ihm nicht möglich war, den DataProcessor von Typoscript-Code
freizuhalten. Typoscript ist offensichtlich eine äußerst mächtige
Konfigurationssprache, die sich nicht so leicht durch besser ins
Extbase-Umfeld passenden Code ersetzen lässt. Das war mal eine
erhellende Aussage von einem Core-Entwickler. Keiner der Core-Entwickler
will gegenwärtig Typoscript aufgeben.

Von daher ist davon auszugehen, dass der Dataprocessor etwas mehr an
Rechenzeit verbraucht als reines Typoscript. Wer also die vereinfachte
Handhabung mit den Fluidvariablen nicht benötigt, kann sich sein HMENU
natürlich immer noch selber schreiben.

Beste Grüße
Stefan



Am 11.09.2017 um 19:10 schrieb Dr. Dieter Porth:
> Hallo André,
> 
> wer falsche Fragen stellt, erhält auch mit Milliarden-schwerer Forschung
> immer sicher eines: falsche Antworten.
> 
> cObject ist eine Krücke für die ehemaligen TypoScriptler und der Feind
> jeden puren MVC-Konzeptes. Den Dataprozessor dagegen rechnet man noch
> zum Controller zu, weil er vorm ersten View alle Daten fertig zur
> Verfügung stellt.
> 
> Tendeziell bin ich schon am Überlegen, zukünftige Projekte ordentlich zu
> trennen, um  ein überschaubare Kontrolle für SEO-Text und
> domain-übergreifende Namespace-Eintragungen zum Beispiel für
> Bezahlservices Tageszeitungen-Cloud, Wetterdienste, ... zu haben.  Ich
> denke, meine zukünftigen Projekte könnten auch folgende TypoScript
> Konfiguration aufweisen:
> 
> page = PAGE
> page.headerData.10 = FLUIDTEMPLATE
> page.headerData.10 {..
> 
> TypoScript als Krücke im Rendering macht Webseiten meist unnötig
> kompliziert, weil es Rendering und Datenabfrage vermischt. TypoScript
> als Renderhilfe ist rationalisierungsfeindlich.
> 
> Welche Art von Menü meinst du? Meinst du zum Beispiel ein
> CSS-getriggerte responsive-Tab-DropDown-Menü, dass beim 'hover' im
> DropDown-Menü im Vorschaufeld einen Teaserbild mit Text zur Seite
> anzeigt, wobei sich das Dropdown des Menüs bis zu vier Ebenen tief sein
> kann,  oder meinst  ein einfaches List-Menü. Oder meinst du ein Menü, wo
> die Hintergrundfarbe bei den Links durch die Kategorien der Seite
> bestimmt wird und welches Vorschaubilder hat.
> 
> Für die Standardfälle ist vermutlich das TypoScript-Geraffel in der
> Ausführung schneller. Für die angedachten komplexeren Fälle wird man
> aber schon aus Clean-Code-Gründen und mit Blick auf die zukünftige
> Automatisierungen immer
> den Menü-Prozessor verwenden, weil er pflegbarer, leider modifizierbar
> und besser Daten und Ausgabe trennt.
> 
> Warum ist dir die Millisekunde Performance wichtig? Mir ist
> überschaubarer Code lieber als eine Mikrosekunde an Performance; denn
> wenn ein System langsam ist, habe ich die falsche Software, das falsche
> CMS und/oder ein falsches Konzept gewählt bzw. genauer: eine Antwort auf
> eine falsch gestellte Frage gefunden.
> 
> Mit besten Grüßen
> 
>       Dieter
> 
> 
> 
> Am 11.09.2017 um 11:03 schrieb André Spindler:
>> Hallo miteinander!
>>
>> Mit TYPO3 8(.5) wurde der Fluid Datenprozessor für Menüs eingeführt.
>>
>> Dazu ist noch relativ wenig online an Erfahrungen zu finden. Wird der
>> schon von euch verwendet?
>> Mich interessiert hier die Performance im Vergleich zur Einbindung
>> eines Menüs als HMENU per cObject-Viewhelper.
>>
>> Technisch macht der Datenprozessor ja genau das. Er erzeugt eine
>> typoscript-Konfiguration für ein HMENU und ruft dieses auf, um ein
>> json Array zu erzeugen. das wird dann an Fluid übergeben, welches
>> durchlaufen werden muss, um daraus das auszuliefernde HTML zu
>> generieren. Im Vergleich zur cObject-Einbindung aufwändiger. Aber
>> greifen hier möglicherweise Cache-Mechanismen von Fluid, welche das
>> abfangen. Gibt es vielleicht Unterschiede je nach Umfang des Menüs,
>> indem sich bei kleinen vielleicht eher cObject lohnt und bei großen
>> der Datenprozessor - oder umgekehrt?
>>
>> Danke und liebe Grüße,
>> André
>>
> 


-- 
Bergische Webschmiede
Dipl.-Ing. Stefan Padberg
TYPO3-Integrator und Webprogrammierer
:: Borner Str. 18 - 42349 Wuppertal
:: +49 202 97648355
:: +49 173 9219845
:: post at bergische-webschmiede.de
:: http://www.bergische-webschmiede.de