Ext.NET Web Application Development: If you're looking to build .NET based rich internet applications, look no further. This is the ideal primer that takes you step by step through the practical aspects of combining Ext.NET and Ext JS, and much more.

A great thing about Ext.NET is that it works with both ASP.NET Web Forms and ASP.NET MVC. If you are integrating Ext.NET into a legacy application built with ASP.NET Web Forms, or if you simply prefer ASP.NET Web Forms, Ext.NET will work very well and provide enhanced HTML5 functionality.

The newer ASP.NET MVC framework is a powerful and well-architected MVC framework, designed to avoid the Post Back model that ASP.NET Web Forms is based on and allow better access for developers to the underlying HTML, JavaScript, and CSS.

The choice of using ASP.NET MVC or Web Forms is not important for the scope of this book. Examples of both will be shown from time to time, though most of these will be based on ASP.NET Web Forms.

Many ASP.NET developers, especially those using ASP.NET MVC may be more familiar with jQuery or other JavaScript frameworks. It is, therefore, worth explaining Ext JS a bit further.

If you are used to creating ASP.NET applications using ASP.NET controls or using vendor controls that follow ASP.NET controls closely (for example, using the Post Back model where most of the control state is maintained on the server via ViewState) then Ext.NET may initially appear quite similar, but behind the scenes, there are some useful enhancements and considerations, for example:

It is worth focusing on the point about ViewState for a moment. In a traditional ASP.NET Web Forms application, ViewState and the associated Post Back Model are the keys to recreating complex controls in the state the user expects them to be. With Ext.NET's approach, however, control state does not typically need to be maintained on the server; this usually flies against conventional ASP.NET Web Forms applications, but rich Internet applications are becoming more and more AJAX-oriented, which means less (sometimes no) browser page reloads. As such, the control state management normally associated with page reloads and post backs is less prominent and helps simplify code.

For the client side, Ext.NET's JavaScript and the underlying Ext JS framework handles most complexities of control management such as instantiation, destruction, layout management, and redrawing components. This also means the client-side code needed to maintain the state is also very minimal, if anything; Ext JS components will handle most of the internal state for you and if you need more, the API is flexible enough for you to introduce your own code as needed.

Because Ext.NET uses Ext JS's built-in AJAX capabilities, mixing different server-side toolkits—while not impossible—can limit the flexibility and performance you can get out of Ext.NET. For example, if you have a mix of components on your page, and the other non-Ext.NET components rely on ASP.NET Web Form's Post Back and ViewState, Ext.NET will still work with that, but you won't be able to take advantage of some of Ext.NET's more sophisticated capabilities, as frequently.

At the same time as being a complete UI framework, you can always by-pass Ext.NET on the server side and do something directly using Ext JS or Ext.NET's own JavaScript, if that proves more optimal. This flexibility makes the Ext.NET server-side abstraction more flexible and less "leaky".

From an ASP.NET development perspective, the main thing to take away is that as powerful as ASP.NET is, Ext.NET enhances and integrates client and server coding much more completely and gives you the flexibility to get your hands dirty with JavaScript, if you so wish.

With Ext.NET's integration of Ext JS the versions are important to understand.

The latest version of Ext JS, as of writing, is 4.1. It is an impressive evolution of the previous version (Ext JS 3.4) which is still widely used.

Ext.NET targets specific Ext JS versions:

This is important to note if ever consulting the Ext.NET or Ext JS documentation online.

Ext.NET 2 will work with the following:

In this book, code examples will be created using Visual Studio 2010 Service Pack 1 and .NET Framework 4.

Ext JS and Ext.NET support all the major modern browsers such as Chrome, Firefox, IE9, Opera, and Safari) as well as older versions of Internet Explorer (also referred to as IE)—IE8, IE7, and IE6. As of writing, IE10 has only just come out, so is not officially supported, but we can expect both Ext.NET and Ext JS to provide maintenance releases to support IE10, as they have done with IE9 in the past.

With all the benefits that Ext.NET may offer, why might you consider not using it?

The following points are just guidelines as there will always be exceptions, but the main consideration is that Ext.NET is based on Ext JS, which is a JavaScript framework.

If you have a website where search engine visibility is crucial, progressive enhancement is important, and full control over every bit of HTML and CSS is important, Ext JS (and therefore Ext.NET) may not be for you. This may include public-facing consumer websites such as blogs and e-commerce sites. You can certainly use Ext JS (and Ext.NET) on these sites, but it would not be the main or intended use cases.

However, if you are building complex applications, such as business/intranet applications or a public-facing site where JavaScript dependency can be an accepted pre-requisite, then Ext JS/Ext.NET can be an excellent choice.

If you are looking to build a sophisticated application, the user interface, the usability, and interaction design principles may also differ to what you would follow for websites. There is certainly a lot of overlap, but additional principles such as those described in the authoritative About Face 3: The Essentials of Interaction Design by Alan Cooper et al is highly recommended.

The first thing to note is that Ext.NET is dual licensed and you can choose between the following:

The differences between the two are very minimal. In the Ext.NET Pro release there is an option to render resources (JavaScript, CSS, and images) from a global Content Delivery Network. The Community version does not have this option. The Pro version also does some license checking. Other than that, the code is the same.

If your own project is licensed with the AGPL license, then you can use the Community license. If you are producing a closed source project, then you should purchase an Ext.NET Pro license. The Pro license includes a license to the underlying Ext JS framework so you do not have to purchase both. The Pro license also comes with a license key that can be added to Web.config or Global.asax without which you would see a message appearing on any web pages that are not running locally. This message warns about the software being unlicensed. The FAQs at Ext.NET's download page, http://ext.net/download/, has further details and can help you decide which license is suitable for your project.

There are a number of ways you can download Ext.NET:

From the Ext.NET download site: http://ext.net/download/

All these options, except the NuGet option, include the full source code so you can choose whether to build the solution yourself or use the supplied assemblies. Downloading the source code is useful to at least explore how Ext.NET has been put together. The SVN option will include a pre-release source code if you want bug fixes more quickly than official releases.

NuGet is a popular Visual Studio extension to manage packages for you and will install the Ext.NET binaries to your web project's bin folder. The download from Ext.NET is a ZIP file. The DLLs that you will find are as follows:

Json.NET is itself a popular open source .NET library for working with JSON. It is extremely effective at serializing .NET into JSON and deserialization from JSON to .NET. So much so that Microsoft itself has started using it instead of some of its own JSON serializers. More information about Json.NET can be found at its website: http://james.newtonking.com/pages/json-net.aspx.

In addition to the DLLs, the following text files are also available and worth reading:

If you have opted for the Ext.NET Premium Support Subscription service, amongst other benefits, you get access to their latest source code. So, for example, any bug fixes or feature requests reported by you or others in the community that have recently been implemented are available immediately for you to compile and use.

If you go for this option, Ext.NET will send you instructions on how to connect to the public SVN code repository to download the latest code. You can then open the Visual Studio solution file and compile the code manually. If you then look in the Ext.Net project's bin\Debug or bin\Release directory (depending on which mode you want) you will find the same DLLs as above.

You can then include the output assemblies in your own solution. This means you do not need to compile their source code every time you compile your own solution; only when you update your local Ext.NET code from their SVN repository.

The quickest way to get going in just a few seconds is to use NuGet. First, ensure you have the latest version of NuGet installed and then perform the following steps:

Following the above steps, the project will include a new page called Ext.NET.Default.aspx.

Right-click on the file and select View in Browser and you will see a page similar to the following:

The above page renders a simple Ext.NET Window in the center of the page with a message textbox.

But it is not a static page; go ahead, type a short message, and click on Submit.

An AJAX request will be made to the server and a message notification will slide up from the lower-right side of the browser window, then slide-out and disappear after a few seconds:

This very simple example does many things for you

The code for the sample page is quite minimal. Here is the full ASPX code:

<%@ Page Language="C#" %>

<script runat="server">
    protected void Button1_Click(object sender, DirectEventArgs e)
    {
        X.Msg.Notify(new NotificationConfig { 
            Icon  = Icon.Accept,
            Title = "Working",
            Html  = this.TextArea1.Text
        }).Show();
    }
</script>

<!DOCTYPE html>
<html>
<head runat="server">
    <title>Ext.NET Example</title>
</head>
<body>
    <form runat="server">
        <ext:ResourceManager runat="server" Theme="Gray" />

        <ext:Window
            runat="server" 
            Title="Welcome to Ext.NET 2.1"
            Height="215"
            Width="350"
            BodyPadding="5"
            DefaultButton="0"
            Layout="AnchorLayout"
            DefaultAnchor="100%">
            <Items>
                <ext:TextArea
                    ID="TextArea1" 
                    runat="server" 
                    EmptyText=">> Enter a Message Here <<"
                    FieldLabel="Test Message" 
                    Height="85" 
                    />
            </Items>
            <Buttons>
                <ext:Button
                    runat="server" 
                    Text="Submit"
                    Icon="Accept" 
                    OnDirectClick="Button1_Click" 
                    />
            </Buttons>
        </ext:Window>
    </form>
</body>
</html>

The key things happening in the preceding code are as follows:

The X class contains many Ext.NET utilities and properties.

All the components and techniques used in the above code will be expanded upon in subsequent chapters. A key thing to note at this point is that overall, this looks much like a regular ASP.NET button-click handler in terms of the code you write. However, the significant difference is that this is not doing a full page post back; it is a light-weight AJAX request, with an even lighter AJAX response.

Here is the full response from the server to the browser:

{script:"Ext.net.Notification.show({title:\"Working\",html:\"Hello World!\",iconCls:\"#Accept\"});"}

It is just 100 bytes of JSON which Ext.NET's JavaScript will handle and process for you. Had this been an ASP.NET traditional post back, the response would have been a full HTML page. In a real application these kinds of responses can save a lot of server resources and improve the user experience considerably.

Let's take moment to go back to the project we created and see what other project artifacts we now have after the NuGet package installed Ext.NET for us.

In addition to creating Ext.NET.Default.aspx, the only other things that were done to the project were the following:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="extnet" type="Ext.Net.GlobalConfig" requirePermission="false" />
  </configSections>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
    <httpHandlers>
      <add path="*/ext.axd" verb="*" type="Ext.Net.ResourceHandler" validate="false" />
    </httpHandlers>
    <httpModules>
      <add name="DirectRequestModule" type="Ext.Net.DirectRequestModule, Ext.Net" />
    </httpModules>
  </system.web>
  <extnet theme="Default" />
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules>
      <add name="DirectRequestModule" preCondition="managedHandler" type="Ext.Net.DirectRequestModule, Ext.Net" />
    </modules>
    <handlers>
      <add name="DirectRequestHandler" verb="*" path="*/ext.axd" preCondition="integratedMode" type="Ext.Net.ResourceHandler" />
    </handlers>
  </system.webServer>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
        <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="4.5.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

<extnet theme="Default" />

<pages>
  <controls>
    <add tagPrefix="ext" namespace="Ext.Net" assembly="Ext.Net"/>
  </controls>
</pages>

To get MVC support, there is a similar NuGet package, called Ext.Net.MVC. So, you can follow the earlier steps, but instead do the following:

The changes will be the same as before. Web.config will be updated for you as needed, and Global.asax will have an additional route registered to handle Ext.NET resources.

To get a feel of how Ext.NET looks in MVC/Razor, here is a similar example as earlier, but using the MVC/Razor syntax. First, the View:

<!DOCTYPE html>
<html>
<head>
    <title>Ext.NET Example</title>
</head>
<body>    
    @Html.X().ResourceManager().Theme(Theme.Gray)

    @(Html.X().Window()
        .Title("Welcome to Ext.NET 2.1")
        .Height(215)
        .Width(350)
        .Layout(LayoutType.Fit)
        .Items(Html.X().FormPanel()
            .Layout(LayoutType.Anchor)
            .DefaultAnchor("100%")
            .Border(false)
            .BodyPadding(5)
            .Items(Html.X().TextArea()
                .ID("message")
                .EmptyText(">> Enter a Message Here <<")
                .FieldLabel("Text Message")
                .Height(85)
            )
            .Buttons(
                Html.X().Button()
                    .Text("Submit")
                    .Icon(Icon.Accept)
                    .DirectClickAction("Notify", "ExtNET")
            )
        )
    )
</body>
</html>

And next, the Controller:

using System.Web.Mvc;
using Ext.Net;
using Ext.Net.MVC;
using Controller = System.Web.Mvc.Controller;

namespace ExtNet2Mvc.Controllers
{
    public class DirectEventExampleController : Controller
    {  
      //
      // GET: /DirectEventExample/
      public ActionResult Index()
      {
          return View();
      }
      //
      // GET: /DirectEventExample/Notify/
      public ActionResult Notify(string message)
      {
          var config = new NotificationConfig
          {
              Icon = Icon.Accept,
              Title = "Working",
              Html = message
          };

          X.Msg.Notify(config).Show();

          return this.Direct();
       }
    }
}

The code does the same thing as the ASP.NET Web Forms example, earlier. We have defined two actions in the same controller. The Index, or default action when browsing /DirectEventExample/ will simply return the View. The View creates the same components as before, but using Razor syntax and Ext.NET's MVC helper methods.

The button's Click DirectEvent is slightly different; the associated controller action, Notify, takes a string parameter. To set that parameter, the Click DirectEvent adds it as an extra parameter getting the value via a small bit of client-side JavaScript code (which gets the value of the client-side representation of the text area).

To handle the event on the server side, the Notify action creates an Ext.NET Notification object and shows it. The Direct() method generates a DirectResult which is a subclass of ActionResult. It is a class created by Ext.NET and handles the script generation so that the Notification object appears on the user's browser.

These techniques will, of course, be expanded upon in this book, so don't worry about the inner workings in too much detail for now! The key points to take away for MVC Razor is that it generally follows the standard ASP.NET MVC Razor patterns and Ext.NET components come with their own helper methods to help configure the controls as needed. There will be additional features specific to MVC that Ext.NET is building even as this book goes to print so there will be more capabilities to expect that cannot be covered in this book, including Data Annotations support, Model Binding support, specialized Ext.NET action results, and more.