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
----------------------------------------------------
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
