[Frage] Fluid Cache Fehler in eigenem IF-ViewHelper

  • Donpeponi Donpeponi
    TYPO3-Anwärter
    0 x
    4 Beiträge
    1 Hilfreiche Beiträge
    16. 09. 2015, 13:30

    Ich habe einen ViewHelper der den AbstractConditionViewHelper extendet und ein Array von objekten (oder strings) und eine uid zum Vergleich übergeben bekommt. Ist diese Uid im Array wird der if, ansonsten der else Zweig gerendert.

    Dies klappte auch seit typo3 4.5 bis 6.2 problemlos.

    Jetzt in typo3 7.4.0 wird dieser beim 1. aufruf richtig ausgeführt und ab dem 2. nur noch der if zweig gerendert.
    Fluid erzeugt in

    /typo3temp/Cache/Code/fluid_template/
    für die Action eine File und diese führt zu meinem Fehler. Wird der Systemcache gelöscht (oder die file direkt), läuft der Viewhelper wieder 1x.

    Die action ist als noncached in ext_localconf deklariert.
    Ich habe versucht die cache file aus dem fluid-cache auszulesen, was aber nicht funktioniert. Bis jetzt hat nur ein flush auf den gesamten fluid-cache geholfen (nicht akzeptabel).

    Kann mir jemand etwas dazu sagen?

    ViewHelper:
    [code]

    1. class IsInArrayViewHelper extends \TYPO3\CMS\Fluid\Core\ViewHelper\AbstractConditionViewHelper {
    2.  
    3. /**
    4. * @param mixed $array View helper condition
    5. * @param mixed $needle View helper condition
    6. * @return string the rendered string
    7. */
    8. public function render($array, $needle) {
    9.  
    10. $flag = FALSE;
    11. if($array != ""){
    12. foreach ($array as $value) {
    13. if(is_object($value)){
    14. if ($value->getUid() == $needle) {
    15. $flag = TRUE;
    16. }
    17. }else{
    18. if ($value == $needle) {
    19. $flag = TRUE;
    20. }
    21. }
    22. }
    23. }
    24. if ($flag) {
    25. return $this->renderThenChild();
    26. } else {
    27. return $this->renderElseChild();
    28. }
    29. }
    30.  
    31. }
    [/code]

    Template:

    1. <f:for each="{languages}" as="lang" iteration="i">
    2. <vn:isInArray array="{user.languages}" needle="{lang.uid}">
    3. <f:then>
    4. <f:form.checkbox class="checkbox-languages" id="languages" name="user[languages][]" value="{lang.uid}" checked="checked" />
    5. </f:then>
    6. <f:else>
    7. <f:form.checkbox class="checkbox-languages" id="languages" name="user[languages][]" value="{lang.uid}" />
    8. </f:else>
    9. </vn:isInArray>
    10. <label class="label-languages-person">{lang.nameLocalized}</label>
    11. </f:for>


  • 1
  • wp_bube wp_bube
    TYPO3-Anwärter
    0 x
    6 Beiträge
    1 Hilfreiche Beiträge
    18. 10. 2015, 22:56

    Hi, habe das selbe Problem. Konntest du schon eine Lösung finden?

  • harald1972 harald197...
    Sternenflotten-Admiral
    0 x
    198 Beiträge
    13 Hilfreiche Beiträge
    20. 10. 2015, 11:03

    Kann mir jemand etwas dazu sagen?

    Ja, ich ;)

    Du solltest einer nicht-gecheckten Checkbox (das gleiche bei Radiobuttons) ein [b]checked=""[/b] oder [b]checked="false"[/b] oder dergl. mitgeben.
    Das Problem hatte ich schonmal hier im Forum geschildert (thema/117127).

    Was anderes: Hat das einen Sinn, daß du ein Flag setzt und gleich darauf wieder abfragst?
    An der Stelle der Zuweisung $flag=TRUE kannst du gleich returnen. Wenn dein Flag einmal TRUE ist, wird es nie wieder FALSE. Wenn das Ergebnis feststeht, besteht doch kein Grund, weitere Prüfungen vorzunehmen oder das ganze Array durchzunudeln.

    Gruß, Harald

  • Donpeponi Donpeponi
    TYPO3-Anwärter
    0 x
    4 Beiträge
    1 Hilfreiche Beiträge
    22. 10. 2015, 09:15

    Hat das einen Sinn, daß du ein Flag setzt und gleich darauf wieder abfragst?

    Danke, wäre mir nicht aufgefallen, war noch altbestand bevor ich in diese Firma kam..

    Das checked="false" löst auf 7.5 leider das problem mit dem cache nicht, nach dem 1. speichern wird der viewhelper aus dem cache heraus aufgerufen und leere checkboxen gerendert..
    Eigentlich könnte mir das ja jetzt egal sein, da ich die Firma wechsle, aber wäre interessant was man dagegen machen kann..

  • dachande dachande
    T3PO
    0 x
    10 Beiträge
    1 Hilfreiche Beiträge
    15. 01. 2016, 11:41

    Ja, auch ich stand bis eben vor diesem Problem und war schon langsam am verzweifeln.
    Nach langer Suche hat mir Google endlich die Lösung ausgespuckt.

    Da dein ViewHelper von AbstractConditionViewHelper abgeleitet wird, welcher das Compilable Interface benutzt (und vermutlich dadurch das beschriebene Problem auftritt), muss die compile() Methode aus dem AbstractConditionViewHelper überschrieben werden und zum Schluss die Konstante
    \TYPO3\CMS\Fluid\Core\Compiler\TemplateCompiler::SHOULD_GENERATE_VIEWHELPER_INVOCATION
    zurückgegeben werden. Im Endeffekt sieht das dann so aus:

    1. public function compile(
    2. $argumentsVariableName,
    3. $renderChildrenClosureVariableName,
    4. &$initializationPhpCode,
    5. \TYPO3\CMS\Fluid\Core\Parser\SyntaxTree\AbstractNode $syntaxTreeNode,
    6. \TYPO3\CMS\Fluid\Core\Compiler\TemplateCompiler $templateCompiler
    7. ) {
    8. parent::compile(
    9. $argumentsVariableName,
    10. $renderChildrenClosureVariableName,
    11. $initializationPhpCode,
    12. $syntaxTreeNode,
    13. $templateCompiler
    14. );
    15.  
    16. return \TYPO3\CMS\Fluid\Core\Compiler\TemplateCompiler::SHOULD_GENERATE_VIEWHELPER_INVOCATION;
    17. }

    Gefunden habe ich das in einem Commit für die fal_securedownload Extension auf Github:
    https://github.com/pvanhemmen/fal_securedownload/commit/aae660f811da713ffe7e27a6994f0750cc4395ae

  • 1