New Features in ASP.NET AJAX 4
New Features in ASP.NET AJAX 4
Note The documentation in this section concerns ASP.NET 4 AJAX Preview 4. A more recent preview release might be available at the URL above. If so, it will include updated documentation.
The new functionality in ASP.NET AJAX enables new client data scenarios for page and component developers that enable JSON data from the server to be rendered as HTML in a highly manageable and efficient way. To enable these scenarios, ASP.NET AJAX includes the following major features:
· Client-side template rendering.
· Declarative instantiation of client-side behaviors and controls.
· Live data binding.
· Use of the observer pattern with JavaScript types.
· An AdoNetServiceProxy class for client-side interaction with ADO.NET Data Services.
· A client-side DataView control for data-bound UI in the browser.
· DataContext and AdoNetDataContext classes for interaction with Web services.
· Refactored ASP.NET AJAX framework libraries.
· Support for the DOM Ready event.
· Using JSONP to retrieve cross-domain data.
Client Template Rendering
In client-based development, templates are the most manageable way of creating UI from data. ASP.NET AJAX 4 includes a new template engine for client development that meets the following requirements:
· Performance — The engine must be able to render a typical number of items using a reasonably complex template before users perceive an interruption in their interaction with the application.
· Simplicity — The template syntax must be very readable and must be optimized for the most common scenario, namely one-way/one-time binding.
· Expression language — Templates must support an expression language to go beyond the simplest cases. The expression language should use familiar syntax, ideally JavaScript syntax.
· Interspersed code and markup — It must be possible to perform conditional rendering or to loop over markup by using code that surrounds HTML.
· Components — When using the template syntax, the developer must be able to instantiate client-side controls and behaviors that attach to HTML elements in the page or within templates.
Template Example
The following example shows a typical client template that you can create using ASP.NET AJAX 4.
<ul id="myTemplate" class="sys-template"
sys:attach="dataview"
>
<li>
<h3>{{ Name }}</h3>
<div>{{ Description }}</div>
</li>
</ul>
The class attribute of the outer div element is set to sys-template, which is a convention that is used in order to hide the initial template from the user. You should define this class in your CSS style sheet as {display:none;}.
When the template is rendered, it has a data item as context. Fields or properties of that data item can be included in the template markup by using {{ }} expressions — for example, {{ Name }}, if the data item has a Name field. These expressions can be placed anywhere in text content, or you can use them as the value of an attribute. In addition to fields or properties, the expression blocks can also contain any JavaScript expression that can be evaluated as a string.
You can set up DOM events by using the $addHandler method. The DOM on* attributes of elements (for example, onclick=method) also work from within templates.
Instantiating a Template by Using the DataView Control
The most convenient way to use client templates in ASP.NET AJAX 4 is through the DataView control. The content of a DataView control is used as a template that renders the data item that is provided to the control. If you set the DataView control's data property to an array, the template is rendered once for each item in the array. The DataView control binds to live data, meaning that the control is automatically updated when the data changes, without the need to rebind. This provides a dynamic data-driven UI in the browser. The following example shows the declarative markup for a DataView control that binds to an array named imagesArray.
<body xmlns:sys="javascript:Sys"
xmlns:dataview="javascript:Sys.UI.DataView"
sys:activate="*">
<ul sys:attach="dataview" class="sys-template"
dataview:data="{{ imagesArray }}"
>
<li>
<h3>{{ Name }}</h3>
<div>{{ Description }}</div>
</li>
</ul>
</body>
Instantiating a Template by Using Code
You can also create a compiled template from code by using the Sys.UI.Template class, as shown in the following example:
var t = new Sys.UI.Template($get("myTemplate"));
The constructor takes the parent element of the template as its argument. You can then render a compiled template into the DOM by calling its instantiateIn method and specifying an HTML container element and a data item as context. The following example shows how to do this.
t.instantiateIn(
$get("targetContainer"),
{
Name: "Name",
Description: "Description"
}
);
Using Pseudo-Columns in a Template
In addition to providing access to fields and properties of the data item, the template rendering engine also provides access to pre-defined "pseudo-columns" such as $index and $dataItem. These pseudo-columns give you access to values from the rendering engine at render time. You can use pseudo-columns the way you use any JavaScript variable in the template instance. The first example applies a different CSS class to the div element for alternating items that are rendered by the dataView control. The second examples passes the pseudo-column $dataItem, which represents the data for the current row, to a custom function named nameConvert for processing.
<div class:alternateitem="{{$index%2 == 1}}">
<span>{{nameConvert($dataItem)}}</span>
Incorporating Code into a Template by Using the code:if, code:before, and code:after Attributes
You can add the new code:if, code:before, and code:after declarative attributes to any DOM element within a template in order to render the element conditionally (code:if) or to render arbitrary code before (code:before) or after (code:after) the element. The following example shows how to use the code:If attribute to render an hr element as a separator between items. The code:if attribute uses the value of the $index pseudo-column to ensure that the hr element is rendered only between items, and not before the first one or after the last one.
<ul id="myTemplate" class="sys-template">
<li>
<hr code:if="$index!==0" />
<h3>{{ Name }}</h3>
<div>{{ Description }}</div>
</li>
</ul>
Posted in: asp.net | Tags: asp.net asp.net 4.0 performance feature asp.net ajax ajax dataview adonetdatacontext datacontext rendering simplicity template examplenew in Dynamic Lookup, C# 4.0
Dynamic lookup allows you a unified approach to invoking things dynamically. With dynamic lookup, when you have an object in your hand you do not need to worry about whether it comes from COM, IronPython, the HTML DOM or reflection; you just apply operations to it and leave it to the runtime to figure out what exactly those operations mean for that particular object.
This affords you enormous flexibility, and can greatly simplify your code, but it does come with a significant drawback: Static typing is not maintained for these operations. A dynamic object is assumed at compile time to support any operation, and only at runtime will you get an error if it wasn’t so. Oftentimes this will be no loss, because the object wouldn’t have a static type anyway, in other cases it is a tradeoff between brevity and safety. In order to facilitate this tradeoff, it is a design goal of C# to allow you to opt in or opt out of dynamic behavior on every single call.
The dynamic type
C# 4.0 introduces a new static type called dynamic. When you have an object of type dynamic you can “do things to it” that are resolved only at runtime:
dynamic d = GetDynamicObject(…);
d.M(7);
The C# compiler allows you to call a method with any name and any arguments on d because it is of type dynamic. At runtime the actual object that d refers to will be examined to determine what it means to “call M with an int” on it.
The type dynamic can be thought of as a special version of the type object, which signals that the object can be used dynamically. It is easy to opt in or out of dynamic behavior: any object can be implicitly converted to dynamic, “suspending belief” until runtime. Conversely, there is an “assignment conversion” from dynamic to any other type, which allows implicit conversion in assignment-like constructs:
dynamic d = 7; // implicit conversion
int i = d; // assignment conversion
Dynamic operations
Not only method calls, but also field and property accesses, indexer and operator calls and even delegate invocations can be dispatched dynamically:
dynamic d = GetDynamicObject(…);
d.M(7); // calling methods
d.f = d.P; // getting and settings fields and properties
d[“one”] = d[“two”]; // getting and setting thorugh indexers
int i = d + 3; // calling operators
string s = d(5,7); // invoking as a delegate
The role of the C# compiler here is simply to package up the necessary information about “what is being done to d”, so that the runtime can pick it up and determine what the exact meaning of it is given an actual object d. Think of it as deferring part of the compiler’s job to runtime.
The result of any dynamic operation is itself of type dynamic.
Example
Assume the following code:
dynamic d1 = new Foo();
dynamic d2 = new Bar();
string s;
d1.M(s, d2, 3, null);
Because the receiver of the call to M is dynamic, the C# compiler does not try to resolve the meaning of the call. Instead it stashes away information for the runtime about the call. This information (often referred to as the “payload”) is essentially equivalent to:
“Perform an instance method call of M with the following arguments:
1. a string
2. a dynamic
3. a literal int 3
4. a literal object null”
At runtime, assume that the actual type Foo of d1 is not a COM type and does not implement IDynamicObject. In this case the C# runtime binder picks up to finish the overload resolution job based on runtime type information, proceeding as follows:
1. Reflection is used to obtain the actual runtime types of the two objects, d1 and d2, that did not have a static type (or rather had the static type dynamic). The result is Foo for d1 and Bar for d2.
2. Method lookup and overload resolution is performed on the type Foo with the call M(string,Bar,3,null) using ordinary C# semantics.
3. If the method is found it is invoked; otherwise a runtime exception is thrown.
Posted in: programming | Tags: example dynamic c# 4.0 dynamic lookup lookup dynamic type getdynamicobject dynamic operations