LesSjo Posted November 18, 2009 Share Posted November 18, 2009 I am trying to get this function to work, but FP doesn't like it. My issue is this: I have a text field that I need to have return an &, but it returns an & help. It has got to be something simple. Link to comment Share on other sites More sharing options...
esmith Posted November 18, 2009 Share Posted November 18, 2009 NormalizeEntities(Field("YOUR FIELD")) is your friend. Link to comment Share on other sites More sharing options...
LesSjo Posted November 19, 2009 Author Share Posted November 19, 2009 I tried that and it still doesn't work. See attached. Link to comment Share on other sites More sharing options...
esmith Posted November 19, 2009 Share Posted November 19, 2009 Stupid question. Does your data file have "&" or "&" in the field itself? Link to comment Share on other sites More sharing options...
LesSjo Posted November 19, 2009 Author Share Posted November 19, 2009 the data has a "&". this is also a form being set up for Marcom Central and I didn't realize that it would be an issue because I hadn't tested it. The customer is actually doing testing of the product (getting used to the store front before it goes live) and used the "&" in the data field. Link to comment Share on other sites More sharing options...
esmith Posted November 19, 2009 Share Posted November 19, 2009 I can't recreate the problem on my end. Can you post the one record so I can test it on my end? I'm wondering if it is due to data being generated on a PC with composition (preview) happening on a Mac? Link to comment Share on other sites More sharing options...
LesSjo Posted November 19, 2009 Author Share Posted November 19, 2009 Now I am totally confused. I took the NormalizeEntities off like it was in the beginning and it now works. Link to comment Share on other sites More sharing options...
LesSjo Posted November 19, 2009 Author Share Posted November 19, 2009 Too soon I start to think my day is going to be peachy... Once I loaded it online the "&" shows back up. If I put the normalize entities back on, "&" shows up online, but only "&" shows up in FPdesktop.sampleBC.zip Link to comment Share on other sites More sharing options...
esmith Posted November 19, 2009 Share Posted November 19, 2009 Everything works peachy on my end. Both return Field() and return NormalizeEntitities(Field()) (the latter with return tagged text checked) work in Preview mode. If you are still having problems it may be time to restart hardware? Not knowing much about MarcomCentral, is it possible the problem could be occurring on that end? Link to comment Share on other sites More sharing options...
LesSjo Posted November 19, 2009 Author Share Posted November 19, 2009 I initially ran this thread in the javascript forum, but now am thinking it may be a Marcom Central issue. Link to comment Share on other sites More sharing options...
Dan Korn Posted November 19, 2009 Share Posted November 19, 2009 What you need to look at is the "Treat returned strings as tagged text" check box. If that box is checked, and you are returning a string which may contain ampersands (&), less-than characters (<), or any other characters which denote a tag or entity in tagged markup, then you need to use the TaggedTextFromRaw (or NormalizeEntities in older versions) function to replace those characters with entities so that they are processed properly. Generally you will need to do this for rules which already use tags to modify the style of the text. If your rule is simply returning field data, without any other tags, then you can leave the box unchecked, and you don't need to call TaggedTextFromRaw, and the text will be properly handled even if it contains any of the special characters. This functionality is exactly the same in FusionPro Desktop as in MarcomCentral (or other FP Server) jobs. Link to comment Share on other sites More sharing options...
LesSjo Posted November 19, 2009 Author Share Posted November 19, 2009 Attached is the rule and the outputs from FP Desktop and Marcom Central. I can't figure out why I am getting two different results. Link to comment Share on other sites More sharing options...
Dan Korn Posted November 19, 2009 Share Posted November 19, 2009 Attached is the rule and the outputs from FP Desktop and Marcom Central. I can't figure out why I am getting two different results. Okay, when I said that the functionality of the "Treat returned strings as tagged text" check box and the TaggedTextFromRaw function is exactly the same in FusionPro Desktop as in MarcomCentral (or other FP Server) jobs, that's still absolutely true, for the same data. The reason you're getting different results in FusionPro Desktop and in MarcomCentral is because the input data being sent to the composition engine is different. In FP Desktop, you specify an input file (usually delimited, or "flat" text), and you are responsible for making sure that the data in the file is in the correct format. With MarcomCentral, the data is driven by the web application. For "versioned" jobs, there's a form where the data is entered, and then MarcomCentral generates an input file (in tagged format) for FP Server. For "VDP" jobs, I believe what happens is that your input data is still re-written to a different format for composition. This is about the limit of my personal knowledge of MarcomCentral, though, so someone who knows more about that side of things may have to look into this further. You may want to contact your CPM. Link to comment Share on other sites More sharing options...
LesSjo Posted November 19, 2009 Author Share Posted November 19, 2009 I appreciate your input. I will continue the hunt. Link to comment Share on other sites More sharing options...
LesSjo Posted November 20, 2009 Author Share Posted November 20, 2009 Checking the "Treat returned strings as tagged text" check box - even though there were no tagged items in the rule - fixed this issue. I am totally confused... but it works. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.