Latest posts
Fluent API for .NET RIA Services Metadata
9/20/2009 9:34:10 PM
.NET RIA Services relies heavily on metadata annotations for expressing intent beyond what can be inferrd via convention. For example, validation rules on entities and members can be declared as annotations, which then enable a variety of consumption scenarios. We also have metadata for describing model aspects in DAL-agnostic fashion, and hints for automatic UI-generation. What we have today is just a first step.
The general design we're enabling is actually quite flexible. For example, a number of developers want to have metadata specified external to their code, for example in XML files or in a database. Some don't like attributes, and have asked for a fluent interface instead. In RIA Services, we wanted to create a consistent API for consumers to lookup metadata. In short the CLR metadata API, or the TypeDescriptor API from component model. And we want to let producers or specifiers of metadata choose a persistence store or specification mechanism that meets the needs of their scenario, as long as they can surface attribute instances when needed.
In fact, we have an over-arching vision for a metadata pipeline (which I'll get to later in the post).
However, the first concrete experience developers have with our metadata model when adding validation rules and UI hints, is unfortunately not very pretty. The out-of-the-box approach is based on an associated metadata class (or buddy class) mechanism that we share with ASP.NET dynamic data. Some folks have called them "ugly buddies” and that name has caught on in terms of how the feature is described! The ugly buddies mechanism suffers from usability issues (eg. lots of repetition, and room for typos, or names getting out of sync) and discoverability issues. At the end of the day, it is no more than a workaround for the missing language feature that would enable adding metadata to members via a partial class.
Using the extensibility mechanisms in the bits today, we've published a sample that demonstrates specifying metadata in XML. In this post, I'll show you my first stab at providing a fluent-API-based metadata approach. I'd obviously love to see this in the product out-of-the-box, but it is another feature, and there is the realities of a product cycle. However, there is always a v-next. In the meantime, do provide feedback via comments - it will definitely feed into the design process.
[
Full post continued here...]
Dialogs and ViewModel - Using Tasks as a Pattern
9/11/2009 9:37:28 AM
The ViewModel/MVVM pattern continues to gain popularity, with a blog post showing up every so often, and with tweets and retweets popping up even more often :-). At the same time, there are some interesting topics beyond the core pattern that continue to fuel experimentation. A big one amongst those is how should applications use dialogs when using the view model pattern.
The crux of the problem is the desire to keep the view model independent of UI concerns, and ensure it can be tested in a standalone manner, but that often comes to odds when you want the view model to launch a dialog, and/or do some work after the dialog is closed.
The most recent version of Silverlight.FX (v3.2) that I published earlier this week, addresses this scenario using a Task pattern. This blog post discusses that pattern, and opens it up for your thoughts.
The screenshot on the right represents my updated TaskList sample application (Click to run and create a task item, and double click on it to launch an edit dialog). All of the sample code is available along with Silverlight.FX for running on your end, and using the same pattern in your own applications of course.
Silverlight.FX provides a concrete notion of a view model representing a task with commit and cancel semantics in the form of a TaskViewModel base class. This serves as the base class for view models associated with dialogs. The view model associated with the main/parent window creates and initializes an instance of a TaskViewModel-derived class to represent the task as hand (when the view decides it needs to launch the dialog). The TaskViewModel raises completion notifications that can be used to do additional work in the parent view model. The main/parent window then creates a Form and assigns the resulting TaskViewModel as Form's view model, and finally shows the dialog. The user interacts with the dialog. The Form implements OK and Cancel commands that the OK/Cancel buttons invoke, and these commands are wired up to call into the TaskViewModel to commit it or cancel it.
I'll use some actual sample code to hopefully make this more concrete.
[
Full post continued here...]
Photos from Death Valley
8/29/2009 7:57:02 AM
A small set of photos from a trip to Death Valley National Park ... drove up there right after MIX '09 in Las Vegas.
[Full post continued here...]
BouncingPlane Behavior for Silverlight
8/27/2009 4:15:22 PM
Time for a brief but fun post... some time back Tim Heuer posted the Silverlight 3 bouncing plane gratuitous demo. Click an element, and the nearest corner would bounce backwards and forwards as it comes back to rest.
Tim had the code to setup the storyboards, and handle the mouse interaction in code-behind. I look at it, and immediately see a reusable component (even if it is a gratuitous one), or more specifically a behavior, that encapsulates all the logic, and can be attached declaratively in XAML to one or more elements simply without needing any code-behind logic. So I created one such behavior. I used this behavior in my TwitterBug sample at TechEd recently, and thought it could use a dedicated blog post. :-)
Here is a screenshot, which really doesn't do much justice to something interactive. So go ahead, and click it to run the sample live. Click around on the images. And if you're wondering how its done, go ahead and download the code. You'll see a BouncingPlane class that derives from Behavior.
[
Full post continued here...]
LINQ to Bing, Silverlight and .NET RIA Services
8/26/2009 11:20:20 AM
In my last post, I described BLinq, or LINQ to Bing, an API that allows you use LINQ to access the Bing search results (ok, so perhaps BLinq was not the best of names, given prior art on that name ... but anyway). I also alluded to .NET RIA Services integration, which I'll cover in this installment. In fact, IQueryable and the LINQ pattern lie at the very heart of .NET RIA Services, in allowing developers to access data in a consistent manner not just on client or server but across client and server, and enabling code to compose queries naturally. If you haven't read the intro post, please take the few minutes to check out the LINQ snippets to get a general sense before continuing on.
You might use Bing in your rich internet application in one of two ways: have your client make requests to Bing by proxying through your server, or make requests directly from the client, using a cross-domain networking API, such as the one provided by Silverlight. I'll show both approaches in this post.
Here is a screenshot of the Silverlight application using .NET RIA Services. It is pretty straightforward and minimalistic. It has a search TextBox, and a couple of panels to display matching pages and images, along with some paging UI. Behind the scenes are a couple of DomainDataSource controls to perform the data loading one page at a time.
I have two apps with the same user interface demonstrating the two different approaches. The first uses RIA Services on both server and client. The second will use RIA Services only on the client, and will demonstrate how you can in fact use the client programming model and framework against a custom or very different back-end service (in this case, Bing).
[
Full post continued here...]