Weblog Home Page

Yesterday I blogged about using and creating behaviors in Silverlight. This post will walk you through an autocomplete behavior that will hopefully furher crystallize the behavior concept.

To recap, a behavior is simply an object that can be declaratively attached to another component to extend the built in functionality of that component. Typically a behavior will encapsulate some event handling logic. This event handling logic could have been written by the app developer in their code-behind, but moving it into a behavior makes it much more encapsulated and suited for reuse. It has the nice side-effect of making things a bit more designer-friendly by cleaning up the code-behind and turning things into a more XAML-friendly form.

Remember Google Suggest? That kicked off a spree of auto-complete implementations for use in Ajax apps including the one we did for ASP.NET Ajax (and later in the Ajax Control Toolkit). The AutoComplete behavior is very similar. It can be used to suggest various completions based on the text that a user has entered so far. This behavior allows extending the standard Silverlight TextBox control (as well as the WatermarkTextBox control). This post will cover various scenarios accomodated by the behavior I've put together.

The screenshot above illustrates the type of experience you can add to any TextBox. You can see and play with a live demo by scrolling toward the end of this post (this requires Silverlight 2). Of course, all of the code is available as well, so you can include this into your own app.

Scenario 1: Basic completion scenario
Lets assume I've got a TextBox on a form that allows your user to enter in the name of a city, and I also have a service on the server that accepts a string prefix and returns a set of matching city names as an array of strings (serialized using the JSON format). I'd like to hook the two of them together to improve the user experience of the form, by offering a list of suggestions.

Here's the most basic use of the AutoComplete behavior in XAML as a way to get started.

<TextBox x:Name="cityTextBox">
  <f:Form.AutoComplete>
    <f:AutoComplete ServiceUri="/App_Services/Cities.ashx" />
  </f:Form.AutoComplete>
</TextBox>

Done... no code required! The AutoComplete instance assigned to the Form.AutoComplete attached property listens the TextBox events and in the background fetches city suggestions, displays a dropdown list with the cities, and allows the user to pick one. The AutoComplete does all sorts of fancy things by default like not fire off a web request per keystroke, cache results etc. As you can see the declarative XAML-based usage model makes the scenario quite simple to implement.

[... continued here]

In the past, I've written about behaviors and control extenders in the context of Ajax and HTML-based UI. This post introduces a similar behavior semantics for Silverlight and XAML-based UI as well.

The mini-behavior framework I have prototyped allows you to write and use behavior as a combination of a component + an attached property. The framework provides the logic to attach/detach behaviors for behavior authors. The rest of this post demonstrates using and writing a simple behavior based on this framework. Over the next few posts, I'll discuss a few more behaviors as a way to further experiment and demonstrate the behavior concept.

Using the DefaultCommit Behavior
Lets say you're implementing a typical form with a TextBox and a search Button. You'll probably want to allow users to press the Enter key after typing in some search keywords to kick off the search rather than force them to click the button explicitly. What you'd normally do is write a couple of event handlers to handle both the Click event from the Button and the KeyDown event from the TextBox (to look for the Enter key) in your code-behind, and trigger the search logic from each of them. This is more complicated and messy than it needs to be.

Ideally you simply want to handle a single event - the button's Click event. In fact, in HTML forms, this is built in into the notion of a Form with a submit button. However, it isn't so in Silverlight, where a Form concept is baked in. This is where this behavior comes in. Once this behavior is available, I can author the following XAML:

<TextBox x:Name="searchTextBox">
  <f:Form.Commit>
    <f:DefaultCommit ButtonName="searchButton" />
  </f:Form.Commit>
</TextBox>
<f:Button x:Name="searchButton" Content="Search"
  Click="OnSearchButtonClick" />

[... continued here]

Live Mesh is finally public - it was announced earlier today at the Web 2.0 conference. We’ve had the social graph buzzword bantered around for some time in the context of Facebook. Will mesh become the next one to go around? Check out the intro post. Live Mesh is all about software + services, and connecting and bringing devices together into your own personal "mesh" enabling them to work in a connected way.

Ray Ozzie alluded to the Web as the Hub of the social mesh and the device mesh earlier at MIX08. Over on the Live Mesh blog, Mike Zintel alludes to a bunch of concepts around the Live Mesh platform, such as mesh object, and a data synchronization platform. I am particularly excited about the prospect of seeing a new generation of Web apps that leverage the platform in all sorts of interesting ways, not just for local storage, but also synchronized local storage of application data and personal data, and offline execution, as a means to differentiate and cater to new user experiences on the Web. The APIs that emerge around this platform will be something to keep an eye on.

On another personal note, I am super excited to see and run the Web version of Live Mesh, which simulates a Vista desktop and Explorer folders right within your Web browser for anywhere access to your devices and a data. While it will be interesting to see the user reactions around this UI metaphor in the browser as shown in the screenshot, the Ajax code behind the scenes is pretty much written in Script# (I've worked with the team for a while), and now that the site is public, I’ve added it to the new showcase page on my project site.

This is a quick post on the latest release of Script# (Build 0.5). I'll be following up with subsequent posts with more details on some of the specific feature additions, but here is a list of whats new (besides bug fixes, and improved compiler error reporting):

• Support for localization based on .resx files - now you can generate localized script files while using strongly typed resources using .resx tooling available in Visual Studio and other localization tools.
• Support for generating script doc-comments - now XML doc-comments are automatically transformed into ASP.NET Ajax-style doc-comments, which are useful for driving intellisense in Visual Studio, if you're creating script libraries that will be used by others.
• Updated compat layer to abstract browser differences now works for not just Mozilla but also WebKit-based (Safari, iPhone), and Opera browsers.
• Support for creating overloaded APIs, and creating and invoking functions dynamically (these were limitations in the past).
• Support for creating Silverlight 2 plugin instances.

Also, Script# is now on CodePlex (actually it has been on there for a month or so, but this is the first release since). The forums associated with the CodePlex project should significantly improve the experience around sending feedback, and having discussions around the technology and using it. Several folks have asked me in the past about open sourcing it. My plan is to eventually have the source out there as the project approaches its v1 status, starting the with the core framework and runtime, and subsequently the compiler itself. Stay tuned on that front for more in the next few months.

There are a couple of related CodePlex projects to call out:

• Messenger Developer Samples - contains MIX08 Messenger samples including how you can use Messenger APIs using Script#
• Script# proxy generator - Think wsdl.exe for Script#. A number of you have sent me mail about this feature. This project basically takes care of generating C# proxies for ASP.NET Ajax-enabled Web services.

Finally, I've updated my project site as well with more introduction to Script#, release notes, and a high-level roadmap. I will also be transitioning the documentation that is currently available in pdf form to the site over time.

Just over a month ago, at MIX08, I presented a talk on Real-World Ajax. One of the demos I included was an Ajax templating technique to demonstrate separation of presentation and content from behavior to help manage script complexity, and to help facilitate designer/developer workflow.

The demo was based on early thoughts around what we need to do in this area. What is presented here is still quite simplistic in terms of the range of options it provides to developers. The demo worked well with the audience, and I'd love to hear any feedback people have in this area that can be fed into the design process at this early stage (I alluded to this work in comments to my Ajax vs. Silverlight post).

Here is my scenario - in my Ajax app, script issues a web request to fetch a list of data, in this case a list of bookmarks, and constructs HTML to visualize the results. This is often implemented as follows:

<div id="bookmarkList"></div>
<script type="text/javascript">
function fetchBookmarks() { 
    // Issue an XMLHTTP request to retrieve user's bookmarks.
}
function onBookmarksAvailable(bookmarks) {
    // Update display using retrieved bookmarks. Each boomark has Url and Title properties.
    var sb = new Sys.StringBuilder();
    sb.append("<ul>");
    for (var i = 0; i < bookmarks.length; i++) {
        sb.append("<li>");
        sb.append("<a href=\"");
        sb.append(bookmarks[i].Url);
        sb.append("\">");
        sb.append(bookmarks[i].Title);
        sb.append("</li>");
    }
    sb.append("</ul>");
    $get('bookmarkList').innerHTML = sb.toString();
}
</script>

This works. However, there is a problem. The definition of the UI is now embedded in script. Its hard to design and change it. And its hard to preview it without running the page. The problem is worse if the structure of each item is more complicated than what the sample tries to do.

Here is where templating comes into the picture. Templates have been super common in server-side frameworks like ASP.NET, and are now popping up in client-side script frameworks, as Ajax apps start becoming more client-centric. With templating the developer or designer can define the structure of an item in regular markup, and the templating engine is then responsible for generating the script equivalent.

[... continued here]

I get the Silverlight vs. Ajax question all the time, whether it is at a conference, over email, or over on discussion forums. In the interest of seeding a broader discussion, and hearing what other people think, I thought this would be an interesting blog post, along with the side benefit of having a ready-made answer the next time the topic comes up.

There have been a number of blog posts pitching Ajax vs. RIA (whether its Flash or Silverlight) such as this one here. Personally, I think Ajax and Silverlight complement each other, and the "vs." is a bit misplaced. Furthermore, the way I see it, there is a continuum, with a number of sweet spots representing specific classes of applications. This perspective is perhaps directly reflected in the makeup of the UIFX team that I work on at Microsoft - the team is spread across ASP.NET, Ajax, Silverlight and RIA frameworks all at once actively working on cool stuff in each of these areas (i.e. lots to look forward to).

[... continued here]

While developing Facebook.NET, it was on the back of my mind to create a script library equivalent in script# for client-side only interaction with the Facebook REST API using the existing JSONP interface to their REST service. I didn't do it yet for security reasons, as it would require sending down both the application key and secret to the client (something that existing Flash and Silverlight examples unfortunately and incorrectly show). Instead I opt'd for creating a Facebook Proxy service that allows your client code to talk to facebook via your service in an almost transparent manner. Those of you who have downloaded Facebook.NET can see a sample of this.

Now Facebook is offering a client-side SDK. Wei Zhu blogged about the JavaScript Client Library for the Facebook API on the official developer blog last Friday. If you're a Facebook application developer, you'll want to check this out.

Wei Zhu has been a long-time supporter of Script#, and it makes me super excited to see that the library itself was coded in Script#, and also uses the Script# runtime as part of its implementation. I am sure Script# usage resulted in some substantial productivity gains, and makes me hopeful that this will spike some more interest in the technology. Its also exciting to see the potential for a number of Facebook apps built on top of this. I am hopeful that Facebook will eventually release the .dll version of the script, so other downstream users of Script# will be able to directly reference these APIs in their C# code, without having to create a stub metadata dll

I also chatted with Wei during the weekend about possible security implications. It looks like they've thought through the implications. Specifically, you only need to publish the API key (which is public anyway), and the client library connects with Facebook to generate a temporary user-session scoped secret using some new services, so you don't have to publish your actual secret. Nice!

A couple of days back I blogged about some first impressions while skimming through the HTML 5 spec, and I made a note about its length, which partly stems for a whole slew of new tags such as <dialog>, <figure> etc.

I can certainly see them being useful in creating a somewhat featured vocabulary for creating semantic markup. Here is the example from the draft spec:

<dialog>
  <dt>Costello
  <dd>Look, you gotta first baseman?
  <dt>Abbott
  <dd>Certainly.
  ...
</dialog>

Ignoring the problem about this being invalid xml (Strange! Why doesn't the HTML 5 require valid XML?), I think there are a couple of issues I see with this approach overall.

First this introduces a new tag, which isn't going to be available in all browsers any time soon. So I wonder whether if developers are likely to use the new tag, or will they just continue to use the <dl> tag or other appropriate existing tags.

Second, as it stands, it doesn't really address a meaningful conversation scenario where it might be useful to identify the participants, time stamps etc. There are numerous examples of conversations in a general sense across the web - every blog post's comment stream is a conversation of sorts. Facebook's Wall-To-Wall feature is a conversation. A saved chat transcript is a conversation. The <dialog> tag doesn't really capture the common pieces of information that are typically represented in all these conversations.

Finally, the number of interesting semantics is huge; the number of possible tags is small... so you fundamentally need a way to define semantics and layer them on basic tags, at some point or the other.

During the holidays, I was reading about microformats to understand a bit more about the concepts and patterns at play. So immediately when I saw the <dialog> tag, I began wondering, isn't any value in describing the semantics of a conversation, already achievable today using some sort of microformats-based approach? My own definition of microformats is basically a set of patterns using existing HTML tags to convey semantic data and metadata embedded in your page content. The microformats.org site describes them as a set of simple, open data formats built upon existing and widely adopted standards. See that page for more about what they are and aren't, as well as other related content.

There isn't an hConversation or hDialog type of microformat agreed upon right now. But here is a rough sketch of how you might use microformats approach to get not only a working visualization supported by all browsers today, but at the same time, embed additional semantics. To clarify, this isn't some approved conversation microformat, but me being creative and mocking one up while writing this post. Who knows... something might even come out of this. :-)

[... continued here]

I was reading through the HTML 5 draft (actually glancing … since it goes on and on). If you're looking for a summary, I think the HTML 5 Differences draft is more useful. As I read through the list and the TOC, I had a few different reactions.

There are definitely some bits of goodness in it, albeit a few years delayed, and those additions will realistically only become available and dependable still more years down the road. Its great to see the <input> tag finally grow up to support common semantic data types such as date, time, url, email etc. It is also good to see HTML incorporate media scenarios by adding the <video> and <audio> elements as part of the tag soup. Other useful additions that I think will go a long way are better and standard support for application scenarios such as managing navigation history, local storage, drag/drop, drawing and content editing. There is definitely lots of possibility, esp. when combined with the latest CSS capabilities.

The spec is long! And I wonder if it should even be called the HTML 5 spec. It looks like it wants to be an end-all spec for the browser platform, and even speaks to socket connections and peer-to-peer connections. However, at the same time it doesn't speak to other foundational UI and presentation features such as animation, or data-binding. Instead it adds a whole bunch of new tags like <dialog> which to me seem less critical at this point in time (I'll blog about this some more ... see here).

The spec doesn't seem speak to extensibility either. To me this is a key feature, and personally near-and-dear, having worked on the platforms side of software for so long. Back in May of '06, I listed my wish list for the browser platform... and one of the bigger items on my list was getting DOM fundamentals right. Specifically, I would have loved to see the HTML 5 spec address extensibility of the tag set and rationalize things like HTC behaviors and XBL bindings. We now have built in media tags, but what if I want a <slideshow> tag? It simply doesn't address encapsulation of behavior, composition, layout extensibility, and ability to define new object models.

Its over-encompassing nature, especially beyond HTML in a strict sense, also makes me wonder if there shouldn't be a much more trimmed down HTML 5 Core spec. I'd love to see something that has a chance of being realistically and fully implemented in the foreseeable future.

In the meantime, it looks like browser plugins such as Silverlight will continue to be an important part of the RIA platform, by bringing not only consistency in APIs and capabilities across browsers, but also by nailing some of the fundamentals.

What are your thoughts? Or your rants? :-)

Over the weekend I released the next version of Facebook.NET over on the CodePlex project site.

If you've built a Facebook application using my framework, you'll definitely want to check out this build. Facebook has deprecated the setFBML API as it currently exists (read about this on the developer blog), and I can't think of any application that isn't affected by this. To summarize the old signature, now marked obsolete, was effectively:

    SetFbml(string userID, string fbmlMarkup)

and the new signature has the FBML markup broken out into separate parameters:

    SetFbml(string userID, string profileMarkup, string actionsMarkup);
    SetFbml(string userID, string profileMarkup, string actionsMarkup, string mobileMarkup)

This actually makes constructing the FBML a bit more cleaner, as it keeps the different logical bits of markup separate. Facebook.NET has contained support for the new updated SetFbml API for a while now, but its now packaged as part of the 0.3 release. The old API goes out of service on the 17th, at which point I'll update the framework to completely remove the obsoleted API as well.

I love the fact that Facebook is able to announce changes to the API or mark things as deprecated when they need to, give some time to developers to allow them to catch up, and then actually go ahead and flip the switch to actually make the change. Relating this to the .NET Framework APIs and personal experience with the process, its certainly a luxury when if you can afford to do that. It certainly speaks to something about the dynamic nature of the Web, and the need for developers creating mashups or using services to keep up!

There are several other changes including several bug fixes that have been packaged up into this release, that you can read about on the project's page. These were also available in source code form during the past month.

• The big one is support for creating applications for Facebook Pages. Facebook introduced the Page/Fan-of concept sometime back, which allow the page creator to add applications. Facebook.NET supports these applications. As an aside, there is a page for ASP.NET if you're on Facebook, and you'd like to declare yourself as a fan :-)
• Various other APIs are now covered. These include detecting application permissions, storing application preferences, etc.
• I've added a sample that demonstrates using Facebook.NET for creating desktop applications to complement the samples for the regular FBML/IFrame application styles.

I'll be creating a show case of applications using Facebook.NET soon. I know of a few, but if you'd like to submit your application to show up on the list, feel free to list it down here in the comments.

Just a quick heads up - I posted the latest release of script# - version 0.4.5.0... you can check it out and download it from my projects site.

This build introduces support for installing project and file templates into VS 2008. However, it continues to works with VS 2005 and .NET 2.0. It also has a number of fixes, esp. in the minimization logic that is used to compact release builds. Finally it introduces one small compiler-driven optimizations: constant inlining - so if you've got consts, they're inlined at compile time in release builds. There are many more optimizations a compiler can do - this is just a start. For a full list of changes, you can see the associated readme documentation.

Its always fun talking to folks using the technology building real solutions.

Recently, I chatted with the guys at Coveo who have built a Sharepoint plugin to do media search, and present the results using Silverlight 1.0 - they implemented their media player and client experience (shown in the image on the left) in script#. You can follow the link to see a live demo.

Martin, if you're reading this, you should find this build useful - it has a number of fixes for things you encountered, along with fixes for various issues reported by others on the script# bug list.

At MIX07 earlier this year, I demonstrated a basic slide show control for one of my Silverlight talks (I tend to squeeze in at least one demo around the photos scenario... invariably).

The folks at Vertigo Software have recently put together a pretty full-featured interactive slide show control, with some cool transition effects, called Slide.Show, built on script and Silverlight 1.0. They have also created a project on CodePlex to keep it open and going forward, and also serve as a good example of some of the things you can do with Silverlight today.

I gave the control a whirl with a sampling of some of my photos. It is pretty straightforward to set up, and still offers a high degree of customization capabilities. I just had to tweak a few settings... just for heart's content. For the rest of my photos, head over to my photo gallery.

I have already started developing a small wish list for some features as I played with it, that I'd like to see added, but wish it was implemented in c# and converted to script using script# - I'd be much more inclined to tinker around if it was.

Theres a lot of exciting and new technology to check out with the ASP.NET 3.5 Extensions released just yesterday... MVC, Silverlight controls, more Ajax stuff, dynamic data controls, Astoria, and lots of interesting blog posts and samples to check out.

If you're looking for a quick break, or some Monday humor, check out this short video on YouTube titled "Here Comes Another Bubble"... a totally hilarious take on the web 2.0 craze, the blogging craze, the social networking craze and other fun takes at the world today.

Update, 12/11: Looks like the video was taken down and is no longer available - it was funny while it lasted. Oh well...
Update, 12/18: The video is back... links restored. I think the video should have been titled as Here Comes Another Bubble 2.0 (not 1.1) :-)

I had an email exchange with a couple of folks about fixing the form's action attribute as rendered by asp.net that gets in the way of URL rewriting, by rendering out an action attribute pointing to the rewritten URL rather than the prettier original URL as shown on the browser's address bar when the page is initially browsed. I've brought this up for fixing in the past. I know, it is unfortunate that it is still not fixed. I am going to try again, and maybe it'll happen in the next SP... fingers crossed.

In the mean time I thought I'd post my solution here as well. I know various techniques have been blogged about before. I have seen various approaches that I don't quite like personally. For instance I've seen solutions based on control adapters and derived HtmlTextWriter implementations (these suffer from perf overhead of using control adapters, or from having to inspect every attribute rendered out). I have also seen some solutions involving response filtering, and that gets pretty expensive as well.

The solution I use on my own site is a derived form control that renders out a bit of script to essentially rewrite the form's action attribute back to the original URL on the client. Here is my implementation, which also adds support for partial rendering scenarios enabled through the use of ScriptManager, if you're using ASP.NET Ajax:

public class Form : HtmlForm {
    private const string FormActionScript =
@"document.getElementById('{0}').action = window.location.href;
";

    private const string AjaxFormActionScript =
@"Sys.WebForms.PageRequestManager.getInstance().add_endRequest(function() {{
  document.getElementById('{0}').action = window.location.href;
}});
";

    protected override void OnPreRender(EventArgs e) {
        base.OnPreRender(e);

        StringBuilder sb = new StringBuilder();
        sb.AppendFormat(FormActionScript, ClientID);

        ScriptManager scriptManager = ScriptManager.GetCurrent(Page);
        if ((scriptManager != null) && scriptManager.SupportsPartialRendering) {
            sb.AppendFormat(AjaxFormActionScript, ClientID);
        }

        Page.ClientScript.RegisterStartupScript(typeof(Form), String.Empty,
                                                sb.ToString(),
                                                /* addScriptTags */ true);
    }
}

The issue generally cited with this approach is that every page has to be touched, which is pretty painful, and every new page has to use a non-standard <form> tag. Additionally, I would have to implement a custom designer to associate with my derived form control to allow natural editing its contents on the design surface. However, there is a simple solution to both of these issues: I can use the tag mapping feature in ASP.NET to map all occurrences of the HtmlForm control with my derived Form control. Thereafter, as the parser encounters any existing <form> tag, it automatically uses my derived type instead without requiring the developer to make the change explicitly. This makes the approach less intrusive, and quite a bit more natural. All code that accessed the control still thinks its a Form tag.

Specifically, I just need to add this entry in web.config:

<system.web>
  <pages>
    <tagMapping>
      <add tagType="System.Web.UI.HtmlControls.HtmlForm"
           mappedTagType="Site.Form"/>
    </tagMapping>
</pages>

The tag mapping functionality is a mechanism to instruct the parser to subtitute a different derived type implementation whenever it encounters the type being mapped. It was originally invented as part of the WebPart framework so as to allow the ASP.NET WebPartManager to be mapped to the derived Sharepoint WebPartManager implementation without having to change individual pages. However, it is quite powerful and generally applicable.

Tag mapping is one of the esoteric features that comes in handy every once in a while. :-)