This example is not that complex so the gains aren't that great but when you have more tasks and also throw error handling and conditionals into the mix you can easily end up with a big ball of mud that's hard to debug. I think that the task runner makes it easier to see how the tasks execute after each other when you set them up in a list like this than when you have the nested Dispatcher calls above.

The base class contains some common features like an Exception that can be set if an error occurs during the execution of the task and also a property that states if the chain of tasks should continue to execute if the task fails.

The big thing in the class is the Run method that takes two Dispatchers and an action as parameters. The two different dispatchers are the foreground and background dispatchers and the task itself decides on which it should execute. The nextAction parameter is an action that is created by the TaskRunner and will be next task in the chain, or null if this is the last task.

I could then create a SimpleTask class that will handle the basic tasks that run either on a foreground thread on on the background.

A little more complex task - RiaTask

The main reason I created this solution is that when you do calls to RIA services you usually end up with a big mess. The thing is that when you create an instance of a context you must do it on the UI thread, but you usually always want to handle the result on the background thread.

In this example I have created a service that returns a string describing a customers age (kind of weird, I know). If an error occurs I want to notify the user with a message box. If the operation succeeds I want to update the selected customer, save the screen and notify the user with a message box.

If there is a better and cleaner way to do this I would greatly appreciate any pointers!

I decided to create a Task that would hide away all that and just let me focus on what I want to do. When I set up my task I just want to specify what type of context I want, what I want to do with the result and set any error message that should be displayed.

The RiaContext is the type of my RIA service context class. The task will new-up an instance of the context by itself on the foreground thread and execute it there. I can then set an action that will run on the background thread to handle the return value. If an exception occurs the supplied error message as well as the exception itself will be passed to the TaskRunner that executes the task.

Using this I could rewrite the first RIA example like this using tasks

The main grunt of the class is in the SetupChain method that recursively traverses each task and creates a chain of actions. The links in the chain are the nextAction parameters that are passed to each task in the Run method. This way each task can make sure that the next task is executed after this task, regardless of which thread it will execute on.

Future improvements

I just created this during the weekend so it still has some improvements to be made.

One thing I'm thinking of is checking which thread we are on in the simple tasks so that we don't have to do Dispatcher.BeginInvoke if we are going to execute the action on the thread we currently are on.

Another new Task I'm thinking about implementing is a ParallellTask (maybe not the best name), but it would take a list of tasks and execute them all at once and would only call the nextAction after all the tasks had executed.

That way you could easily do multiple RIA service calls and only after all them had completed would you call the next task in the chain.

If any of you have any suggestions for improvements or other comments they are all greatly appreciated. I've attached the source code to this post and would love if you would download it and play around with it.

jQuery makes event handling in javascript very easy and extremely handy to perform all kinds of different things in the UI.

The great thing about the event handling is that you can bind to events to almost anything, this makes things like creating hover effects over tables and creating clickable divs a breeze. And since you use the jQuery css style selectors to specify which elements you want to bind the event to, you can bind the event to many elements with one line of code!

What is jQuery, and why should I use it

Quite many .NET developers avoid using client side scripting and often use post backs to do simple updates that could just as well be done on the client. Using a post back where client scripting would have worked just as well is a real bad thing. It makes the web app experience much slower for the end user since the post back needs to send data to the server, it also bogs down the server with unnecessary requests.

Historically javascript has been quite painful to use due to browser differences that forced us developers to use ugly browser sniffing and create duplicate code targeting different vendors.

But things are different today!

jQuery is a small javascript library that makes creating cross browser javascript a breeze. It is an open source frame work that due to it’s simpleness and extensibility has drawn a great following.

One of the key benefits of encapsulating logic and behavior in a user control is that the user of the control doesn’t have to care about the inner workings of the control. We only need to expose the things that the users of the control needs.

We will demonstrate this by creating a simple user registration control. The control will expose an event, UserCreated, which will contain the newly created user as data.

This way the page that the user control is located in doesn’t need to care about what fields the user needs to fill out or how the person is created. It is simply handed a user that was created.

User controls are great for encapsulating both behavior and look. When you have some UI elements that you want to use in more than one place a User control is a great way to add reusability.

One problem that you can run into is how you add communication from the user control to the web page. Perhaps you have a button in a user control, and when you click it the web page should perform some action. If the button was on the page we would simply bind to the Clicked event on the button, but when it’s inside of the user control we don’t have access to the button.

Luckily it is really easy in .NET to add your own events. In this really simple example we will create a user control with a button that also has an event, ButtonClicked. We will then create a page that contains an instance of the user control and bind to the exposed event so that the page will know when the button has been clicked.

One problem I've faced with the model-view-presenter pattern is how to add communication between different user controls on a web form without adding a bunch of logic to the web form. Ideally the web form shouldn't be aware that the user control is there, the user control should be able to load it's data and update the model by itself.

My solution to this problem was to create a custom object builder attribute - CreateShared.

The CreateShared attribute functions the same way as CreateNew except that it will only create one instance / request for the requested type. This can for instance be used in presenters to create a shared instance of the controller.

By doing this you can add events to the controller which reflects changes in the model. The different presenters can listen to these events and respond to changes made by another presenter. This is how you can perform the communication.

You can read a How-To and a description of the sample on the Wiki page on codeplex.com. Read it here.

Attached to this entry is both the code and a sample that shows how to use it. Both projects are Visual studio 2008 projects and references Web Client Software Factory 2.0 feb 2008.