As mentioned on Ext.NET's official website (http://ext.net):
Ext.NET is an open source ASP.NET (WebForm + MVC) component framework integrating the cross-browser Sencha Ext JS JavaScript Library.
Sencha's official website (http://www.sencha.com/products/extjs/) describes Ext JS (pronounced eee-ecks-tee) as a JavaScript framework for rich apps in every browser.
In other words, Ext.NET is an ASP.NET framework, or a set of controls and classes, that typically generates JavaScript (though HTML and CSS are generated wherever needed). And, the JavaScript it generates is based on the Ext JS framework, from Sencha.
Ext.NET also includes components that are not found in Ext JS, and extends various Sencha Ext JS classes wherever needed, thus providing its own JavaScript layer on top of Ext JS.
Ext.NET is a good abstraction over Ext JS. The abstraction is not leaky or restrictive—you can also write Ext JS-based JavaScript directly, as well as in conjunction with Ext.NET. This flexibility importantly allows you to tap into the wider Ext JS community of plugins and components that you might want to incorporate into your Ext.NET applications.
This means that knowing the underlying Ext JS library can really help you understand Ext.NET, and will open you to more options when building complex applications.
The other way of thinking about it is that Ext.NET is a great bridge between Ext JS on the client side and ASP.NET on the server side.
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.
Although Ext JS is a reasonably popular JavaScript framework (especially in the enterprise and in the Java world), there are other more popular JavaScript frameworks, such as the excellent jQuery.
However, as popular as jQuery may be (Microsoft includes it by default in their MVC framework, for example), there is a significant difference between Ext JS and libraries such as jQuery, Prototype, and MooTools.
Libraries such as jQuery attempt to solve common problems for web developers and designers by providing cross-browser compatible ways to navigate and manipulate the DOM. They provide standard event, AJAX and other capabilities. Their UI components, such as jQuery UI are typically designed to work in a progressive enhancement way (i.e. the web page will work with and without JavaScript; JavaScript in that context, when structured properly, is used to enhance the base functionality of a web document to add further behavior and improved user experience, but the absence of JavaScript allows search engines and users of lower-grade browsers to still access the page and use it).
Ext JS's goal, however, is to provide a complete UI framework for building complex web-based applications. Ext JS also provides a full and extensible object-oriented UI component framework, in addition to providing cross-browser abstractions in the similar ways that other JavaScript frameworks do. (Ext.NET mimics this component hierarchy on the server side quite closely, which makes for easier learning of both frameworks).
In that regards, it is more appropriate to compare jQuery UI with Ext JS, and in that context, Ext JS is far richer in capability.
All that being said, the use of Ext JS—and, therefore, Ext.NET—does not preclude the use of other frameworks. For example, you can include jQuery on the same page as an Ext.NET application.
Progressive enhancement and web standards are excellent principles for building websites. However, Ext JS is not about progressive enhancement. The problem space it addresses is different; it is intended for much richer applications where a dependency on JavaScript can be mandated. A back-office application in a corporate or intranet setting is one example. Another may be a public application but where search engine visibility is not required. In such scenarios typically, JavaScript is the starting point for the application; the HTML-based web page then becomes a container to load and initialize the JavaScript-based application.
It is possible to use Ext JS on top of HTML and get it to replace say an HTML table with a powerful Ext JS grid, but that is not considered the optimal way to use Ext JS.
All is not lost from a web standards perspective, however! You should still test on modern browsers, such as Chrome, Firefox, and Opera, first and then work backwards. It is well established that this way of working with web technologies will reduce (though not eliminate) the number of workarounds you need for older web browsers, in a maintainable way. For many components, Ext JS and Ext.NET will also let you override the underlying HTML it uses to generate its components. In addition, Ext JS is also increasing its HTML5 and ARIA accessibility standards support in its numerous widgets.
From a CSS point of view, complete themes are provided. These also include resets of default styles to normalize them across browsers as much as possible. The default themes may be quite suitable for many Ext JS-based applications, which also means less time may be required working with CSS on Ext.NET-based applications. You can also create your own themes but this will be beyond the scope of this book. You can find various tutorials on the Web, as well as on Sencha's official website.
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:
ViewState is typically not required for Ext.NET controls and is turned off by default (but is on if you use FormsAuthentication, which requires it). This can save a lot of bandwidth. In one case, a roughly 1.5 MB page (mostly due to ViewState) during an AJAX request became a mere 500 bytes using one of Ext.NET's AJAX approaches.
An ASP.NET Web Forms application requires a single ASP.NET
<form runat="server">, which contains all the controls, ViewState, event arguments, and so on. With Ext.NET it is optional as later chapters will show. Furthermore, you can choose to have multiple HTMLformtags if you require and Ext.NET will happily work with that.When normally developing ASP.NET applications, you add controls to the container's
Controlscollection. With Ext.NET, you typically add child Ext.NET controls to an Ext.NET component'sItemscollection. This is important to bear in mind. This helps generate more optimized Ext.NET JavaScript and lets you take advantage of additional Ext.NET features such as Layout which we will see in Chapter 3, Layout with Ext.NET.
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:
Ext.NET 1.x works with Ext JS 3.x
Ext.NET 2.x works with Ext JS 4.x
Note
This book covers Ext.NET 2.1 which is the latest version as of writing. However, note that the Ext.NET team works to produce updates as frequently as they can. If Ext.NET 2.2 or later has been produced, most principles and techniques from this book will still apply.
This is important to note if ever consulting the Ext.NET or Ext JS documentation online.
Ext.NET 2 will work with the following:
Visual Studio 2010 or 2012
Visual Web Developer Express 2010 or 2012
.NET Framework 4.0 and 4.5
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.
Note
Keep an eye on the Ext.NET website, http://ext.net, because new versions of the .NET framework and Visual Studio are being released as of writing, and browser manufacturers are frequently releasing newer versions of their software.
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.