Is there a way to determine if a field exists?

[scubajbc]

If I had a job that had 2 data files with different headers...

 

FirstName,LastName,Country

FirstName,LastName,State

 

is there a way to use something like .exists for fields

ie.

 

if field "Country" exists

return Resource "foo"

else

return Resource "bar"

 

Mac OSX.4.11

Acrobat 8.2.3

FusionPro 5.1P2C

[Dan Korn]

Yes, like this:

function FieldExists(Name)
{
 try
 {
   Field(Name);
   return true;
 }
 catch (e)
 {
   return false;
 }
}

Add this function in the JavaScript Globals for the job, then you can do this in a rule:

if (FieldExists("Country"))
 return Resource("foo");
else
 return Resource("bar");

[DSweet]

Dan,

 

Does using this feature also mean that you do not have to have the same data layout all the time?

 

We have data processing programs that have been written so long ago that no one that is still here knows what they do or how the processing rules and features come out with their final results. Obviously a bad documentation problem to begin with in the original programming - which is another headache for us. But the output for data files that are to be mailed using a "presorted standard or first-class" structure seem to come out with different headers and fields than those files that are sent straight first-class. The difference being the necessary fields for the mailing needs: barcode, endorsement line, tray/pack and sequence numbers. We are in the process of picking this program apart line by line but that will take quite some time. Currently we have to use two separate template for this and when some of the rules, graphics or text changes for one template we have to remember to change them for the other one as well. Another big pain for us.

 

If I use this feature of the "FieldExist" function, can I use data files with completely different structures (fields and header names) within the same template on FP desktop and server versions without the normal error/warning about the "fields not matching do you want to use this file anyway"?

[Dan Korn]

Does using this feature also mean that you do not have to have the same data layout all the time?

Well, there's no real reason that you have to use the same data layout all the time anyway, regardless of this feature. You'll just have to deal with any problems that crop up from the data not supplying the same field names that the template design is expecting.

 

You can also use this feature to look for a field from a set of possible names, as in this thread.

We have data processing programs that have been written so long ago that no one that is still here knows what they do or how the processing rules and features come out with their final results. Obviously a bad documentation problem to begin with in the original programming - which is another headache for us. But the output for data files that are to be mailed using a "presorted standard or first-class" structure seem to come out with different headers and fields than those files that are sent straight first-class. The difference being the necessary fields for the mailing needs: barcode, endorsement line, tray/pack and sequence numbers. We are in the process of picking this program apart line by line but that will take quite some time. Currently we have to use two separate template for this and when some of the rules, graphics or text changes for one template we have to remember to change them for the other one as well. Another big pain for us.

Yep, I'm sure there are a lot of jobs like that out there, where it's almost impossible to figure out what the previous designer was trying to do. Just like if you're a developer, you have to sort through a lot of old code that's mysterious and poorly documented. Not that anything like that every happens to me, or to the next guy who has to read my code.

If I use this feature of the "FieldExist" function, can I use data files with completely different structures (fields and header names) within the same template on FP desktop and server versions without the normal error/warning about the "fields not matching do you want to use this file anyway"?

Sure, like I said, you can use any data you want, it's just a matter of how you deal with having different data field names in your rules. I don't think you can suppress that warning message, though; it is really trying to tell you something that you (or 95 percent of users) probably want to know.