A State of Flex

I remember when first seeing Flex, that it was the ultimate, best thing out there. With its advanced binding abilities, MXML, and those cool sleek visuals – what more can a dev ask?. Then came AIR, adobe was determined to rule RIA. And MS had no answer.

I myself researched alternatives, openlazlo, etc. There was only Winforms to compare to, but that was oranges and apples, really.

Then came Silverlight. This was actually the quiet before the storm, Silverlight had no builtin effects, no controls, and exposed raw interface and unknown idioms. People started comparing Silverlight vs Flex, and the general opinion was the Flex was much superior. I spent a day googling for such comparisons, and saw some conversations between an Adobe dev and Silverlight fans over the Silverlight forums.

But then the storm came. Microsoft rose up all guns machine guns, rockets, and turrets blazing, with the release of VS2008, .NET 3.0, 3.5 the VAST documentation, blogs saturated with information, and now even upcoming MVC.NET and framework source code(!).

Only with these all bits and pieces out there, everything starts falling into place. suddenly using Expression Blend feels “right” and making my own Silverlight controls is a second nature. Visual Studio is so great that it makes me want to leave it open 24/7, and WPF is so much fun I don’t want to do anything else!
Currently I guess Adobe is deep in developing the Flex 3 IDE, and from the Beta2 state of things, its hella buggy. So, I think it is inevitable to declare Flex as dead.

Attached Properties/Events

This is a new concept in WPF. However I find that the best selling book in WPF (WPF Unleashed) fails to explain the meaning properly. I will attempt to explain this, trying to rely on familiar concepts.

Firstly, you can take at this short but to the point post to get the motivation for using Attached Properties/Events.

If you’ve read the motivational part in the link above, you now know, that a Parent object needs to store information about his Children.

So the Parent attaches a property, a tag if you will, on each Child. Imagine it as you putting post-it notes on items before shipping them off. Coding rational: the information serves you and thats why you need to provide the facilities to store and manipulate it:

(From Rob’s example)

RobPanel.SetRotatationsPerMinute(b1, 30);

Rob’s Panel tracks information, or property, of the button b1. From the button’s b1 point it has an attached property.

This is a lot simpler than the XAML syntax, because it would rely on knowledge you already have. Attached Properties are probably a concept for something you coded before.

So Attached things conceptually are nothing but a Hash at the parent, where the key is the child object and the value is the information. Practically, it might be that the Child “inherits” the property from the Parent, what ever it may be, the concept remains the same.

The confusing part is that in XAML it only seems like it works the other way around. That is, metaphorically, every item puts the post-it note on himself:

(Directly from Rob’s example – see link above)

<my:RobPanel>

<Button Name=”b1″ my:RobPanel.RotationsPerMinute=”60″ />

<Button Name=”b2″ my:RobPanel.RotationsPerMinute=”3″ />

</my:RobPanel>

Hope I’ve cleared things up.