[TYPO3-german] Field: longdescURL

[Thomas Skierlo]

Quote: Jo Hasenau (cybercraft) wrote on Mon, 09 September 2013 16:58
----------------------------------------------------

> >
> > Im setup stoße ich auf Folgendes:
> >
> > tt_content.image.20.1.params.override.dataWrap =
> > aria-describedby="csc-longdesc-{field:uid}-{register:IMAGE_NUM_CURRENT}"
> >
> > darunter die übelste "if" Struktur, die mir bislang begegnet ist. Der
> > "isTrue" Part leuchtet ein. Aber den "isFalse" Part verstehe ich nicht:
> >
> > isFalse = 1
> > isFalse {
> >      if {
> >          isFalse {
> >              cObject = TEXT
> >              cObject {
> >                  field = longdescURL
> >                  split {
> >                      token {
> >                          char = 10
> >                      }
> >                      returnKey.data = register : IMAGE_NUM_CURRENT
> >                  }
> >              }
> >          }
> >      }
> > }
> 
> Ich nehme mal an, das hängt am override?
> Dann bedeutet das Folgendes:
> 
> Erste Zeile:
> 
> override wird prinzipiell nicht gerendert, weil 1 (oder TRUE) != FALSE ist.
> Folgekonstrukt:
> TRUE wird hier mit dem Ergebnis der Abfrage auf das cObject ersetzt.
> 
> Sprich:
> Wenn es KEINE longdescURL für das entsprechende Bild gibt, ist das 
> Ergebnis des inneren isFalse 1 (oder TRUE), damit liefert aber das 
> äußere isFalse weiterhin ein FALSE. Override wird also nicht gerendert.
> 
> WENN es aber eine longdescURL gibt, ist das innere Ergebnis FALSE, damit 
> liefert das äußere isFalse ein TRUE. Override wird gerendert.
> 
> IMHO würde es aber völlig ausreichen, das mit einer Ebene zu machen:
> 
> isTrue {
> 	cObject = TEXT
> 	cObject {
> 		field = longdescURL
> 		split {
> 			token {
> 				char = 10
> 			}
> 			returnKey.data = register : IMAGE_NUM_CURRENT
> 		}
> 	}
>   }
> 
> es kann aber sein, dass das aus Kompatibilitätsgründen über das 
> isFalse-Konstrukt laufen musste.

Uff - 1000 Dank für die Erklärung. Ich denke/hoffe auch, dass es an Kompatibilität zu Historischem liegt. Unter Verzicht darauf konnte ich auch lib.stdheader um mehr als 100 Zeilen kürzen. Und die gekürzte Version ist plötzlich transparent und verständlich. Die Frage wäre nun, ob nicht genau eine anstehende LTS ein probater Grund wäre, mit diesen ganzen Altlasten zu brechen - oder zumindest den Setup zwischen HTML5 und XHTML zu separieren. Diese if/case Gräber kosten nicht nur Nerven, sie fressen auch Resourcen.

> 
> > Zur Frage: Wenn ich mich recht entsinne, gab es in früheren Versionen
> > ein ausdrückliches Feld "longdescURL", welches auch von einem Redakteur
> > befüllt werden konnte. In der DB existiert es weiterhin, und ich könnte
> > es wohl auch per TS setzen. Wie aber gelangt ein Redakteur heute noch an
> > dieses Feld?
> 
> Indem es im TCA für tt_content aktiviert/nicht deaktiviert wird.
> 
> Selbst wenn das nicht mehr im Default-Setup aktiviert sein sollte, oder 
> z.B. von FAL überschrieben werden sollte, ist das Feld ja weiterhin 
> nutzbar, wenn man z.B. nicht über FAL gehen möchte. Genaugenommen müsste 
> es aber auch über FAL verfügbar sein und dann entsprechend abgefragt werden.
> 

Jetzt wäre es natürlich schön, zu wissen, ob es nicht mehr im Standard angezeigt wird, weil es
a) mit FAL (derzeit noch) kollidiert
b) zu einem Lokalisierungsproblem führt, oder
c) man es entfernt hat, weil es fast niemand nutzt.