Weblog Home Page

The WebMatrix announcement last week triggered a range of reactions on Twitter. It also brought back some personal memories.

A decade ago (wow), I started a little tool to simplify using and developing asp.net server controls as a side project, and it grew bigger and was eventually released using the name "WebMatrix". It was a fun project, and my first "serious" side project so to speak. There were a few interesting things we did there, both technical and non-technical. It is great seeing similar things happening in this generation of WebMatrix branded tooling. :-)

Vertical and Scenario-Focused Tooling

I personally think having a variety of tools is good, especially if they can focus on different verticals, and are optimized for different scenarios/tasks. There is a saying - use the right tool for the job. And the reality is there is a wide spectrum of developers and correspondingly a breadth of requirements and expectations. Lots of professional/enterprise developers will find Visual Studio and its rich set of features + ecosystem a must-have for their work. At the same time, there is a huge number of Web developers, designers and scripters that primarily use Notepad, Textmate or a simple text editor to quickly build and manage their web sites and applications. For those folks, the simplicity that comes from the minimal set of options is a feature in itself. WebMatrix caters to that huge audience. This is true today, and was true back then.

The ASP.NET pipeline allows HTTP modules to plug in into the request processing lifecycle and do work at various stages. For example, output caching, authentication, authorization etc. are all implemented as HTTP modules.

However one of the problems is that HTTP modules must be registered in configuration. This is a little painful for writing framework components where an HTTP module is essentially an implementation detail. You don't want every app developer using your framework to have to add in some configuration entries. What you want is the ability to programmatically add HTTP modules to the pipeline. This isn't available out-of-the-box today.

I faced this problem in my previous post around RIA Services, Authentication and Roles, as I needed to handle the PostAuthenticateRequest event. This seems to have come up before (for example here and here on stack overflow).

So in the interim, we can use the new, and somewhat obscure, ASP.NET 4.0 feature, the PreApplicationStartMethodAttribute, that lets you declare some code you want to run early in the initialization phase of your web application, even before any dynamic compilation happens and before any application startup code runs. Combine that capability with an HttpApplication that supports registering HTTP modules programmatically, as we're in business. I wrote DynamicHttpApplication that provides this API (link to code below):

public abstract class DynamicHttpApplication : HttpApplication {
    public static void RegisterModule(Func<HttpApplication, IHttpModule> moduleFactory);
}

When I posted my RIA Services and Authentication post earlier in the week (which I highly recommend checking out first if you haven't), the first comments/tweets I saw indicated people also want to see roles working in the application. So I decided to add this bit of functionality, both in the Book Club application and the supporting functionality in the RIAEssentials framework, so you can use it easily in your own applications as well.

From a scenario perspective, what I am going to do is require an Admin role to browse and add book club members.

Adding and Using Roles

The first step is to update the AuthenticationService implementation I showed earlier to add roles into the authentication process. It only requires quite literally a couple of minor tweaks, th. The added lines are shown in bold:

Authentication is the third in a series of posts covering the key concepts of RIA Services using the Book Club application to digger deeper and go beyond the basics. Links to the first two posts on validation and authorization as well as an overview of the application/source code are at the end of this post.

Authentication Overview

Like authorization, RIA Services provides a higher level programming model, and out-of-the-box, but extensible solution. Authentication answers the question:

"Do these credentials represent a valid user?"

Credentials might be user name and password, or any other piece of data that can be used to verify that the user is who he/she says they are. Generally, a side-effect of authentication is to produce a representation of the user, usually represented as an IPrincipal, as well as establishing an authenticated session for the client to use in making subsequent requests.

RIA Service defines an authentication service as a domain service that implements IAuthetication<TUser> where TUser is application's notion of a user that brings together identity, roles and settings that span across client and server.

RIA Services also provides an out-of-box implementation based on the standard asp.net membership, roles and profile infrastructure services. If you use the business application template, this is all setup for you by default. However RIA Services also lets you implement your own authentication service when you want to use your own custom credential store, or a different authentication mechanism such as OpenID.

This post covers using authentication and the User object on client and server, as well as building a custom forms authentication service that works against the application's data model.

Using Authentication on the Client

I created an inplace-LoginControl with a number of visual states (Unauthenticated, CredentialInput, Authenticating and Authenticated) as shown here.

Authentication functionality is accessed through a class called WebContext on the client. WebContext represents the functionality provided by the home web server to the client application. This is how WebContext is initialized in the application:

This post digs deeper into the Book Club application from the perspective of the authorization feature of RIA Services. You can check out more information about the application via its associated table of contents post.

The post covers how the out-of-box authorization rules can be applied, how custom rules that can be implemented, how custom rules can use additional bits of information in their implementation, and how client-side UI can be customized to account for authorization.

The sample application has been updated, so you might want to download the latest release of the code from the RIA Services Essentials project on CodePlex or browse the checkin history.

Authorization and validation share a lot of common concepts and patterns, so the deep dive into validation with RIA Services might be particularly interesting.

Authorization Overview

Authorization allows you to secure operations and data in your application based on the authenticated user. It essentially answers the question:

"Can X do Y [with Z]?"

where X is the user (the subject), Y is the operation (the verb), and optionally, Z is the entity being operated upon (the object). In RIA Services, each authorization rule encapsulates a specific question that you can associate your services and its operations with. These rules help create a more complete picture of the domain or application semantics that are being encapsulated within a domain service. Rules are associated with operations as metadata attributes that derive from AuthorizationAttribute.

Earlier this week, I published the RIA Services Essentials project on CodePlex to share some sample code. The first sample included is an updated version of the Book Club application.

This application has become sort of a reference application. It was written to demonstrate some aspects of writing a semi-real-worldish application (note that it is still very much a demo app), but more importantly, demonstrating how you can use RIA Services effectively by going beyond the basics. As such, it isn't meant to be a HelloWorld app, which I agree would be useful. This post is a sort of guide for what is in the sample.

Here is a list of what the application demonstrates:

• Entity framework data model with one-to-many and many-to-many relationships as well as use of stored procedures
• Local data model augmented/mixed with a web service-based data model (in this case Amazon).
• CRUD and more (queries, insert, update, delete, as well as named update methods, and invoke methods)
• Use of convention and configuration for identifying CRUD operations
• Validation (field level, entity level, operation level, change-set scoped, server-only validation, async validation)
• Custom authentication (i.e. using your DAL/user table, rather than asp.net membership)
• Authorization (including custom authorization rules)
• Using authentication service and your User object in server code
• Usage of DomainServiceFactory
• Exposing reference data
• Presentation model for defining custom (non-DAL) types for use between client and server
• Shared code between client and server for validation rules
• Query limits, and caching
• Using RIA Services with MVVM on the client
• Adding computed properties on Entities on the client along with propagation of change notifications
• "More" style paging (as seen for example on twitter.com)
• Display of pending changes, validation errors
• Reference data used to fill lookup dropdown lists.

This is a brief post to share a CodePlex project I have set up, called RIA Services Essentials. It will host various samples and extensions I've shared out in the past on the blog and at various presentations.

The initial sample I've published is my Book Club app, as a reference application of sorts. I wrote the application at MIX10, and since then it has appeared in various other presentations. The bits I published include some bug fixes, updated login UI and other new features. I'll be publishing a second post detailing what is demonstrated in this application.

Other planned samples I'll be adding over time include my Fluent metadata extension, and LocalDomainClient for unit testing as well as some some samples from MIX09 that are still relevant (such as offline storage) as I get a chance to refresh these things so they run against the RIA Services v1 bits.

Check out the project and stay tuned for updates over time. What else would you like to see the samples cover?

"Those Who Ship, Win!"

This used to be written on a giant poster in the hallways of building 42 (original home of the .net framework) ... should have taken a picture of it while it used to be around. (missed classic photo opportunity - anyone have a shot of it?)

Today, we delivered one of the most important features, shipping a v1. Yes, WCF RIA Services v1 is done, and shipped! You can get the final build along with the final build of Silverlight 4 tools, right here on the RIA Services landing page, that also has links to blogs, tweets, docs, forums and all things RIA Services.

It has been an exciting ride building this technology from the ground-up, seeing people use it live even with early preview builds, and providing tons of feedback (thanks), and bringing credibility to Silverlight as a line of business application platform. It has also been an interesting learning experience for me personally in many dimensions.

The diagram below captures the essense - what can a framework do by redfining a Rich Internet Application as a single logical application that spans across client and server, and consumes as well as provides data and services. My original Vision to Architecture blog post still holds up a year or so later. I'll be doing a follow-up to that post, as well as updating my Book Club reference app with a couple of new features, so stay tuned.

Just a quick blog post on a couple of things related to Script#...

I've been working on a number of things for the upcoming release (v0.6) of Script#, and hope to have it publicly available soon. Most of the core work is complete, but I do need to do a massive update to documentation/how-to/tutorial/readme content. Some of the highlights of this release will be:

• jQuery support - ability to write code against jQuery core, and to write basic plugins. This release will contain just some initial support, as I look at more increasing ways to build on the foundation provided by jQuery.
• Unit testing support - ability to use VS2010 test projects along with QUnit (unit test framework used in jQuery)
• Other features - some of the key ones are support for a script loader, VS2010 support, support for latest ASP.NET Ajax APIs.

Secondly, I will be doing a presentation including some demos of this upcoming functionality. The format of the presentation is somewhat open-ended, so hopefully there will be some time for Q&A. This is tomorrow (May 5th, 11am PDT), for the LIDNUG folks (Linked.NET user group on LinkedIn). More information is on the event page if you're interested in joining.

Finally, Script# is on twitter (@scriptsharp), as am I (@nikhilk). Please follow to keep up on more frequent announcements/updates.

Earlier today, my SilverlightTV recording on RIA Services and Validation went online. I used validation as a feature area to focus on this first recording on RIA Services, because I think it illustrates both the RIA Services value proposition and key elements of the vision around the project in a very direct manner. Specifically:

• Focus on end-to-end solutions for data scenarios. It is not sufficient to just address querying data or submitting some changes, but about providing the infrastructure for managing data, editing with validation, tracking errors raised on client and/or server, rolling back changes, and more.
• The server project and client project are logical halves of the same application. It would be great to preserve and propagate developer intent, and semantics from the database to the middle tier to the client, and share code across tiers where possible. In other words leverage intent and rules as close to the end-user, while enforcing them at each tier. Automatically.
• Provide out-of-box solutions to common scenarios. The Entity class on the client provides a pretty complete implementation of working with data on the client. It provides identity management, change tracking, change notification, transacted editing and rollback capabilities, as well as tracking and surfacing validation and concurrency conflict errors. In particular, in the context of this post, Entity provides an implementation of infrastructure interfaces such as INotifyDataErrorInfo introduced in Silverlight 4, so you don't have to roll your own.

In my demo for SilverlightTV, I used a product catalog and product editing scenario (my favorite scenario if you ask folks on the team). However for MIX10, I used a Book Club scenario, which I think is quite a bit more interesting (with the potential to become my new favorite scenario).

Check out the video. And then come back to read further. My MIX10 summary post lists everything else going on in the Book Club sample (along with a link to all of the sample code), but the rest of the post focuses on the validation aspects.

Update 3/26/10: For those looking for a copy of the app demo'd on the SilverlightTV show, you can download the Store sample.

It looks like I have a set of posts on ViewModel, aka MVVM, that have organically emerged into a series or story of sorts.

Recently, I blogged about The Case for ViewModel, and another on View/ViewModel Association using Convention and Configuration, and a long while back now, I posted an Introduction to the ViewModel Pattern as I was myself picking up this pattern, which has since become the natural way for me to program client applications. This installment adds to this on-going series. I've alluded to this topic in the past, but it is now time to focus and dedicate a post on the interactions between a view and its view model, i.e. the arrows in the diagram below:

I like to present ViewModel as something that is not brand-new, but a simple refactoring of [most of the] code-behind into a separate class so that the logic is decoupled from the user interface. This class simply employs the basic OOP constructs that you might have encountered in CS101 - it encapsulates state and behavior, exposed via properties, methods and events.

As simple as properties, methods and events...

All view models will encapsulate some interesting application state or data, exposed as properties, usually, in an observable form, i.e. properties that raise change notifications. Almost all view models will also expose some operations, ideally exposed as vanilla methods. And finally, some view models will also raise application-specific notifications as events.

Declarative glue...

A view is then responsible for consuming and working against the object model exposed by its view model as it presents information, and collect and react to user input, gestures etc. The data-binding engine in Silverlight makes it natural to bind to the properties in one-way or two-way fashion. Commands (in the UI, not in the view model - will address this below) allow invoking operations, usually in response to some user input or external inputs (eg. a timer or GPS input). Finally triggers allow the view to listen to events and translate view model notifications into user interface actions. All of these serve as glue expressed in XAML via declarative markup.

This is captured in the diagram above. Bindings are fairly straightforward and you've more than likely used them if you've done any Silverlight programming. So I am mostly going to focus on commands and triggers, but first, lets see this pattern in action.

An example application...

As always, an example helps make things concrete. I converted Tim Heuer's translation/text-to-speech application to follow the view model. In doing so I used the latest release of Silverlight.FX - while the ViewModel is an abstract presentation, it is useful to pick up a framework that allows you to quickly get started with your application, rather than build the plumbing from scratch.

On the right is a screen shot of the application. It is also now included as part of a series of sample applications packaged with Silverlight.FX. You can dowload the latest version (v3.5) by visiting the project page. I'll have a Silverlight 4 version that takes advantage of new capabilities, but in the mean time the Silverlight 3 version should continue to work. The sample application here uses v2 of Microsoft Translator API, which now has support for not just translating text, but also converting text to speech for a specific set of languages. You'll need to get an API key and update the web.config in the sample on your end to run the application.

The class diagram of the view model highlights the interesting things going on in the view model:

In terms of application state, it exposes the text to be translated, the resulting translated text, the list of languages, and whether the speak operation can be performed. In terms of operations, it provides the ability to perform translation, or to speak (as in produce the audio stream) the translated text. Finally in terms of notifications, it lets its associated view know when that audio stream has been loaded and is available for playing.

At MIX10, I presented the Developing with WCF RIA Services Quickly and Effectively talk. For the demos I used a BookClub application - the scenario is a team application for team members to use to share books and browse/search/request shared books.

The following are the concepts that the demos and code cover:

One of the comments I got on my last post on view/view model hookup options was the following:

I've been a mvvm fan but actually when I see all the hoops to jump through I wonder at times how effective this is

So I wanted to take a moment to list what I thought compelled me to adopt the ViewModel pattern of client application development (so much so, that I now feel odd writing Silverlight and sometimes even Ajax apps in any other way). Some will be obvious benefits, especially to those already using MVVM in their everyday development, but I want to throw in a couple that are farther out exploratory ideas that I am thinking about. I'd also love to pursue what it means to make view model more mainstream, so if you've got ideas on this topic of "Why ViewModel", I'd love to hear.

The often cited benefit is increased testability of additional code within the application, and I'll get to that, but I think there are some other benefits that are more applicable, considering not everyone practices the rigor of the level of testing we're talking about here. Essentially, testability is not a justification for the ViewModel pattern on its own.

Some time back, I blogged about different options to hook up a view to its view model when following the ViewModel (aka MVVM) pattern. There are multiple approaches in use out there. I raised the possibility of a convention-based approach in addition to existing ones like the ViewModelLocator pattern.

Motivation: I find the simplest way to explain ViewModel is to present it as a better code-behind, especially to the mainstream developer who is intimately familiar with the latter (at least in the .net world). With the code-behind approach the UI, its state and operations are all mixed up. The ViewModel pattern is of course designed to help separate application logic from the view, but now results in two discrete halves that need to be reconnected. Result: additional concept count. With a convention-based approach, I believe the simplicity of the code-behind model can be achieved while preserving the ability to decouple.

Like most other convention-based systems, it addresses the common and mainline scenarios well. There will always be some more advanced or less common scenarios that will fall out of the convention, for which a configuration-based approach needs to exist alongside.

With that context, I want to share what Silverlight.FX (@silverlightfx) now offers around hooking up a view to its view model by following a convention over configuration approach, to provide simplicity while retaining flexibility.