John Gossman, architect of the WPF team (desktop and subset taht supplies UI
framework for Silverlight),
discusses
a few of the pain points developers and designers are facing today with WPF to
Silverlight portability. From his post:
The above example is a bit of a special case, and I don’t feel bad about
it at all. A much greater struggle that hits a very large number of users
is how we do Control templating. All of the APIs we use in
Silverlight’s Beta1 control templating model exist in desktop WPF, and yet
the templates are completely different. By subsetting the APIs we ended up
changing not just the best practices, but the essential model.
Let me be clear. If you write your own custom control in Silverlight,
using the Silverlight model, you can create a template for it and take your
custom control and its template and run them on desktop WPF. The problem
is, we do not provide Triggers in Silverlight and many of the properties
(IsMouseOver, IsPressed) that Triggers depend on to work. There are
technical reasons Triggers were hard to add in Silverlight 2 (though we will add
them in the future), but even greater was the test and development cost of
adding all the additional properties necessary to make them work. So, we
decided to make the controls have to “trigger” the state changes
themselves in code. All this code works on desktop WPF. But existing
controls, written for the desktop, don’t contain the code to
“trigger” the state changes, so the control templates don’t do
anything when applied (they create their children, but don’t react to
events).
The more I consider this … the less I care about portability specifically
between WPF and Silverlight. It’s unlikely that I’ll ever be able to use
or need to use code exactly as it was written for a desktop WPF application (yes,
there will be elements that are worth copying — but I believe that a full
installed application should work differently from an enhanced web page with
Silverlight). If I’m running a WPF app — I’m running a thick,
rich, installed application (or click-once). If I’m writing something for
Silverlight, I need to write code which lives within the confines of the browser.
Although similar, they’re still quite different on many levels.
That being said, I would like the models to be the same — if only because
I’ve really become fond of many of the WPF features and techniques for
building a user interface: triggers, triggers, and triggers. I can absolutely live
without 3D and even without a full .NET framework. But triggers really help separate
the UI from the code. I’ve done some investigation and I can’t see how I
could create a reasonable approximation of Triggers without a lot of work —
and even then it wouldn’t be compatible with WPF XAML. John said “when
we add triggers…” …, so it gives me a bit of hope (albeit with no
time tables…).
