Hallo noch mal, okeee - so groß sind die Erfahrungen damit dann wohl noch nicht.
Aber genau darum ging es mir. Dass der intern mit Typoscript arbeitet war klar, sieht man beim Blick in den Quellcode.
Ich hab jetzt zwar nicht mit Milliarden von Antworten gerechnet, aber hatte das ganz bewusst mal offen gelassen. Und gar nicht auf kleine oder große Menüs reduzieren wollen. Eben WEIL ich vermute, dass es je nach Größe/Typ der eine oder der andere Weg der sinnvollere ist.
Deshalb Danke für eure Beiträge, auch wenn sie mir leider nicht wirklich weiter geholfen haben ;-)
Liebe Grüße, André Am 12.09.2017 um 09:38 schrieb 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é
_______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
