[TYPO3-german] ViewHelper-Rückgabe erneut in FLUID rendern?
Hallo zusammen, ich habe folgendes Problem und bisher keine Lösung dazu finden können: ein eigener ViewHelper generiert u.a. für gewisse Textmuster. Die Rückgabe des ViewHelpers wird im Template dann leider als String bzw. ungültiges HTML aufgenommen und nicht gerendert. Genau das brauche ich allerdings zwingend. Ich kann mir nicht vorstellen, dass noch nie jemand vom ViewHelper bzw. Widget ausgehend FLUID-Tags zurückgeben lässt, die dann erneut gerendert werden sollen. Gibt's doch nicht... Weder das Setzen des Codes in ein Widget noch bzw. haben mir (in jedweder Kombination) geholfen. Der ViewHelper funktioniert - das sehe ich im HTML-Quelltext, in dem eben leider enthalten ist und natürlich ignoriert wird. Auch das direkte generieren der 's im Repository (anstatt im Template mithilfe des ViewHelpers) bringt nichts; das Ergebnis ist das gleiche. Hat jemand eine Idee dazu? Viele (verzweifelte) Grüße, Manuel ps.: aus dem ViewHelper kommt z. B. die Ausgabe Übersetzung zu vorhanden" und innerhalb dieser soll schlichtweg der f-link gerendert werden. Eigentlich ne sehr banale Anforderung -.- ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] ViewHelper-Rckgabe erneut in FLUID rendern?
Hi Dieter, danke für deine Antwort. Das Konzept ist mir bekannt, aber es bremst einen an vielen Stellen leider total aus, wenn man sich strikt daran hält. Außerdem bedeutet es einen uuunglaublichen Mehraufwand in solchen Fällen. Wirtschaftliches Entwickeln ist das absolut nicht. Deswegen weiche ich an ein paar Stellen ganz bewusst davon ab - solange im ViewHelper der Zugriff auf ein Repository und dessen Funktionen nicht verboten wird, wird das auch nie ein Problem werden. Was ich möchte, ist ja eigentlich nichts anderes als ein str_replace, nur eben so, dass $replacement wieder gerendert wird. Klingt sehr einfach, aber TYPO3 macht es aus "Sicherheitsgründen" sehr schwer. Das Verhindern solcher Endlosschleifen muss der Job des Entwicklers sein, nicht der des Frameworks. Danke, ich werde mir mal DataProcessing ansehen und andernfalls im Logikteil auf sehr umständliche Art ein neues Objekt erstellen, das in FLUID dann gesondert behandelt wird. Das bedeutet für diese einfache Aufgabe dann einen ganzen Vormittag Arbeit... Falls zwischenzeitlich jemand eine andere Lösung hat...nur her damit :) Viele Grüße, Manuel ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] ViewHelper-Rckgabe erneut in FLUID rendern?
Hi Stephan, danke - ich bin gestern Abend noch auf eine Lösung gekommen (durch Mithilfe eines Kollegen; siehe nächter Post), die vllt (?) so in die Richtung geht, die du beschrieben hast. Viele Grüße, Manuel ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] ViewHelper-Rckgabe erneut in FLUID rendern?
Hi Dieter, ich denke, du meinst es nur gut, aber ich finde es ehrlich gesagt nicht so fein, dem anderen Denk- oder Planungsfehler zu unterstellen bzw. es für möglich zu halten, dass diese gemacht wurden, wenn man nicht von "unterstellen" sprechen möchte. Stattdessen wäre es angebrachter zu sagen "ja, TYPO3 hat manche Eigenschaften, die man als Einschränkung sehen kann". Du musst mir hier schließlich nichts verkaufen ;) Anderes Beispiel: bau dir eine SQL-Abfrage mit $this->createQuery() und sag mir dann, wenn du merkst, dass du GROUP BY nicht einbringen kannst, dass es an deinem Denkfehler liegt. Wirst du kaum machen - schließlich ist es nicht dein Fehler. Man könnte zwar sagen, dass man sich vorher ewig lang mit den Einschränkungen von TYPO3-Klassen beschäftigen soll, aber wer geht heutzutage schon davon aus, dass man keinen GROUP BY angeben kann?! Das ist so dermaßen banal und gehört in jeden QueryBuilder und Konsorten! Der Fehler liegt auch hier nicht in der Planung, sondern in TYPO3/Extbase. Und dann darf man den Mist eben anders lösen -.- Kurz: Nicht alle Probleme lassen sich auf Denk-/Planungsfehler zurückführen. Ja, mir ist am ersten Tag TYPO3 bereits aufgefallen, dass das System für jene gedacht ist, die Hilfe dabei brauchen, kein "dummes Zeug" zu machen in der Entwicklung. Ich habe es damals anders ausgedrückt, aber im Prinzip lief es inhaltlich genau darauf hinaus :D Ich weiß für gewöhnlich, was ich mache, und daher brauche ich diese Hilfe des Frameworks nicht so zwanghaft. Dass sie da ist, finde ich prima, da sie einen unterstützen kann, aber ich möchte sie eben bei Bedarf möglichst unkompliziert umgehen. Andere Templatesprachen sind flexibler; FLUID eben nicht. Also muss eine Lösung her - für eine einfache Anforderung eine einfache Lösung. Na, mit JS wäre es ja erst recht Flickschusterei :D DataProcessing war zu umständlich und noch dazu in TypoScript. Aber danke trotzdem für den Hinweis. Ich bin durch einen Kollegen auf eine andere, viel einfachere Lösung gekommen. Im Prinzip sogar unkompliziert. Siehe nächster Post. Viele Grüße, Manuel ps.: Recherchen sind dann wirtschaftlich, wenn sie ein hilfreiches Ergebnis haben. Andernfalls freilich nicht, aber die Alternative ist es ebenso wenig, da man dadurch auch nicht weiter kommt. Lohnenswert ist eine Recherche daher allemal. ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: ViewHelper-Rückgabe erneut in FLUID rendern?
Sodale,
ich bin zwischenzeitlich auf eine Lösung gekommen (durch Mithilfe eines Kollegen, der wesentlich länger Extensions entwickelt, aber bisher auch noch nie den beschriebenen Bedarf hatte):
Ich hole mir den Text via renderChildren(), verarbeite und prüfe ihn auf die Textmuster, die ich dann im ViewHelper durch gerenderte Tags ersetze und dann einfach wieder als Text zurückgebe. Letztlich ist mein Kernproblem in 4 Zeilen Code gelöst.
Mein ViewHelper leitet von \TYPO3\CMS\Fluid\ViewHelpers\Link\ActionViewHelper ab, nicht vom AbstractViewHelper.
In PHP 5.6 überschreibe ich render() wie folgt:
/**
* @param string $action
* @param array $arguments
* @param string $controller
*/
public function render($action = null, array $arguments = [], $controller =
null)
{
$sigel= $this->renderChildren();
#
# Text zum $sigel wird geholt, verarbeitet und mit preg_match_all() auf Muster
geprüft, die dann im Anschluss in ActionLinks gesetzt werden sollen
#
#
# Die nächsten 4 Zeilen lösen das Kernproblem:
$uriBuilder = $this->controllerContext->getUriBuilder();
$uri = $uriBuilder->reset()->uriFor($action, $arguments, $controller);
$this->tag->setContent($match[0]);
$this->tag->forceClosingTag(true);
$str = str_replace($match[0], $this->tag->render(), $str);
#
# sonstiger Code; Schleifenende
#
return $str;
}
Diese Zeilen sind in einer Schleife, die die Treffer von preg_mach_all() durchläuft.
Im Template habe ich den Aufruf via <...action="list" controller="Literatur"
arguments="{searchSubmitted : 2, literaturKurztitel : ''}">{element.textSigel}
In PHP 7 muss man entweder warnings deaktivieren ODER aber die Funktion
render() 1:1 überschreiben, d.h. dass die eigene render() exakt die gleichen
Parameter benötigt, wie die der Originalklasse. Andernfalls kommt ein
php:warning, dass die Strukur nicht identisch ist, und TYPO3 steigt aus. Der
Vollständigkeit halber hier der 1:1-kopierte Code:
/**
* @param string $action Target action
* @param array $arguments Arguments
* @param string $controller Target controller. If NULL current
controllerName is used
* @param string $extensionName Target Extension Name (without "tx_" prefix
and no underscores). If NULL the current extension name is used
* @param string $pluginName Target plugin. If empty, the current plugin
name is used
* @param int $pageUid target page. See TypoLink destination
* @param int $pageType type of the target page. See typolink.parameter
* @param bool $noCache set this to disable caching for the target page. You
should not need this.
* @param bool $noCacheHash set this to suppress the cHash query parameter
created by TypoLink. You should not need this.
* @param string $section the anchor to be added to the URI
* @param string $format The requested format, e.g. ".html
* @param bool $linkAccessRestrictedPages If set, links pointing to access
restricted pages will still link to the page even though the page cannot be
accessed.
* @param array $additionalParams additional query parameters that won't be
prefixed like $arguments (overrule $arguments)
* @param bool $absolute If set, the URI of the rendered link is absolute
* @param bool $addQueryString If set, the current query parameters will be
kept in the URI
* @param array $argumentsToBeExcludedFromQueryString arguments to be
removed from the URI. Only active if $addQueryString = TRUE
* @param string $addQueryStringMethod Set which parameters will be kept.
Only active if $addQueryString = TRUE
* @return string Rendered link
*/
public function render($action = null, array $arguments = [], $controller =
null, $extensionName = null, $pluginName = null, $pageUid = null, $pageType =
0, $noCache = false, $noCacheHash = false, $section = '', $format = '',
$linkAccessRestrictedPages = false, array $additionalParams = [], $absolute =
false, $addQueryString = false, array $argumentsToBeExcludedFromQueryString =
[], $addQueryStringMethod = null)
{ . }
Viele Grüße,
Manuel
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] ViewHelper-Rckgabe erneut in FLUID rendern?
Hi Stephan, zunächste hatte ich schlichtweg den String für den ActionLink drin: $str = str_replace($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 seehr 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
[TYPO3-german] Validierung ausschalten
Hallo zusammen, mein Problem zu __trustedProperties muss hier quasi nochmal in anderer Form wiederbelebt werden, da die Lösung, die ich gepostet habe, nicht für MS Edge gilt. Folgendes: ich habe in meiner Form einige Auswahllisten, die hunderte Einträge enthalten. Die werden alle in __trustedProperties geschrieben und auch an die Paginierungs-URLs gehängt. So entstehen ewig lange URLs, die entweder zu einem 414-Error führen oder - bei Edge - vom Browser selbst bereits nach ca. 10k abgeschnitten werden. In allen Browsern außer Edge kann man das Problem einfach mittels JS lösen, indem man __trustedProperties aus dem QueryString schneidet. Das geht bei Edge leider nicht, da der Rest des QueryStrings durch das browser-eigene Abschneiden nicht mehr vorhanden ist und somit die Links defekt sind. Es ist ohnehin etwas unsinnig, die Inhalte aller Felder komplett zu übernehmen im QueryString, da schließlich nur das dort stehen sollte, das tatsächlich auch mittels GET übergeben werden soll nach dessen Auswahl. Aber das ist ein anderes Problem. Eines im Core, das seit Jahren nicht behandelt wird, wie die Bug-Reports aufzeigen. Nun meine Frage: wie stelle ich die Validierung aus? Ich habe es bereits mit @ignorevalidation und @dontvalidate probiert, aber beides hat absolut keinen Effekt -.- Wie kann ich __trustedProperties anderweitig kürzen/killen, bevor das Framework HTML bastelt und ausgibt? Und nein: ich kann die Listen nicht kürzer halten. Viele Grüße & herzlichen Dank schonmal, Manuel ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] GELÖST
ein Hook ist die Lösung des Problems :)
Nervig, dass es nicht anders geht, aber immerhin ist es möglich.
In ext_localconf.php muss der Hook zunächst registriert werden:
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['contentPostProc-output'][$_EXTKEY]
=
'EXT:'.$_EXTKEY.'/Classes/Hook/myPreOutputHook.php:&myPreOutputHook->contentPostProc_output';
in der Extension muss dann die Klasse in (in diesem Beispiel)
Classes/Hook/myPreOutputHook/myPreOutputHook.php liegen und wie folgt aussehen:
class myPreOutputHook
{
function contentPostProc_output(&$params) {
$obj = &$params['pObj'];
$obj->content = preg_replace('/&.+?__trustedProperties[^&]+/', '',
$obj->content);
}
}
Dann noch die Extension neu installieren und fertig.
Eine uralte Liste mit bestehenden Hooks findet sich:
https://buzz.typo3.org/uploads/media/TYPO3_Frontend_Rendering_Process_v1.5.pdf
Eine neuere habe ich nicht finden können via Google -.-
Diese kann man dann entweder erweitern oder ersetzen mit einem eigenen.
Kollege meinte eben, dass die neuere Methode wäre, SignalSlots zu verwenden. Das nur mal als Hinweis, denn es funktioniert mit dem Hook und ich bin zufrieden.
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: jQuery einbinden
öhm, natürlich gibt es das noch: https://jquery.com/upgrade-guide/3.0/#deprecated-document-ready-handlers-other-than-jquery-function ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Re: jQuery einbinden
Hallo Sina,
das klingt ja komisch.
Gibt jQuery bzw. natives JS an der Stelle irgendwas anderes aus, z. B. console.log("hallo welt"); ?
Wenn nicht, wird das gar nicht geparst, weil Typo3 das eventuell aus Sicherheitsgründen verhindert. Das würde mich auch nicht wundern, weil Frameworks das direkte Einbinden von Script via Datei oftmals unterbinden innerhalb des BE, da man das aus Sicht des Frameworks natürlich durch interne Methoden regeln/registrieren soll und nicht via Plain-Einbindung.
Falls eine Konsolenausgabe funkioniert und dementsprechend geparst wird, findet er wohl
schlichtweg nichts, weil der Selektor an der falschen Ebene angesetzt ist. Eigentlich
sollte das ja mittels jQuery() funktionieren, aber ... vllt braucht man an der Stelle
explizit die Suche innerhalb des Dokuments:
jQuery(document).find(".bodytext")[0].mousover
VG
Manuel
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
