1. Oct. 25, 1978: First pet goldfish died. Realized living things die. Cried for weeks.
2. Dec. 25, 1980: Opened gift from "Santa" that I had seen in parent's closet. Realized Santa is a lie. 
3. July 16, 2007: Couldn't get this code to compile:

  ...realized that System.Windows.DependencyProperty and System.Workflow.ComponentModel.DependencyProperty are two entirely different classes. Only System.Windows.DependencyProperty, or more precisely System.Windows.PropertyMetadata supports the nifty CoerceValue callback.

I wonder why we have two separate families of DependencyProperty related stuff? Seems really weird and poorly thought out. Kind of "Hack"-ish.

What really hurts is that there doesn't seem to be a good way to coerce custom type dependency properties in WF-land. The answer is right there in WPF's PropertyMetadata, but we can't use it in WF.

The thing I was really trying to do was have a generic iterator-like activity that contained custom activities with custom type dependency properties. Like a ForEach activity that contained a custom Activity like "LoadPortfolio" with a Dependency Property called "Client" that was a custom type. The ForEach has a DataItem property it sets to the current item it is iterating in the context of each child, but because ForEach is general purpose, the type of DataItem is System.Object.

It would be easy to coerce DataItem to "Client" (just cast or use "as"!) but there doesn't seem to be a mechanism to do this in WF, and because of the type mismatch, my workflow can't even load.

So do I make a special ForEach for each type I want to iterate over? Do I change the Client property on my LoadPortfolio activity to type System.Object?

Hopefully I'll find a way to work around this that I can live with soon.

 

Miguel de Icaza made this statement on his blog. I wish he would elaborate. I have a few not very serious reservations about what little I know about Avalon at this point, but I am not seeing the simmilarity to j2ee. Is it just the complexity/surface area? If so, then I think the statment:

We will have to wait a couple of years for the "Rails" of GUI toolkits to come into existance. In the meantime programmers will pay for their sins.

is off by some years. Frameworks like rails are becoming commodity. Someone will have this out in no time. Just take the top off Monorail or add a new template for generating XAML views and some better tooling to the SCSF.

I would rather have rails for GUI apps than rails for web apps. Therefore Avalon on rails is a net gain to me, and others I'm sure.

I wish Miguel would elaborate a little.