Desarrollo de la autonomía desde diferente punto de vista

Among other things, dependency properties in our Office workflows give us the ability to tie our activity properties to values that will not exist until runtime. Typically, this is going to be something from the

WorkflowProperties collection, but there is nothing that says it has to be. In our example, we’re tying our

PayloadItem dependency property to whatever SPListItem the workflow is running on. When the work- flow executes, that value will be available to us, but it is not available at design time. We can’t even code for it in our activity because the bridge from the activity to the workflow won’t exist until runtime.

At design time, the property is rendered as shown here. We can specify what value we want, and can operate on the object as an SPListItem.

This isn’t to say that you should always use dependency properties. If the property you are working on is not dependent on the specific workflow instance—for example, you just need to collect a simple string from the Designer—you can write regular component-type properties with a member variable backing it up.

Dependency properties are great for when you need them, but otherwise, they just introduce overhead and complexity. So, if you need them—great, use them. If not, keep things simple and use regular properties.

We’ll start with dependency properties. In their ongoing effort to be helpful, Microsoft has provided us with a very easy way to add new dependency properties to our workflow activities through the Code Snippet functionality introduced in Visual Studio 2005. Within the Workflow category is a snippet for inserting a dependency property. Use that snippet to insert a skeleton into our class file. Make the few modifications necessary to convert the snippet to the contents of Listing 5-6 and our custom property is complete.

Listing 5-6. The Final Source for Our Custom Property Definition

public static DependencyProperty PayloadItemProperty =➥

DependencyProperty.Register("PayloadItem", typeof(➥

Microsoft.SharePoint.SPListItem),➥

[DesignerSerializationVisibilityAttribute(➥

DesignerSerializationVisibility.Visible)] [BrowsableAttribute(true)]

[DescriptionAttribute("List Item the Workflow is operating upon")] [CategoryAttribute("Configuration")]

public SPListItem PayloadItem { get { return ((SPListItem)(base.GetValue(KCD.SharePoint.Activities.MacroStripperActivity.➥ PayloadItemProperty))); } set { base.SetValue(KCD.MacroStripper.➥ PayloadItemProperty, (SPListItem)value); (SPListItem)value); } }

Each of the attributes decorating our property in Listing 5-6 means something different to Visual Studio and the Workflow Designer. They are described briefly in Table 5-3.

Table 5-3. Design-Time Property Attributes

Attribute Description

DesignerSerializationVisibilityAttribute Controls how the property will be serialized. Possible values for this attribute are:

Visible: Specifies that the property should be serialized. Use this value for simple properties.

Hidden: Specifies that the property should not be serialized.

Content: Specifies that contents of the object should be serialized. Use this value for complex properties and collections.

ValidationVisibilityAttribute Controls validation of the values supplied for the property by the workflow builder. Possible values for this attribute are:

Optional: The property can be null.

Required: The workflow builder must supply a value.

Hidden: No validation will occur.

BrowsableAttribute Controls whether or not the property is displayed in the Properties window.

That takes care of an example of using a dependency property, but as I said, you don’t always need a dependency property. Sometimes a regular old simple property will do the trick quite nicely. Listings 5-7 through 5-10 show the standard properties that we need for our solution.

Listing 5-7. Nothing Special Here—Just a Regular Old Property

private string _finalDocumentName;

[DesignerSerializationVisibilityAttribute(DesignerSerializationVisibility.➥

Visible)]

[BrowsableAttribute(false)]

[DescriptionAttribute("Name of macro-free document in Document Library")] [CategoryAttribute("Configuration")]

public string FinalDocumentName {

get { return _finalDocumentName; } set { _finalDocumentName = value; } }

You’ll notice in Listing 5-7 that this property is not going to show up in the Properties window because its BrowsableAttribute is set to false. This property is going to be accessed in our Workflow code in Chapter 6 to retrieve the name of the macro-free document.

Next up (Listing 5-8) is another property that is only used in code. This time it is the oppo- site of the previous property—it stores the original name of the document before we started tearing it apart and looking to put it back together again.

Listing 5-8. A Property to Store the Original Name of Our Payload’s Document

private string _originalDocumentName;

[DesignerSerializationVisibilityAttribute(DesignerSerializationVisibility.Visible)] [BrowsableAttribute(false)]

[DescriptionAttribute("Original name of document in Document Library")] [CategoryAttribute("Configuration")]

DescriptionAttribute A brief description of the property to help the workflow builder understand what the property is used for. This is displayed in the Properties window of Visual Studio.

CategoryAttribute Indicates the category in which the property appears within the Properties window of Visual Studio.

Table 5-3. Design-Time Property Attributes

public string OriginalDocumentName {

get { return _originalDocumentName; } set { _originalDocumentName = value; } }

One more property is shown in Listing 5-9. This time around, we’re storing a reference to the SPList that our workflow is running within. As before, this is going to be used later in Chapter 6.

Listing 5-9. Setting Up Our ParentList Property

private SPList _parentList;

[DesignerSerializationVisibilityAttribute(DesignerSerializationVisibility.Visible)] [BrowsableAttribute(false)]

[DescriptionAttribute("SPList item containing document")] [CategoryAttribute("Configuration")]

public SPList ParentList {

get { return _parentList; } set { _parentList = value; } }

Last but not least, we need to set up a property we can check from the workflow to see whether or not we successfully removed the macros from the file. Listing 5-10 shows this code.

Listing 5-10. The IsMacroFree Property

private bool _isMacroFree = false;

[DesignerSerializationVisibilityAttribute(DesignerSerializationVisibility.Visible)] [BrowsableAttribute(false)]

[DescriptionAttribute("Indicates whether resulting document is free of macros")] [CategoryAttribute("Configuration")]

public bool IsMacroFree {

get { return _isMacroFree; } set { _isMacroFree = value; } }