[TYPO3-german] Fluid raw vs. html

[Dr. Dieter Porth]

Hallo Christoph,

deine Vermutung ist falsch.

f:format.html ohne Parameter ist von der Benennung her schlecht gewählt; 
Wenn man in den Code schaut, sieht man, dass per Default der Viewhelper 
'nur' das TypoScript ' lib.parseFunc_RTE' auf den Inhalt anwendet.

Durch den doppelten Aufruf wird dein HTML nur zweimal geparst, was für 
die Laufzeit schlecht ist.

Mit besten Grüßen

    Dieter

TypoScript

Zusatzinfo: 
http://www.typo3lexikon.de/typo3-tutorials/typoscript/referenz/parsefunc.html

# Creates persistent ParseFunc setupfor non-HTML content.
lib.parseFunc {
    makelinks =1 makelinks {
       http {
          keep = {$styles.content.links.keep}
          extTarget = {$styles.content.links.extTarget}
       }
       mailto {
          keep = path
       }
    }
    tags {
       link = TEXT
       link {
          current =1 typolink {
             parameter.data = parameters : allParams
             extTarget = {$styles.content.links.extTarget}
             target = {$styles.content.links.target}
          }
          parseFunc.constants =1 }
    }
    allowTags = {$styles.content.allowTags}
    denyTags = *
    sword = <spanclass="ce-sword">|</span>
    constants =1 nonTypoTagStdWrap {
       HTMLparser =1 HTMLparser {
          keepNonMatchedTags =1 htmlSpecialChars =2 }
    }
}


# Creates persistent ParseFunc setupfor RTE content (which is mainly HTML) based on the"ts_css" transformation.
lib.parseFunc_RTE < lib.parseFunc
lib.parseFunc_RTE {
    # Processing <table> and <blockquote> blocks separately
    externalBlocks = article, aside, blockquote, div, dd, dl, footer, header, nav, ol, section, table, ul
    externalBlocks {
       # The blockquote content is passed into parseFunc again...
       blockquote {
          stripNL =1 callRecursive =1 callRecursive {
             tagStdWrap {
                HTMLparser =1 HTMLparser.tags.blockquote.overrideAttribs = style="margin-bottom:0;margin-top:0;" }
          }
       }

       ol {
          stripNL =1 stdWrap.parseFunc = < lib.parseFunc
       }

       ul {
          stripNL =1 stdWrap.parseFunc = < lib.parseFunc
       }

       table {
          stripNL =1 stdWrap {
             HTMLparser =1 HTMLparser {
                tags.table.fixAttrib.class {
                   default = contenttable
                   always =1 list = contenttable
                }
                keepNonMatchedTags =1 }
          }
          HTMLtableCells =1 HTMLtableCells {
             # Recursive call toself but without wrapping non-wrapped cell content
             default.stdWrap {
                parseFunc = < lib.parseFunc_RTE
                parseFunc.nonTypoTagStdWrap.encapsLines.nonWrappedTag =
             }
             addChr10BetweenParagraphs =1 }
       }

       div {
          stripNL =1 callRecursive =1 }

       article < .div
       aside < .div
       footer < .div
       header < .div
       nav < .div
       section < .div
       dl < .div
       dd < .div
    }
    nonTypoTagStdWrap {
       encapsLines {
          encapsTagList = p,pre,h1,h2,h3,h4,h5,h6,hr,dt
          remapTag.DIV = P
          nonWrappedTag = P
          innerStdWrap_all.ifBlank = &nbsp;
       }
    }
    nonTypoTagStdWrap {
       HTMLparser =1 HTMLparser {
          keepNonMatchedTags =1 htmlSpecialChars =2 }
    }
}


Am 01.12.2016 um 08:34 schrieb Christoph:
> Hallo Dieter,
>
> danke für die Info!
>
> Was mir noch eingefallen ist: Die Templatefiles von fluid styled content
> geben den Bodytext bereits mit <f:format.html>....</f:format.html>  aus.
> Ich vermute, dass die erneute Ausgabe mit
> <f:format.html>{content}</f:format.html> in meine "Designtemplate" dann
> die Probleme verursacht.
>
> VG
> Christoph
>
>
> Am 01.12.2016 um 07:17 schrieb Dr. Dieter Porth:
>> Hallo Christoph,
>>
>> Die P's kommen sicher vom RTE.
>>
>> Entwder die p's zu entfernen  bzw. nicht erzeugen lassen.  Ich habe
>> die Konfigurationen nicht alle vor augen und müsste sie auch googlen.
>> Vielleicht hat einer der Mitleser aktuell einen Konfigurationshinweis
>> zur Hand.
>>
>> Wenn die p--Tags das Layout zerschießen, dann ist aber vielleicht auch
>> dein Layout subopmtial. Vielleicht solltest du es überarbeiten, da es
>> ja schon sein kann, dass später zum Beispiel Blockstyles im TRE
>> verwenden möchte. Es wäre also besser, das Layout schon jetzt an die
>> Eigenheiten von TYPO3 anzupassen.
>>
>> Mit besten Grüßen
>>
>>         Dieter
>>
>>
>> Am 30.11.2016 um 22:29 schrieb Christoph:
>>> Hallo Zusammen!
>>>
>>> Frage zu Fluidtemplates: wenn ich den Inhalt einer Seite (z.B. alles von
>>> Spalte "normal") ausgeben will und das ganze via
>>>
>>>                   <f:format.html>{content}</f:format.html>
>>>
>>> einfüge, zerschießt es mir das Layout, da um jedes Element größeren
>>> Mengen <p>´s platziert werden (die im Backend nicht sichtbar sind). Mit
>>> "raw" kommt ein vernünftiger Output heraus
>>>
>>>                    <f:format.raw value="{content}" />
>>>
>>>
>>> Ist "raw" in dem Fall die richtige Wahl? Gibt es einen besseren Weg?
>>>
>>> Danke!
>>> VG
>>> Chirs
>>>
>>> _______________________________________________
>>> TYPO3-german mailing list
>>> TYPO3-german at lists.typo3.org
>>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
>> _______________________________________________
>> TYPO3-german mailing list
>> TYPO3-german at lists.typo3.org
>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
>
> _______________________________________________
> TYPO3-german mailing list
> TYPO3-german at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german