FCE Validierung bzw. FCE versus Extension?

  • rookie07 rookie07
    T3PO
    0 x
    17 Beiträge
    0 Hilfreiche Beiträge
    20. 07. 2012, 10:22

    Hallo liebes Forum,

    ich bin ein totaler Frischling und beschäftige mich seit ca 3 Wochen mit TYPO3. Zur Zeit versuche ich mittels Flexibel Content Elements (TemplaVoila) dem Backend-User eine definierte Eingabe von mehreren Content-Elementen vorzugeben. Die Backend-Benutzer sollen in ihrer Kreativität möglichst eingeschränkt werden damit diese Eingaben dem CI und dem Seitendesign nicht schaden.

    Nun bin ich natürlich an Realisierungen von Benutzereingabe-Validierungen, required-fields, Plausibilitätsprüfungen interessiert - dazu konnte ich noch keine Info finden - ich habe angenommen, dass ich diese Validierungen vielleicht über eine TypoScript Konfig lösen könnte, gibt es da etwas in der Richtung, oder kann ich da mittels PHP oder JavaScript einwirken?

    Vielleicht bin ich ganz und gar auf dem Holzweg und eine Extension wäre das richtige? Wie gesagt, ich möchte das durch die Benutzereingaben ein vorhersehbares (X)HTML-Ergebnis raus kommt, darum die Annahme ich könnte zB ein FCE erstellen um den Benutzer eine Art von Verlinkung erstellen zu lassen, Benutzer gibt zB, Linkziel, Linktext, target ein - beim Abspeichern wird das ganze Validiert und schlussendlich im Frontend so gerendert wie vorgesehen?

    Bin für jeden Tipp dankbar!


  • 1
  • Silkea Silkea
    R2-D2
    0 x
    79 Beiträge
    0 Hilfreiche Beiträge
    26. 07. 2012, 12:17

    Ich verwende für Linklisten (und anderes) auch FCEs. Wobei ich keine Validierung der Links vornehme (schau dir mal <eval> an, z.B. <eval>required</eval> für ein Pflichtfeld in der Flexform, es gibt aber noch mehr Möglichkeiten).
    Über die Backend-Usergroup kannst du auch steuern welcher User was darf (über exlude-fields). Das habe ich bisher aber noch nicht verwendet.
    Für Dateilinks käme auch filelinks in Frage (http://wiki.typo3.org/De:TSref/filelink).
    Du kannst auch eigene Funktionen in die Flexforms einbauen über <userfunc>, z.B. um eine select-Box mit Werten aus der Datenbank zu füllen.

    Ganz generell kannst du mit FCEs das Aussehen ziemlich gut steuern, da du ja die Ausgabe komplett in der Hand hast. Man kann auch die Verwendung von FCEs je nach User einschränken (über die Rechte der Usergroup), was auch Fehlerquellen reduzieren kann.

    Für komplexere Sachen kannst du ja dann eine (eigene) Extension einsetzen, z.B. wenn du prüfen wolltest, ob ein Link wirklich besteht und keine 404er-Seite ausgibt.

  • rookie07 rookie07
    T3PO
    0 x
    17 Beiträge
    0 Hilfreiche Beiträge
    26. 07. 2012, 12:45

    hallo silkea,

    erst mal vielen dank für deine tipps!
    bin mittlerweile schon etwas erfahrener im umgang mit den fce (in zusammenhang mit templavoila) geworden.

    konnte auch wie du vorgeschlagen hast mittels typoscript und allowed excludefields sowie TCA-konfig ein wenig auf die berechtigungen von content einwirken, zb: http://www.typo3.net/forum/beitraege/rich_text_editor/111461/

    ganz am anfang habe ich auch versucht die flexform ein wenig mittels dem

    1. <eval>required</eval>
    -tag anzupassen, was mir aber nicht wirklich gelungen ist.

    für fce bäruchte ich noch einen mechanismus der beim / oder vor dem submit der backend-form dann meine validierungen vornimmt oder mindestens die form-felder auf required überprüft.

    an letzterem problem kämpfe ich gerade - ich würd sonst sofort in richtung extension tendieren, da hab ich aber noch überhaupt kein know how, ausserdem möchte ich das rad nicht 2x erfinden, werd zuerst versuchen ob es nicht doch irgend einen trick gibt die zur verfügung gestellten tools nach meinen anforderungen zu verbiegen - dachte nur dass diese probleme ziemlich klein sein dürften, jedes framework hat ja üblicherweise validierungs-funktionen...

    vielen dank!

  • rookie07 rookie07
    T3PO
    0 x
    17 Beiträge
    0 Hilfreiche Beiträge
    26. 07. 2012, 14:42

    zusatz:

    eigentlich ist mein hauptproblem noch immer die richtige doku zu finden!

    somit befindet sich eine detailierte beschreibung der validierungsmöglichkeiten nicht wie angenommen in den flexforms, templavoila, ect sondern in der tca ref: http://typo3.org/documentation/document-library/core-documentation/doc_core_tca/4.7.1/view/1/3/#id385120

    hinterlegt man schließlich den richtigen code, abhängig vom type bei den fce (form), dann funktionierts auch!

  • Silkea Silkea
    R2-D2
    0 x
    79 Beiträge
    0 Hilfreiche Beiträge
    26. 07. 2012, 15:22

    Also das mit dem eval funktioniert bei mir, sowohl required als auch andere Dinge wie trim oder int. Vielleicht hast du das <eval> an die falsche Stelle geschrieben?

    1. <config type="array">
    2. <type>input</type>
    3. <size>48</size>
    4. <eval>trim</eval>
    5. </config>

    Ja, die Dokumentation ist echt schlimm! :-( Ich suche mir auch immer den Wolf ab bis ich das finde, was ich suchte - wer kommt schon auf die Idee für TV bei der Doku über TCA zu suchen. Ohne Google ginge da gar nichts... Deswegen habe ich die die paar Stichwörter aufgeschrieben, dann kann man wenigstens danach googeln.

  • rookie07 rookie07
    T3PO
    0 x
    17 Beiträge
    0 Hilfreiche Beiträge
    26. 07. 2012, 15:45

    sorry - ist wohl aus meinem letzten beitrag nicht richtig raus gekommen: mit

    1. eval
    funktioniert die validierung jetzt auch!

    bin gerade dabei den rundlauf gründlich zu testen bzw welche möglichkeiten es gibt:

    1. <a tabindex="71" href="#" title="linkbeschreibung" target="_self" class="betonter_verweis">ein verweis</a>

    bis jetzt gefällt mir folgende lösung am besten - im fce / templavoila mappe ich:

    a:inner - als element (plain text)
    a:attr:href - als attribut (link field)
    a:attr:title - als attribut (plain text)
    a:attr:target - als attribut (select box)

    somit sollte ich die volle kontrolle erhalten wenn ich die redundanten felder im browse_links.php ausblende (um verwirrungen der user vorzubeugen),

    ich evaluiere gerade:

    *) title (bei anderen tags wäre dann wichtig das title/alt in allen browsern ausgegeben wird)
    *) vorbelegung der select box bzw. anzeige und value steuern

    bin aber zuversichtlich, dass sich das auch irgenwie lösen lässt (nach erneuten 3 tagen recherchen #paralyzed#)

  • Silkea Silkea
    R2-D2
    0 x
    79 Beiträge
    0 Hilfreiche Beiträge
    27. 07. 2012, 09:57

    So wie du habe ich das auch gelöst, also alles getrennt.

    select-Box für das Linkziel (gibt nur self und blank, da Seite keine Frames hat)

    1. <config type="array">
    2. <type>select</type>
    3. <items type="array">
    4. <numIndex index="0" type="array">
    5. <numIndex index="0">_self</numIndex>
    6. <numIndex index="1">_self</numIndex>
    7. </numIndex>
    8. <numIndex index="1" type="array">
    9. <numIndex index="0">_blank</numIndex>
    10. <numIndex index="1">_blank</numIndex>
    11. </numIndex>
    12. </items>
    13. <default>0</default>
    14. </config>

    Mit default triffst du die Vorauswahl.

    title kannst du an Typolink anhängen mit "typolink.title = ..." (da kann man noch Parameter übergeben mit "additionalParams" ).

    Andere Felder der Flexform kannst du über "field" auslesen und diese dann im Link zusammenbasteln.

    Hab leider kein genau passendes TS parat, aber hier als Beispiel die Einbindung eines alt-Tags für ein Bild (link titel wäre dann analog dazu):

    1. 10.1.altText = TEXT
    2. 10.1.altText {
    3. field = field_imagealt
    4. listNum = 1
    5. listNum.stdWrap.data = register : IMAGE_NUM_CURRENT
    6. }

    "field_imagealt" heißt das entsprechende Feld in der Flexform.

  • rookie07 rookie07
    T3PO
    0 x
    17 Beiträge
    0 Hilfreiche Beiträge
    27. 07. 2012, 10:42

    hallo silkea,

    vielen dank für die genaue doku, das ist total nett!

    hab das gestern eigentlich genau so gelöst wie von dir beschrieben, ausser dass ich halt für den titel ein "plain text" element nehme und kein "typoscript path" so wie du dass machst (nehme ich an). mit deiner lösung bist du noch etwas flexibler da du das typoscript entsprechend verändern kannst, sonst seh ich da keinen vorteil - oder ist mir da was entgangen?

    ich kämpfe seit gestern gerade mit mehrsprachigkeit in den fce(s) - hast du da schon was gemacht?
    hatte mir das so vorgestellt, dass ich ähnlich wie bei "herkömmlichen" content elementen einfach eine (zb engliche) kopie anlege - mein gedanke war, dass sich dann auch die lables entsprechend anpassen - ein engländer kann ja mit einer deutschen beschriftung / beschreibung in der regel weniger anfangen.
    es wäre somit auch wichtig dass sich die beschreibung in der select box von zb "in einem neuen fenster öffnen" zu "open in new window" ändert.
    scheinbar bin ich da aber auf dem holzweg. stimmt es, dass ich für jede sprache ein neues fce anlegen müsste (um meine werte zb in der select box zu übersetzen)?

    ich hatte es gestern mal so versucht:

    *) einen locallang_xxx.xml file erstellt mit den übersetzungen
    *) über typoscript ist natürlich die mehrsprachigkeit eingestellt, funktioniert auch im fe & be
    *) meine fce T3DataStructure entsprechend angepasst (deutsche/default version wird auch schon verwendet)

    1. <field_target type="array">
    2. <type>attr</type>
    3. <tx_templavoila type="array">
    4. <title>Link-Fenster</title>
    5. <sample_data type="array">
    6. <numIndex index="0"></numIndex>
    7. </sample_data>
    8. <eType>select</eType>
    9. <tags>a:attr:target</tags>
    10. <proc type="array">
    11. <HSC>0</HSC>
    12. <stdWrap></stdWrap>
    13. <int>0</int>
    14. </proc>
    15. <preview></preview>
    16. <TypoScript></TypoScript>
    17. </tx_templavoila>
    18. <TCEforms type="array">
    19. <label>LLL:fileadmin/templates/template01/locallang_fce_multilang.xml:field.target</label>
    20. <config type="array">
    21. <type>select</type>
    22. <items type="array">
    23. <numIndex index="0" type="array">
    24. <numIndex index="0">LLL:fileadmin/templates/template01/locallang_fce_multilang.xml:field.self</numIndex>
    25. <numIndex index="1">_self</numIndex>
    26. </numIndex>
    27. <numIndex index="1" type="array">
    28. <numIndex index="0">LLL:fileadmin/templates/template01/locallang_fce_multilang.xml:field.blank</numIndex>
    29. <numIndex index="1">_blank</numIndex>
    30. </numIndex>
    31. </items>
    32. <default>0</default>
    33. </config>
    34. </TCEforms>
    35. </field_target>

    auch wenn ich die meta info umstelle auf:

    1. <meta type="array">
    2. <langChildren>1</langChildren>
    3. <langDisable>0</langDisable>
    4. </meta>

    bekomme ich die eingabefelder zwar pro sprache angeboten, die beschriftungen bzw der inhalt der select box ändert sich jedoch nicht...

    lg.

  • Silkea Silkea
    R2-D2
    0 x
    79 Beiträge
    0 Hilfreiche Beiträge
    30. 07. 2012, 14:02

    Das Beispiel mit dem Bild ist etwas verkürzt wiedergegeben. Ich hatte deshalb keinen Plaintext, weil ich den title aus der DAM auslese für den Fall dass keiner angegeben ist.

    Mehrsprachige Flexforms musste ich noch keine machen bisher (zumindest nicht für FCEs). Für ein Plugin hatte ich aber genau deine Variante mit dem LLL:

    1. <label>LLL:EXT:edx_productnavigator/locallang_db.php:edx_productnavigator.view</label>

    Sollte also eigentlich funktionieren. Evtl. hast du dich beim Pfad verschrieben? Heißt das label in deiner locallang wirklich field.target?

  • rookie07 rookie07
    T3PO
    0 x
    17 Beiträge
    0 Hilfreiche Beiträge
    30. 07. 2012, 17:27

    hallo silkea,

    ich habe da natürlich schon etwas weitergeforscht (das mit dem "sich den wolf suchen" kann ich nur bestätigen!!!).

    das hauptproblem scheint templavoila an sich zu sein, dass für fce einen anderen mulit-sprachen modus vorsieht und zwar können hier die werte parallel eingegeben werden (soll heissen ein feld "titel" kann für die deutsche sprache - im meinem fall standard eingegeben werden, wärend sich auf dem selben be formular auch ein feld "titel" befindet welches die werte für die englische frontend ausgabe aufnimmt).

    somit war mein problem dass die lables der felder und auch die werte in der select box immer in deutscher sprache zur verfügung stehen. die übersetzung wird aus meiner locallang.xml gezogen (halt nur für die standard-sprache) was das ganze somit unnötigt macht. mit typoscript komm ich da auch nicht wirklich weiter was mich am wochenende dazu gebracht hat mich mit der entwicklung von extension zu beschäftigen (wollte eigentlich das rad nicht 2x erfinden).

    somit bin ich beim entwickeln eines frontend-plugins gelandet welches flexforms verwendet, da ziehen auch die hinterlegten sprechen etc - macht aber für mich noch nicht so richtig sinn, da ich für jedes "fce" ein eigenes plugin schreiben müsste.

    somit bin ich auf diesen artikel gestoßen: http://castironcoding.com/resources/our-blog/sp/view/single/post/reason-6-for-choosing-typo3-custom-content-elements-and-extbase-again-part-23.html

    was aber auch einen heftigen headover mit sich zieht (muss ja wieder für jedes fce dann ein plugin schreiben)

    intern konnten wir uns darauf einigen, dass wir wahrscheinlich keine übersetzungen der lables brauchen - somit kommen wieder die ursprünglichen fce mit templavoila ins spiel.

    ich werde jetzt versuchen ob ich da ins backend irgendwo javascript einschleusen kann damit ich abhängig von der ausgewählten sprache dann nur den entsprechenden block anzeige, den sprach-block bekomme ich ja im fce so hin:

    1. <meta type="array">
    2. <langChildren>1</langChildren>
    3. <langDisable>0</langDisable>
    4. </meta>

    sonst bin ich mit meinem wenigen know how bald mal am ende - einen entsprechenden hook hab ich im templavoila auch nicht gefunden wo ich ansetzten könnte - aber wie gesagt ich bin ja noch ziemlich am anfang...

    lg

  • 1