Reviewing the Role of the Condition Property
Many activities such as While or IfElse require you to set the Condition property. This will be used to
evaluate if the activity and any sub-activities should continue to execute. Recall that the While activity
makes use of a Code Condition that maps to a method in your workflow class. The ConditionalEventArgs
parameter controls the continuation of the looping logic.
Take, for example, the following While activity named AskForNameLoopActivity.
This activity can be configured with the following Code Condition. Note the name of the method being called
is GetAndValidateUserName().
This is handled by the following VB programming logic (C# code would be similar). Notice you are setting the
Result property of the ConditionalEventArgs parameter.
' VB (C# code would be similar)
Private Sub GetAndValidateUserName(ByVal sender As Object, _
ByVal e As ConditionalEventArgs)
...
e.Result = (UserName.Length >= NameLength)
End Sub
Code Conditions are very helpful when your decision logic is based on a large variety of inputs and other
runtime information. Furthermore, Code Conditions make it possible to write additional custom code
statements beyond checking a simple Boolean value. However, one possible drawback is that if your rules
change, the assembly must be recompiled—and possibly redeployed—as the data is hardcoded in the
assembly.
As an alternative to Code Conditions, the Condition property can be set using Declarative Rule Conditions.
Simply put, a ‘rule’ is a declarative statement regarding data manipulated by an activity. These rules always
evaluate to either true or false, and based on the outcome, the specified actions will execute.
Using rules, you have a declarative manner to describe business logic conditions. Therefore, rather than
hardcoding your logic within event handlers and custom properties, your rules can be placed in a dedicated *.
rules file. Rules are represented via an XML-based grammar.
Although *.rules files are always optional, there are some compelling reasons to use them. Rules provide a
separation of concerns from your business rules and the code that executes them. Rules make is possible to
change your business rules without the need to recompile your application.
Many activities such as While or IfElse require you to set the Condition property. This will be used to
evaluate if the activity and any sub-activities should continue to execute. Recall that the While activity
makes use of a Code Condition that maps to a method in your workflow class. The ConditionalEventArgs
parameter controls the continuation of the looping logic.
Take, for example, the following While activity named AskForNameLoopActivity.
This activity can be configured with the following Code Condition. Note the name of the method being called
is GetAndValidateUserName().
This is handled by the following VB programming logic (C# code would be similar). Notice you are setting the
Result property of the ConditionalEventArgs parameter.
' VB (C# code would be similar)
Private Sub GetAndValidateUserName(ByVal sender As Object, _
ByVal e As ConditionalEventArgs)
...
e.Result = (UserName.Length >= NameLength)
End Sub
Code Conditions are very helpful when your decision logic is based on a large variety of inputs and other
runtime information. Furthermore, Code Conditions make it possible to write additional custom code
statements beyond checking a simple Boolean value. However, one possible drawback is that if your rules
change, the assembly must be recompiled—and possibly redeployed—as the data is hardcoded in the
assembly.
As an alternative to Code Conditions, the Condition property can be set using Declarative Rule Conditions.
Simply put, a ‘rule’ is a declarative statement regarding data manipulated by an activity. These rules always
evaluate to either true or false, and based on the outcome, the specified actions will execute.
Using rules, you have a declarative manner to describe business logic conditions. Therefore, rather than
hardcoding your logic within event handlers and custom properties, your rules can be placed in a dedicated *.
rules file. Rules are represented via an XML-based grammar.
Although *.rules files are always optional, there are some compelling reasons to use them. Rules provide a
separation of concerns from your business rules and the code that executes them. Rules make is possible to
change your business rules without the need to recompile your application.
Activity Documentation
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services
