Variable validation within process plan

[AdrianC]

Hi everyone,

I’m not sure if this forum can be used to ask for help or just to discuss bugs/issues, feature requests, etc. If so, my apologies.

I’m having an issue during a variable check. I will eventually be using this profile in Switch, but for now I’m testing it in pdfToolbox Desktop.

I’m capturing all the variables in “FST_1up_Spec”:
app.requires(“isSelfCover”,true,{label:“Is Self-Cover”,regex:true});
app.requires(“bindingEdge”,“Left”,“Binding Edge”,[“Left”, “Top”]);
app.requires(“gutter”,6,“Gutter Between FST books (min 6mm)”);
app.requires(“cutMarkOffset”,3,“Cut Mark Offset”);
app.requires(“cutMarkLength”,3,“Cut Mark Length”);

With “isSelfCover” being a boolean, but “bindingEdge” as string.

The boolean “isSelfCover” is working.

The problem is happening in the “bindingEdge:Top” check, where it’s not recognising the different options and it always goes through the success path.

It’s also possible I’m using this feature incorrectly.

Any help would be greatly appreciated.

[David]

This is an absolutely valid topic here - so no worries there!

Your problem is caused by misunderstanding how a Process Plan with a variable is going to react I think.

Your “bindingedge” variable will either be “Top” or “Left” because those are the options you give to the user. For pdfToolbox both of these are “truthy”, and so both of these would go through the success path.

In your initial script, I would do something like this:

app.vars.flipForTopEdge = app.vars.bindingEdge == "Top";

So you create a new variable that will either be true or false. You would now use the “flipForTopEdge” variable in your Process Plan instead of the “bindingEdge” one.

In short: if you want to use a simple variable in a Process Plan to select different directions, it should either be “0” / false, or “1” / true.

Does that make sense?

[AdrianC]

Perfect. That works.

Thanks

The only issue I’m having now is passing the boolean value for “isSelfCover” from Switch.

The variables I’m passing to Callas are:
isSelfCover:[Metadata.Boolean:Dataset=“Xml”,Model=“XML”,Path=“/XmlPcJobTicket/IsSelfCover”]
bindingEdge:[Metadata.Text:Dataset=“Xml”,Model=“XML”,Path=“/XmlPcJobTicket/BindingEdge”]

Our xml has the field for “isSelfCover” as a boolean, but with title case (“True”, "False). Switch seems to use the same title case for it’s booleans (as far as I’ve seen on results). But it seems Callas uses lower case?

And I can’t create a script to convert to lower case within the Callas App list of values.

Do I need to do the same with “isSelfCover” as you suggested for “bindingEdge”?

[David]

That would probably be easiest, yes.

What I typically do in cases like this, is having the first part of the script take in all variables that come from the outside, and convert them to what I really want.

So my set of variables I use inside the Process Plan is typically completely shielded from what comes from the outside. This means that if you change your mind about what you’re passing from Switch (well, “when”, not “if” probably - we all change our minds eventually ), you only have this “translation” part of your script to change…