The recent Proof of Concept work we've been working on has mainly involved the use
of WPF/E as we
look towards MIX07. I thought I'd share a few thoughts and links from the experience.
Firstly, it's important to consider how WPF/E will
be used within a web site. This is really a matter of opinion, but I think that
if you consider some of the better uses of Flash, then this is when it isn't 'overcooked'.
I'm not a huge fan of 'all Flash' sites and a lot of that is to do with the unusual
user experience they can give. (This is fine for a showcase site for a design agency
perhaps, but not so useful for, for example, straightforward e-commerce, or even an
enterprise web presence).
So, IMHO, WPF/E is
best used for a specific piece of rich interactivity, which means that likely any
given experience will be a combination of ASP.NET (AJAX) and WPF/E.
It's an important planning point, because it's quite easy to slip into the mindset
that everything should be delivered in WPF/E (just because it can).
ASP.NET AJAX can provide a lot of benefit when
programming WPF/E.
Firstly, the ScriptManager and its automatic generation of web service proxies is
great for enabling rapid access to data for WPF/E. Taking a CodeSmith template
such as .NET
tiers and running it across a database to generate CRUD layers with web services
is a rapid way to enable this for WPF/E.
(In practice, we found that the template - which supported XML Serialization - couldn't
handle JSON Serialization, but this was fixed by adding the [ScriptIgnore] attribute
everywhere that there was a [XmlIgnore] attribute so a tweak to the template should
remedy this). I have a sneaking suspicion that the same issue was present with LLBLGenPro but
I didn't investigate much further.
Secondly, one needs a strategy for the JavaScript coding required to power the WPF/E XAML.
There's a problem here as JavaScript is not particularly well cared for in VS2005
(no intellisense, how will I manage!?), though I did consider that some code generation
might be useful to move this along. Nikhil Kothari's ScriptSharp effort
is a great example of a similar approach and if you're considering how to construct
OO JavaScript. This aside, the main point is that a sensible series of constructs
- base objects with parent/child relationships and other such utilities - will go
a long way to assisting development - and you must consider the use OO
JavaScript techniques. ASP.NET has a series of JavaScript
helpers and shortcuts that shouldn't be forgotten about here: it's easy to begin
reinventing the wheel. Outside of ASP.NET then of course Prototype would
have similar benefits). Beyond the technique and language enhancements, you need to
devise a method to connect the XAML and JavaScript consistently and correctly,
such as in this
framework from Nick Kramer.
With all of this considered and maybe tackled, then the coding is actually quite natural.
Access to XAML attributes is obvious, and given the available interactions then the
implementation of desired interactivity is typically logical. Combined with the proxies
generated by ScriptManager, you can be moving along at quite a pace.
So, the use of XAML can be leveraged from WPF (broadly) and designer experiences and
all of the existing JavaScript and ASP.NET skills of the development team can now
be applied to rich interaction on the web which is probably a boost for any development
team.
Subscribe