Weblog Home Page

A long while back, I wrote an Ajax InPlaceEdit behavior that you could attach to input controls to enable in-place editing experiences in HTML. I was thinking of doing the same in Silverlight using the behavior framework in Silverlight.FX that I used to demonstrate adding auto-complete, text filtering and other functionality to a regular TextBox control.

Here is a scenario - an image with a title (ala Flickr). The title needs to be editable, but it would be suboptimal to show it as a TextBox (since it is not changed frequently). It is also suboptimal to go into a different page or different mode to edit it as that is one step too many. This is where the in-place edit comes into use. An example of this style of ux is in the screenshot below.

In HTML, an in-place edit textbox is simulated using a label in addition to the original input control, and hacking a bit to correctly overlay them and toggling visibility via script event handlers. One of the key strengths and capabilities of the Silverlight presentation framework and XAML is the fact that you can restyle and redefine the visual structure of any control including the intrinsic controls, such as the out-of-the-box TextBox, in a declarative (yet reusable) manner. So I was wondering how far I could get using just styling and templating, which goes far beyond CSS, as a first step without creating a behavior programmatically. Turns out you can actually go quite a ways.

If you haven't played with control styles and templates, the visual state manager feature or Expression Blend yet, I'd recommend reading this tutorial on the general flow for customizing Silverlight controls. I'll walk through the couple of edits I had to make to the default TextBox template to enable in-place editing in the remainder of the post.

I started by dropping a TextBox control onto the design surface in Blend. This is the XAML I am starting with.

<TextBox Text="Turtle" />

Earlier today, Live Search released a simple REST and JSON-based API for performing search with full flexibility for developers in terms of how to use the results (code named "Silk Road"). The previous API happened to be SOAP-based. Cool (and finally)! Check out the general documentation and the JSON example.

In brief, you issue a request to http://api.search.live.net/json.aspx?AppId={appID}&Market=en-US&Query={query_words}&Sources=web, and you get back a JSON structure as the response that looks like the following:

{
  "SearchResponse": {
    ...
    "Web": {
      "Total": 100,
      "Offset": 0,
      "Results": [
        {
          "Title": "...",
          "Description": "...",
          "Url": "...",
          "DisplayUrl": "...",
          "DateTime": "...",
          "Rank": ...
        }
      ]
    }
  }
}

My immediate thought was would my recent experimentation with REST via dynamic C# programming and turning dynamic method invokation into HTTP requests just work? In fact, can I use this new Live Search API without building a strongly typed wrapper? It turns out the answers are yes - the dynamic RestClient just worked. Here is my snippet of C# code:

I blogged about effects and transitions for Silverlight in the past - the first time on declaratively attaching some simple effect behaviors and the second time on using effect-enabled higher-level controls. I got comments asking more details on how this part of the Silverlight.FX works, especially how these features can be used programmatically and how such controls can be built, and I think this topic warrants a post all by itself (you can tell, I love this topic). I put this together some while back, but then PDC-related topics and vacation kept this from being published. Anyway, here it is...

You can download the code for entire Silverlight.FX framework and associated samples so you can play with it and use it in your own applications. The rest of the post describes the nuts and bolts of using and extending the effects and animation features.

Attaching Effects Declaratively
I'll start with the most basic scenario as a refresher so everyone is on the same page.

<Rectangle x:Name="redRect" Fill="Red" Opacity="0.5">
  <fxui:Interaction.Behaviors>
    <fxui:HoverEffect>
      <fxeffects:Fade FadeOpacity="1" />
    </fxui:HoverEffect>
  </fxui:Interaction.Behaviors>
</Rectangle>

In my last post, I blogged about the upcoming C# 4.0 dynamic feature and using it to work with JSON data in a more natural late-bound manner. I also alluded to where I was heading with the idea - issuing calls to REST services through a dynamic interface.

Specifically, I was thinking of being able to have a dynamic object represent a proxy to a REST service, and having its encapsulated late-binding behavior turn method calls into actual HTTP requests, serializing parameters into URL query string parameters, and finally processing responses (JSON or XML) into a dynamic object for the caller to poke into and extract interesting pieces of data. This post builds on the previous one, so be sure to check that out.

Also, do check out the comments. There was a lot of interesting commentary about how c# and dynamic don't mix together. It is an interesting debate no doubt, and I thought I should summarize my perspective. I personally tend to think dynamic is just another tool, and when used appropriately it is quite nice. Often times there is a small bit of code where late-binding would help, and its nice to be able to do so in c#, without switching to another dynamic language and losing all static typing in the process, or having to split your code artificially. Instead I envision using and encapsulating late-binding code within an object, and then using that object itself in a strongly-typed, compile-time-bound manner in the rest of the app.

Back to REST services... it is interesting to look at an example, such as Flickr.

Looking at its API documentation page, you can see Flickr offers around 100 or so APIs. Every single API has numerous permutations of parameters (just look at search for example). It would be an fairly big and non-trivial task to create a full-featured toolkit, and keep it up to date as the service evolves. More often than not an app just wants a handful of APIs. What if there was a generic and dynamic REST proxy that could out-of-the-box support typical REST services. That would at least facilitate quick and dirty prototyping even if you do decide later to turn just the APIs you care about into a strongly typed REST client library for the actual implementation. The same pattern repeats itself with other services such as Amazon, Facebook and so on.

Once I had this generic REST client coded up, I could write the following code to work against Flickr:

C# 4.0 features a new dynamic keyword that allows you to mix in a bit of late-bound code in the midst of your otherwise statically typed code. This helps cleanup the string-based programming mess that is a characteristic of late-bound code. In fact, there are a number of scenarios that would benefit from dynamic typing in my opinion in addition to interop with other dynamic code (such as Silverlight talking to the DOM or a .NET app talking to Office automation APIs). For example:

• Accessing JSON data
• Accessing XML nodes and attributes
• Experimenting and calling into with REST services without an explicitly coded up proxy
• Access to settings (eg. Isolated storage settings in Silverlight, or configuration settings such as appSettings)
• ... and more

Traditional dynamic languages are striving to introduce some degree of static typing (eg. type information in ActionScript 3, and the unfortunately failed EcmaScript 4 attempt) for perf and more appeal. On the flip side, C# is evolving nicely by introducing dynamic typing through a static type called dynamic (nice oxymoron) and offering not just a nicer syntax, but a much more intuitive model for these scenarios. I can only wish the C# 4.0 was here now!

Anyway, I am still excited about this feature, and given the VS 2010 and C# 4.0 CTP are available, I decided to play with a few of the above listed scenarios. In this post, I'll describe the JSON scenario, and in a subsequent post, I'll write about the REST services scenario, so stay tuned and come back for more.

Yesterday's PDC keynote featured a number of interesting products and technologies, such as Office 14 and Live Services, that today involve fairly large-scale (code size, team size and project length) Ajax development. The demos were just amazing - Kudos to the product teams!

Behind the scenes, on the engineering front, Script# provided the toolset and script authoring model. I've been working with both teams for quite a while now, and am really excited to be able to finally share these particular uses now that they are public (since to be honest, I was myself quite pleasantly surprised to see the model of compiling down to script scale up in this manner).

Live Mesh features an online desktop experience within the browser to enable remotely accessing files from any browser. The Live Framework exposes the underlying platform to .NET applications and script applications alike. The script framework portion of the SDK, like the UI, is based on Script#. The documentation for this framework on msdn was built from doc-comments in the originating c# code, which double up to enable script intellisense in Visual Studio.

Next in the keynote was a quick peek at what is to come in a web-ified Office 14. Some of the highlights included Excel, OneNote, and the Ribbon interface. These apps bring document sharing and collaboration to a whole new level. What is really cool is the live editing and continual sync'ing with the actual good-old, full-fidelity Office document file on the server or with another concurrent editing session in the full-blown desktop Office suite. These apps build on top of the ASP.NET Ajax framework, and were for the most part coded in c# and converted to javascript using script#.

The devs clearly recognized the value from using standard .NET tools and C# for engineering the thousands of lines of script and Ajax code that power these great consumer and developer experiences.

The PDC announcements keep flowing. Today's keynote was full of them - with the first Windows 7 preview, Live Services announcements and Live Mesh updates, a peek at Office 14 and even hints at whats to come in the Silverlight space. The one I want to share some thoughts on is the Live Framework one.

The true developer platform underlying the Live Mesh that enables file sync and sharing across devices was finally unweiled in full form and there were a couple of demos on how both client apps (a WPF photo app) and Web apps (such as the BBC iPlayer) can use sync and data sharing to offer users new functionality including offline experiences. I personally think sync (not just between the client and the server, but in a peer-to-peer fashion across devices) is the interesting space for next-generation Web applications to differentiate on, especially as raw offline storage and eventually offline execution itself get commoditized by client runtimes and browsers alike. It is great to see the Live Framework enabling these capabilities while taking care of the underlying plumbing and operations. I alluded to these forthcoming APIs in my post on Live Mesh when it was first introduced. Now they’re here...

There is an interesting Live Framework diagram detailing various aspects of what happens behind the scenes.

Oh, and I can't wait to get the new version of Live Mesh as well, with Mac support later this week. I've gotten into the habit of using it to share files as well as remote into all my machines.

Windows Azure took center stage at PDC this morning during the keynote (watch here). The cloud computing space is now really heating up with competing platform plays from Google’s AppEngine and Amazon’s recent EC2 announcements. In some sense this is perhaps the re-birth of Windows as a platform that enables developers and the ecosystem to build on a whole new set of capabilities and scale for the Software+Services world, in much the same way as Windows fueled the desktop software industry in the past "era".

The really compelling thing about this particular development platform especially combined with other technologies such as Mesh, SQL and Silverlight is that you’re likely already familiar with it - if you’ve been developing ASP.NET and .NET applications using Visual Studio, either on the desktop or your own servers or hosted servers, you’re already got a good head start in working against this new platform. Earlier in the year I blogged about the .NET spanning across different presentation tiers and ASP.NET as a common back-end. This much anticipated announcement essentially adds a new dimension - Windows and .NET as the common platform that really scales.

I am eagerly anxious to build both apps and frameworks that leverage the new possibilities. Make sure you sign up today for getting your invitation code to start experimenting with Azure Services as well.

Also, anyone notice the cool new branding and blue hues in the next generation of logos? Azure itself is a cool bluish color… I wonder if there is a connection there? :-)

A general on-going discussion in software development is around features, complexity and simplicity. During the past couple of weeks, I've been part of more than the usual number of discussions ... my inbox seems to be filled with long mail threads about what features should be added and what should not be. And then there are some comparisons between some "competing" shipped technologies. I won't name names here. :-)

One of my colleagues shared a Dilbert strip on this subject and I thought I'd post it here for some weekend humor.

You can find this strip and some others on feature creep in Another Day in Cubicle Paradise.

I wish there was full text search for the entire collection of Dilbert strips ... the closest I've come to is Google's Book Search.

Earlier this week, the much anticipated Silverlight 2 was finally released! Personally speaking, it's a day that's been coming for a while - ever since my days prototyping the Core CLR engine running in the browser some two+ years ago now... and already, we're busy building the next layer of frameworks beyond the foundation provided by the CLR and the graphics/media engine and basic controls. Wow!

I'm working on one such effort of building an application framework on top of Silverlight these days at work, which as usual for any v1 product takes time. Over the past few weeks, I've also been working on updating Silverlight.FX to work against the final SL2 build, as well as adding a bunch of new goodies into the framework.

The area I want to talk about in this post is using and writing Silverlight controls that are effects and transitions enabled. This picks up from my last Silverlight.FX post that demonstrated procedural animations and declarative effects and transitions. The first iteration of this framework allowed an app developer to add some richer user interaction by associating effects and transitions to basic events such as clicks, hovers, focus etc. This post takes that one step further - higher level controls that intrinsically support such effects and transitions.

I have three controls to share in the context of two sample applications (screenshots below - click to run). The first application is Flickr Tiles - a basic Flickr browser (yes, I gotta have a photos sample), and the second is a simple Task List sample (yes, I've used the Task List scenario in a number of contexts in the past - what can I say - it's a nice simple scenario).

Static screen shots don't do justice to animations - so I'd encourage running the samples to get an idea of the application experiences I am talking about enabling via controls before reading on. You'll need to make sure you've installed the final build of Silverlight 2 if you haven't already.

FxCop is a great tool to help ensure consistency of .NET code and to help push quality upstream in the development process by reinforcing design guidelines and flagging some potential issues that can be detected through static analysis of your assemblies. Last week, the FxCop team released v1.36 of the standalone tool.

The design guidelines are documented and explained in the Framework Design Guidelines book, which also has a section dedicated to FxCop. The interesting thing is a good chunk of the guidelines also apply to Ajax, as they're first and foremost targeted at the general task of creating usable APIs and frameworks. I'd highly recommend familiarizing yourself with them if you're writing .NET code.

This announcement spurred me into demonstrating the integration of this essential .NET tool into the Ajax development process. One of the key value propositions of Script# is enabling you to leverage existing .NET tooling in the context of building script-based applications and components. FxCop is a key scenario in that regard.

I just released v0.5.1.0 of script# which is a minor increment that includes a few bug fixes, the ability to define overloads and methods with optional parameters, and for those using Script# against the Microsoft Ajax library, the corresponding c# assembly has been updated to account for the addition of history APIs in .NET 3.5 SP1. Additionally, I've taken the chance to tweak the project templates and installer ever so slightly to allow you to much more easily use FxCop.

Here is a quick walkthrough, assuming you've installed this latest version of Script# and FxCop. I'll create a super-simple app for the purposes of demonstration that fetches a list of bookmarks via an XMLHttp request (it is Ajax after all) and display the results in an HTML list. Undoubtedly, you'll have a more interesting code-base for FxCop to analyze.

My recent Silverlight-related blog posts have shared a common theme: creating declarative views - whether it is declaratively attaching behaviors such as auto-complete, or declaratively hooking up views to their associated view models, or declaratively authoring themes and loading them. This post is the next installment in that overall series - declarative effects and transitions.

XAML and Silverlight provide some building blocks like storyboards and now visual state manager that enable some powerful mechanisms for adding visual pizzaz to your application's user interface. However, I sometimes find they are too general and low-level a solution, requiring one to go into custom template mode all too often, whether it is to define storyboards, or new states and transitions - more often than not, I just want a simple pre-packaged effect that I can attach to an element and associate with some user interaction. Furthermore, the current lack of event triggers requires code to be added to views to begin and stop those storyboards or switch from one visual state to another. Think powerpoint - the prepackaged animation effects with some basic triggers go a long way.

That sort of problem space, and approach inspired me to see what can be done in Silverlight today, resulting in the addition of a Glitz namespace in my Silverlight.FX work. (The name is no coincidence. For those that remember our Ajax framework's early days, back when it was called Atlas, I had written a Glitz script animation framework there, and then wrote one for Script# - this Silverlight work started its life when I recompiled my Script# code as actual managed code rather than into JavaScript!)

On the top is a set of screen-shots of a simple application that consumes some of these effects. You have to click it to run it live to actually see the effects! The application basically fetches the current weather and the forecast for the supplied zip code (and yes, it seems summer has decided to take a break here in the northwest). All the core logic is implemented in a view model that is decoupled from the view, and is easily tested. It is responsible for talking to the data layer, which is responsible for invoking a web service and unpacking the JSON data returned from the service. The view is completely declarative and is about 130 lines of XAML. It uses behaviors (for things like filtering zip code input to numbers), actions to hook into the view model, and of course effects and transitions for some subtle bits of glitz.

I'll share a couple of snippets of the XAML, just to get the general programming model across.

Yesterday, I received my copy of "Advanced ASP.NET Ajax Server Controls". I had a chance to get an early peek at the content when Adam and Joel asked me to write the foreword for their book.

One thing I liked about this book is that this is one of the few that dive deep into the framework, its architecture and extensibility, and address the power-user/developer scenarios.

If you're building applications in Ajax today, and want to take that to the next level, you'll want to look into the platform deeper beyond the out-of-the-box features i.e. its extensibility. You'll specifically want to build reusable components and controls, on both the server and on the client. Check out this book on more details like "the client script framework", "the script application object", "localization" and "the control toolkit" amongst many other relevant topics.

Silverlight provides the ability to completely customize the look and feel of controls (including the intrinsic ones - often something one desires when working with HTML), while preserving their behavior, through a combination of styles, templates, visual states and transitions. For example, the screen shot below (click to run), shows the stock look replaced with a sketch or napkin look and feel (based on Corrina's (our resident designer) rough skin sample).

The general approach to defining app-wide customizations in Silverlight today is to define a bunch of named styles in the Resources dictionary of the Application's XAML markup, and then reference them via the StaticResource markup extension elsewhere in the UI. However this approach has some shortcomings, that HTML designers have long overcome through the use of separate and multiple style sheets.

• Application.Resources become unwieldy. Styling just a few controls can quickly lead to 1000's of lines of XAML. Simply navigating and finding what you're looking for becomes a chore. The first thing I do when I pick up a theme created by a designer is try to separate out the set of individual styles per control.
• Styles get mixed up with functionality. To me (speaking from my developer mindset), Application.Resources is better suited for global data and other behavioral aspects of my application shared across the application, rather than serving as a container for visual and presentation items. Hence my desire for separating these out, so I can just import a designer's creation into my app.
• Styles are not easily swappable. This is also partly because styles are mixed up in an application's resources. If I want to switch from say a Flat look to a Sketch look in my app, I have to carefully swap things in and out, track dependencies between styles etc.
• Styles cannot be dynamically selected. I'd like to create an application that can dynamically pick a different font/color scheme, i.e. have the notion of themes, perhaps based on a user's profile. This requires some level style merging as well as the ability to include multiple themes separately in the xap package and pick one of them dynamically.

There are probably a few other issues that came up in my discussion with Corrina but suffice to say, these stem from placing styles statically in Application.Resources. Designers working on HTML have long overcome these issues through the use of separate and multiple style sheets that help separate content and behavior from presentation.

I started to think about how I might go about creating a more concrete theming system for Silverlight apps, and naturally I looked to CSS as well as what we had done with Themes in ASP.NET (the App_Themes folder pattern) to see how much I could re-use here, while still feeling natural in the context of Silverlight, and reasonably designable via Expression Blend. The end result was a very small theming feature addition to on-going Silverlight.FX framework.

In the rest of the post, I'll describe how to go about creating the themes above and consuming them in the application.