I was helping another friend design a guidance package, and I realized that he was thinking about recipes as wizards. This is not such a good idea, and may lead to misusing GAT.

 

Recipes are simple animals; they get information from the user and/or their environment, and execute a sequence of actions. That's it.

You can make a recipe implement a conditional flow. To do that you have to make an earlier action in the sequence provide input to a later action (through an Output property), and program that later action to take a conditional flow depending on this input. This, however, breaks atomicity of actions and will be difficult to debug.

 

The GAT wizard has been designed to simplify obtaining recipe arguments values. If you wanted conditional flow, you would most likely wanted a wizard to show or not show (gray out) fields depending on values of other fields. This can be done in the GAT wizard framework extension, but only with custom wizard pages. Even if you do that, you end up with Null arguments (the grayed out ones) and have to make actions behave differently depending on if they have or have no argument values (back to the previous point about breaking action atomicity).

 

Recipes use simple wizard mechanism to collect information from the user, but they are not like wizards. They are atomic, in that they perform a sequences of chainable, yet independent actions. They don't perform actions between wizard pages and have not been designed to execute actions conditionally.

 

If you think you need a conditional recipe, try to break it up into different recipes, each performing one thing. Let the user decide which recipe is applicable in what situation. Also, remember that one recipe can attach (spawn) another recipe.

 

-- Wojtek