A quick note on using DynamicUpdatePanels and body onload events. The update panels, when updated, do not trigger the body’s onload event. To get past this, we can use the form’s “Script” section and use the native function pageLoad() to run the actions we want to have happen.
Whether this is a great, or extensible, or lazy, or short-sighted solution is likely quite debatable. However, I use this method for nearly every variable evaluation, and have never had a terrible issue with it.
Let’s set up a situation — say you’re doing a search for a set of values in a SQL table. The results need to be mapped to another variable, but if there are no results (null), the mapping component fails. We need to verify that a value exists prior to leading the data to the mapping component.
Have a look at two examples of sprawling processes, and imagine trying to make sense of them. The first I can take credit for; the second, I can only take credit for grabbing a screenshot when I saw it.
Let’s take a look at how to keep a readable, usable Workflow canvas, and untangle that spaghetti.
After I gained a bit of experience with Workflow, I began to attempt to tackle more complex processes. While developing these, I ended up with a sprawling mess of a canvas, duplicate evaluations and actions, and path lines jumping all over the place and each other. It was at that point that another, more experienced Workflow developer showed me the importance of modular processes, how to configure them, when to use them, and the difference between model types.
First helpful rule: if using the “fit to screen” zoom button renders the Workflow tiny and indecipherable, then you could likely benefit from some linked or embedded models. We’ll go over the different types shortly.
Second helpful rule: the easiest way to simplify the sprawl of a workflow is to group components into Embedded Rule Model components. Embedded Rule Models are like using folders to sort a stack of random documents on your desk into a nice, neat filing system.