Happy Coding

Extend ASP.NET MVC for Asynchronous Action

2009-01-30T05:14:00Z

Numerous new features come into people’s eyes since ASP.NET 2.0 and asynchronous request handling is one of the most important parts. It reduces the working thread number by the async mechanism based on IO completion port when processing IO bound request and improves throughput of web sites significantly (please refer to the theory analyzing and benchmarks if you can read Chinese :P). But the current version of ASP.NET MVC doesn’t support async actions and that’s just ‘the missing key feature’ I mentioned before. I gave a so-called solution that introduced the async action to ASP.NET MVC in my session of TechED 2008 China but it’s full of limitations and inappropriate for production use.

These days I’m preparing for the session in the coming .NET conference in Shanghai (that Jeffrey Richter would also attend) and I think it’s better to release a better solution at that time: straightforward, rather full-featured and light-weighted – the core funtion contains only about 200 lines of codes, which means it maximize the usage of existing framework functions to make the solution more stable, efficient and backward-compatible.

I built the the new solution based on ASP.NET MVC Beta at first but RC released when I was writing the post. When I was trying to change the implementation for RC I found the improvements in design that impressed me a lot. These improvements change my strategy of building the solution but seems it’s a little easier when building extensions for RC. The ASP.NET MVC team did a good job.

Now let’s get started.

Change the way of request handling

It should be clear how ASP.NET MVC handles a request before we make decisions:

When the application starts (without any incoming requests), route strategies would be registered in ASP.NET Routing module. At that time each strategy object (Route instance) contains a route handler – which is an intance of MvcRouteHandler type in ASP.NET MVC framework.
When the Routing module meets a request that fit one of the strategies, the route handler belongs to the corresponding Route object would be used (by calling GetHttpHandler method) to get an http handler that can process the request. The MvcRouteHandler always returns an MvcHandler object.
When MvcHandler object is processing the request, the ‘controller’ value in RouteData would be retrieved to build a controller object (which implements IController) by a controller factory (which implements IControllerFactory). After that, the controller would be executed (by calling Execute method on it).
Generally, in an ASP.NET MVC application a controller type inherits from the System.Web.Mvc.Controller class. When executing these kind of controllers, the ‘action’ value in RouteData would be retrieved and passed to the action invoker (which is an IActionInvoker object get by the ActionInvoker property) to execute the action.
…

If the way of processing requet needs to be async, we have to let it meet the architecture of ASP.NET. There’re several method to enabled the async mechanism such as async page and async http module, but the best one to use in our scenario is using async http handler. To implement an async http handler, we must make the handler type to implement IHttpAsyncHandler instead ot IHttpHandler. The BeginProcessRequest and EndProcessRequest methods compose the ‘two-phase’ processing style which meets the standard APM (Aynchronous Programming Model) pattern in .NET.

Now you may realized that an IHttpAsyncHandler should be used if we want to execute an action asynchronously, but the default choice of ASP.NET MVC framework is MvcHandler, which is always sync. It’s too late for us to decide whether the executing action is async or not in the handler. We have to move it to Routing. Fortunately, the route handler in ASP.NET Routing is just like IHttpHandlerFactory in ASP.NET architecture, which can be used to create an http handler object dynamiclly by context. So the first step we shoud do is to build a new route handler to replace the default MvcRouteHandler. Here comes the AsyncMvcRouteHandler – you can imagine that part of it is the same as MvcHandler since what we need to do is just to move some code to the earlier stage:

public class AsyncMvcRouteHandler : IRouteHandler
{
    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        string controllerName = requestContext.RouteData.GetRequiredString("controller");

        var factory = ControllerBuilder.Current.GetControllerFactory();
        var controller = factory.CreateController(requestContext, controllerName);
        if (controller == null)
        {
            throw new InvalidOperationException(...);
        }

        var coreController = controller as Controller;
        if (coreController == null)
        {
            return new SyncMvcHandler(controller, factory, requestContext);
        }
        else
        {
            string actionName = requestContext.RouteData.GetRequiredString("action");
            return IsAsyncAction(coreController, actionName, requestContext) ?
                (IHttpHandler)new AsyncMvcHandler(coreController, factory, requestContext) :
                (IHttpHandler)new SyncMvcHandler(controller, factory, requestContext);
        }
    }

    internal static bool IsAsyncAction(
        Controller controller, string actionName, RequestContext requestContext)
    {
        ...
    }
}

In GetHttpHandler method, we get the controller name from RouteData and create a controller object by the factory registered in ControllerBuilder. We try to cast the controller object as Controller type since we’ll use the action invoker in it to decide whether the action is async or not. If the controller object is in type Controller, we’ll get the action name from RouteData and try to return an AsyncMvcHandler (which implements IHttpAsyncHandler) or SyncMvcHandler (which implements IHttpHandler) object by the result of IsAsyncAction method.

To enable the AyncMvcRouteHandler, we should use it to replace the default one while mapping route strategies when application starts.

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default",                                              // Route name
        "{controller}/{action}/{id}",                           // URL with parameters
        new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
    ).RouteHandler = new AsyncMvcRouteHandler();
}

Decide whether the action is async or not

We made a convention in code above: an async action could only be defined in an controller type which inherits from Controller. Here’s another one: the action invoker in the controller must be an object of ControllerActionInvoker or its child type.

There’re several ‘helper’ methods in ControllerActionInvoker which can be used to get the descriptors for controller and actions. We can get the action’s information from its descriptor object, such as whether it has been marked with AsyncActionAttribute – that’s the sign of an async action:

private static object s_methodInvokerMutex = new object();
private static MethodInvoker s_controllerDescriptorGetter;

internal static bool IsAsyncAction(
    Controller controller, string actionName, RequestContext requestContext)
{
    var actionInvoker = controller.ActionInvoker as ControllerActionInvoker;
    if (actionInvoker == null) return false;

    if (s_controllerDescriptorGetter == null)
    {
        lock (s_methodInvokerMutex)
        {
            if (s_controllerDescriptorGetter == null)
            {
                BindingFlags bindingFlags = BindingFlags.Instance | BindingFlags.NonPublic;
                MethodInfo method = typeof(ControllerActionInvoker).GetMethod(
                    "GetControllerDescriptor", bindingFlags);
                s_controllerDescriptorGetter = new MethodInvoker(method);
            }
        }
    }

    var controllerContext = new ControllerContext(requestContext, controller);
    var controllerDescriptor = (ControllerDescriptor)s_controllerDescriptorGetter.Invoke(
        actionInvoker, controllerContext);
    var actionDescriptor = controllerDescriptor.FindAction(controllerContext, actionName);
    return actionDescriptor == null ? false :
        actionDescriptor.GetCustomAttributes(typeof(AsyncActionAttribute), false).Any();
}

There’s a protected method named ‘GetControllerDescriptor’. It accepts a ControllerContext object as parameter and returns a ControllerDescriptor object to describe the controller. From the descriptor of controller we can get the ActionDescriptor object as the descriptor of the executing action by calling FindAction method with the action name as one of the parameters. IsAsyncAction returns false for a non existing action so that SyncMvcHandler would be used to process the request with the default behavior. If and only if the action is marked with AsyncActionAttribute it would be identified as an async one. BTW, a special class ‘MethodInvoker’ is used above. It is a replacement for the function of MethodInfo.Invoke method and provide huge performance improvement. That’s a helper class from Fast Reflection Library project (I also wrote a post about it) that you can use for your own need.

Let’s talk about the change of design in ASP.NET MVC RC. There’s nothing like the descriptors but a method to get the MethodInfo of the action in previous ControllerActionInvoker. The current design uses the implementations based on reflection for the abstraction of descriptors by default. e.g., the descriptor of an action we used is an object of RelfectedActionDescriptor class, which implements the abstract class ActionDescriptor. That’s a great improvement. Since we’re using descriptors for elements (controller/action/parameter, etc.),

we could use different concrete implementations to describe elements. e.g., we can build descriptors based on configurations rather than the default behavior – reflection – which is more like ‘convention’.
there’s no limitations for the underly form of action. e.g., an async action could be composed by two methods.
it’s easy to add more information on descriptor types. e.g., in the future we could know whether the action disabled session state from an action descriptor.
…

Execute an action

The SyncMvcHandler type which used to execute a normal action is quite an easy one:

public class SyncMvcHandler : IHttpHandler, IRequiresSessionState
{
    public SyncMvcHandler(
        IController controller,
        IControllerFactory controllerFactory,
        RequestContext requestContext)
    {
        this.Controller = controller;
        this.ControllerFactory = controllerFactory;
        this.RequestContext = requestContext;
    }

    public IController Controller { get; private set; }
    public RequestContext RequestContext { get; private set; }
    public IControllerFactory ControllerFactory { get; private set; }

    public virtual bool IsReusable { get { return false; } }

    public virtual void ProcessRequest(HttpContext context)
    {
        try
        {
            this.Controller.Execute(this.RequestContext);
        }
        finally
        {
            this.ControllerFactory.ReleaseController(this.Controller);
        }
    }
}

But I thought a lot for dealing with an async action, or how I can change the default execution style into ‘two-phase’ (BeginXxx/EndXxx). I tried to implement a new action invoker before but found it would take a lot of work. If I want to keep all the current features (action filter, action selector, etc.), it seems the best way is to build a child class of ControllerActionInvoker and use te exsiting functions as much as possible. But I think it’s nealy impossible after reading the code. For example, one of the characters of an action method is that it returns ActionResult (or its child), but the BeginXxx method for an async action returns IAsyncResult so we cannot use the FindAction method in ControllerActionInvoker directly; and, if we want to use FindAction to get the ‘EndAbc’ method by passing the action name ‘Abc’ with ‘End’ before it, what would happen if there’s a request to execute a sync action ‘EndAbc’?

Since the problems described above, I almost rewrite the whole invoker last year and it brings a lot of complexities and limitations. Developers have to compromise in some aspect when using it. When I introduced the solution in my session of TechED 2008 China I said it should not be used in production environment.

The current solution is much better. It uses an interesting work around to solve the problems. It’s not perfect but usable. The reason we meet such difficulties is that we break the design of framework, from single action method to a ‘APM-style’ execution. Wait a minute, have you idetified the source of the problems? That’s right, it’s the ‘APM-style’.

‘APM-style’ separates a single method into a pair of BeginXxx/EndXxx method, but we can just implement an async execute with an ‘two-phase’ style. Since the framework force an action to return an ActionResult, why can’t we keep the reference(s) of method(s) in the object? It’s not ‘APM-style’ but it’s really ‘async-style’, isn’t it?

public class AsyncActionResult : ActionResult
{
    public AsyncActionResult(
        IAsyncResult asyncResult,
        Func<IAsyncResult, ActionResult> endDelegate)
    {
        this.AsyncResult = asyncResult;
        this.EndDelegate = endDelegate;
    }

    public IAsyncResult AsyncResult { get; private set; }

    public Func<IAsyncResult, ActionResult> EndDelegate { get; private set; }

    public override void ExecuteResult(ControllerContext context)
    {
        context.Controller
            .SetAsyncResult(this.AsyncResult)
            .SetAsyncEndDelegate(this.EndDelegate);
    }
}

We execute the BeginXxx method in the action method and return an AsyncActionResult instance contains the IAsyncResut object and the reference to the EndXxx method. These two objects will be saved when the result executes and we can get them back in AsyncMvcHandler.EndProcessRequest method. Generally we should build an extension method to help the developers to return an AsyncActionResult object from an action method. Now we get the style of an async action:

[AsyncAction]
public ActionResult AsyncAction(AsyncCallback asyncCallback, object asyncState)
{
    SqlConnection conn = new SqlConnection("...;Asynchronous Processing=true");
    SqlCommand cmd = new SqlCommand("WAITFOR DELAY '00:00:03';", conn);
    conn.Open();

    return this.Async(
        cmd.BeginExecuteNonQuery(asyncCallback, asyncState),
        (ar) =>
        {
            int value = cmd.EndExecuteNonQuery(ar);
            conn.Close();
            return this.View();
        });
}

No secret for AsyncMvcHandler now:

public class AsyncMvcHandler : IHttpAsyncHandler, IRequiresSessionState
{
    public AsyncMvcHandler(
        Controller controller,
        IControllerFactory controllerFactory,
        RequestContext requestContext)
    {
        this.Controller = controller;
        this.ControllerFactory = controllerFactory;
        this.RequestContext = requestContext;
    }

    public Controller Controller { get; private set; }
    public RequestContext RequestContext { get; private set; }
    public IControllerFactory ControllerFactory { get; private set; }
    public HttpContext Context { get; private set; }

    public IAsyncResult BeginProcessRequest(
        HttpContext context,
        AsyncCallback cb,
        object extraData)
    {
        this.Context = context;
        this.Controller.SetAsyncCallback(cb).SetAsyncState(extraData);

        try
        {
            (this.Controller as IController).Execute(this.RequestContext);
            return this.Controller.GetAsyncResult();
        }
        catch
        {
            this.ControllerFactory.ReleaseController(this.Controller);
            throw;
        }
    }

    public void EndProcessRequest(IAsyncResult result)
    {
        try
        {
            HttpContext.Current = this.Context;
            ActionResult actionResult = this.Controller.GetAsyncEndDelegate()(result);
            if (actionResult != null)
            {
                actionResult.ExecuteResult(this.Controller.ControllerContext);
            }
        }
        finally
        {
            this.ControllerFactory.ReleaseController(this.Controller);
        }
    }
}

We save the current HttpContext object in BeginProcessRequest – that’s important since HttpContext.Current is based on the call context and it would be thrown after an async callback, which means we shoud set it back in EndProcessRequest for the rest functions. After saving the HttpContext object, we should also save the async callback and async state parameters, and next, execute the controller. The whole progress is finished after Execute method’s return, which means the IAsyncResult object and the reference to the EndXxx method haved been saved. We get the IAsyncResult object back and return from BeginProcessRequest. In EndProcessRequest method, we retrive the saved reference to the EndXxx method and get another ActionResult by calling it. Finally we execute the new result and complete the whole async processing.

The code above only considers the logic of normal state. You can get more (e.g. logic to deal with the exceptional state) in the source code of the solution. Both the BeignProcessRequest and EndProcessRequest methods take care of error handling to make the controller released at a property time.

ModelBinder support

Actually you cannot use async action so far, since the default model binder don’t know how to bind an AsyncCallback object and the AsyncCallback parameter in the action method is always null. That’s easy. We could build a AsyncCallbackModelBinder whose only purpose is to return the AsyncCallback object saved in controller:

public sealed class AsyncCallbackModelBinder : IModelBinder
{
    public object BindModel(
        ControllerContext controllerContext,
        ModelBindingContext bindingContext)
    {
        return controllerContext.Controller.GetAsyncCallback();
    }
}

We should register the model binder for AsyncCallback type when application starts.

protected void Application_Start()
{
    RegisterRoutes(RouteTable.Routes);
    ModelBinders.Binders[typeof(AsyncCallback)] = new AsyncCallbackModelBinder();
}

It’s inappropriate to do so for async state parameter in an action method since object is the base class of all the types and it’s not specific to the async state. I suggest that you mark an attribute for the async state parameter in each action method. Here’s the AsyncStateAttribute, which has been built into the solution with AsyncStateModelBinder:

[AttributeUsage(AttributeTargets.Parameter, AllowMultiple = false, Inherited = false)]
public sealed class AsyncStateAttribute : CustomModelBinderAttribute
{
    private static AsyncStateModelBinder s_modelBinder = new AsyncStateModelBinder();

    public override IModelBinder GetBinder()
    {
        return s_modelBinder;
    }
}

Here’s the way to use it:

[AsyncAction]
public ActionResult AsyncAction(AsyncCallback cb, [AsyncState]object state) { ... }

Actually it won’t be a big deal even if you ignore the async state parameter since it’s always useless when processing a request aynchronously. And, you can also get the async callback and async state object by the extensions methods (GetAsyncCallback and GetAsyncState) defined for Controller type, but it reduces the testability.

Limitations and drawbacks

The solution definitely has limitations and drawbacks:

It doesn’t follow the standard APM pattern.
Since the solution is based on the existing functions in framework, all the filters would be executed when BeginXxx method finished.
Some features are missed since the filters cannot be applied to EndXxx method and the final action result.

ASP.NET MVC will introduce the ‘async controller’ in the future according to the official roadmap. Actually the MvcFuture project in the source of ASP.NET MVC RC has already contains the code about async features. You can found serveral new types such as IAsyncController, AsyncController, IAsyncActionInvoker, AsyncControllerActionInvoker, etc.. All types are inherited from exsiting type but as I predicted before, the AsyncControllerActionInvoker class rewrites almost all the code. I cannot tell the quality of design before reading it – hope it is as good as the current one.

I’m going do more for the drawbacks listed above. I hope it would become a solution good enough for production. The whole solution, source code and benchmark have been published in MSDN Code Gallery. Please feel free to contact me for any comments and suggestions.

Fast Reflection Library

2009-01-26T18:01:00Z

This is a project I've created in CodePlex under Microsoft Public License (Ms-PL). You can find it here.

Simple Usage

Reflection is one of the most important features of .NET platform. The way of accessing/assigning a property or invoking a method dynamically is widely used by numerous projects. As we all know, invoke-by-reflection is much less efficient than direct access. FastReflectionLib provide the same as part of the refection features like executing method dynamically but give simple and faster implementations. It can be use as the foundation of reflection-based scenarios such as ORM framework.

Please look at the code snippets below:

using System;
using System.Reflection;
using FastReflectionLib;

namespace SimpleConsole
{
    class Program
    {
        static void Main(string[] args)
        {
            PropertyInfo propertyInfo = typeof(string).GetProperty("Length");
            MethodInfo methodInfo = typeof(string).GetMethod("Contains");

            string s = "Hello World!";

            // get value by normal reflection
            int length1 = (int)propertyInfo.GetValue(s, null);
            // get value by the extension method from FastReflectionLib,
            // which is much faster
            int length2 = (int)propertyInfo.FastGetValue(s);

            // invoke by normal reflection
            bool result1 = (bool)methodInfo.Invoke(s, new object[] { "Hello" });
            // invoke by the extension method from FastReflectionLib,
            // which is much faster
            bool result2 = (bool)methodInfo.FastInvoke(s, new object[] { "Hello" });
        }
    }
}

When we get the MethodInfo object, we can call the Invoke method to execute the method. FastReflectionLib contains several extension methods on these types (such as MethodInfo), so we can just put "Fast" before the method to replace the build-in ones. Comparing with the build-in functions, these new implementations get big performance improvements.

Use the worker object directly

For example, the extension method "FastInvoke" defined for MethodInfo type gets the corresponding worker object by the MethodInfo instance as the key from cache, and execute the Invoke method in the worker object. Apparently keeping the worker object and use it directly after getting it would give us better perfermance than retrieving it from cache again and again.

Here's the list of worker types for each XxxInfo type:

PropertyInfo: IPropertyAccessor
MethodInfo: IMethodInvoker
ConstructorInfo: IConstructorInvoker
FieldInfo: IFieldAccessor

We can get an IMethodInvoker object from FastReflectionCaches.MethodInvokerCache by a MethodInfo object:

static void Execute(MethodInfo methodInfo, object instance, int times)
{ 
    IMethodInvoker invoker = FastReflectionCaches.MethodInvokerCache.Get(methodInfo);
    object[] parameters = new object[0];
    for (int i = 0; i < times; i++)
    {
        invoker.Invoke(instance, parameters);
    }
}

Default implementations of worker types and extensions

FastReflectionLib has already provide default implementations for each worker interfaces. These implementations generate lambda expressions and compile them (by call Compile method) to delegate objects with the same signatures as the corresponding reflection methods. The implementation is simle, general and safe than directly Emit and the performance is good enough for most scenarios (please refer to the Benchmarks section).

But it's not the most efficient way to do so. The best optimized way by Emit could get better performance than directly access the members in code (Dynamic Reflection Library is one of these implementations). You can build your one worker interface implementation and factory to replace the build-in ones if necessary:

public class BetterPropertyAccessor : IPropertyAccessor
{
    public BetterPropertyAccessor(PropertyInfo propertyInfo) { ... }

    ...
}

public class BetterPropertyAccessorFactory :
    IFastReflectionFactory<PropertyInfo, IPropertyAccessor>
{
    public IPropertyAccessor Create(PropertyInfo key)
    {
        return new BetterPropertyAccessor(key);
    }
}

class Program
{
    static void Main(string[] args)
    {
        FastReflectionFactories.PropertyAccessorFactory =
            new BetterPropertyAccessorFactory();

        ...
    }
}

Default implementaions of caches and extensions

FastReflectionLib uses the caches based on System.Collections.Generic.Dictionary<TKey, TValue>. When we invoke a FastXxx extension method, the library would retrieve the worker object from the cache container and execute it. If the worker object cannot be found in the cache, a new one would be created by the corresponding factory. In the Benchmarks section we can found that considerable time is "wasted" in searching the cache.

If you have better cache implementation you can replace the build-in one as following:

public class BetterMethodInvokerCache :
    IFastReflectionCache<MethodInfo, IMethodInvoker>
{
    public IMethodInvoker Get(MethodInfo key) { ... }
}

class Program
{
    static void Main(string[] args)
    {
        FastReflectionCaches.MethodInvokerCache = 
            new BetterMethodInvokerCache();

        ...
    }
}

Cache the worker objects by your own

FastReflectionLib uses the reflection objects (such as PropertyInfo) as key to cache the worker object (such as PropertyAccessor). But in some scenarios, we can cache the worker objects by your own. Here's an sample web site "CustomCache" release with the source of FastReflectionLib, which contains a series of overloaded FastEval extension methods that can be used as an efficient replacement for the build-in Eval method in some cases. The sample:

uses both the Type of class and the property name as a "joint key" to cache the PropertyAccessor objects.
uses PropertyAccessor to get the value of property defined in an "anonymous object".
caches in the scope of "page" instead of the whole AppDomain.

Benchmarks

A benchmark project is provided with the source of FastReflectionLib. Here's part of the results (the benchmarks were run on my laptop with release build):

Execute the following method 1,000,000 times:

public class Test
{
    public void MethodWithArgs(int a1, string a2) { }
}

The way to execute	Time elapsed (in second)
Directly invoke	0.0071397
Build-in reflection	1.4936181
MethodInvoker.Invoke	0.0468326
FastInvoke	0.1373712

Build a Simple Control to Refresh UpdatePanel from Client Side

2008-04-28T01:15:00Z

(It's the post I wrote one year ago in my previous blog which has been cancelled now.)

Daron Yondem provided a solution to refresh UpdatePanels from client side. He built an Extender control (with AjaxControlTookit) and use an invisible textbox as an trigger to raise an async postback. The extender model in ASP.NET AJAX is an light-weight solution to build extensions for existing controls, but these extenders based on AjaxControlToolkit is realy heavy. Using a single extender control build upon AjaxControlToolkit will cause all the base scripts to load on the page. It's probably not a good idea to use such a heavy model and some simple solution is just enough for some simple objectives.

All we should do for the current feature is just to generate JavaScript proxies in the page. Actually I've also build an simple control to help the devs to raise async postbacks from client side, encapsulated the way described in this post. It can be used as following:

<ajaxExt:JavaScriptUpdater ID="Updater1" runat="server" MethodName="Refresh">
    <TriggeredPanels>
        <ajaxExt:TriggeredPanel UpdatePanelID="up1" />
        
    </TriggeredPanels>
</ajaxExt:JavaScriptUpdater>

The MethodName property in this control indicates the name of the proxy method generated in the client. Each control will be provided a collection of references to the UpdatePanels on the page. And now, devs can raise an async postback to refresh those UpdatePanels by executing the following method:

UpdatePanels.Refresh();

First of all, we should define a class as the element for the collection of UpdatePanel would be triggered. It can't be easier:

public class TriggeredPanel
{
public string UpdatePanelID { get; set; }
}

Of course we'll expose the collection in the control:

[PersistChildren(false)]
[ParseChildren(true)]
[NonVisualControl]
public class JavaScriptUpdater : Control
{
    ...

    private List<TriggeredPanel> m_triggeredPanels = new List<TriggeredPanel>();

    [PersistenceMode(PersistenceMode.InnerProperty)]
    public List<TriggeredPanel> TriggeredPanels
    {
        get
        {
            return m_triggeredPanels;
        }
    }

    ...
}

Please note that the MethodName can only be modified during initialize period. It's the way which has been widely used in ASP.NET AJAX to keep the consistency of an control's settings in the lifecycle. Please see the following code:

private bool m_pageInitialized = false;

private string m_methodName;
public string MethodName
{
    get
    {
        return this.m_methodName;
    }
    set
    {
        if (this.m_initialized)
        {
            throw new InvalidOperationException("...");
        }

        this.m_methodName = value;
    }
}

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

    this.Page.InitComplete += (sender, ev) =>
    {
        this.m_pageInitialized = true;
    };

    this.Page.Load += new EventHandler(OnPageLoad);

    if (!ScriptManager.GetCurrent(this.Page).IsInAsyncPostBack)
    {
        this.Page.PreRenderComplete += new EventHandler(OnPagePreRenderComplete);
    }
}

Each helper control on the page will put a invisible button on the page as the trigger. The following code will dynamically generate an LinkButton control on the page and handle its Click event:

private string m_triggerUniqueId = null;

private void OnPageLoad(object sender, EventArgs e)
{
    LinkButton button = new LinkButton();
    button.Text = "Update";
    button.ID = this.ID + "_Trigger";
    button.Style[HtmlTextWriterStyle.Display] = "none";
    button.Click += new EventHandler(OnTriggerClick);

    this.Page.Form.Controls.Add(button);

    this.m_triggerUniqueId = button.UniqueID;
    ScriptManager.GetCurrent(this.Page).RegisterAsyncPostBackControl(button);
}

Before page's rendering, we should register the proxy to the page:

private static readonly string BaseScripts =
@"if (!window.UpdatePanels) window.UpdatePanels = {};
UpdatePanels.__createUpdateMethod = function(triggerUniqueId)
{
    return function()
    {
        __doPostBack(triggerUniqueId, '');
    }
}";

private const string RegisterMethodTemplate =
    "\nUpdatePanels['{0}'] = UpdatePanels.__createUpdateMethod('{1}');";

private void OnPagePreRenderComplete(object sender, EventArgs e)
{
    this.Page.ClientScript.RegisterClientScriptBlock(
        this.GetType(),
        "BasicScripts",
        JavaScriptUpdater.BaseScripts,
        true);

    this.Page.ClientScript.RegisterClientScriptBlock(
        this.GetType(),
        this.m_triggerUniqueId,
        String.Format(
            JavaScriptUpdater.RegisterMethodTemplate,
            this.MethodName,
            this.m_triggerUniqueId),
        true);
}

When the page received an async postback raised by the proxy, the Click event of the dynamic button would be fired. As you can see later, I defined three events in the contorl. The ResolveTriggeredPanel event is to help the control to find the specified UpdatePanels. In addition, the other two events, Updating and Updated will be fired before and after refreshing the UpdatePanels:

public event EventHandler<ResolveTriggeredPanelEventArgs> ResolveTriggeredPanel;
public event EventHandler Updating;
public event EventHandler Updated;

private void OnTriggerClick(object sender, EventArgs e)
{
    if (this.Updating != null)
    {
        this.Updating(this, EventArgs.Empty);
    }

    foreach (TriggeredPanel panel in this.TriggeredPanels)
    {
        UpdatePanel updatePanel = this.FindTriggeredPanel(panel.UpdatePanelID);
        if (updatePanel != null && updatePanel.UpdateMode != UpdatePanelUpdateMode.Always)
        {
            updatePanel.Update();
        }
    }

    if (this.Updated != null)
    {
        this.Updated(this, EventArgs.Empty);
    }
}

private UpdatePanel FindTriggeredPanel(string id)
{
    UpdatePanel triggeredPanel = null;

    if (id != null)
    {
        triggeredPanel = this.NamingContainer.FindControl(id) as UpdatePanel;
    }

    if (triggeredPanel == null)
    {
        ResolveTriggeredPanelEventArgs e = new ResolveTriggeredPanelEventArgs(id);
        if (this.ResolveTriggeredPanel != null)
        {
            this.ResolveTriggeredPanel(this, e);
        }

        triggeredPanel = e.TriggeredPanel;
    }

    return triggeredPanel;
}

Oh, I've missed the ResolveUpdatePanelEventArgs class. Here it is:

public class ResolveTriggeredPanelEventArgs : EventArgs
{
    public string ID { get; private set; }

    public UpdatePanel TriggeredPanel { get; set; }

    public ResolveTriggeredPanelEventArgs(string id)
    {
        this.ID = id;
    }
}

Here we have finished the control. Let's see a simple demo of it. The following is the declarative code in aspx file:

<asp:UpdatePanel runat="server" ID="up1">
    <ContentTemplate>
        <%= DateTime.Now.ToString() %>
    </ContentTemplate>
</asp:UpdatePanel>

<ajaxExt:JavaScriptUpdater ID="Updater1" runat="server" MethodName="Refresh">
    <TriggeredPanels>
        <ajaxExt:TriggeredPanel UpdatePanelID="up1" />
    </TriggeredPanels>
</ajaxExt:JavaScriptUpdater>

<input type="button" onclick="UpdatePanels.Refresh()" value="Refresh" />

When we click the button, the UpdatePanel will be refresh without updating the whole page. Let's see the proxy code generated in client side:

The attachment is the source code of the JavaScriptUpdater control.

Refresh the UpdatePanel using JavaScript Code

2008-04-26T12:38:00Z

(It's the post I wrote one year ago in my previous blog which has been cancelled now.)

Lots of customers asked me that how to refresh the UpdatePanel - it actually is to raise an async postback using JavaScript code. The feature is quite important in some scenarios but unfortunately, ASP.NET AJAX does not give any native support, so we should find work arounds to do that.

An UpdatePanel will be refreshed if the user clicks the specific control in the page and the control is the trigger that raises the async postback. The straightest thought of raising an async postback is to simulate a button's clicking. There're several kinds of buttons in ASP.NET (we use the concept in ASP.NET rather than the concept in HTML since the server side konws ASP.NET better). They are Button, LinkButton, ImageButton, etc. Let's just look at the LinkButton control since it will shows the things we need. (I use an master page here to show the effect of NamingContainer.):

<asp:LinkButton ID="LinkButton1" runat="server">LinkButton</asp:LinkButton>


<a id="ctl00_Main_LinkButton1" href="javascript:__doPostBack('ctl00$Main$LinkButton1','')">
LinkButton
</a>

A LinkButton on server side generates an anchor tag on the page. The way to submit the form when click the anchor is to execute the JavaScript method "__doPostBack". Please note that it's really simple for us to simulate that. The only thing we should pay attention to is the first parameter passed to the method. What's that?

An experience ASP.NET programmer will easily figure out that a string separated by dollar signs ($) is most likely the UniqueID of the control, which is used to indicate the control at server-side, and then the proper event will be raised, etc. So, if we are going to simulate the postback raised by the LinkButton, its UniqueID shoud be write to clint side for further use.

I'm going to show you a demo here to tell the way discussed above. At first, we should build a page with an UpdatePanel and a invisible LinkButton in it. Please note that we set the style of the LinkButton to "display:none" rather than set its Visibile property to false, otherwise the LinkButton won't be rendered on the page, which will cause an exception when postback:

<asp:UpdatePanel ID="UpdatePanel1" runat="server">
    <ContentTemplate>
        <%= DateTime.Now %>
    </ContentTemplate>
</asp:UpdatePanel>
<asp:LinkButton ID="LinkButton1" runat="server" style="display:none;">
    LinkButton
</asp:LinkButton>

Secondly, write the following code to the page. You can find that we should write the UniqueID of the LinkButton to the client:

function raiseAsyncPostback()
{
__doPostBack("<%= this.LinkButton1.UniqueID %>", "");
}

The last thing to do is to make the LinkButton raising an async postback, so add the code to the code behind file:

ScriptManager.GetCurrent(this).RegisterAsyncPostBackControl(this.LinkButton1);

Now we can simply call the raiseAsyncPostBack method defined in the page when we want to raise an async postback using JavaScript code. Both the client and server will think the LinkButton is clicked. The client side will raise an async postback and the server will fire the Click event of the LinkButton. If we want to refresh some UpdatePanels when we execute the JavaScirpt method, we can just assign the LinkButton to the UpdatePanels as an AsyncPostBackTrigger.

LINQ to SQL Extension: Batch Deletion with Lambda Expression

2008-03-06T08:40:00Z

Batch deletion in the O/R Mapping frameworks is always depressing. We need to query all the entities we want to delete from the database, pass them to the DeleteOnSubmit or DeleteAllOnSubmit methods of DataContext, and finally invoke SubmitChanges to delete the records form database. In this case, we will cost an additional query and send lots of "DELETE" commands to database. How wasteful!

So if we want to make batch deletion with LINQ to SQL, we'll probably execute a SQL command in souce code:

ItemDataContext db = new ItemDataContext();
db.ExecuteCommand(
"DELETE FROM Item WHERE [CreateTime] < {0}",
DateTime.UtcNow.AddMonths(-1));

But in my opinion, it's ugly if we put SQL commands in source code. Ideally, the developers should focus on the business logics, data access logics or domain models, and the database operations are encapsulated by some other layers. In the days without O/R Mapping frameworks, we always defines Stored Procedures in databases and make calls in the source code. And finally we get O/R Mapping frameworks such as Hibernate and LINQ to SQL, so in most cases we could write code to query the database without dealing with SQL commands.

But batch deletion is one of the exceptions, as I said minutes ago. To avoid making batch deletion with SQL commands, I build an extension method for LINQ to SQL. Now we can delete the records from database with lambda expression:

ItemDataContext db = new ItemDataContext();
db.Items.Delete(item => item.CreateTime < DateTime.UtcNow.AddMonths(-1));

Of course, we could use more complicated expressions to indicate the entities to delete:

ItemDataContext db = new ItemDataContext();
db.Items.Delete(item =>
item.CreateTime < DateTime.UtcNow.AddMonths(-1) ||
item.ViewCount < item.CommentCount && item.UserName != "jeffz");

For the extensions I built for LINQ to SQL, most of them are based on DataContext. But now I extended the Table<TEntity> class. The implementation is not so difficult as I thought before I finish it. The key part of extending with LINQ/Lamba Expression is parsing the Expression Tree, but in this case, most of the expressions are binary expression and that's almost all of the extension - I just implemented the common used conditions. For instance, it doesn't support the expressions like "item.Introduction.Length < 10" and it should be converted to the use of LEN function in an completely implemented version.

The "Where Condition" in the SQL command converted from lambda expression is built in 3 steps, you can see the corresponding classes in the source code for more details:

Use PartialEvaluator class to replce the expressions which can be evaluated directly with the constant expressions indicated the calculated results (E.g., replace the expression "3 * 3" with the constant expression of "9", or replace the variables with the values of them).
Use ConditionBuilder class to collect all the constants in the expression tree as parameters for te SQL command, and generate the SQL where condition with the parameters' placeholders in it (E.g., "[CreateTime] < {0} AND [UserName] <> {1}").
Use DataContext.ExecuteCommand method to execute the whole SQL command with parameters and return the number of effected records.

Now we have the function of batch deletion but what about batch updating? Actually I'm working on it. I'm going to let the developers updating the records in the database like this:

ItemDataContext db = new ItemDataContext();
db.Items.Update(
    item => new Item
    {
        Introduction = item.Title + "Hello World",
        ViewCount = item.ViewCount + 1,
    }, // SET [Introduction] = [Title] + 'Hello World', ...
    item => item.CommentCount > 100 /* WHERE condition */);

For more details about the batch deletion extionsion please see the attachment.

Chinese version of this post

Giving rich styles to auto-complete feature using StyledAutoCompleteExtender

2008-03-04T02:15:00Z

Auto-complete is one of the key features in ajax style applications. As the most popular ajax toolkit for asp.net development, Ajax Control Toolkit provides AutoCompleteExtender control to build the feature without writing any JavaScript codes. The current version of AutoCompleteExtender is more powerful than before because that the user can input multiple words in the same text box by setting delimiter characters now. But it's still not so useful in some kinds of scenarios - in my opinion - since the control can only support plain text as the choices.

"How can we build the auto-complete feature like Google Suggest using AutoCompleteExtender?" The question like this has been asked times by the developers. The answser is "No, we can't" at the curent moment. But I've extended the AutoCompleteExtender to solve the problem.

The control I build which I called "StyledAutoCompleteExtender" extends the AutoCompleteExtender and the behavior class it uses on client-side extends the AutoCompleteBehavior. I keep most of the features the same as before to give the best compatibility. We can use the control just like the current AutoCompleteExtender and get the same result. But the new StyleAutoCompleteExtender control will accept a ItemTemplete value as the html template to display a single item. ItemTemplate gives us the flexibility to show the choices as the styles we want.

For example, we are building the auto-complete features like Google Suggest. What we should do first is to write the declarative code as following:

<asp:TextBox runat="server" ID="myTextBox" Width="400" style="margin:auto;"/>

<jeffz:StyledAutoCompleteExtender
    runat="server"
    BehaviorID="AutoCompleteEx"
    ID="autoComplete1"
    TargetControlID="myTextBox"
    ServicePath="AutoComplete.asmx"
    ServiceMethod="GetSearchCompletionList"
    MinimumPrefixLength="2"
    CompletionInterval="1000"
    EnableCaching="true"
    CompletionSetCount="10"
    CompletionListCssClass="completionListElement"
    CompletionListItemCssClass="listItem"
    CompletionListHighlightedItemCssClass="highlightedListItem"
    CompletionListElementID="Panel1">
    <ItemTemplate>
       <span style="float:left;" class="keywords">{0}</span>
       <span style="float:right;" class="result">{1} results</span>
       <div style="clear:both;"></div>
    </ItemTemplate>
</jeffz:StyledAutoCompleteExtender>

<asp:Panel ID="Panel1" runat="server"></asp:Panel>

Please focus on the ItemTemplate set in the AutoCompleteExtender. There're format parameters like "{0}" and "{1}" in it. It will be replaced by the value get from the method on server-side - I'll give more information of that later. Actuallly the value of ItemTemplate is the format string witch will be used as the paratemer of String.format() method so we can utilize the localization features in ASP.NET AJAX by setting format parameters as "{0:d}".

The values to replace the format item would be get from the web service method on server-side. Apparently, we'll probably get multiple values for a single chioces so the return type of the method should be modified. The following is web service method used for our "Google Suggest":

[WebMethod]
public IList<object[]> GetSearchCompletionList(string prefixText, int count)
{
    if (count == 0)
    {
        count = 10;
    }

    Random random = new Random();
    IList<object[]> items = new List<object[]>(count);
    for (int i = 0; i < count; i++)
    {
        char c1 = (char)random.Next(65, 90);
        char c2 = (char)random.Next(97, 122);
        char c3 = (char)random.Next(97, 122);

        items.Add(new object[]
        {
            prefixText + c1 + c2 + c3,
            random.Next(10000, 300000)
        });
    }

    return items;
}

The new method should return a list contains an array of objects. Each array will be used to display a single item of choices. The objects in the array will be used as the rest paramesters when calling String.format() method. Please note that if the method returns an array of string as before, the ItemTemplate set in the control would be ignored and everything will work like the traditional AutoCompleteExtender. The final result is just like the following image (the css style defined in the page has been omitted).

The most important modification of StyleAutoCompleteExtender is the separation of "the text to complete user's typing" and "the content in the choices". In the current version of StyledAutoCompleteExtender, the first object in the array for each choise will be selected as "the text to complete user's typing". That means the first object could be ignored in ItemTemplate if necessary. The following sample is to simulate the email selection when using Windows Live Mail. Please note that the real feature is purely implemented on client-side but we're using StyleAutoCompleteExtender, which will get the choises from server-side.

Here're the defined css styles and the declarative code:

.completionListElement
{
    visibility : hidden;
    margin : 0px! important;
    background-color : inherit;
    color : black;
    border : solid 1px gray;
    cursor : pointer;
    text-align : left;
    list-style-type : none;
    font-family : Verdana;
    font-size: 11px;
    padding : 0;
}
.listItem
{
    background-color: white;
    padding : 1px;
}
.highlightedListItem
{
    background-color: #c3ebf9;
    padding : 1px;
}

<asp:TextBox runat="server" ID="myTextBox" Width="500" style="height:14px;
    border: solid 1px gray; font-family:Verdana; font-size: 11px;" />

<jeffz:StyledAutoCompleteExtender
    runat="server"
    BehaviorID="AutoCompleteEx"
    ID="autoComplete1"
    TargetControlID="myTextBox"
    ServicePath="AutoComplete.asmx"
    ServiceMethod="GetEmailCompletionList"
    MinimumPrefixLength="2"
    CompletionInterval="1000"
    EnableCaching="true"
    CompletionSetCount="10"
    CompletionListCssClass="completionListElement"
    CompletionListItemCssClass="listItem"
    CompletionListHighlightedItemCssClass="highlightedListItem"
    DelimiterCharacters=",;">
    <ItemTemplate>{1}</ItemTemplate>
</jeffz:StyledAutoCompleteExtender>

And here's the corresponding web service method. Please note that each item in the list is an array with 2 elements. The first one is the text would be set in the textbox and second one is the html string for a single choise.

private static string[] s_emails = new string[]
{
    "\"jeffrey zhao at yahoo\" <jeffz@yahoo.com>",
    "\"jeffrey zhao at yahoo china\" <jeffz@yahoo.com.cn>",
    "\"jeffrey zhao at live mail\" <jeffz@live.com>",
    "\"jeffrey zhao at gmail\" <jeffz@gmail.com>"
};

[WebMethod]
public IList<object[]> GetEmailCompletionList(
    string prefixText, int count)
{
    IList<object[]> items = new List<object[]>();

    prefixText = prefixText.Trim();
    foreach (string email in s_emails)
    {
        if (email.Contains(prefixText))
        {
            string encoded = email.Replace(
                prefixText, "<b>" + prefixText + "</b>");
            items.Add(new object[]
            {
                HttpUtility.HtmlDecode(email) + ";",
                encoded
            });
        }
    }

    return items;
}

Since we have set the DelimiterCharacters property int the control we can type multiple words in the textbox. The final result is showing in the following image.

The implementation of StyleAutoCompleteExtender is not so complex as I thought before and I'll explain it in another post. The attachment is the code of the control with two samples. Please feel free to contract me if you found problems and any suggestions would be better. :)

IE will be stuck when requests too much? Fake the XHR!

2008-02-21T15:37:00Z

It's one of the articles I wrote in CodeProject, click here to read the original one.

Introduction

Months ago, a friend of mine, who is a also a consultant and trainer, told me that one of his customers met a problem. IE will be stuck when too many connections have been set up in the page at the same time. The problem is becoming more and more popular since AJAX technology has been widely used these days. When an AJAX application is composed of smaller ones - that we call it "mash up" - the problem will be likely to occur.

It's a bug in Internet Explorer. When you make a lot of AJAX calls, the browser keeps all the requests in a queue and executes two at a time. So, if you click on something to try to navigate to anthoer page, the browser has to wait for running calls to complete before it can take another one. The bug is quite serious in IE 6 and unfortunately, it still exists in IE 7.

Manage the requests programically

The solution is simple. We should maintain the queue ourselves and send requests to the browser's queue from our queue one by one. Thus I wrote a queue to manage the requests. It's really a piece of cake:

if (!window.Global)
{
    window.Global = new Object();
}

Global._ConnectionManager = function()
{
    this._requestDelegateQueue = new Array();
    this._requestInProgress = 0;
    this._maxConcurrentRequest = 2;
}

Global._ConnectionManager.prototype =
{
    enqueueRequestDelegate : function(requestDelegate)
    {
        this._requestDelegateQueue.push(requestDelegate);
        this._request();
    },

    next : function()
    {
        this._requestInProgress --;
        this._request();
    },

    _request : function()
    {
        if (this._requestDelegateQueue.length <= 0) return;
        if (this._requestInProgress >= this._maxConcurrentRequest) return;

        this._requestInProgress ++;
        var requestDelegate = this._requestDelegateQueue.shift();
        requestDelegate.call(null);
    }
}

Global.ConnectionManager = new Global._ConnectionManager();

I build the component names ConnectionManager using pure JavaScript code without any dependence on any AJAX/JavaScript framework/library. If users want to use this component to manage the request, they should use enqueueRequestDelegate method to put an delegate into the queue. The delegate will be executed when there's no or only one request is running in the browser. And after receiving the response from the server, the user must call the next method to notify the ConnectionManager, and then the ConnectionManager will execute the next pending request delegate if the queue is not empty.

For example, if we are using Prototype framework to make ten AJAX calls continuously:

And we'll use the ConnectionManager to queue the requests as following:

Please note that we assign the next method to both the onFailure and onException callback handlers to guarantee that it will be called after receiving the response from the server, since the rest delegate in the queue will be failed to execute and the system cannot raise a new call anymore if the next method hasn't been executed.

I send the file to my friend and serveral days later he told me that his customer said the component is hard to use. I agreed. It's really verbose and error prone. Apparently the ConnectionManager is not so convenient to be integrated into the existing codes. The devs must make sure that all the requests should be queued in ConnectionManager and the next method must be executed in any case when the request finishes. But it's far from enough yet. More and more AJAX applications will execute scripts created by the server. Perhaps the dynamically created file cannot be loaded successfully if the internet connection of client side is not stable enough. At that time, the scripts execution throws exceptions and the next method which should be executed by design will probably be missed.

Build a fake XMLHttpRequest type

I got an idea after days of thinking. That will be perfect if we can use another component to replace the native XMLHttpRequest object and provide the build-in request queue. If so, devs can solve the problem by putting the script file in the page without changing a single line of code.

The solution is much easier than I thought before and now I'm going to show you how to build it.

The first thing we should do is to keep the native XHR type. Please note that the follow code has solved the compatibility problem of XHR in different browsers.

And then, we should create a new class to replace the native XHR type. Most of the methods are just delegated to the corresponding one in the native object.

The key points are the implementations of the send method and _internalOnReadyStateChange method. The send method will put a delegate of the native XHR type's method into the queue. The delegate will be executed by the ConnectionManager at a proper time.

send : function(body)
{
    var requestDelegate = this._createDelegate(
        this,
        function()
        {
            this._xmlHttpRequest.send(body);
            this.readyState = this._xmlHttpRequest.readyState;
        });

    Global.ConnectionManager.enqueueRequestDelegate(requestDelegate);
},

We assign the _internalOnReadyStateChange method as the onreadystatechange callback handler of the native XHR object in the constructor. When the callback function raises, we'll keep all the native properties into our object and execute our onreadystatechange handler. Please note that our new component take the responsibility of executing the next method of ConnectionManager when the readyState equals to 4, which means the current request is "completed", so that the next method can been executed automatically from the devs' point of view.

_internalOnReadyStateChange : function()
{
    var xmlHttpRequest = this._xmlHttpRequest;

    try
    {
        this.readyState = xmlHttpRequest.readyState;
        this.responseText = xmlHttpRequest.responseText;
        this.responseXML = xmlHttpRequest.responseXML;
        this.statusText = xmlHttpRequest.statusText;
        this.status = xmlHttpRequest.status;
    }
    catch(e){}

    if (4 == this.readyState)
    {
        Global.ConnectionManager.next();
    }

    if (this.onreadystatechange)
    {
        this.onreadystatechange.call(null);
    }
},

We have tried our best to let the new component behaves as the same as the native XHR type. But it still exists an little thing we can't do it. When we access the status property in the native XHR object, an error would be thrown if the object cannot recieve the headers from server side. But in IE, we can't define the object's property as a method like using __setter__ keyword in FireFox. It's the only difference between the native XHR type and our new one when use the two components.

How to use

And now, we can easily reference the js file in the page to solve the problem when the user browses the page using IE.

I sent the script files (see attachment) to my friend. It seems that his customer is quite pleased with this solution.