Matt W's Windows Workflow Place : designer

Inspection, Default Services and Items (WF4 EditingContext Intro Part 6)

mwinkle — Wed, 23 Dec 2009 01:59:00 GMT

This part 6 of my 6 part series on the EditingContext.

Introduction

Sharing Functionality between Designers

Host provided capabilities

Providing callbacks for the host

Subscription/Notification engine

Inspection, Default Services and Items (you are here)

I want to wrap up this series of posts by posting some code for an activity designer that functions more as a diagnostic tool, and will display all of the Items and services of the EditingContext within the designer. This will be useful from an investigation perspective, and hopefully as a diagnostic tool. We will use this to help us understand what are the services that are available out of the box in VS, as well as in a rehosted application.

We first need to create an empty activity to attach a designer to.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Activities;
using System.ComponentModel;

namespace blogEditingContext
{
    [Designer(typeof(DiagnosticDesigner))]
    public sealed class Diagnosticator : CodeActivity
    {
        // Define an activity input argument of type string
        public InArgument<string> Text { get; set; }

        // If your activity returns a value, derive from CodeActivity<TResult>
        // and return the value from the Execute method.
        protected override void Execute(CodeActivityContext context)
        {
            // Obtain the runtime value of the Text input argument
            string text = context.GetValue(this.Text);
        }
    }
}

Now, let’s create our designer. We could do fancy treeviews or object browser style UI’s, but as this is a blog post, I want to provide you with the basics, and then let you figure out how that is most useful to you. So, we will just create a designer that writes out to debug output the relevant information.

<sap:ActivityDesigner x:Class="blogEditingContext.DiagnosticDesigner"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:sap="clr-namespace:System.Activities.Presentation;assembly=System.Activities.Presentation"
    xmlns:sapv="clr-namespace:System.Activities.Presentation.View;assembly=System.Activities.Presentation">
  <Grid>
        <Button Click="Button_Click">Debug.WriteLine Context Data</Button>
    </Grid>
</sap:ActivityDesigner>

And now the code

using System.Diagnostics;
using System.Linq;
using System.Windows;

namespace blogEditingContext
{
    // Interaction logic for DiagnosticDesigner.xaml
    public partial class DiagnosticDesigner
    {
        public DiagnosticDesigner()
        {
            InitializeComponent();
        }

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            // the goal here is to output meaningful and useful information about 
            // the contents of the editing context here. 
            int level = Debug.IndentLevel;
            Debug.WriteLine("Items in the EditingContext");
            Debug.IndentLevel++;
            foreach (var item in Context.Items.OrderBy(x => x.ItemType.ToString()))
            {
                Debug.WriteLine(item.ItemType);
            }

            Debug.IndentLevel = level;
            Debug.WriteLine("Services in the EditingContext");
            foreach (var service in Context.Services.OrderBy(x => x.ToString()))
            {
                Debug.WriteLine(service);
            }
        }
    }
}

Let’s break this down. The work here happens in the button click where we simply order by types’ string representations and output them to the debug writer (a more robust implementation might use a trace writer that could be configured in the app, but for this purpose, this will be sufficient.

So, what output do we get?

VS Standard Services and Items

We determine this by using the activity in a freshly opened WF project

Items

System.Activities.Presentation.Hosting.AssemblyContextControlItem

System.Activities.Presentation.Hosting.ReadOnlyState

System.Activities.Presentation.Hosting.WorkflowCommandExtensionItem

System.Activities.Presentation.View.Selection

System.Activities.Presentation.WorkflowFileItem

Services

System.Activities.Presentation.Debug.IDesignerDebugView

System.Activities.Presentation.DesignerPerfEventProvider

System.Activities.Presentation.FeatureManager

System.Activities.Presentation.Hosting.ICommandService

System.Activities.Presentation.Hosting.IMultiTargetingSupportService

System.Activities.Presentation.Hosting.WindowHelperService

System.Activities.Presentation.IActivityToolboxService

System.Activities.Presentation.IIntegratedHelpService

System.Activities.Presentation.IWorkflowDesignerStorageService

System.Activities.Presentation.IXamlLoadErrorService

System.Activities.Presentation.Model.AttachedPropertiesService

System.Activities.Presentation.Model.ModelTreeManager

System.Activities.Presentation.Services.ModelService

System.Activities.Presentation.Services.ViewService

System.Activities.Presentation.UndoEngine

System.Activities.Presentation.Validation.IValidationErrorService

System.Activities.Presentation.Validation.ValidationService

System.Activities.Presentation.View.ActivityTypeDesigner+DisplayNameUpdater

System.Activities.Presentation.View.DesignerView

System.Activities.Presentation.View.IExpressionEditorService

System.Activities.Presentation.View.ViewStateService

System.Activities.Presentation.View.VirtualizedContainerService

Basic Rehosted Application Standard Services and Items

Items

System.Activities.Presentation.Hosting.ReadOnlyState

System.Activities.Presentation.Hosting.WorkflowCommandExtensionItem

System.Activities.Presentation.View.Selection

Services

System.Activities.Presentation.DesignerPerfEventProvider

System.Activities.Presentation.FeatureManager

System.Activities.Presentation.Hosting.WindowHelperService

System.Activities.Presentation.Model.AttachedPropertiesService

System.Activities.Presentation.Model.ModelTreeManager

System.Activities.Presentation.Services.ModelService

System.Activities.Presentation.Services.ViewService

System.Activities.Presentation.UndoEngine

System.Activities.Presentation.Validation.ValidationService

System.Activities.Presentation.View.DesignerView

System.Activities.Presentation.View.ViewStateService

System.Activities.Presentation.View.VirtualizedContainerService

Comparison Table View

Items	VS	Rehosted
System.Activities.Presentation.Hosting.AssemblyContextControlItem	Yes	No
System.Activities.Presentation.Hosting.ReadOnlyState	Yes	Yes
System.Activities.Presentation.Hosting.WorkflowCommandExtensionItem	Yes	Yes
System.Activities.Presentation.View.Selection	Yes	Yes
System.Activities.Presentation.WorkflowFileItem	Yes	No

Services	VS	Rehosted
System.Activities.Presentation.Debug.IDesignerDebugView	Yes	No
System.Activities.Presentation.DesignerPerfEventProvider	Yes	Yes
System.Activities.Presentation.FeatureManager	Yes	Yes
System.Activities.Presentation.Hosting.ICommandService	Yes	No
System.Activities.Presentation.Hosting.IMultiTargetingSupportService	Yes	No
System.Activities.Presentation.Hosting.WindowHelperService	Yes	Yes
System.Activities.Presentation.IActivityToolboxService	Yes	No
System.Activities.Presentation.IIntegratedHelpService	Yes	No
System.Activities.Presentation.IWorkflowDesignerStorageService	Yes	No
System.Activities.Presentation.IXamlLoadErrorService	Yes	No
System.Activities.Presentation.Model.AttachedPropertiesService	Yes	Yes
System.Activities.Presentation.Model.ModelTreeManager	Yes	Yes
System.Activities.Presentation.Services.ModelService	Yes	Yes
System.Activities.Presentation.Services.ViewService	Yes	Yes
System.Activities.Presentation.UndoEngine	Yes	Yes
System.Activities.Presentation.Validation.IValidationErrorService	Yes	No
System.Activities.Presentation.Validation.ValidationService	Yes	Yes
System.Activities.Presentation.View.ActivityTypeDesigner+DisplayNameUpdater	Yes	No
System.Activities.Presentation.View.DesignerView	Yes	Yes
System.Activities.Presentation.View.IExpressionEditorService	Yes	No
System.Activities.Presentation.View.ViewStateService	Yes	Yes
System.Activities.Presentation.View.VirtualizedContainerService	Yes	Yes

Conclusion

This wraps up our series on the editing context. We’ve gone through the basics of why we need it, what we can do with it, and then we moved how to use it, from both the very simple to the very complex. We’ve finished with a diagnostic tool to help understand what all items I can bind to.

What’s Next From Here?

A few ideas for the readers who have read all of these:

Wire up a few attached properties to reflect back through to some interesting data (like if it is selected). These attached properties could then be used directly by your UI (via the binding in XAML) to let your designers display and react to changes in the data
Think about ideas for services you might want to add in VS without depending on an activity to inject it (and send me mail, I am trying to compile a list of interesting things)
Are there service/item implementations you want to override in VS?
Is there a service/item you expect to see that is not there?

Thanks for now!

WF4 Design Time AttachedPropertiesService and Attached Properties

mwinkle — Sun, 06 Dec 2009 04:51:01 GMT

I’ve been meaning to throw together some thoughts on attached properties and how they can be used within the designer. Basically, you can think about attached properties as injecting some additional “stuff” onto an instance that you can use elsewhere in your code.

Motivation

In the designer, we want to be able to have behavior and view tied to interesting aspects of the data. For instance, we would like to have a view updated when an item becomes selected. In WPF, we bind the style based on the “isSelectionProperty.” Now, our data model doesn’t have any idea of selection, it’s something we’d like the view level to “inject” that idea on any model item so that a subsequent view could take advantage of. You can kind of view Attached Properties as a nice syntactic sugar to not have to keep a bunch of lookup lists around. As things like WPF bind to the object very well, and not so much a lookup list, this ends up being an interesting model.

To be clear, you could write a number of value converters that take the item being bound, look up in a lookup list somewhere, and return the result that will be used. The problem we found is that we were doing this in a bunch of places, and we really wanted to have clean binding statements inside our WPF XAML, rather than hiding a bunch of logic in the converters.

How Does it Work

First, some types.

Name	Description
AttachedPropertiesService	Service in editing context for managing AttachedProperties
AttachedProperty	Base attached property type (abstract)
AttachedProperty<T>	Strongly typed attached property with interesting getter/setter programmability

in diagram form:

One thing that might look a little funny to some folks who have used attached properties in other contexts (WF3, WPF, XAML), is the “IsBrowsable ” property. The documentation is a little sparse right now, but what this will do is determine how discoverable the property is. If this is set to true, the attached property will show up in the Properties collection of the ModelItem to which the AP is attached. What this means is that it can show up in the Property grid, you can bind WPF statements directly to it, as if it were a real property of the object. Attached properties by themselves have no actual storage representation, so these exist as design time only constructs.

Getter/ Setter?

One other thing that you see on the AttachedProperty<T> is the Getter and Setter properties. These are of type Func<ModelItem,T> and Action<ModelItem,T> respectively. What these allow you to do is perform some type of computation whenever the get or set is called against the AttachedProperty. Why is this interesting? Well, let’s say that you’d like to have a computed value retrieved, such as “IsPrimarySelection” checking with the Selection context item to see if an item is selected. Or, customizing the setter to either store the value somewhere more durable, or updating a few different values. The other thing that happens is that since all of these updates go through the ModelItem tree, any changes will be propagated to other listeners throughout the designer.

Looking at Some Code

Here is a very small console based app that shows how you can program against the attached properties. An interesting exercise for the reader would be to take this data structure, put it in a WPF app and experiment with some of the data binding.

First, two types:

public class Dog
{
    public string Name { get; set; }
    public string Noise { get; set; }
    public int Age { get; set; }
   
}

public class Cat
{
    public string Name { get; set; }
    public string Noise { get; set; }
    public int Age { get; set; }
}

Ignore no common base type, that actually makes this a little more interesting, as we will see.

Now, let’s write some code. First, let’s initialize and EditingContext and ModelTreeManager.

   1:       static void Main(string[] args)

   2:          {

   3:              EditingContext ec = new EditingContext();

   4:              ModelTreeManager mtm = new ModelTreeManager(ec);

   5:              mtm.Load(new object[] { new Dog { Name = "Sasha", Noise = "Snort", Age = 5 },

   6:                                      new Cat { Name="higgs", Noise="boom", Age=1 } });

   7:              dynamic root = mtm.Root;

   8:              dynamic dog = root[0];

   9:              dynamic cat = root[1];

  10:              ModelItem dogMi = root[0] as ModelItem;

  11:              ModelItem catMi = root[1] as ModelItem;

Note, lines 7-9 will not work in Beta2 (preview of coming attractions). To get lines 10-11 working in beta2, cast root to ModelItemCollection and then use the indexers to extract the values

Now, let’s build an attached property, and we will assign it only to type “dog”

   1:  // Add an attached Property

   2:  AttachedProperty<bool> ap = new AttachedProperty<bool>

   3:  {

   4:      IsBrowsable = true,

   5:      Name = "IsAnInterestingDog",

   6:      Getter = (mi => mi.Properties["Name"].ComputedValue.ToString() == "Sasha"),

   7:      OwnerType = typeof(Dog)

   8:  };

   9:  ec.Services.Publish<AttachedPropertiesService>(new AttachedPropertiesService());

  10:  AttachedPropertiesService aps = ec.Services.GetService<AttachedPropertiesService>();

  11:  aps.AddProperty(ap);

12:

  13:  Console.WriteLine("---- Enumerate properties on dog (note new property)----");

  14:  dogMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

15:

  16:  Console.WriteLine("---- Enumerate properties on cat (note  no new property) ----");

  17:  catMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

Let’s break down what happened here.

Line2-8, create an AttachedProperty<bool>

We set IsBrowsable to true, we want to see it in the output
Name, that’s what it will be projected as
OwnerType, we only want this to apply to Dog’s, not Cat’s or Objects or whatever.
Finally, Getter, and look what we do here, we operate on the model item to do some computation and return a bool (in this case, we look to see if the name property equals “Sasha”

Line 9-11 create an AttachedPropertiesService and add it to the editing context.
Lines 13-17 output the properties, and let’s see what that looks like:

---- Enumerate properties on dog (note new property)----

 Property : Name

 Property : Noise

 Property : Age

 Property : IsAnInterestingDog

---- Enumerate properties on cat (note  no new property) ----

 Property : Name

 Property : Noise

 Property : Age

Ok, so that’s interesting, we’ve injected a new property, only on the dog type. If I got dogMI.Properties[“IsAnInterestingDog”], I would have a value that I could manipulate (albeit returned via the getter).

Let’s try something a little different:

   1:  AttachedProperty<bool> isYoungAnimal = new AttachedProperty<bool>

   2:  {

   3:      IsBrowsable = false,

   4:      Name = "IsYoungAnimal",

   5:      Getter = (mi => int.Parse(mi.Properties["Age"].ComputedValue.ToString()) < 2)

   6:  };

7:

   8:  aps.AddProperty(isYoungAnimal);

9:

  10:  // expect to not see isYoungAnimal show up

  11:  Console.WriteLine("---- Enumerate properties on dog  (note isYoungAnimal doesn't appear )----");

  12:  dogMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

  13:  Console.WriteLine("---- Enumerate properties on cat (note isYoungAnimal doesn't appear )----");

  14:  catMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

15:

  16:  Console.WriteLine("---- get attached property via GetValue ----");

  17:  Console.WriteLine("getting non browsable attached property on dog {0}", isYoungAnimal.GetValue(dogMi));

  18:  Console.WriteLine("getting non browsable attached property on cat {0}", isYoungAnimal.GetValue(catMi));

Let’s break this down:

Lines 1-6 create a new attached property

IsBrowsable is false
No OwnerType being set
The Getter does some computation to return true or false

Lines 10-14 write out the properties (as above)
Lines 17-18 extract the value with AttachedPropertyInstance.GetValue(ModelItem)

Let’s see the output there:

---- Enumerate properties on dog  (note isYoungAnimal doesn't appear )----

 Property : Name

 Property : Noise

 Property : Age

 Property : IsAnInterestingDog

---- Enumerate properties on cat (note isYoungAnimal doesn't appear )----

 Property : Name

 Property : Noise

 Property : Age

---- get attached property via GetValue ----

getting non browsable attached property on dog False

getting non browsable attached property on cat True

As we can see, we’ve now injected this behavior, and we can extract the value.

Let’s get a little more advanced and do something with the setter. Here, if isYoungAnimal is set to true, we will change the age (it’s a bit contrived, but shows the dataflow on simple objects, we’ll see in a minute a more interesting case).

   1:  // now, let's do something clever with the setter.

   2:  Console.WriteLine("---- let's use the setter to have some side effect ----");

   3:  isYoungAnimal.Setter = ((mi, val) => { if (val) { mi.Properties["Age"].SetValue(10); } });

   4:  isYoungAnimal.SetValue(cat, true);

   5:  Console.WriteLine("cat's age now {0}", cat.Age);

Pay attention to what the Setter does now. We create the method through which subsequent SetValue’s will be pushed. Here’s that output:

---- let's use the setter to have some side effect ----
cat's age now 10

Finally, let’s show an example of how this can really function as some nice sugar to eliminate the need for a lot of value converters in WPF by using this capability as a way to store the relationship somewhere (rather than just using at a nice proxy to change a value):

   1:  // now, let's have a browesable one with a setter.

   2:  // this plus dynamics are a mini "macro language" against the model items

3:

   4:  List<Object> FavoriteAnimals = new List<object>();

5:

   6:  // we maintain state in FavoriteAnimals, and use the getter/setter func

   7:  // in order to query or edit that collection.  Thus changes to an "instance"

   8:  // are tracked elsewhere.

   9:  AttachedProperty<bool> isFavoriteAnimal = new AttachedProperty<bool>

  10:  {

  11:      IsBrowsable = false,

  12:      Name = "IsFavoriteAnimal",

  13:      Getter = (mi => FavoriteAnimals.Contains(mi)),

  14:      Setter = ((mi, val) =>

  15:          {

  16:              if (val)

  17:                  FavoriteAnimals.Add(mi);

  18:              else

  19:              {

  20:                  FavoriteAnimals.Remove(mi);

  21:              }

  22:          })

  23:  };

24:

25:

  26:  aps.AddProperty(isFavoriteAnimal);

27:

  28:  dog.IsFavoriteAnimal = true;

  29:  // remove that cat that isn't there

  30:  cat.IsFavoriteAnimal = false;

  31:  cat.IsFavoriteAnimal = true;

  32:  cat.IsFavoriteAnimal = false;

33:

  34:  Console.WriteLine("Who are my favorite animal?");

  35:  FavoriteAnimals.ForEach(o => Console.WriteLine((o as ModelItem).Properties["Name"].ComputedValue.ToString()));

Little bit of code, let’s break it down one last time:

Line 14 – Create a setter that acts upon the FavoriteAnimals collection to either add or remove the element
Line 28-32 – do a few different sets on this attached property

NOTE: you can’t do that in beta2 as the dynamic support hasn’t been turned on. Rather you would have to do isFavoriteAnimal.SetValue(dogMi, true).

Line 35 then prints the output to the console, and as expected we only see the dog there:

-- Who are my favorite animals?
Sasha

I will attach the whole code file at the bottom of this post, but this shows you how you can use the following:

Attached properties to create “computed values” on top of existing types
Attached properties to inject a new (and discoverable) property entry on top of the designer data model (in the form of a new property)
Using the Setter capability to both propagate real changes to the type, providing a nice way to give a cleaner interface, as well as use it as a mechanism to store data about the object outside of the object, but in a way that gives me access to it such that it seems like the object.

This is some really nice syntactic sugar that we sprinkle on top of things

What do I do now?

Hopefully this post gave you some ideas about how the attached property mechanisms work within the WF4 designer. These give you a nice way to complement the data model and create nice bindable targets that your WPF Views can layer right on top of.

A few ideas for these things:

Use the Setters to clean up a “messy” activity API into a single property type that you then build a custom editor for in the property grid.
Use the Getters (and the integration into the ModelProperty collection) in order to create computational properties that are used for displaying interesting information on the designer surface.
Figure out how to bridge the gap to take advantage of the XAML attached property storage mechanism, especially if you author runtime types that look for attached properties at runtime.
Use these, with a combination of custom activity designers to extract and display interesting runtime data from a tracking store

Full Code Posting

using System;
using System.Activities.Presentation;
using System.Activities.Presentation.Model;
using System.Collections.Generic;
using System.Linq;

namespace AttachedPropertiesBlogPosting
{
    class Program
    {
        static void Main(string[] args)
        {
            EditingContext ec = new EditingContext();
            ModelTreeManager mtm = new ModelTreeManager(ec);
            mtm.Load(new object[] { new Dog { Name = "Sasha", Noise = "Snort", Age = 5 },
                                    new Cat { Name="higgs", Noise="boom", Age=1 } });
            dynamic root = mtm.Root;
            dynamic dog = root[0];
            dynamic cat = root[1];
            ModelItem dogMi = root[0] as ModelItem;
            ModelItem catMi = root[1] as ModelItem;
          
            // Add an attached Property
            AttachedProperty<bool> ap = new AttachedProperty<bool>
            {
                IsBrowsable = true,
                Name = "IsAnInterestingDog",
                Getter = (mi => mi.Properties["Name"].ComputedValue.ToString() == "Sasha"),
                OwnerType = typeof(Dog)
            };
            ec.Services.Publish<AttachedPropertiesService>(new AttachedPropertiesService());
            AttachedPropertiesService aps = ec.Services.GetService<AttachedPropertiesService>();
            aps.AddProperty(ap);

            Console.WriteLine("---- Enumerate properties on dog (note new property)----");
            dogMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

            Console.WriteLine("---- Enumerate properties on cat (note  no new property) ----");
            catMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));


            
            AttachedProperty<bool> isYoungAnimal = new AttachedProperty<bool>
            {
                IsBrowsable = false,
                Name = "IsYoungAnimal",
                Getter = (mi => int.Parse(mi.Properties["Age"].ComputedValue.ToString()) < 2)
            };

            aps.AddProperty(isYoungAnimal);

            // expect to not see isYoungAnimal show up
            Console.WriteLine("---- Enumerate properties on dog  (note isYoungAnimal doesn't appear )----");
            dogMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));
            Console.WriteLine("---- Enumerate properties on cat (note isYoungAnimal doesn't appear )----");
            catMi.Properties.ToList().ForEach(mp => Console.WriteLine(" Property : {0}", mp.Name));

            Console.WriteLine("---- get attached property via GetValue ----");
            Console.WriteLine("getting non browsable attached property on dog {0}", isYoungAnimal.GetValue(dogMi));
            Console.WriteLine("getting non browsable attached property on cat {0}", isYoungAnimal.GetValue(catMi));
            
            
            // now, let's do something clever with the setter. 
            Console.WriteLine("---- let's use the setter to have some side effect ----");
            isYoungAnimal.Setter = ((mi, val) => { if (val) { mi.Properties["Age"].SetValue(10); } });
            isYoungAnimal.SetValue(cat, true);
            Console.WriteLine("cat's age now {0}", cat.Age);

            // now, let's have a browesable one with a setter.
            // this plus dynamics are a mini "macro language" against the model items

            List<Object> FavoriteAnimals = new List<object>();

            // we maintain state in FavoriteAnimals, and use the getter/setter func
            // in order to query or edit that collection.  Thus changes to an "instance"
            // are tracked elsewhere.
            AttachedProperty<bool> isFavoriteAnimal = new AttachedProperty<bool>
            {
                IsBrowsable = false,
                Name = "IsFavoriteAnimal",
                Getter = (mi => FavoriteAnimals.Contains(mi)),
                Setter = ((mi, val) => 
                    {
                        if (val)
                            FavoriteAnimals.Add(mi);
                        else
                        {
                            FavoriteAnimals.Remove(mi);
                        }
                    })
            };
            aps.AddProperty(isFavoriteAnimal);
            dog.IsFavoriteAnimal = true;
            // remove that cat that isn't there
            cat.IsFavoriteAnimal = false;
            cat.IsFavoriteAnimal = true;
            cat.IsFavoriteAnimal = false;
            Console.WriteLine("Who are my favorite animals?");
            FavoriteAnimals.ForEach(o => Console.WriteLine((o as ModelItem).Properties["Name"].ComputedValue.ToString()));
            Console.ReadLine();
        }
    }

    public class Dog
    {
        public string Name { get; set; }
        public string Noise { get; set; }
        public int Age { get; set; }
    }

    public class Cat
    {
        public string Name { get; set; }
        public string Noise { get; set; }
        public int Age { get; set; }
    }
}

WF4 ViewStateService

mwinkle — Sun, 06 Dec 2009 01:33:20 GMT

A comment posted by Notre asked for some more details about view state and attached property services, so I thought I would dive into those next. I will follow-up in a subsequent post on the AttachedPropertyService, as there is a little bit more going on there.

Motivation

Why do I care about viewstate? Well, usually it is because we want to write something down and store it for later that is not required for runtime. A common example of viewstate is the position of nodes within a flowchart. While not required to execute the flowchart, they are required to effectively view the flowchart.

Where to write them down?

This was a question that caused a fair amount of debate on the team. There are basically two places to write down things like view state in a file-based world.

In the source document itself
In a document that stays close to the source (usually referred to as a sidecar file)

We had customers asking for both. The motivation for the first is that for things like flowchart, where I may always care about the visualization representation, I want to keep that metadata around and only deal with one element. For the second, it is motivated by the reason that we want a clean source document that only describes the minimal artifact to run. Now, there are certainly many stops along the spectrum (for instance, we might always want to keep annotations or source comments in the source document, and put positioning elsewhere). For VS2010, we landed with a unified API to use, and we write in the source document. This is something that is likely to change in future releases, as it does make things like textual diffs rather painful.

So, that’s why we want to use it.

How do we use it?

We are going to create a simple activity designer that lets me write down a comment.

A few simple steps:

Create a new VS Project, let’s create an Activity Library
Add a Designer to that activity library
Add an attribute to the activity pointing to the designer
Add a new WorkflowConsoleApp Project
Build

Now, let’s go and make our activity designer a little interesting.

Let’s add a text box and a button. We’ll make the text of the button something obvious like “commit comment” The XAML for the activity designer looks like this:

<sap:ActivityDesigner x:Class="simpleActivity.CommentingDesigner"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:sap="clr-namespace:System.Activities.Presentation;assembly=System.Activities.Presentation"
    xmlns:sapv="clr-namespace:System.Activities.Presentation.View;assembly=System.Activities.Presentation">
  <Grid>
        <StackPanel Name="stackPanel1" VerticalAlignment="Top" >
            <TextBox  Name="commentBlock"   />
            <Button Content="Load View State" Name="loadViewState" Click="loadViewState_Click" />
            <Button Content="Commit View State"  Name="button1" Click="button1_Click" />
        </StackPanel>
    </Grid>
</sap:ActivityDesigner>

Now, let’s add some code to the button (and to the initialization of the form)

ViewStateService has a few useful methods on it. I want to call out a subtle difference. You will see StoreViewState and StoreViewStateWithUndo. The primary distinction as the name implies is that one will simply write the view state down and will bypass the undo/redo stack. This is for view state like an expanded/collapsed view. You don’t really want ctl-z to simply flip expanded versus collapsed for you. But for something like flowchart, where changing some of the viewstate, like position, might be such a thing that you want support for undoing the action. That’s the primary difference.

So, our code for the button looks like this:

private void button1_Click(object sender, RoutedEventArgs e)
{
    ViewStateService vss = this.Context.Services.GetService<ViewStateService>();
    vss.StoreViewStateWithUndo(this.ModelItem, "comment", commentBlock.Text);
}

Now, on load, we want to be able to populate the value, so we will use the RetrieveViewState method in order to extract this.

private void loadViewState_Click(object sender, RoutedEventArgs e)
{
    ViewStateService vss = this.Context.Services.GetService<ViewStateService>();
    commentBlock.Text = vss.RetrieveViewState(this.ModelItem, "comment") as string;
}

Now, let’s go back to our workflow project and put an instance of this activity on the surface:

Let’s add some viewstate information and commit it. Now let’s look at the XAML:

<s4:NotRealInterestingActivity Text="{x:Null}" sap:VirtualizedContainerService.HintSize="200,99">
  <sap:WorkflowViewStateService.ViewState>
    <scg3:Dictionary x:TypeArguments="x:String, x:Object">
      <x:String x:Key="comment">basic comment</x:String>
    </scg3:Dictionary>
  </sap:WorkflowViewStateService.ViewState>
</s4:NotRealInterestingActivity>

Ok, now, to show that we can pull this in, let’s change the text in the xaml and then reload our designer.

You can muck around with ctl-z to see that this does get handled correctly via the undo.

The other important thing to note is that this takes an object, so your viewstate is not limited to strings, you can have more full featured objects if you’d like. Finally, the ViewStateService also has a ViewStateChanged you can subscribe to in order to handle, dispatch, and react to view state changes in the designer.

Types, Metatypes and Bears, Redux

mwinkle — Fri, 23 Oct 2009 16:16:29 GMT

I made a quick post a few months back where I tried to talk about the way the designer works and lets us design types, as well as simply configure instances of types.

There were a couple of key points that I wanted to make there in that post:

The workflow designer can configure instances of activity graphs, and create entire types as well
Types are designed by editing an instance of a type that represents the type being designed, the metatype
There is some XAML trickery required to serialize and deserialize this
This same type of work is done to enable the DynamicActivity capability

A few folks have noticed (and sent me mail), that things look a little different in Beta2. While we are going to have a more thorough, “here’s everything that changed” doc, I want to go ahead and update at least some of the things that I’ve been talking about here.

What’s New

In reality, very little is new, we’ve primarily moved stuff around now. One thing that you may remember is that the DesignTimeXamlReader was not public in beta1, and if you are looking around, you may not find it. We have made this functionality public however. Thus, see the “what’s changed" bit.

What’s Changed

We took a long look at things and realized we had a bunch of XAML stuff all over the place. We felt it would be a good idea to try to consolidate that into one place in WF, so System.Activities.XamlIntegration.ActivityXamlServices becomes your one stop shop for most things Activity and XAML related. Let’s take a quick look and see what’s in there:

ActivityXamlServices Members

[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]

Creates an instance of an activity tree described in XAML.

The ActivityXamlServices type exposes the following members.

Methods

Name

Description

CreateBuilderReader

Overloaded. Maps an x:Class activity tree to an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>).

CreateBuilderWriter

Maps an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>) from the specified writer to an x:Class activity tree.

CreateReader

Overloaded. Maps an x:Class activity tree to an DynamicActivity or DynamicActivity<(Of <(TResult>)>).

Load

Overloaded. Creates an instance of a declarative workflow.

Top

Load is used to generally take some XAML and return an Activity which you can then use to execute. If Load encounters a XAML stream for <Activity x:Class, it will subsequently generate a DynamicActivity. This functions basically the same way WorkflowXamlServices.Load() did in beta1.

You also see CreateBuilderReader, and CreateBuilderWriter, which are used to surface the DesignTimeXaml capabilities that we used in beta1. These will return an instance of a XamlReader/Writer that handles the transformation between the metatype and the <Activity x:Class XAML. The metatype has changed names from ActivitySchemaType to ActivityBuilder.

The table below should help summarize the uses and changes between beta1 and beta2. In this area, I don’t expect any changes between what you see now, and what you will see in RTM.

Task	Beta1	Beta2
metatype (type to build types)	ActivitySchemaType	ActivityBuilder
Mechanism to load DynamicActivity	WorkflowXamlServices.Load()	ActivityXamlServices.Load()
Mechanism to load ActivityBuilder	use WorkflowDesigner.Load() to get an ActivitySchemaType	Use the reader from CreateBuilderReader() to pass into XamlServices.Load()
Mechanism to save ActivityBuilder to XAML	Create a new DesignTimeXamlWriter, pass that to XamlServices.Save()	Use the writer returned from CreateBuilderWriter() to pass into XamlServices.Save()

To explore this, use CreateBuilderReader() and XamlServices.Load() on a workflow that you’ve built in the designer and poke around a bit to see what’s going on.

Here is some sample code that walks through this:

   1:  ActivityBuilder ab1 = new ActivityBuilder();

   2:  ab1.Name = "helloWorld.Foo";

   3:  ab1.Properties.Add(new DynamicActivityProperty { Name = "input1", Type = typeof(InArgument<string>) });

   4:  ab1.Properties.Add(new DynamicActivityProperty { Name = "input2", Type = typeof(InArgument<string>) });

   5:  ab1.Properties.Add(new DynamicActivityProperty { Name = "output", Type = typeof(OutArgument<string>) });

   6:  ab1.Implementation = new Sequence

   7:  {

   8:      Activities =

   9:      {

  10:          new WriteLine { Text = "Getting Started " },

  11:          new Delay { Duration = TimeSpan.FromSeconds(4) },

  12:          new WriteLine { Text = new VisualBasicValue<string> { ExpressionText= "input1 + input2" }},

  13:          new Assign<string> { To = new VisualBasicReference<string> { ExpressionText = "output" },

  14:                       Value = new VisualBasicValue<string> {ExpressionText= "input1 + input2 + \"that's it folks\"" } }

  15:      }

16:

  17:  };

  18:  StringBuilder sb = new StringBuilder();

  19:  StringWriter tw = new StringWriter(sb);

  20:  XamlWriter xw = ActivityXamlServices.CreateBuilderWriter(

  21:      new XamlXmlWriter(tw, new XamlSchemaContext()));

  22:  XamlServices.Save(xw , ab1);

  23:  string serializedAB = sb.ToString();

24:

  25:  DynamicActivity da2 = ActivityXamlServices.Load(new StringReader(serializedAB)) as DynamicActivity;

  26:  var result = WorkflowInvoker.Invoke(da2, new Dictionary<string,object> { {"input1","hello"}, {"input2", "world" }});

  27:  Console.WriteLine("result text is {0}", result["output"]);

28:

29:

  30:  ActivityBuilder ab = XamlServices.Load(

  31:      ActivityXamlServices.CreateBuilderReader(

  32:          new XamlXmlReader(new StringReader(serializedAB)))) as ActivityBuilder;

33:

  34:  Console.WriteLine("there are {0} arguments in the activity builder", ab.Properties.Count);

  35:  Console.WriteLine("Press enter to exit");

  36:  Console.ReadLine();

Good luck, and happy metatyping!

You say XAML, I say XOML, PoTAYto, PoTAHto, let's call the whole thing off

mwinkle — Wed, 30 Jan 2008 21:00:29 GMT

With all due respect to George and Ira Gershwin, I have a quick question for the readers of this blog. In V1, we have an interesting scenario is talked about frequently, and that's the file extension of our xml form of workflow.

When we debuted at PDC05, there existed an XML representation of the workflow which conformed to a schema that the WF team had built, and it was called XOML. Realizing that WPF was doing the same thing to serialize objects nicely to XML, we moved to that (XAML), but the file extensions had been cast in stone due to VS project setups. So, we had XAML contained in a XOML file.

Is this a problem for you? I could see three possible solutions in the future <insert usual disclaimer, just gathering feedback>:

XOML -- we have a legacy now, let's not change it
XAML -- it's XAML, so change the file extension to match it (and introduce an overload to the XAML extension, which for now is associated with WPF)
something else, say .WFXAML -- this reflects the purpose, is unique to declarative workflows and doesn't have any weird connotations (What does xoml stand for???).

Is this an issue? Is this something you would like to see changed? Do any of these solutions sound like a good idea, bad idea, etc?

Thanks, we appreciate your feedback :-)

mwinkle.SetState("newRole")

mwinkle — Thu, 29 Nov 2007 21:46:46 GMT

I'm moving on from my role as the technical evangelist for WF, but not too far. I've joined the product team, working as a program manager (PM) for the Connected Tools team. The job of the connected tools team is to provide all of the tools for the technologies inside the Oslo effort, including the WF designer. As such, I'll be focused on the programming model for activity designers to use when they create WF activities.

Oslo is interesting, as it represents the first real chance to look at the stuff we did in V1 of WF and think about it and find out ways we can improve on the experience. .NET 3.5 was a very "constrained" release for the WF team, as we had only shipped about 12 months prior, so we were primarily concerned with adding functionality to what we shipped (the WF/WCF integration, for instance). For WF, Oslo will be our first chance to take in a lot of the feedback we have heard (and keep it coming) to move things to the next level. I'm excited to be part of that effort, especially from the designer side of things, as I see a great opportunity to simplify a number of things that a lot of our customers have been doing.

It was a tough decision to leave DPE (developer and platform evangelism). The job of a TE is probably one of the closest to geek nirvana one can achieve. It was a bit odd when I was looking into this new position to lead off by saying, "I'm leaving the best job I've had." I didn't do it because anything was wrong with the role, on the contrary, it is a perfect fit for anyone who is deeply passionate about technology and wants to drive that passion and excitement out to the rest of the world while working with an entire team of people focused on that goal. My new role offered a really unique opportunity to have a large influence on the way people see WF (literally). I'm also a bit crazy about making sure the tools are right, because that is going to be the bit of the technology most people will see first, and the way many people will interact with the product. Finally, when I look at the things I want to accomplish at Microsoft, shipping a product is a big item on that list.

As we're not talking publicly yet about a lot of the stuff we are doing in Oslo, I probably won't be blogging about it (that tends to be frowned upon for obvious reasons). I'll still be posting about WF, and as always, am interested in your feedback (and will probably use the blog to solicit some as well).

	Name	Description
	CreateBuilderReader	Overloaded. Maps an x:Class activity tree to an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>).
	CreateBuilderWriter	Maps an ActivityBuilder or ActivityBuilder<(Of <(TResult>)>) from the specified writer to an x:Class activity tree.
	CreateReader	Overloaded. Maps an x:Class activity tree to an DynamicActivity or DynamicActivity<(Of <(TResult>)>).
	Load	Overloaded. Creates an instance of a declarative workflow.