Over the past week I’ve been getting myself up to speed with
the latest emerging .Net technologies namely WPF, Silverlight and LINQ. By emerging I mean; they’ve all been around
for a while now in various forms, but I’ve only just got around to reading up
on each of them in any detail.
WPF – Windows Presentation Foundation (formerly known as
Avalon) is probably best described as the
WinForms replacement built entirely on .Net components. Much like other new Microsoft technologies of
late, this is not simply the introduction of some new features - this is a ground-up
re-write. As such there is much to
discuss, I’m just going to touch on some of the fundamentals.
Breaking the mould -
DirectX
If you create a WinForms application ultimately the core
controls and the rendering of them backs onto some pretty old Windows components;
User32.dll and GDI/GDI+ (this division dates back to the days of Windows
3.0). For the most part, if creating a
.Net WinForms application, you don’t know or care about either of these components
because .Net wraps them. But if you
wanted to break out of the standard Windows button and make it look a little
more interesting the core controls weren’t very extendable and you would very
quickly find yourself getting involved with drawing every element using a
lower-level model and handling all the events yourself. All the while the computers primary CPU would
be hard at work drawing everything.
A fair bit has changed in the last 15 years, not least the
introduction of extremely powerful graphics cards. WPF pushes the job of rendering the UI onto
the GPU via DirectX, where it can take advantage of the features a graphics
card brings to the table like onboard shaders and anti-aliasing. This makes delivering slick UI’s, such as
Vista, much easier to deliver. The
core components (buttons etc) have been re-written from the ground up in pure
.Net making them completely extendable and customisable in a way simply not
possible before.
The Glue - XAML
Whilst all this rendering guff is interesting cocktail party
talk, for your every day business developer it doesn’t amount to whole heap of
beans. The big change is the
introduction of XAML (eXtensible Application Markup Language). XAML is described as “a declarative XML-based
language created by Microsoft which is used to initialize structured values and
objects.” What does this mean? Well let’s take a look. (The XAML code below is all that’s needed to
render the Window below it.)
The first thing that may strike you if, like me, you’ve
spent a lot of time in the world of ASP.Net, is the mark-up looks pretty
familiar. And it should, both ASP.Net
and XHTML are also “XML based” languages.
As such XAML feels remarkably natural.
You may also note the lack of co-ordinates. Unlike WinForms, you’re strongly incentivised
away from using co-ordinates to layout your UI which can make catering for
different resolutions and window re-sizes tricky. Instead a flow layout is encouraged which if
you’re familiar with CSS and the use of DIV’s to layout your web-page will again
feel incredibly natural.
The similarities between Web and WPF don’t stop there. Styles in WPF allow you to abstract the
formatting of an applications elements to a separate resource file. You can create named styles or target
particular elements to add consistent padding to all buttons in your
application for example. If this sounds
a lot like CSS, well, that’s because it is.
There is no doubt that much of XAML/WPF has been inspired by
standards created in web development. When
ASP.Net first appeared on the scene it was often said to have brought the
WinFoms event driven model of development to the web world. It could be said that with WPF, the favour
has been returned by bringing the Web layout and the separation of design and implementation
to the Windows world.
One Pony – Many Tricks
Although XMAL and WPF are intrinsically linked, XMAL is a
common ingredient that once mastered can be used many times over in the world
of .Net. As the definition said; XAML “is
used to initialize structured values and objects” – so whilst in the case of
WPF it’s used to initialize UI objects, it can be used to initialize any kind
of object. If you look under the hood of
WF (Windows Workflow Foundation) or Silverlight (Microsoft’s answer to Flash)
guess what. You’ll find XAML describing
the show.
Further more XMAL will run directly in both IE and Firefox
(2.0+). Take a look at this Font Picker
example. (You’ll need the .Net 3.5
Framework installed).
http://blogs.msdn.com/text/attachment/592777.ashx
[Related blog post: http://blogs.msdn.com/text/archive/2006/06/20/592777.aspx]
If you view the source of main link above you’ll get pure XAML
- that’s the only code involved. Under
the hood the .Net CLR is parsing the XMAL and generating the UI hence you (the client)
need to have the framework installed. (Silverlight
overcomes this, but that’s a story for another day
All in all, I’m extremely impressed and pleasantly surprised
with WPF and XAML. I’m excited at the
deep XAML integration across the .Net platform and the possibilities that it opens
up. I’ll leave you with a geeky
observation...
If you’re an exciting, fly by the seat of your pants kinda
guy like me, you’ll find it interesting it to note the namespaces involved. Ya classic Windows Forms controls all appear
in the System.Windows.Forms namespace.
Whilst the new WPF controls all exist in System.Windows.Controls i.e.
these are the controls that Windows now
uses. It’s quite a statement.
Subscribe