Hallo zusammen.
Abhängig von dem möglichen Parametern eines ViewHelpers lässt sich halt einfach nicht generisch bestimmen, ob der jetzt eine triviale oder komplexe Ausgabe hat. Ich nehm mal als Beispiel den ifViewHelper der als Parameter eine Condition hat und, wenn er nicht zusammen mit einem thenViewHelper und/oder einem elseViewHelper verwendet wird abhängig vom Rückgabewert dieser Condition wahlweise seine ChildNodes rendert oder nicht. Ich verbinde diesen ifViewHelper mit einem linkViewHelper der mir eine Seite verlinkt, diesen linkViewHelper mit einem zweiten und einem Stringvergleich und möchte prüfen, ob der erzeugte Link Cross-Domian wird oder nicht. Und abhängig von dieser Rückgabe lass ich dann wahlweise einen HTML-Code-Block produzieren der mir lediglich ein DIV und einen Link darin ausspuckt oder einen ganz anderen der die erste 10 Inhaltselemente der Zielseite in UL/LI packt, mit einer Pagination drum rum um von 0-9 auch noch 10-19 und weitere Inhaltselementsgruppen aufgelistet zu bekommen. Das Beispiel habe ich so natürlich nicht im Einsatz, nicht mal im Ansatz. Trotzdem wäre dieses Konstrukt möglich. Alleine wenn man den ifViewHelper betrachtet kann man natürlich immer sagen: Dazu lade ich mir keinen aufgeblasenen View, die Funktion kann ich viel leichter ohne Template abbilden. Aber bei den anderen sieht das schon anders aus. * Der (action.)linkViewHelper braucht ein Plugin, damit die NULL-Parameter definiert sind (controller und extension) * Der paginateViewHelper braucht sowohl ein Plugin damit sein grundsätzlicher definiert ist als auch ein QueryResultInterface damit er einen Query zum Verändern hat. Es ist -- und das ist eigentlich alles was ich bisher sagen wollte -- ganz häufig situationsabhängig, wie viel Framework ich drum rum brauche. Aber gerade der linkViewHelper und der ifViewHelper zeigen eigentlich intern schon wie hier die Lösung aussieht: Wenn diese Situation auftritt dann ist ein Service sinnvoll der die Arbeit erledigt und ein kleiner schmaler ViewHelper der den Service lediglich in Fluid zur Verfügung stellt. Immer dann wenn ich lediglich die Rückgabe in einem String in der Hand haben will spreche ich mit dem Service direkt, nicht mit dem ViewHelper. Was sicher jeder schon mal gemacht hat und was bei der Betrachtung auch so trivial ist dass es überhaupt nicht auf fällt: Es würde von uns ja nie einer auf die Idee kommen, den linkViewHelper im PHP-Code zu instanziieren, nur um einen Link in der Hand zu haben, etwa für einen Header-Redirect. Der relevante Punkt dabei bleibt immer der gleiche: Es muss situationsabhängig abgewogen werden, wie viel Kontext ein Mechanismus braucht. In die gleiche Frage fällt dann auch, warum ich nicht so ohne Weiteres über ein eID oder in einem CLI TypoLink verwenden kann. Die Antwort ist klar: Es fehlt der Kontext in Form des TSFE. Konkret fehlt die aktuelle Seite mit analysiertem TypoScript um zu wissen wie Mount-Points, LinkVars und was sonst noch alles für einen Link notwendig ist aussehen. Und diese Frage hat offensichtlich überhaupt nichts mit ExtBase am Hut sondern steht schon grob fünf Jahre länger monatlich auf sämtlichen TYPO3-Listen. Und genau aus diesem Grund kann ich hier auch keine Musterlösung nennen. Die Frage ist: "Was machen die eigenen FormatViewHelper, mit welchen Daten gehen die um und was benötigen sie". Ausgehend von diesen Antwort lässt sich das dann entweder auch ohne Fluid-Stack bewerkstelligen oder eben nicht. Der grundsätzlich einfachste Weg, an einen Fluid-Stack zu kommen ist wohl der ObjectManager->get(StandaloneView). Man braucht zwar noch ein paar andere Kleinigkeiten, aber dazu sollte Google weiter helfen. Jedenfalls ist der StandaloneView hier vermutlich das Mittel der Wahl, wenn sich die Funktionalität nicht ohne ViewHelper machen lässt. Den ViewHelper separat zu instanziieren und mit "->render()" auszuführen halte ich dagegen für keine kluge Idee. Eben weil alles das dann defekt ist, das im ViewHelper so an Kontext normalerweise da ist. Das kann in Ausnahmefällen gehen (ifViewHelper->render($condition=$condition; $then='ja'; $else='nein') wird wohl immer "ja" oder "nein" liefern, dazu ist nicht viel Kontext notwendig), aber eben aufgrund der obigen Erkläuterung nicht immer. Gruß, Stephan Schuler Web-Entwickler Telefon: +49 (911) 539909 - 0 E-Mail: stephan.schu...@netlogix.de Website: media.netlogix.de -- netlogix GmbH & Co. KG IT-Services | IT-Training | Media Andernacher Straße 53 | 90411 Nürnberg Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99 E-Mail: i...@netlogix.de | Internet: http://www.netlogix.de netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338) Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634) Umsatzsteuer-Identifikationsnummer: DE 233472254 Geschäftsführer: Stefan Buchta, Matthias Schmidt -----Ursprüngliche Nachricht----- Von: typo3-german-boun...@lists.typo3.org [mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Elmar Hinz Gesendet: Freitag, 26. April 2013 10:01 An: typo3-german@lists.typo3.org Betreff: [TYPO3-german] Re: ViewHelper in Controller rendern Beides Verstöße gegen das DRY-Prinzip. In beiden Fällen aber zu möglicherweis zu rechtfrtigen. > Alternativ könnte man die Funktion des ViewHelpers ohne Abhängigkeiten > selbst bauen ... Man könnte hier den vorhandnen Viewhelper so abwandeln, daß seine Funktionalität auch ohne Abhängigkeiten zu nutzen ist. Das entspräche DRY. Wenn der vorhanden Viewhelper in einer anderen Extension steckt, kann man möglicherweiese etwas durch Vererbung erreichen. > > PS: Bei jQuery mit MVC solltest du eh nur die Daten übertragen und > dann im FE das Layout mit JS rendern ... Ja, um die Seitenperformance zu verbessern, macht es Sinn Funktionalitäten im Browser zu doppeln. DRY wäre eine automatische Erzeugung des JS Codes auf Basis des PHP codes. Praktisch nicht machbar. Dazu fehlte ein entspechendes System. Idealerweise sollte man View und Viewhelper in JavaScript schreiben, damit man sie wahlweise serverseitig und clientseitig einsetzen kann. Fluid ist aber nun einmal kein JavaScript. Damit müssen wir unsere Daten oft 5-fach programmieren: SQL, TCA, DO, FLUID, jQuery. Das ist für mich nicht der Weg in die Zukunft. Xajax pumpt die XHTML-Ausgabe ausschnitsweise vom Server in den Client. Das ist vom Konzept eher DRY als jQuery. Elmar _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german _______________________________________________ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
