[TYPO3-german] ViewHelper-Rckgabe erneut in FLUID rendern?

Fri Jul 28 13:05:39 CEST 2017

Hi Stephan,

zunächste hatte ich schlichtweg den String für den ActionLink drin: $str = str_replace($match[0], '<f:link.action action="list" controller="Literatur" arguments="{searchSubmitted : 1, literaturKurztitel : $match[0]}"/>', $str); 
Danach habe ich versucht, den uriBuilder aus einem anderen Controller zu injecten und zu initialisieren. Scheiterte dann immer mit "reset() on null". Den genauen Code dazu habe ich nicht mehr - da er nicht funktionierte, wurde er nicht commited. 

Soweit ich das verstehe mit dem AbstractTag, kann ich dort zwar einen Tag bauen, aber dann nicht oder nur umständlich Argumente wie "action", "controller" oder "arguments" übergeben, die dann korrekt (im Sinne gleichnamiger Parameter des ActionLinks) verwendet werden. Oder? Daher ist der ActionLink perfekt und echt easy für den konkreten Anwendungsfall. 

Grundsätzlich versteh ich das schon, die Funktion 1:1 zu überschreiben, nach dem Motto "sicher ist sicher". Etwas "overhead", wenn man so will, stellt es ggbfs. aber dennoch dar. Die Parameterreihenfolge wird von FLUID ja durch das Mapping in die richtige Form gebracht...? Daher sehe ich an der Stelle kein Problem, wenn ich nur 3 benötigte Parameter in der überschriebenen Funktion angebe (anstatt aller) und sogar alle 3 brav verwende. Ändert sich etwas bei den Parametern der Funktion der Elternklasse (z. B., dass es $variable nicht mehr gibt, sie nicht mehr fakultativ ist, oder von einem bestimmten Typ sein muss), hat man sowieso das Problem, anpassen zu müssen. 
Fügt man in der Ableitung einen Parameter hinzu, ist das natürlich schnell mal ein Problem - völlig klar. Aber das mache ich ja nicht in diesem Fall und das wird sich auch nie ändern an der Stelle...also wäre die "PHP5-Variante" ausreichend.

Nun ja, das ORM "verbietet" mir das zwar nicht, aber es unterstützt die Verwendung von GROUP BY oder JOIN eben nicht. Dadurch ist ORM eingeschränkt nutzbar. Man sollte bei einem solchen System davon ausgehen dürfen als Entwickler, dass der normale Abfrage-Befehlssatz der Datenbanksprache unterstützt wird. Das sind beides Basisfunktionen. Dass da keine Funktionen für die Strukturänderung enthalten sind, ist völlig verständlich. Man sollte ALTER TABLE etc. pp. auch nur bedingt ausführen innerhalb der Anwendung.
Bei sehr einfachen Datenstrukturen/-inhalten benötigt man die beiden nicht, aber ist es wirklich so, dass ORM nur für banale Strukturen zu gebrauchen ist und deshalb u.a. diese nicht unterstüzt? Das fände ich schon ziemlich schwach. 

Beim Sportlerbeispiel ist ein GROUP BY auf das Alter nicht sinnvoll, das stimmt. Unabhängig vom DBMS sollte das hinsichtlich der Bestzeit etc. jeweils strikt die Logik des GROUP BY auf das Alter ausführen und damit für den Nutzer keine semantisch sinnvolle Ausgabe erzeugen. Man hat dann einen Eintrag pro Alter...bringt nix. Stimmt. In zig anderen Fällen sind GROUP BY oder auch JOIN aber seeeeeehr nützlich.
Z. B. wenn du eine sprachliche Belegdatenbank hast und Belege nach Wort und Bedeutung gruppieren willst um zu prüfen, welche Kombinationen vorhanden sind, dir aber die teils tausenden Beispiele an dieser Stelle erstmal egal sind. 

Ich habe jetzt erstmal Urlaub :)

Viele Grüße, schönes WE & danke für die Anmerkungen,
Manuel

Quote: Stephan Schuler wrote on Thu, 27 July 2017 17:21
----------------------------------------------------
> 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
----------------------------------------------------