WF from Getting started to proficient (16th chapter): Declarative Workflows

After completing this chapter, you will learn:

1. Understand the main differences between the procedural (imperative) workflow model and the declarative (declarative) workflow model

2. Create a declarative workflow

3. Use XAML XML vocabulary to create workflows

4. Transfer into a XAML based workflow and execute

Many developers may not know that WF can execute workflows using a procedural definition (using the Workflow View Designer), as well as using declarative definitions to perform workflows (workflows use XML for definitions).

Every style has its advantages. When you create your workflow application using the techniques we've used throughout this book, the workflow model is actually compiled into an executable assembly. The advantage is that it is faster to load and execute the workflow.

But this style also lacks flexibility. Although there are ways to add dynamic capabilities to WF (this is not included in this book), usually your workflows still have to be compiled by you. If your business processing logic changes, unless you use declarative rules (discussed in chapter 12th "policies and Rules") for the decisions in your workflow, you will have to revise your workflow definitions, compile and deploy them, along with all the relevant testing and validation work.

However, the workflow runtime is capable of accepting almost any form of workflow definition. You've had to write code to translate the workflow definition you provide into a model that the workflow can execute when it runs. In fact, these are the things that WF does to deal with xml-based workflow definitions.

As you might expect, documenting your workflow into an XML-formatted file makes it easy to modify and redeploy. Instead of recompiling your workflow in Microsoft Visual Studio, you can simply use any XML editor (even the "Notepad" in Windows) Notepad) to modify the Xml-based workflow definition and to provide the workflow model that it creates to the workflows runtime. You can even have both worlds: Compile your XML workflow definition by using the workflow compiler for WF. This is what we'll explore in this chapter.

Declarative Workflow--xml Tag

First, the definition of a declarative application (which includes WPF) in. NET 3.0 has a long history. WPF begins to provide declarative programming capabilities that can be fully declarative and partially declarative. You can encapsulate your application completely using XML tag words like XML Application Markup Language or XAML (read as "Zammel"). Alternatively, by using a special XAML based structure, you can compile parts of your application into an assembly and transfer it into execution through XAML. You can even write down the C # code and embed it in your XAML definition, or put your C # code in a code-behind file for later execution.

Note: You cannot find a more recent book than Charles Petzold: "Application = code + tags" ("Application = codes + Markup", 2006 Microsoft Printing) better in terms of XAML and WPF monographs. If you are interested in the detailed details of the XAML thesis, it is highly recommended that you look again at Chapter 19th of this book.

The following experiment is actually just for fun. Create a new text file in your system and name it Button.xaml. Enter the code in listing 16-1 into the file and save it, and then double-click the file. Because you have to install the. NET 3.0 component to create a workflow application, you have also completed registering for the. xaml type file. Windows knows to load a XAML file into your Web browser and display it. Although it has only one button, it is a complete WPF application, although it is simple. Figure 16-1 shows the output effect of the button using the IE 7.0来 in Window XP.

<?xml version= "1.0"?>
<button xmlns= "http://schemas.microsoft.com/winfx/2006/xaml/presentation" margin= "foreground=" "Blue" Fontsize= "36pt" >
    hello,world!
</Button>

Listing 16-1 example of a XAML-based application showing a button

Figure 16-1 A XAML-based button that is running

WF teams also incorporate these ideas into WF. Although the XML for WF follows the convention of a XAML namespace, the file name that contains the XML associated with WF is usually named with the. xoml file extension. This approach allows the automation tool to interpret the file as a workflow file rather than as a look (presentation) file. In fact, one of the tools we'll use in this chapter is called the Workflow Compiler (Wfc.exe), which requires a file of the. xoml type when creating a XAML based workflow.

Although listing 16-1 is not a declaration of workflows, take a closer look at the XML you see. Note the name of the XML element is the same as the name supported in the. NET WPF class, and in this case it is a button. It is also worth mentioning that the properties of the button are interpreted by the XAML file: Fontsize,margin and foreground. By changing these properties or adding other properties, we can easily modify the attributes of the button.

XAML files based on workflows also have the same characteristics. The name of an XML element represents an activity type such as CodeActivity or ifelseactivity. As you might expect, each element can contain their attributes and their values. As for the structure of the workflow, the composite activity will have a child XML element, while the underlying activity is not.