& problems in rules

[NPN]

I've made a rule with IF's that work fine except for values with an '&'.

 

This is AFTER I've collected and uploaded it to DSF.

 

The rule basically changes the language for the other side of a business card. So, IF field 'department'(pick list) contains 'soandso' return 'loandlo'

Which works fine, except where 'department' contains an '&'

 

So IF field 'department' contains 'so & so' return 'lo & lo', doesn't work.

 

The field just returns blank. I suspect this is because of the XML file, but I don't know how to fix it.

 

Any ideas?

[esmith]

We convert special characters to their respective HTML entities in the data so an ampersand is replaced my "&" in the data ("loandlo" would become "lo&lo").

[Dan Korn]

The problem is that the input data for FP Server, generated from a web form by the DSF application, is in an XML-like tagged markup format, which is different than the flat (delimited) data files which are typically used in FP Desktop. If you type an ampersand in the web form, the DSF app correctly converts this to an & entity for the generated tagged markup input file. (At least I think it does; you'd need to talk to the folks at EFI about exactly how their app handles the form data.) MarcomCentral users have similar issues from time to time, although we've made a lot of improvements in both FusionPro and MarcomCentral to alleviate these kinds of issues.

 

I'd have to see your exact rule to suggest a specific workaround, but generally, you need to account for the fact that the tagged markup input will have entities and such in it. FusionPro has a TaggedDataField function which figures out whether the input data itself is tagged or not, which can help in crafting a rule that will work both in FP Desktop with flat file data and in a Web-to-Print system such as DSF using tagged markup for FP Server.

 

So if your rule is doing something like this:

if (Field("department") == "this & that")

You'll want to do something like this instead:

if (TaggedDataField("department") == NormalizeEntities("this & that"))

Again, though, I'd have to see the rule to offer a more specific suggestion.

[NPN]

I managed a workaround based on ESMITH comments. (thanks!)

 

This worked:

 

switch (Field("department").toLowerCase())

{

case "This & that".toLowerCase():

return "Lo & behold";

 

Dan, I didn't get to try your workaround, but thanks.

 

I'm back in business.