Changes in ajax 4.0 Preview 5

Declarative Attribute Changes

It is no longer necessary to include a sys:activate attribute on the body of a page containing declarative markup.

The attributes used in declarative markup have been modified slightly to minimize the number of namespaces used, and to minimize cross browser issues with some html attributes.

1. All attributes that contain an expression (e.g. {{ .. }}) or markup extension (e.g. {binding ..}) must now be prefixed with “sys:”. For example, previously you could do this:
<input type=”text” value=”{{ foo }}” />
You must now do this:
<input type=”text” sys:value=”{{ foo }}” />
Some attributes such as ‘src’ of an image already required this due to various browser issues or side effects. It was confusing when you needed sys and when you didn’t. Also, “top level bindings” naturally require sys as otherwise the expression/binding would be seen as actual content and possibly rendered to the user.

2. The ‘code’ attributes have been moved into ‘sys’.
code:if -> sys:if
code:before -> sys:codebefore
code:after -> sys:codeafter

3. The ‘class’ attributes have been moved into ‘sys’.
class:foo -> sys:class-foo

4. The ‘style’ attributes have been moved into ‘sys’.
style:font-size=”8” -> sys:style-font-size=”8”

Top Level Bindings

Support for "top level" expressions and bindings. Previously these were only supported within the context of a template marked with sys-template. For example, to bind the value of an input to a javascript object, you might do this:

This binds the value to the ‘bar’ field of a global ‘foo’ object. You can use other bindings to update the value, or directly with Sys.Observer:
Sys.Observer.setValue(foo, “bar”, “newValue”);

Binding the content of an element as text or HTML

You may bind to the content of a node using the new sys:innertext and sys:innerhtml attributes. Choose the appropriate attribute depending on whether or not you want to allow HTML in the value to be interpreted as HTML. For example, if you have a variable named ‘foo’ set to the value “<p>hello</p>”:
<div sys:innertext=”{{ foo }}”></div>
Will result in seeing <p>hello</p> in the browser.
<div sys:innerhtml=”{{ foo }}”></div>
Will result in the <p> tag being interpret as a paragraph tag.

The difference is in how the value is inserted. “sys:innertext” injects a text node with the given value. “sys:innerhtml” sets the innerHTML of the target element. Note that while “innerText” is an Internet Explorer only concept, “sys:innertext” is not an Internet Explorer only attribute. The name is semantically correct, despite it being implemented differently than IE’s native innerText field.

Template Changes

The pseudo variables accessible within template markup have been improved. Previously there was no way to get to the current context, only the parent context ($parentContext). Also, there was no simple way of getting to the current set of data being rendered.

The $parentContext pseudo variable is no longer. Now there is simply the $context variable. From there you can get to all the information available on the Sys.UI.TemplateContext class:
$context.parentContext
$context.data
$context.dataItem
$context.index
… and others. You also still have access to these for convenience:
$dataItem ß the current dataItem (e.g. $context.dataItem)
$index ß index of the current dataItem (e.g. $context.dataIndex)
$element ß The last element to either begin or close
$component ß The last component that was created
The Sys.UI.Template.instantiateIn() method has been changed to accept the data as well as the dataItem for the context that is created.
Before: template.instantiateIn(container, dataItem, dataIndex, insertBeforeNode, parentContext)
Now: template.instantiateIn(container, data, dataItem, dataIndex, insertBeforeNode, parentContext)

DataView Improvements

DataView now has the following events:
rendering
itemRendering
itemRendered
rendered

DataView Dynamic Templates and Placeholders

From each event you have the opportunity to override the parameters the DataView uses to render. The itemTemplate and itemPlaceholder can both be changed dynamically from the rendering and itemRendering events. This allows you to dynamically determine both the default template and placeholder used for all items, without having to change the corresponding DataView properties, as well as dynamically determine them for each individual item. This enables some interesting scenarios where the template used to render each item can be determined based on the data. It also means each item can be rendered into a different location. For example, you might have a Stock Ticker DataView that renders negative stocks with a negativeItemTemplate and positive ones with a positiveItemTemplate. Or you might have a product listing DataView where items of different categories are rendered into separate placeholders, possibly in very distant parts of the page.

Binding Converters and Expandos

Bindings now support the concept of named converters that are set onto the Sys.Binding.converters field. There are none out of the box, but you may now define your own and refer to them by name. For example:
{binding foo,convert=myconverter}
This would look for a converter defined like so:
Sys.Binding.converters.myconverter = function(valueToConvert, binding) {
// convert
}
In addition, you may now set expandos onto the binding object and refer to them from your converter. This allows you to semantically describe what you want in a binding in any custom way you require for any specific binding. It allows you to parameterize a converter function. For example, this example sets a ‘format’ expando on the binding object despite that not being a field or property the binding natively has:
{binding foo,convert=format,format=MM/dd}
Sys.Binding.converters.format = function(value, binding) {
// binding.format === MM/dd
}

UpdatePanel Support

Preview 4 was not compatible with UpdatePanel in ASP.NET 3.5 due to changes to the data format UpdatePanel renders, and the inline script it renders in ASP.NET 4.0. The 4.0 scripts are now designed to work with either 3.5 or 4.0 on the server. To support UpdatePanel with these scripts, you must replace the partial rendering script (MicrosoftAjaxWebForms.js) with the 4.0 version. If you do not use an update panel, you must disable partial rendering.
No UpdatePanel:

<asp:ScriptManager runat=”server” EnablePartialRendering=”false”>
<Scripts>
<asp:ScriptReference Name=”MicrosoftAjax.js” Path=”~/scripts/MicrosoftAjax.js” />
</Scripts>
</asp:ScriptManager>
With UpdatePanel:

<asp:ScriptManager runat=”server”>
<Scripts>
<asp:ScriptReference Name=”MicrosoftAjax.js” Path=”~/scripts/MicrosoftAjax.js” />
<asp:ScriptReference Name=”MicrosoftAjaxWebForms.js” Path=”~/scripts/MicrosoftAjaxWebForms.js” />
</Scripts>
</asp:ScriptManager>