Bug oder Feature – Unterschiedliche Verarbeitung von COA und COA_INT

  • Tosta Tosta
    R2-D2
    0 x
    109 Beiträge
    0 Hilfreiche Beiträge
    17. 06. 2011, 12:06

    Hi,

    der einzige Unterschied zwischen den Inhaltsobjekten COA[/i] und [i]COA_INT[/i] sollte sein, dass [i]COA_INT[/i] nicht cached wird; in verschiedenen Dokumentationen, allen voran TSRef, finde ich jedenfalls keine gegenteilige Aussage. Ich bin allerdings auf einen Fall gestoßen, in dem der Einsatz eines [i]COA[/i] bzw. eines [i]COA_INT[/i] zu unterschiedlichen Ergebnissen führt.

    Die TYPO3-Version ist 4.5.2.

    Das folgende Beispiel ist sehr abstrakt, aber dafür kompakt. Ich habe meinen tatsächlich eingesetzten Code weitgehend eingedampft.

    Kurze Beschreibung der Anforderung: Eine Reihe von Textstücken wird ausgegeben. Dabei steht zwischen den Textstücken immer ein Separator, im Beispiel »#«. Hinter dem letzten Textstück steht kein Separator. Leere Textstücke müssen ignoriert werden, d.h. hinter einem leeren Textstück folgt kein Separator, und somit erscheinen auch keine zwei Separatoren unmittelbar hintereinander.

    Ich realisiere das mit der [i]stdWrap[/i]-Funktion [i]split[/i]. Der Trenner dafür ist »---«; er wird mittels [i]wrap[/i] hinter jedes Textstück gesetzt. [i]split[/i] trennt dann die Textstücke und setzt hinter jedes – außer dem letzten! – den Separator.

    Die einzelnen Textstücke sind

    1. ein einfacher [i]TEXT, »one«
    2. ein COA[/i] ohne Inhalt, indirekt referenziert als TS-Element [i]coa
    3. ein einfacher TEXT, »two«
    4. ein COA_INT[/i] ohne Inhalt, indirekt referenziert als TS-Element [i]coa_int
    5. ein einfacher TEXT, »three«
    6. ein COA_INT ohne Inhalt, direkt benutzt
    7. ein einfacher TEXT[/i], »four«

    Das Ganze ist noch ein bisschen strukturiert: Alle 5 Textstücke sind in ein [i]COA[/i] eingepackt, für das [i]required gesetzt ist. Damit wird die Anforderung »Leere Textstücke müssen ignoriert werden« erreicht.

    1. lib.my {
    2. coa = COA
    3. coa {
    4. 10 = TEXT
    5. }
    6.  
    7. coa_int = COA_INT
    8. coa_int {
    9. 10 = TEXT
    10. }
    11.  
    12. element = COA
    13. element.stdWrap {
    14. wrap = | ---
    15. }
    16.  
    17. foo = COA
    18. foo {
    19. token = ---
    20. cObjNum = |*|1|*|2||3|
    21. 1 {
    22. current = 1
    23. wrap = | #
    24. }
    25. 2 {
    26. current = 1
    27. }
    28. }
    29.  
    30. 10 < lib.my.element
    31. 10.10 = TEXT
    32. 10.10.value = one
    33.  
    34. 20 < lib.my.element
    35. 20.10 < lib.my.coa
    36.  
    37. 30 < lib.my.element
    38. 30.10 = TEXT
    39. 30.10.value = two
    40.  
    41. 40 < lib.my.element
    42. 40.10 < lib.my.coa_int
    43.  
    44. 50 < lib.my.element
    45. 50.10 = TEXT
    46. 50.10.value = three
    47.  
    48. 60 < lib.my.element
    49. 60.10 < COA_INT
    50. 60.10.10 = TEXT
    51.  
    52. 70 < lib.my.element
    53. 70.10 = TEXT
    54. 70.10.value = four
    55. }
    56. }

    Die Überraschung: Bei der Ausgabe wird das indirekt referenzierte COA_INT (40) nicht als leer erkannt, wie an den zwei hintereinander stehenden Separatoren zu erkennen ist:
    1. one#two##three#four

    Das indirekte COA[/i] und das direkte [i]COA_INT werden aber richtig als leer erkannt und ignoriert.

    In meinen Augen ist das ein Bug, der unter sehr speziellen Umständen zum Tragen kommt – aber ich will nichts überstürzen. Vielleicht hab ich selbst etwas falsch konfiguriert. Was meint ihr? Danke für eure Beiträge.

    Tosta


  • 1
  • 1