[TYPO3-german] ViewHelper-Rückgabe erneut in FLUID rendern?

Stephan Schuler Stephan.Schuler at netlogix.de
Thu Jul 27 17:21:56 CEST 2017


Hallo Manuel.

Schön dass Du eine Lösung gefunden hast.

Kannst Du den Versuch der eben nicht funktioniert hat auch noch kurz hier veröffentlichen?  Ich bin nämlich von deutlich anderen Voraussetzungen ausgegangen als ich Dir meine Erklärung geschrieben habe.

Insbesondere hast Du jetzt aber ja eine Variante gefunden, in der Du nicht „von Hand“ Fluid nochmal „nachrendern“ musst. Und das sollte eigentlich auch immer so sein. Bei verschachtelten ViewHelper-Aufrufen bekommt ein umschließender ViewHelper nicht den umschlossenen Fluid-Code sondern das Renderingergebnis des umschlossenen Codes. Wenn der umschlossene Code selbst ViewHelper enthält werden die zunächst evaluiert, und so wird (zumindest theoretisch) von innen nach außen gearbeitet.

Das war mit ziemlicher Sicherheit in Deinem vorherigen Versuch auch der Fall.

Du brauchst für die Verlinkung nicht zwangsläufig den ActionViewHelper. Du hast zwar vergleichbare Argumente $action, $arguments und $controller, mehr aber auch nicht. Wenn Du einfach vom AbstractTagBasedViewHelper ableitest hast Du ebenfalls den ControllerContext, das reicht. Um zu vermeiden, dass das Ergebnis HTML-Specialchar-Escaped wird musst Du dieses Defaut-On-Feature im ViewHelper deaktivieren. Das dürfte der aber der AbstractTagBasedViewHelper für Dich tun.

Auch unter PHP5 wäre ich nie auf die Idee gekommen, eine Funktion mit nur einem Teil der Argumente zu überschreiben. Das macht man nicht, schon weil die IDE dann mit ihrer Autovervollständigung durcheinanderkommen dürfte. Spätestens wenn die abgeleitete Klasse ein Argument bekommt das es in der Parent-Klasse nicht gibt, das dann aber die Position eines ganz anderen Arguments der Parent-Klasse einnimmt wird es haarig. Ich will mir eigentlich nicht ausmalen, wie die zugehörige Reflection-Meta-Data aussieht. Insbesondere nachdem die Parameterreihenfolge von Fluid ja ausgelesen und aufgerufen wird dürften das die Art von Bugs sein denen man ewig hinterher läuft.

Stell Dir die Methode in einem ViewHelper vor:
➢ public function render($a=null, $b=’’, $c=0)

Und dazu der Aufruf in Fluid:
➢ <xxx:whatever c=“5“>

Was Fluid jetzt machen muss ist klar: Die eigentlich optionalen Argumente „$a=null“ und „$b=’’“ aktiv übergeben, um das letzte optionale Argument „$c=5“ abweichend vom Default übergeben zu können.

Wenn sich da jetzt in der Vererbungshierarchie die Parameterreihenfolge ändert geht die Welt unter.

Dein „GROUP BY“ kann ich allerdings nicht so stehen lassen. Es ist ja nicht so, dass Dir jemand das „GROUP BY“ verbietet. Nur gibt es in der Theorie des ORM eben kein „GROUP BY“, bzw. das Ergebnis ist kein Teil dieser Welt mehr. Stell Dir ein Objekt $sportler vor, sagen wir einen Langstreckenläufer. Der hat die Attribute $sportler->name, $sportler->höchstgeschwindigkeit, $sportler->besteRundenzeit und $sportler->alter. Jetzt nehmen wir „SELECT * FROM sportler GROUP BY alter“. Raus kommt natürlich ein Objekt vom Typ Langstreckenläufer, das ist unsere Domäne. Was ist jetzt die beste Rundenzeit, und was die Höchstgeschwinditkeit? Sind das die Werte des ersten Objekts der Altersgruppe, oder die Höchstwerte der Gruppe? Das hängt offensichtlich vom DBMS ab mit dem Du arbeitest, und in diversen Datenbanken sind bei solchen Abfragen schon im SELECT-Teil nur diejenigen Attribute erlaubt die im GROUP BY genannt sind, andere Queries erzeugen einen Fehler im Datenbankserver.

Wenn Du das „GROUP BY“ verwenden willst: Bitte gerne. Aber im Zusammenhang des ORM ist es eben nicht definiert, dann musst Du ohne ORM auskommen oder es ORM-kompatibel formulieren.
Man könnte hierfür ein paar SQL-Views bauen und die auf sinnvolle Objekte mappen. Wenn ich eine Tabelle „Höchstgeschwindigkeit nach Alter“ rendern möchte sind es keine Sportler mit denen ich hantiere sondern vielleicht „Rennstatistiken“ oder etwas in der Art. Ein solches Objekt hat dann aber keinen Namen mehr, und auch diverse andere Attribute die ein solcher Sportler hat, sondern nur noch ein Alter und eine Höchstgeschwindigkeit.

Beste Grüße,


Stephan Schuler
Web-Entwickler | netlogix Web Solutions

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Web: websolutions.netlogix.de



----------------------------
Neu: Wir sind Amazon Web Services Partner. Mehr erfahren:
https://websolutions.netlogix.de/technologie/amazon-web-services-aws
----------------------------




netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Web: 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: Matthias Schmidt





More information about the TYPO3-german mailing list