Friday, July 14, 2017, 3:14:28 PM, Riehemann, Michael wrote: > Hi Freemarker Devs! > > We are using Freemarker since years and changed our old templates > with no output format to output format HTML to get rid of all the "?thml" and > "<#escape/> parts. > > Everything is fine so far, except that some typical things stopped > working, because some variables are now markup_output instead of > string. So we can't use Built-ins for strings on them anymore. See > example below. What can we do? Do we need the same Built-ins for > markup_output? Can we cast markup_output back to string?
You can get the markup behind a markup_output as a string via ?markup_string: http://freemarker.org/docs/ref_builtins_expert.html#ref_builtin_markup_string Be careful, the result of ?markup_string is just a string and so is subject to auto-escaping again. That's one reason why captured output is not a string. However, it should be very rare that you want to do string manipulation or comparison on captured output. It mostly only meant to be reprinted. Markups tend to have many ways of describing the same thing (like <foo a="1" b="2"/> is equivalent to <foo b='2' a="1"/>, yet as strings they differ). Also they are easily corrupted by most string operations (like when you get a substring, you may end up with unclosed elements). Are you perhaps using #macro where you should use #function? > Any help is appreciated. > > Thanks > --Michael Riehemann > > > > Example: > <#ftl output_format="HTML"> > > <#macro smallTest text> > ${text} > </#macro> > > <#assign smallTestResult><@smallTest "test" /></#assign> > > <#if smallTestResult == "test"> > smallTestResult: ${smallTestResult} > </#if> > > Result: > Can't compare values of these types. Allowed comparisons are > between two numbers, two strings, two dates, or two booleans. > Left hand operand is a markup_output (wrapper: f.c.TemplateHTMLOutputModel). > Right hand operand is a string (wrapper: f.t.SimpleScalar). > The blamed expression: ==>> smallTestResult == "test" [in nameless template at line 9, column 6] -- Thanks, Daniel Dekany
