Dokumentierte Änderungen in ASP.NET AJAX („ATLAS“) gegenüber den CTP-Versionen

Veröffentlicht: 12. Mrz 2007

Von Microsoft ASP.NET AJAX-Team

Dieses Dokument beschreibt Änderungen an ASP.NET 2.0 AJAX Extensions und an der Microsoft AJAX-Bibliothek gegenüber der letzten Community Technical Preview (CTP)-Version. Beide Produkte wurden früher unter dem Codenamen „Atlas“ geführt und gemeinsam als ASP.NET AJAX bezeichnet.

Auf dieser Seite

 Zusammenfassung
 Dokumentkonventionen
 Einführung
 Überblick über die wichtigsten Änderungen
 Zusammenfassung der Änderungen von Beta zu Beta 2
 Zusammenfassung der Änderungen von Beta 2 zum RC
 Zusammenfassung der Änderungen vom RC zu RTM
 Funktionsmatrix
 Änderungen am Client FX im Detail
 Debuggen
 Globalisierung und Lokalisierung
 Netzwerk
 Anwendungsdienste
 Änderungen am Server FX im Detail
 Erforderliche Einträge für IIS 7.0

Zusammenfassung

Das ASP.NET-Team liefert ein Framework zum Generieren von Webanwendungen, die die neuesten Funktionen der Clientfunktionalität in den Bereichen asynchrones JavaScript und XML (Asynchronous JavaScript and XML, AJAX) und Rich Interactive Applications (RIA) nutzen. Die neue Microsoft ASP.NET AJAX-Ergänzung zu .NET Framework umfasst eine Suite von JavaScript-Bibliotheken (das Clientframework oder Client FX), die die Grundlage zum Erstellen vielfältiger Verhalten und steuerelementähnlicher Funktionalität im Browser darstellen. ASP.NET AJAX umfasst auch einen Satz von einen Serversteuerelementen und Basisklassen für Extendersteuerelemente (das Serverframework oder Server FX), der AJAX-Programmierfunktionen für ASP.NET-Webentwickler bereitstellt.

ASP.NET AJAX-Funktionen standen bereits seit Oktober 2005 in Form von Community Technology Previews (CTPs) zur freien Verfügung. Mithilfe dieser CTPs wurden Aspekte wie Rich Client-Verhalten, asynchrone Webseitenpostbacks sowie das Aufrufen und Verwenden von Webdiensten über JavaScript-Proxys vorgestellt.

In diesem Artikel werden die Hauptunterschiede zwischen der letzten CTP-Version (seit Juli 2006 allgemein verfügbar) und der finalen Microsoft ASP.NET AJAX 1.0-Version (hier als „Release To Manufacturing“-, kurz RTM-Version bezeichnet) beschrieben. Darüber hinaus wird eine Vorschauversion der Zukunft vorgestellt (die Futures-Version), über die der RTM-Version weitere Funktionen hinzufügt werden. (Die RTM- und Futures-Versionen enthalten zusammen die vollständige Funktionalität sowie alle Kundenszenarien, die in den frühen CTP-Versionen unterstützt wurden). Bis zur Release Candidate (RC)-Version (der letzten Version vor der RTM-Version) können noch weitere Änderungen an den derzeitigen RTM- und Futures-Versionen vorgenommen werden.

Dieses Dokument ist in Abschnitte unterteilt, in denen jeweils bestimmte Funktionen der CTP-Version aufgelistet werden und geschildert wird, wie die gleiche Funktionalität in der RTM-Version erzielt wird. Für jede Änderung gibt es eine Beschreibung der Gründe und einige technische Kommentare.

 

Dokumentkonventionen

Dieses Dokument umfasst Beispielcode für Features, die in den vorherigen CTPs enthalten waren sowie Features, die zu den Haupt- und den Futures-Komponenten der RTM-Version gehören. Zur besseren Veranschaulichung und Unterscheidung wird über den Codebeispielen angegeben um welche Version es sich handelt.

CTP-Version:

RTM-Version:

Futures-Version:

 

Einführung

Zunächst einmal vielen Dank für das großartige Feedback und die Nutzungsdaten, die wir in der Vorveröffentlichungsphase von Microsoft ASP.NET AJAX erhalten haben! Die Unterschiede zwischen der Community Technology Preview (CTP)-Version und der letzten RTM-Version von Microsoft ASP.NET AJAX sind hauptsächlich auf die folgenden Aspekte zurückzuführen:

• Kundenfeedback – Viele Änderungen basieren auf den Diskussionen in den Communityforen und dem Feedback von Benutzern, die mit den CTP-Versionen Webanwendungen erstellt haben.

• Entwicklerproduktivität – In zukünftigen Versionen von Visual Studio soll umfangreiche Unterstützung für Tools (z. B. Skripterstellung, Skriptdebugging sowie clientseitige Fehlerbehandlung und Berichterstellung) bereitgestellt werden. Darüber hinaus soll das Programmiermodell durch klare Muster und Konsistenz mit den Designrichtlinien und -prinzipien von .NET Framework verbessert werden.

• Leistung – Die Ladezeit und die Größe des Workingsets der Skripts im Browser sollen sowohl für das Versions- als auch das Debugszenario verringert werden. Die Skriptmenge und der dafür erforderliche Speicher, der von Objektinstanzen genutzt wird, spielen bei unseren Entscheidungen eine wichtige Rolle.

In der folgenden Tabelle werden die Ziele zusammengefasst, die wir für verschiedene Zielgruppen beim Bereitstellen eines clientbasierten JavaScript-Frameworks (Client FX) und eines serverbasierten ASP.NET-Frameworks (Server FX) verfolgen. Beide Frameworks sind für zukünftige Erweiterungen entworfen. Das Client FX wurde beispielsweise so entworfen, dass es unsere aktuellen Leistungsziele erfüllt und von serverbasierten Steuerelementen wie AutoCompleteExtender, das im ASP.NET AJAX-Steuerelement-Toolkit enthalten ist, verwendet werden kann. Es bietet jedoch darüber hinaus die Möglichkeit zum Hinzufügen von XML-Skriptunterstützung und Bindungen in einer zukünftigen Version.

Hinweis Tool- und Entwurfszeitverbesserungen, die in diesem Dokument beschrieben werden, zielen auf die nächste Version von Visual Studio (Codename „Orcas“) ab.

Zielgruppe	Ziele	Hinweise
ASP.NET-Seitenentwickler, die serverbasierte Seiten erstellen	Schrittweises Aktualisieren bestehender Webanwendungen mit Rich Client-Funktionalität Verwenden bekannter, konsistenter ASP.NET-Programmiermodelle und -tools Verringern oder Beseitigen der Notwendigkeit, JavaScript zu beherrschen oder zu erlernen Verringern oder Beseitigen des Bedarfs an browserspezifischem Code Nutzen von ASP.NET- und .NET Framework-Programmierfähigkeiten	Entwickler verwenden Serversteuerelemente, mit denen Javascript ausgeblendet wird und gleichzeitig die vielfältigen Möglichkeiten bereitgestellt werden, die von den heutigen Webanwendungsentwicklern verlangt werden.
ASP.NET-Seitenentwickler, die clientbasierte Seiten erstellen	Definieren von Client FX-Features, mit denen das Erstellen und Verwenden von Clientkomponenten vereinfacht wird Bereitstellen eines effizienten Programmiererlebnisses, wie bei möglicher IntelliSense-Unterstützung in Visual Studio „Orcas“ Verringern oder Beseitigen des Bedarfs an browserspezifischem Code	Seitenentwickler, die rein clientbasierte Seiten erstellen möchten, die unabhängig von der Servertechnologie funktionieren, benötigen ein Client FX, das Aufgaben wie das Erstellen von Clientobjekten und das Einbinden von Ereignissen in einer browserunabhängigen Weise vereinfachen.
ASP.NET-Komponentenentwickler	Bereitstellen eines Frameworks, mit dem der Komponentenentwickler Rich Client-Funktionalität und -Verhalten für ASP.NET-Serversteuerelemente erstellen kann Veranschaulichen von Mustern und Konzepten zum Erstellen von Komponenten, die Debug- und Versionsbereitstellungen unterstützen können	Das Client FX bietet Browsererkennung und ist erweiterbar. Diese besonderen Features stellen zusammen mit dem umfassenderen Client FX und Server FX Komponentenentwicklern die Bausteine zum Entwickeln von skriptreichen Steuerelementen zur Verfügung. Das Hauptziel für diese Zielgruppe besteht darin, eine Grundlage für eine lebhafte Community für Drittanbieterkomponenten zu schaffen.

 

Überblick über die wichtigsten Änderungen

Die folgenden Tabellen stellen eine Zusammenfassung der Hauptunterschiede zwischen den CTP-, RTM- und Futures-Versionen dar. Die Funktionsbereiche sind in Client- und Servergruppen unterteilt und enthalten Informationen Unterfunktionsgruppen sowie zu den Auswirkungen auf die jeweiligen Benutzer.

Client FX
Feature	Vorgenommene Änderung & Zweck	Auswirkungen
Clienttypsystem	Vorher: Verwenden von Closures; jetzt: Verwenden von Prototypen Zweck: Verbessern der Gesamtleistung und des Speicherverbrauchs von Objektinstanzen Vorbereitung für eine mögliche IntelliSense-Unterstützung in Visual Studio „Orcas“ in der Zukunft Bereitstellen von besser definierten Entwurfsmustern	Komponentenentwickler und Seitenentwickler können jetzt ein konsistentes Modell zum Erstellen von Typen im Client FX verwenden. Seitenentwickler, die solche Typen nutzen, werden kleine Änderungen im Code sowie eine erhöhte Produktivität durch die mögliche zukünftige IntelliSense-Unterstützung und eine bessere Debuggingunterstützung in Visual Studio bemerken.
Clientereignisse	Geändertes Modell zum Anhängen an ein DOM-Ereignis und zur Anzeige von Komponentenereignissen. Zweck: Unterstützung eines Standardmodells und zukünftige Erweiterbarkeit Bereitstellen von Mustern, die denen in .NET Framework ähneln	Komponentenentwickler und Seitenentwickler können einem einfachen, vertrauten Muster für das Definieren und Anhängen von Ereignissen folgen. Für Seitenentwickler, die Ereignisse anhängen, werden neue APIs leichter nachvollziehbar sein.
Ebene der Clientkompatibilität	Kompatibilität wird durch Browsererkennung und Browserfähigkeit unterstützt und findet vollständig auf dem Client statt. Zweck: Unterstützung des Standardmodells Vereinfachen von APIs zur Browsererkennung	Komponentenentwickler und Seitenentwickler können neue APIs wirksam einsetzen, um das Abzielen auf mehrere Browser zu vereinfachen.
JavaScript-Erweiterungen beim Client	API-Änderungen. Zweck: Vermeiden von Konflikten und Kompatibilitätsproblemen mit anderen AJAX-Bibliotheken und Frameworks	Seitenentwickler und Komponentenentwickler verfügen über neue API-Signaturen, um Konflikte mit anderen APIs zu vermeiden.
Client-„Klassen“ und andere Typen	Geändertes Modell zum Definieren einer Klasse als prototypbasiert. Registrierungs-APIs sind versiegelt. Darüber hinaus werden abstrakte Klassen nicht mehr definiert. Neue Verbesserungen zu Fehlerbehandlungssemantiken. Zweck: Schnellere Objektinstanzierung Verbessern der Gesamtleistung und des Speicherverbrauchs von Objektinstanzen	Komponentenentwickler erhalten neue Modelle zum Definieren benutzerdefinierter Typen. Seitenentwickler erhalten neue Aliase zur Instanzierung von Typen, wodurch die vorherige Komplexität beseitigt wird.
Debug- und Versionsskripts	Optionales Modell zur Bestimmung von Debug- und Veröffentlichungsversionen von Clientskripts, das unabhängig von Serverdebugeinstellungen sein kann. Seitenentwickler verweisen immer auf das Versionsskript im Steuerelement ScriptManager und können den Debugmodus getrennt für die server- und clientseitige Codeausführung angeben. Serveradministratoren können die Konfigurationseinstellungen des Bereitstellungsmodus angeben, um die Verwendung von Versionsskripts in der Produktion zu gewährleisten. Zweck: Möglicher Toolsupport in Visual Studio „Orcas“ für Debugversionen der Skripts; Skripts können auch von Dritten genutzt werden Ermöglichen des Zugriffs auf hochgradig optimierte Versionsskripts für die Produktion für Seitenentwickler	Komponentenentwickler können optional getrennte Debug- und Veröffentlichungsversionen ihrer eigenen Skripts bereitstellen. Seitenentwickler erhalten für das Netzwerk optimierte Skripts und Skripts, die Debugging und den möglichen zukünftigen Einsatz von IntelliSense in Visual Studio „Orcas“ unterstützen.
Component-, Behavior- und Control-Typen für Clients	Bindungen und Aktionen wurden entfernt. Diese Typen sind in den Futures-Version definiert. Die RTM-Version wurde so entworfen, dass sie schichtweise eingebunden werden können. In zahlreichen APIs erfolgte ein Übergang von diesen Klassen in die neue DomElement-Klasse. Zweck: Vereinfachung des Client FX APIs können jetzt verwendet werden, ohne zuerst ein Objekt instanzieren zu müssen Verringerung der Skriptgröße verbessert Ladezeiten und Leistung	Komponentenentwickler und Seitenentwickler, die diese Typen nutzen, müssen ihre API-Aufrufe ändern.
Clientnetzwerk	Vereinfachtes und flexibleres Design für den Aufruf von Webdienstmethoden vom Skript. Zusätzliche Unterstützung für Standardrückruffunktionen und für das Übergeben eines Methodennamens an die Rückruffunktion. Die Instanzseitenmethode in der CTP-Version wurde durch die Unterstützung der statischen Seitenmethode ersetzt. Die Unterstützung für das Aufrufen von WCF-Webdiensten (.svc-Dateien) vom Skript wurde entfernt. Die iframe-Ausführungsklasse, mit der domänenübergreifende Aufrufe möglich waren, wurde entfernt. Die folgenden Funktionen der CTP-Version wurde entfernt: Assemblybasierte Methodenaufrufe InitialData-Steuerelement Batchverarbeitung von Webdienstaufrufen Zweck: Vereinfachen der Webdienstaufrufe vom Skript Vorbereiten einer verbesserten WCF-Implementierung und -Integration, die für Visual Studio „Orcas“ geplant ist Beseitigen möglicher Sicherheitslücken mit domänenübergreifenden Aufrufen Entfernen von Features, die nicht vom Client FX verwendet werden, um dessen Größe zu verringern und die Leistung zu verbessern Verringern der Skriptgröße, um die Ladenzeit und Leistung zu verbessern	Seitenentwickler verfügen über einfachere und flexiblere Möglichkeiten zum Durchführen von Netzwerkaufgaben. Entwickler müssen Verweise auf WCF-Webdienste (.svc), die iframe-Ausführung und andere aus dem Client FX entfernte Funktionen löschen.
Clientanwendungsdienste	Vereinfachtes und flexibleres Design für die Verwendung der Mitglieds- und Profildienste vom Skript aus (analog zu den Verbesserungen bei den Clientnetzwerkfunktionen zum Aufrufen von Webdienstmethoden vom Skript aus). Zusätzliche Unterstützung für die Angabe von Standardrückruffunktionen. Zusätzliche Implementierung von Profildiensten als Komponente in der Futures-Version, ähnlich wie in der vorherigen CTP-Veröffentlichungsversion. Zweck: Vereinfachen des Zugriffs auf ASP.NET-Anwendungsdienste vom Skript aus	Seitenentwickler können ASP.NET-Anwendungsdienste einfacher verwenden.
Futures-Version: Clientkomponenten höherer Ebene, XML-Skript, Clientdaten und Typbeschreibungen	Sys.*-Funktionen wurden in einen neuen Namespace verschoben: Sys.Preview.*. Zusätzliche Unterstützung im Client FX für ein Modell, mit dem eine einfache Typbeschreibung definiert wird, die in der Futures-Version genutzt werden kann. In der Futures-Version wird weiterhin XML-Skript unterstützt. Zusätzlich werden folgende Verbesserungen enthalten sein: Bindungen unterstützen unbegrenzte Verschachtelung in Komponenten. Bessere Zuweisung von Namespace-zu-Komponenten-Tagpräfixen. Zweck: Umgestalten des Haupt-Client FX für die RTM-Version	Seitenentwickler, die XML-Skript verwenden, müssen ihren Code ändern. Änderungen können erforderlich sein, wenn Eigenschaften von Kernobjekten in der RTM-Version zur Futures-Version verschoben werden. Komponentenentwickler können mit der RTM-Version Komponenten erstellen, die auch mit Futures-Funktionen verwendet werden können.

Server FX
Feature	Vorgenommene Änderung & Zweck	Auswirkungen
ScriptManager-Steuerelement	Das ScriptManager-Steuerelement wurde geändert, um neue UpdatePanel-Steuerelementfunktionen zu unterstützen, z. B. Registrierung von Skripts und Stylesheets. Die Fehlervorlage wurde ebenfalls entfernt. ScriptManager wurden neue Bearbeitungsmethoden und Funktionen hinzugefügt, mit denen Verweise auf statische Skripts und webressourcenbasierte Skripts möglich sind. Darüber hinaus wurde ein neues Ereignis zur Auflösung des Speicherorts benutzerdefinierter Skripts eingeführt. Die Bearbeitung von Debug- und Versionsskripts durch ScriptManager wurde verbessert, sodass der Debugstatus nicht mehr allein aus der Serverkonfigurationseinstellung gefolgert wird. Die Ressourcen von Steuerelementen müssen nun über das Steuerelement ScriptManager registriert werden. Zweck: Berücksichtigen von Kundenfeedback und Vorschlägen dazu, Seitenentwicklern mehr Steuerungsmöglichkeiten und Flexibilität bei der Skriptverarbeitung und der Verwendung von UpdatePanel zur Verfügung zu stellen	Seitenentwickler erhalten detaillierte Steuerungsmöglichkeiten bei der Skriptbearbeitung. Komponentenentwickler müssen ihre Komponentenskripts und Ressourcen über das Steuerelement ScriptManager registrieren.
ExtenderControl-Steuerelement	Das Extendermodell wurde vereinfacht, um Unterstützung für „one-control-to-many-extenders“-Szenarien (ein Steuerelement für mehrere Extender) zu aktivieren. Das Modell wurde zum Definieren und Registrieren der Clientbibliothek- und -instanzskripts des Steuerelements zur Laufzeit geändert, um die erforderlichen Kenntnisse für den Seitenlebenszyklus zu verringern. Das neue Modell unterstützt vereinfachte Objekterstellung nach JSON oder ein zukünftiges Modell. Zusätzliche Unterstützung für mögliche Entwurfszeitverbesserungen in Orcas für Extender, um die Typen ihrer Zielsteuerelemente zu definieren.	Komponentenentwickler erhalten vereinfachte Modelle zum Erstellen von Extendern. Seitenentwickler erhalten eine verbesserte und vereinfachte Extender-Markupsyntax.
UpdatePanel-Steuerelement	Änderungen zur Gewährleistung der Funktion von Modellen zur teilweisen Seitenaktualisierung unter allen bekannten Bedingungen. Dies bedeutet: Steuerelemente müssen ihre Ressourcen (Skripts, Stylesheets usw.) über das Steuerelement ScriptManager registrieren. UpdatePanel versucht nicht mehr, Änderungen im gesamten Dokument zu erkennen; stattdessen werden Änderungen nur innerhalb seiner Inhaltsvorlage überwacht. Ereignisse wurden dem clientseitigen Steuerelement PageRequestManager hinzugefügt, um weitere Szenarios zu aktivieren, die asynchrone Postbacks wie Animationseffekte und Fortschrittsteuerelemente umfassen. UpdatePanel-Steuerelemente können einer Seite jetzt sowohl auf dynamische als auch auf deklarative Weise hinzugefügt werden. Das Triggermodell wurde durch das Entfernen von Eigenschafttriggern und das Hinzufügen von Postbacktriggern verbessert. Auf diese Weise ist es möglich, voll synchrone Postbacks vom Steuerelement UpdatePanel aus zu erzwingen. Zweck: Berücksichtigen von Kundenfeedback und Vorschlägen dazu, Seitenentwicklern und Komponentenentwicklern mehr Flexibilität und Optionen zur Steuerung von teilweisen Seitenaktualisierungen und vollständigen Postbacks zur Verfügung zu stellen	Komponentenentwickler müssen Registrierungsmodelle verwenden. Seitenentwickler erhalten neue Verarbeitungs- und Logikmodelle für das Steuerelement UpdatePanel.
Tagpräfix für Serversteuerelemente	Änderung des Tagpräfix für ASP.NET AJAX-Steuerelemente von <atlas:> in <asp:>. Zweck: Normalisieren des Namespace für deklarative Steuerelemente, um Konsistenz mit anderen ASP.NET-Steuerelementen herzustellen	Entwickler von Seiten, die deklarative Steuerelemente enthalten, müssen das Tagpräfix des Steuerelements global ändern.
Futures-Version: Serverkomponenten	Microsoft.Web.*-Funktionen wurden in einen neuen Namespace (Microsoft.Web.Preview.*.) verschoben. Zweck: Umgestaltung des Haupt-Server FX für die RTM-Version	Änderungen können erforderlich sein, wenn Eigenschaften von Kernobjekten in der RTM-Version zur Futures-Version verschoben werden. Komponentenentwickler können mit der RTM-Version Komponenten erstellen, die auch mit Futures-Funktionen verwendet werden können.

 

Zusammenfassung der Änderungen von Beta zu Beta 2

Eine Reihe von Fehlerbehebungen und zusätzlichen Features machen den Unterschied zwischen den Versionen Beta und Beta 2 von ASP.NET AJAX 1.0 aus. In diesem Abschnitt werden die Unterschiede im Allgemeinen beschrieben. Spätere Abschnitte dieses Dokuments beschreiben die Änderungen im Detail.

Hinweis: *Folgende wichtige Änderungen wurden von Beta zu Beta 2 vorgenommen:

• Ein neuer ScriptResource.axd-Handler wurde hinzugefügt, für den ein Eintrag in der Datei „Web.config“ erforderlich ist.

• Array.prototype-Erweiterungen wurden zu statischen APIs für das Array-Objekt.

• Die Typen ExtenderControl, IExtenderControl und IScriptControl müssen sich in ihrer PreRender-Methode über das Steuerelement ScriptManager registrieren.

• Die Sys.UI.Key-Enumerationen „return“ und „delete“ wurden in „enter“ und „del“ umbenannt.

• Die Methode Sys.Services.AuthenticationService.logout leitet jetzt immer um, wenn sie erfolgreich durchgeführt wurde. Zuvor hat eine Umleitung nur stattgefunden, wenn Sie einen URL angegeben haben. (Wenn kein URL angegeben ist, führt die Seitenumleitung zur selben Seite.)

• Die Methoden Sys.Services.AuthenticationService.login und logout rufen beide die Beendigungsrückruffunktion auf, selbst wenn kurz darauf eine Umleitung erfolgt. Vorher wurden die Rückrufe ausgelassen.

Client FX

• Mit den Aliasen $addHandlers und $clearHandlers können mehrere DOM-Ereignisse erstellt werden.

• Array.prototype-Erweiterungen wurden zu statischen APIs für das Array-Objekt.

• Sys.UI.Control-APIs umfassen jetzt addCssClass, removeCssClass, und toggleCssClass.

• Die Sys.UI.Key-Enumerationen return und delete wurden in enter und del umbenannt.

• Die neuen Methoden Date, Number, String format sowie localeFormat verwenden die Typen Sys.CultureInfo.InvariantCulture und Sys.CultureInfo.CurrentCulture.

• Enum.parse unterstützt einen neuen Parameter zum Ignorieren der Groß- und Kleinschreibung.

• Die APIs Debug.trace und Debug.dump wurden hinzugefügt.

• Der Klasse Sys.Application wurden Ereignisse für Skriptladeausnahmen hinzugefügt.

• Die Methode Sys.Services.AuthenticationService.logout leitet jetzt immer um, wenn sie erfolgreich durchgeführt wurde. Zuvor hat eine Umleitung nur stattgefunden, wenn Sie einen URL angegeben haben. (Wenn kein URL angegeben ist, führt die Seitenumleitung zur selben Seite.)

• Die Methoden Sys.Services.AuthenticationService.login und logout rufen beide die Beendigungsrückruffunktion auf, selbst wenn kurz darauf eine Umleitung erfolgt. Vorher wurden die Rückrufe ausgelassen.

Server FX

• Ein neuer ScriptResource.axd-Handler wurde eingeführt, der in die Assembly eingebettete Skriptreferenzen und ihre Ressourcen rendert und darüber hinaus eine Komprimierung durchführt. Der Handler unterstützt die Generierung von Clienttypen für die Lokalisierung.

Hinweis Für diesen Handler ist ein Eintrag in der Datei „Web.config“ erforderlich. Falls der Eintrag fehlt, wird gegebenenfalls die folgende Fehlermeldung angezeigt: „Sys“ ist nicht definiert.

• Die Typen ExtenderControl, IExtenderControl und IScriptControl müssen sich in ihrer PreRender-Phase über das Steuerelement ScriptManager registrieren. Das neue Modell unterstützt diese Typen in komplizierteren Szenarios, z. B. innerhalb von Vorlagen in datengebundenen Steuerelementen.

• Das Steuerelement ScriptManager umfasst jetzt Folgendes:

  • Neue Eigenschaften für die Unterstützung von Globalisierung und Lokalisierung.

  • Neue APIs, die den Fokus auf Clients beim teilweisen Rendern von Seiten des Steuerelements UpdatePanel unterstützen.

  • Eine Eigenschaft SupportsPartialRendering, die auf Browserfunktionen basiert.

  • Eine Methode RegisterDispose, mit der überflüssige Objekte während eines partiellen Renderings gefunden werden, sodass für das Objekt kein DOM-Element mehr erforderlich ist.

  • Globalisierungsunterstützung durch die Generierung eines clientseitigen Objekts Sys.UI.CurrentCulture, das von der Threadkultur des Servers abhängt. Standardmäßig wird dieser Wert auf der Grundlage des ACCEPT_LANG-Headers in der Browseranforderung bestimmt.

  • Eine Eigenschaft ScriptLoadTimeout zur Verarbeitung von Skripts im Client.

 

Zusammenfassung der Änderungen von Beta 2 zum RC

In diesem Abschnitt wird eine Reihe von Fehlerbehebungen und zusätzlichen Features beschrieben, die der RC-Version im Vergleich zur Beta 2-Version von ASP.NET AJAX 1.0 hinzugefügt wurden. Spätere Abschnitte dieses Dokuments beschreiben die Änderungen im Detail.

Bedeutende Änderungen

Folgende Änderungen sind bedeutend:

• Die Kernassembly wurde von Microsoft.Web.Extensions in System.Web.Extensions geändert, sodass Anwendungen, die mit der RTM-Version erstellt werden, mit der Orcas-Version kompatibel sind. In Ihren vorhandenen Anwendungen müssen Sie folgende Schritte durchführen:

  • Stellen Sie sicher, dass Ihre Anwendungen auf die neue Assembly verweisen, und entfernen Sie Verweise auf Microsoft.Web.Extensions.

  • Stellen Sie sicher, dass Ihre Web.config-Dateien in allen Typverweisen nun auf die neue Assembly verweisen.

  • Stellen Sie sicher, dass Microsoft.Web.Extensions aus dem GAC deinstalliert wird.

• Die Hauptnamespaces wurden analog zu den Änderungen an der Hauptassembly bearbeitet. Der Microsoft.Web.*-Namespace wurde in System.Web.* geändert. Außerdem wurden einzelne Typen in andere Namespaces verschoben. In Ihren vorhandenen Anwendungen müssen Sie folgende Schritte durchführen:

  • Stellen Sie sicher, dass using- oder Import-Anweisungen auf die neuen Namespaces verweisen. Alle weiteren vollqualifizierten Verweise müssen ebenfalls geändert werden.

  • Ändern Sie Verweise auf das serverseitige Steuerelement Timer in System. Internet.UI.

  • Ändern Sie Verweise auf die Klasse ScriptModule in System.Web.Handlers.

• Der Namespace Microsoft.Web.Extensions.Design wurde in System.Web.Extensions.Design umbenannt. Die Typen im Namespace wurden ebenfalls von Microsoft.Web.Design in System.Web.Design verschoben. In Ihrer Anwendung müssen Sie daher Verweise und alle using- oder Import-Anweisungen dementsprechend aktualisieren.

• Entwickler, die Extendersteuerelemente oder Skriptsteuerelemente erstellt haben, in denen die Schnittstellen IExtenderControl oder IScriptControl verwendet werden, müssen einen Aufruf von ScriptManager.RegisterScriptDescriptors in der Render-Methode ihrer Steuerelemente hinzufügen.

• Das Skriptkomprimierungsmodul wurde aus dem Produkt entfernt. Skriptkomprimierung wird direkt im Skriptressourcenhandler durchgeführt. In Ihren vorhandenen Anwendungen müssen Sie in der Datei „Web.config“ den Eintrag für den Handler entfernen.

• Der Abschnitt <Microsoft.Web.Extensions> der Datei „Web.config“ wurde in <System.Web.Extensions> umbenannt.

  • Sie müssen bestehende Web.config-Dateien ändern, sowohl für den Abschnitt selbst als auch für die Abschnittsgruppe.

  • Der Abschnitt enthält einen neuen Unterabschnitt <scriptResourceHandler>, mit dem das Zwischenspeicher- und Komprimierungsverhalten des Handlers gesteuert wird.

• Die globale clientseitige Funktion registerNamespace wurde entfernt. Sie sollten bestehende Anwendungen so ändern, dass stattdessen die vorhandene Funktion Type.registerNamespace verwendet wird.

• In der Futures-Version wird mit einfacheren Namen auf Skripts verwiesen, sodass das Präfix Microsoft.Web.Resources.ScriptLibrary nicht mehr erforderlich ist. Sie müssen alle Verweise ändern.

Client FX

Die folgenden Änderungen wurden an der Clientbibliothek vorgenommen:

• Die Globalisierungsunterstützung in der Clientbibliothek umfasst jetzt auch eine Analyse der Typen Date und Number.

• Die Funktion Debug.traceDump führt keine Rekursion auf DOM-Elemente durch.

• Die Futures-Version enthält Konverter für die Typen DataRow, DataTable und DataSet.

• Der Aufruf einer Webdienstmethode von JavaScript-Proxymethoden verwendet jetzt den gleichen URL, der zum direkten Aufrufen von .asmx-Diensten genutzt wurde. Dies ist ein Beispiel für die alte Syntax:

  ...myService.asmx/js/myMethodName

  Dies ist die neue Syntax:

  ...myService.asmx/myMethodName

Server FX

Die folgenden Änderungen wurden an Skriptressourcen vorgenommen:

• ScriptReference-Typen enthalten eine Eigenschaft NotifyScriptLoaded, um das Framework anzuweisen, das Skriptbenachrichtigungsskript an ressourcenbasierte Skriptbibliotheken anzuhängen.

• Der ScriptResource.axd-Handler verfügt über einen neuen Abschnitt in der Datei „Web.config“, mit dem Entwickler und Administratoren das Zwischenspeichern und Komprimieren von Skriptressourcen, die vom Handler bearbeitet werden, steuern können.

• Der ScriptResource.axd-Handler unterstützt die Austauschlogik in eingebetteten Internetressourcen in der gleichen Weise wie der WebResource.axd-Handler.

• Der ScriptResource.axd-Handler unterstützt Skripts, die von einer Anforderung an Seiten direkt unter der Standardwebsite bedient werden.

• Das Steuerelement ScriptManager unterstützt eine Fallbacklogik nach UI-Kultur für dateibasierte statische Skripts, die mithilfe der Eigenschaft ResourceUICultures eines Skriptverweises definiert wurden.

Die folgenden Änderungen wurden an Extender- und Skriptsteuerelementen vorgenommen:

• Die Basisklasse ExtenderControl und eine neue Basisklasse ScriptControl rufen die neue API ScriptManager.RegisterScriptDescriptors in ihrer Render-Methode auf. Entwickler, die IExtenderControl und IScriptControl verwenden, müssen diesen Aufruf in der Render-Methode ihrer Steuerelemente hinzufügen.

• Die Eigenschaften ScriptControlDescriptor, ScriptBehaviorDescriptor und ScriptComponentDescriptor ID sind jetzt mit der clientseitigen Darstellung konsistent. Die Eigenschaften ScriptControlDescriptor und ScriptBehaviorDescriptor Name sind nun ebenfalls mit ihrer clientseitigen Darstellung konsistent. Eine Eigenschaft ClientID wurde im ScriptComponentDescriptor, ScriptControlDescriptor und ScriptBehaviorDescriptor eingeführt.

• Eine API AddScriptProperty wurde dem ScriptComponentDescriptor hinzugefügt. Sie ermöglicht es Entwicklern, einigen JavaScript-Ausdrücken direkt eine Eigenschaft zuzuweisen.

Die folgenden Änderungen wurden an partiellen Seitenaktualisierungen vorgenommen:

• Das Steuerelement UpdateProgress durchsucht den Benennungscontainer, um das Steuerelement AssociatedUpdatePanel zu finden.

• Skriptkomponenten werden über das Steuerelement ScriptManager automatisch als entfernbare Objekte registriert. Clientkomponenten müssen daher kein HTML-Element für das Entfernen vorsehen.

• Die Methode ScriptManager.SetFocus funktioniert mit <input type="text" />-HTML-Elementen.

• Auf die MicrosoftWebAjaxWebForms.js-Bibliothek wird nur von Seiten verwiesen, auf denen es mindestens ein Steuerelement UpdatePanel gibt, und für die die Eigenschaft EnablePartialRendering auf true gesetzt ist.

• ScriptControl-Typen werden von UpdatePanel-Steuerelementen unterstützt, wenn die Eigenschaft EventValidation der Seite deaktiviert ist.

Die folgenden Änderungen wurden für Webdienstproxys vorgenommen:

• Die Klasse WebServiceProxy wurde hinzugefügt, um den Aufruf derjenigen Webdienste zu aktivieren, die im Steuerelement ScriptManager nicht als ServiceReferences-Elemente ausgewiesen sind. Diese Klasse wird auch als abstrakte JavaScript-Basisklasse für generierte JavaScript-Proxys für alle Webdienste verwendet, die als ServiceReferences-Elemente ausgewiesen sind.

• Der Aufruf einer Webdienstmethode von JavaScript-Proxymethoden verwendet jetzt den gleichen URL, der zum direkten Aufrufen von .asmx-Diensten genutzt wurde. Dies ist ein Beispiel für die alte Syntax:

  ...myService.asmx/js/myMethodName

  Dies ist die neue Syntax:

  ...myService.asmx/myMethodName

 

Zusammenfassung der Änderungen vom RC zu RTM

In diesem Abschnitt wird eine Reihe von Fehlerbehebungen und zusätzlichen Features beschrieben, die der RTM-Version im Vergleich zur RC-Version von ASP.NET AJAX 1.0 hinzugefügt wurden. Spätere Abschnitte dieses Dokuments beschreiben die Änderungen im Detail.

Bedeutende Änderungen

Folgende Änderungen sind bedeutend:

Am Client

• Die Hilfs-APIs für Eingabehilfen Sys.UI.DomElement.setAccessibilityAttribute und Sys.UI.Control.set_role wurden entfernt.

• Die Klasse Sys.UI.ScriptLoader ist jetzt ein privates Objekt und wurde in Sys.UI._ScriptLoader umbenannt. Keine der APIs werden als öffentlich betrachtet.

• Die Skripttimeouthandler wurden entfernt. Dies umfasst Sys.Application.add_loadTimedout, Sys.Application.remove_loadTimedout, Sys.Application.add_scriptLoadFailed, Sys.Application.remove_scriptLoadFailed, Sys.Application.get_scriptLoadTimeout und Sys.Application.set_scriptLoadTimeout.

• Die Methode Sys.Application.queueScriptReference wurde entfernt.

• Die Klasse Debug wurde in Sys.Debug umbenannt.

• Die statischen Funktionen Date.parse und Number.parse wurden in Date.parselnvariant und Number.parseInvariant umbenannt. Analog hierzu heißen Date.localeParse und Number.localeParse nun Date.parseLocale und Number.parseLocale.

• Die Methode Number.parseInvariant (früher Number.parse) gibt NaN zurück, anstatt eine Ausnahme auszulösen, wenn ein ungültiger Wert übergeben wird.

• Die Methode Date.parseInvariant (früher Date.parse) gibt null zurück, anstatt eine Ausnahme auszulösen, wenn ein ungültiger Wert übergeben wird.

Am Server

• Die Eigenschaft ScriptManager.ScriptLoadTimeout wurde entfernt.

• Wenn die Einstellung <deploymentmode retail=“false"> aktiviert ist (die Standardeinstellung), nutzt das Steuerelement ScriptManager seine Eigenschaft ScriptMode und die Einstellungen unter ScriptReference, um zu bestimmen, ob Debug- oder Versionsskripts abgewickelt werden sollen. Wenn die Eigenschaft ScriptMode auf Auto oder Inherit (die Standardeinstellung) festgelegt ist, bestimmt das Steuerelement ScriptManager aufgrund des Werts <compilation debug=”true|false”/> in der Datei „Web.config“ auf der Stammebene der Anwendung, ob Debug- oder Versionsskripts versendet werden. Das Steuerelement ScriptManager bestimmt den Debug- oder Versionswert nicht mehr aus der Konfigurationshierarchie. Wie in den vorherigen Versionen hängt die Einstellung ScriptMode nicht von der Debugeinstellung in einer @ Page-Direktive ab.

• Der Namespace System.Web.UI.Compatibility und die Validierungssteuerelemente, die mit asynchronen Postbacks kompatibel waren, wurden entfernt.

• Der Zugriff auf statische Seitenmethoden vom Skript ist standardmäßig deaktiviert. Sie müssen explizit die Eigenschaft EnablePageMethods des Steuerelements ScriptManager auf true setzen, damit der PageMethods-Clientproxy generiert wird.

• Ein Handlertyp System.Web.Script.Services.ScriptHandlerFactory ist jetzt für die Aktivierung von Anwendungsdiensten erforderlich. Dieser Handler muss in der Datei „Web.config“ registriert werden.

• Die Konfigurationsabschnitte für System.Web.Extensions sind nun im Gegensatz zum Abschnitt <jsonSerialization> markiert, um ihre Definition unter dem Anwendungsstamm zu verhindern.

Server FX

Die folgenden Änderungen wurden bei der Registrierung von Skriptressourcen vorgenommen:

• Einige der statischen Registrierungsmethoden der Klasse ScriptManager verfügen über zusätzliche Überladungen, die ein Page-Objekt als Parameter verwenden. Skripts können daher unabhängig von UpdatePanel-Steuerelementen registriert werden, die während des asynchronen Postbacks aktualisiert werden.

• Skriptkomprimierung wird ausgelassen, wenn Microsoft Internet Explorer 6 als Browser eingesetzt wird.

• Das Steuerelement ScriptManager unterstützt jetzt eine Eigenschaft LoadScriptsBeforeUI, mit der Seitenentwickler Skriptverweise am Ende eines Formulars rendern können, statt (wie standardmäßig) am Anfang.

• Die Eigenschaft Name der Klassen ScriptControlDescriptor und ScriptBehaviorDescriptor wurde in die Liste der Eigenschaften aufgenommen, die an die Methode $create gesendet werden, wenn die Eigenschaft nicht leer ist.

• Die Funktion Function._validateParams wurde den Veröffentlichungsversionen von Skripts hinzugefügt.

Client FX

Die folgenden Änderungen wurden am Client FX vorgenommen:

• Die integrierten Typen geben true zurück, wenn die Methode isClass von ihrem Typ aufgerufen wird.

• Viele Problembehebungen in der Methode Sys.UI.DomElement.getLocation wurden vorgenommen, um verschiedenen Browsertypen und -versionen bei Implementierungen sowie dem Verschachteln von Elementen, Rahmen, Rändern und Bildlaufleisten gerecht zu werden.

Die Problembehebungen in der Futures-Version werden in einem späteren Abschnitt des Dokuments aufgeführt.

 

Funktionsmatrix

ASP.NET AJAX wurde im Vorfeld der RTM-Version in zwei getrennte Downloads aufgeteilt. Im Folgenden werden die ursprünglichen CTP-Funktionen aufgeführt, und es wird angegeben, wo sich die einzelnen Funktion jetzt in der RTM-Version befinden: in der unterstützten ASP.NET AJAX Version 1.0-Kernversion oder in der Community-unterstützten Futures-Version.

Serverfunktionen
Feature	ASP.NET AJAX 1.0	ASP.NET AJAX CTP
Asynchrones Client-zu-Server-Netzwerk	X
Authentifizierung als Webdienst	X
AutoCompleteExtender-Klasse		X
ControlExtender-Klasse	X
Drag & Drop für browserunabhängige Webparts		X
DragOverlayExtender-Steuerelement		X
PopupExtender-Klasse		X
Profil als Webdienst	X
ScriptManager- und ScriptManagerProxy-Steuerelemente	X
Statische Seitenmethoden als Webdienste	X
Timer-Steuerelement	X
UpdatePanel-Steuerelement	X
UpdateProgress-Steuerelement	X

Clientfunktionen
Feature	ASP.NET AJAX 1.0	ASP.NET AJAX CTP
Aktionskomponenten		X
Authentifizierung für JavaScript	X
AutoCompleteBehavior-Klasse		X
BatchResponse Klasse		X
Behavior-Klasse	X
Binding-Komponente		X
Button-Steuerelement		X
Aufrufen von .asmx-Webdiensten über JavaScript	X
Checkbox-Steuerelement		X
Click-Verhalten		X
Component-Klasse	X
Control-Klasse	X
Counter-Klasse		X
Browserunabhängige Webparts		X
Data-Steuerelement		X
Debug-Klasse	X
DragDropList-Steuerelement		X
DragDropManager-Komponente		X
DraggableListItem-Steuerelement		X
FadeAnimation-Komponente		X
Floating-Verhalten		X
Hover-Verhalten		X
Hyperlink-Steuerelement		X
Image-Steuerelement		X
Input-Steuerelement		X
Erweiterungen des Typs Array bei JavaScript	X
Erweiterungen des Typs Boolean bei JavaScript	X
Erweiterungen des Typs Error bei JavaScript	X
Erweiterungen des Typs Number bei JavaScript	X
Erweiterungen des Typs Object bei JavaScript	X
Erweiterungen des Typs String bei JavaScript	X
JavaScript-Lokalisierung	X
JavaScript-Globalisierung	X
JSON-Serialisierung	X
Label-Steuerelement		X
Layout-Verhalten		X
Opacity-Verhalten		X
Popup-Verhalten		X
Profil für Javascript	X
Selector-Steuerelement		X
ServiceMethodRequest-Klasse		X
Sys.Data und Sys.UI.Data-Namespaces		X
Textbox-Steuerelement		X
Timer-Steuerelement	Server Timer Steuerelement hinzugefügt	X
Trace-Klasse	X
Validierungssteuerelemente		X
XML-Skriptunterstützung		X

Änderungen am Client FX im Detail

Prototypen und Closures

In der CTP-Version wurden „Klassen“ oder Typen mithilfe einer Closure definiert, die letztlich den Konstruktor für die Klasse darstellt. (Obwohl es sich nicht um Klassen im Sinne von .NET Framework handelt, verwenden wir hier der Einfachheit halber diese Bezeichnung.) In der RTM-Version wird als Modell ein Prototyp verwendet. Diese Änderung wurde aus mehreren Gründen vorgenommen. In der folgenden Tabelle werden die beiden Modelle verglichen.

Prototyp	Closure
Der Konstruktor ist erforderlich.	Der Konstruktor enthält die Mitgliederdeklarationen.
Die Angabe „private“ wird nach Konvention verarbeitet. Mitglieder werden über einen Namen definiert, der das „_“-Präfix enthält.	Mitglieder sind eingekapselt (privat) in einer Klasse.
Mitglieder werden gemeinsam verwendet, sodass der Speicherbedarf für Objektinstanzen verringert wird.	Mitglieder sind instanzbasiert, wodurch der Speicherbedarf für Objektinstanzen erhöht wird.
Der Prototyp wird in allen Browsern schnell geladen. In Mozilla Firefox wird mit dem Prototyp eine bedeutend kürzere Ladezeit erreicht. In allen Fällen sollte die Skriptladezeit für den Endbenutzer nicht wahrnehmbar sein. Die Hauptleistungsvorteile des Prototyps liegen im bedeutend geringeren Speicherverbrauch pro Objekt und in einer bedeutend schnelleren Objektinstanzierung.	Bei Verwendung von Internet Explorer hat das Closure-Modell eine geringfügig kürzere Ladezeit.
Durch die Unterstützung von IntelliSense und der Anweisungsvervollständigung eines Tools können einige Typeninformationen einfach auf Reflektion basierend abgerufen werden, ohne dass die Typen erstellt werden müssen.	Toolunterstützung für IntelliSense und die Anweisungsvervollständigung würde es erforderlich machen, Code durch Instanzierung von Klassen auszuführen, um die nötigen Typeninformationen zu erhalten. Wir ziehen dies für Visual Studio „Orcas“ in Betracht, nicht aber für Visual Studio 2005.
Während des Debuggens können private Mitglieder im Debugger eingesehen werden.	Während des Debuggens können private Mitglieder im Debugger nicht einfach eingesehen werden. Zum Anzeigen von Mitgliederwerten in einem Tool (IDE) muss eine Reihe von Schritten ausgeführt werden.

Wir haben den Leistungsvorteil der Prototypen gegenüber den Closures von vielen Seiten betrachtet – nicht nur hinsichtlich des Speicherbedarfs der Objektinstanzen, sondern auch im Hinblick auf die Instanzierung einer typischen Anwendung, die aus mehreren Klassen mit verschiedenen Arten von Mitgliedern besteht. Diese Leistungsuntersuchung wurde an mehreren Browsern durchgeführt, da das Ziel darin besteht, ein für alle Browser optimal geeignetes Modell zu entwerfen.

Wenn Sie nur ASP.NET-Seiten schreiben und Clientobjekte des ASP.NET AJAX-Frameworks in benutzerdefinierten Skripts oder in deklarativen XML-Skripts verwenden, sollten Sie von diesen Änderungen nicht betroffen sein.

Die CTP-Versionen umfassten Unterstützung für Closures, um zu gewährleisten, dass die Basismethoden aufgerufen werden konnten. Diese Unterstützung wurde aus der RTM-Version entfernt. Sie können weiterhin untergeordnete „Klassen“ verwenden, die von prototypbasierten Typen erben, jedoch sollten Sie keine closurebasierten Typen in Vererbungsketten einsetzen.

Hinweis In der Betaversion gibt es eine ansatzweise Unterstützung von Closures. Diese wird wahrscheinlich in der RTM-Version entfernt. Grundsätzlich können jedoch Closures verwendet und als Unterklassen von prototypbasierten Basisklassen definiert werden. Entwickler sollten keine Closures erstellen, wenn die Closure als Basistyp verwendet werden könnte.

Das folgende Beispiel veranschaulicht die wichtigsten Punkte des Designs der RTM-Version. Eine weitere Beschreibung der Mitgliedermuster erfolgt später.

RTM-Version:

registerNamespace("Custom");

// Prototype: Constructor
Custom.Timer = function() {
    // Ctor creates private fields and calls base. 
    Custom.Timer.initializeBase(this);
    this._interval = 1000;
    this._enabled = false;
    this._timer = null;
}
// Prototype: members
Custom.Timer.prototype = {
    member1: function() { },
    member2: function() { },
    ...
}
Custom.Timer.registerClass('Custom.Timer', Sys.Component);

Im Gegensatz hierzu verwendet die CTP-Version ein Closuremodell, wie im folgenden Beispiel gezeigt.

CTP-Version:

Type.registerNamespace("Custom");

// Closure: Constructor and members
Custom.Timer = function() {
    Sys.Timer.initializeBase(this, [true]);    
    
    var _interval = 1000;
    var _enabled;
    var _timer = null;

    this.member = function() ... 
}
Custom.Timer.registerClass('Custom.Timer', Sys.Component);

JavaScript-Erweiterungen (Client-BCL)

Die CTP-Version enthielt eine Reihe von Erweiterungen der bestehenden, in JavaScript integrierten Typen, und diese bleiben in der RTM-Version erhalten. Sie wurden jedoch neu entworfen, um mögliche Konflikte mit anderen AJAX-Frameworks zu vermeiden. (Die Konflikte können bei Erweiterungen zu den integrierten Typen auftreten.)

Array

Änderung in Beta 2: Wie hier beschrieben, wurden statische Array-APIs eingeführt.

Änderung in Beta 2/RC: Die Erweiterungen des Prototyps Array wurden durch statische Array-Mitglieder ersetzt, denen ein Array-Objekt übergeben werden kann.

Fehler

Die grundlegende Fehlerbehandlung der CTP-Version wurde erweitert. Der Prototyp Error wurde in der RTM-Version stark erweitert, um „eingegebene“ Fehler bereitzustellen. Komponentenentwickler können nun Fehler (normalerweise in Debugskripts) auslösen. In der RTM-Version können Sie die Ausnahme abfangen und weitere Informationen über den Fehler erhalten. Das folgende Beispiel zeigt eine grundlegende Fehlerbehandlung, mit der eine aussagekräftigere Ausnahmemeldung bereitgestellt wird.

RTM-Version:

function checkRange(index) {
    if (index > 10 || index < 0) {
        throw Error.argumentOutOfRange(“index”, index, 
            "The index value must be between 0 and 10.");
    }
}

function myCallingFunction(value) {
    try {
        checkRange(value);
    } catch (e) {
        e.message = e.name + “:” + e.message + “\nIndex value was: “ + 
            e.actualValue;
        throw e; // bubbles up to the default error treatment
    }
    ...
}

Wenn vom Browser eine Ausnahme ausgelöst wird, enthält der Fehler daher Informationen, die vom Browser verarbeitet werden müssen.

Klassen- und Typdefinition, Reflektions-APIs

In der CTP-Version konnten Sie eine Reihe von verschiedenen Typvariationen erstellen, z. B. Klassen, Schnittstellen, Enumerationen und Flags. Diese Funktionalität wurde in der RTM-Version geändert.

Abstrakte und versiegelte Klassen

Mit der CTP-Version konnten Sie abstrakte und versiegelte Klassen erstellen. In der RTM-Version haben wir, basierend auf Nutzungsdaten und zum Zwecke der Leistungsverbesserung, die Konzepte abstrakter und versiegelter Klasse entfernt. Dies ermöglicht es uns, die Menge an Skript in der Bibliothek sowie die Komplexität und die dadurch verursachten Leistungseinbußen bei deren Implementierung zu verringern.

Sie können mit den Type.register*-APIs in der RTM-Version weiterhin Namespaces, Klassen und Schnittstellen definieren. Diese wurden jedoch von der Eigenschaft Function.prototype (wo sie sich in der CTP-Version befanden) in die Eigenschaft Type.prototype verschoben. Dies hat jedoch für Sie keine Auswirkungen, weil in der CTP-Version für die Eigenschaft window.Type das Alias Function verwendet wurde. Wir haben daher die empfohlene Verwendung dieser APIs geändert, obwohl sowohl Function.* als auch Type.* benutzt werden kann.

Wenn in allen definierten Typen-APIs und reflektionsbasierten APIs die Eigenschaft Type.prototype verwendet wird, entsteht ein konsistentes und logisches Entwurfsmuster.

Erstellen von Typen: Einfache Vererbung und Mehrfachvererbung

Wie in der CTP-Version werden in der RTM-Version Typen erstellt, die Unterklassen von Basistypen ableiten und auch beliebig viele Schnittstellen implementieren können. In der CTP-Version konnten Sie einen Typ definieren, der eine Unterklasse beliebig vieler Basistypen sein konnte. Dies hat sich geändert: In der RTM-Version können Sie nur die einfache Vererbung nutzen.

Schnittstellen

Die Definition von Schnittstellen wurde von der CTP-Version zur RTM-Version geändert. Die neue Definition spiegelt den Wegfall abstrakter Funktionen wider und verwendet das Prototypmodell. Das folgende Beispiel zeigt eine Deklaration einer Schnittstelle in der CTP-Version.

CTP-Version:

Custom.ICustomContract = function() {
    this.get_member = Function.abstractMethod;
    this.getAnotherMember = Function.abstractMethod;
}
Custom.ICustomContract.registerInterface("Custom.ICustomContract");

Custom.ICustomContract.prototype.get_member = function() { ...;}
Custom.ICustomContract.prototype.getAnotherMember = function() { ... }

Die RTM-Version definiert eine Schnittstelle ähnlich, verwendet jetzt jedoch die „eingegebenen“ Ausnahmen. Sie definiert keine abstrakten Methoden und keine bestimmte Implementierung. Im Versionsmodus besitzen Schnittstellen keinen Code und keine Mitgliedsdefinitionen.

Das folgende Beispiel zeigt eine Schnittstellendeklaration in der RTM-Version.

RTM-Version:

Custom.ICustomContract = function() {
    throw Error.notImplemented();
}
Custom.ICustomContract.registerInterface("Custom.ICustomContract");

Custom.ICustomContract.prototype = {
    get_member: function() { throw Error.notImplemented();},
    getAnotherMember: function() { throw Error.notImplemented(); } 
}

Wenn Sie Schnittstellen nutzen, können Sie mit reflektionsähnlichen APIs Typen testen. Wenn Sie Schnittstellen implementieren, fügen Sie dem Prototyp für den Typ ihre Mitgliederdefinitionen hinzu, statt sie dem Konstruktor hinzuzufügen, wie in der CTP-Version.

Enumerationen und Flags

Änderung in Beta 2: Sys.UI.Key["return"]] ist jetzt Sys.UI.Key.enter, und Sys.UI.Key["delete"] ist jetzt Sys.UI.Key.del.

Die Beispiele in diesem Abschnitt zeigen die Unterschiede zwischen der CTP-Version und der RTM-Version für Entwickler, die Enum- und Flag-Strukturen erstellen. Das folgende Beispiel zeigt eine enum-Definition in der CTP-Version.

CTP-Version:

Type.createEnum("MyEnum", "One", 1, "two", 2);

RTM-Version:

MyEnum = function() {
   /// <summary>..</summary>
}
MyEnum.prototype = {
  One: 1,
  Two: 2
}
MyEnum.registerEnum("MyEnum");

Eine Reihe von Enumerationen ist im Client FX verfügbar, z. B. Sys.UI.Key, Sys.UI.VisibilityMode und Sys.UI.MouseButton.

Eigenschaften, Methoden und Ereignisse

In der CTP-Version bestand das Modell zur Definition von Eigenschaften normalerweise darin, die Get- und Set-Methoden für die Eigenschaft durch Methoden mit den Präfixen „get_“ und „set_“ zu bestimmen. Dieses Modell bleibt in der RTM-Version bestehen, aber das Mitglied wird nun im Prototyp definiert statt in der Closure, wie bereits beschrieben.

Auf ähnliche Weise werden nun Methoden per Prototyp definiert.

Es gibt zwei allgemeine Arten von Ereignissen: ASP.NET AJAX (Clientobjekt)-Ereignisse und Ereignisse von DOM-Elementen. Sie können eine vereinfachte Syntax verwenden, um DOM-Elementereignisse in Ihren Klassen zu binden. Bei Clientobjektereignissen stellen Sie normalerweise Ereignisse bereit, die Seitenentwickler binden können, und die durch Ihre Klasse aufgerufen werden.

Client FX-Objekte können DOM-Ereignisse als ihre eigenen Ereignisse ausgeben. Damit haben Seitenentwickler die Möglichkeit, ihre eigenen Handler einzubinden. Dies wird im folgenden Beispiel gezeigt. Die Komponente macht das click-Ereignis des Elements direkt als click-Ereignis der Komponente verfügbar.

In der CTP-Version wurde ein Ereignis auf ASP.NET AJAX-Clientobjekten als Feld im Konstruktor deklariert. Der Handler von Seitenentwicklern, die im Ereignis eingebunden waren, wurde dann als Ergebnis des Ereignisses vom Clientobjekt aufgerufen. Clientobjekte wurden in ein DOM-Elementereignis eingebunden, indem sie an das Elementereignis zum Beispiel während der Initialisierung angehängt wurden. Dabei war es erforderlich, dass das Ereignis mit der dispose-Methode der Komponente entfernt wurde, wie im folgenden Beispiel gezeigt.

CTP-Version:

Custom.Button = function(...) {
    this.click = this.createEvent();

    this.dispose = function() {
        if (_clickHandler) {
            this.element.detachEvent('onclick', _clickHandler);
            _clickHandler = null;
        }
        
        Custom.Button.callBaseMethod(this, 'dispose');
    }
    
    this.initialize = function() {
        Custom.Button.callBaseMethod(this, 'initialize');
        
        _clickHandler = Function.createDelegate(this, this._onClick);
        this.element.attachEvent('onclick', _clickHandler);
    }
    
    this._onClick = function() {
        this.click.invoke(this, Sys.EventArgs.Empty);
        ...
    }

Das vorhergehende Beispiel zeigt auch das Modell, in dem attachEvent aufgerufen wird, um das click-Ereignis des Elements anzuhängen. Dies ähnelt eher dem Modell für Internet Explorer, wie durch das Beispiel für onclick gezeigt.

Skriptcode, mit dem Ihre eigenen Handler für Objektereignisse bereitgestellt werden, könnte wie folgt aussehen.

CTP-Version:

// Simple global handler.
var b = new Custom.Button();
b.click.add(OnClickHandler);
function OnClickHandler() {
    ...
}

Dieses Design wurde aus verschiedenen Gründen geändert. Diese umfassen die Verbesserung der Leistung, das Bereitstellen eines ähnlichen Programmiererlebnisses wie in .NET Framework und die Befolgung der ECMAScript Standards Designs, wie durch Kundenfeedback vorgeschlagen. In der RTM-Version stellen Sie einfach Ereignisse bereit, die einem Benennungsmuster mit den Namenskonventionen „add_“ und „remove_“ folgen, so wie Eigenschaften angezeigt werden. Tools können möglicherweise dieses Muster interpretieren. Sie könnten damit zum Beispiel Ereignisse in IntelliSense bestimmen.

In Komponenten höherer Ebenen fügen Sie jetzt einfach einen Handler einem internen EventHandlerList-Objekt hinzu, das durch das get_events()-Mitglied auf der Component-Basisklasse verfügbar ist. Im Unterschied zur CTP-Version erstellt die RTM-Version das Ereignis und dessen Einbindung zum erforderlichen Zeitpunkt, statt jedes Mal, wenn das Objekt erstellt wird. Das folgende Beispiel zeigt das Modell der RTM-Version.

In Beta 2 wird eine vereinfachte Syntax bereitgestellt, die automatisch den Delegierten erstellt und die zur Zuweisung mehrerer DOM-Ereignisse und Handler gleichzeitig verwendet werden kann. Das folgende Beispiel zeigt die entsprechende Vorgehensweise.

RTM-Version:

Custom.Button.prototype = {
    initialize: function() {
        Custom.Button.callBaseMethod(this, 'initialize');
        // Create the handler and add the DOM handler
        this._handler = 
            Function.createDelegate(this, this._onClickHandler);
        $addHandler(this.get_element(), 'click', this._handler);
        ..
        // Alternative syntax for single or multiple handlers. 
        // When multiple handlers are involved, this
        // syntax greatly reduces the amount of code you need
        $addHandlers(this.get_element(), 
          {  click: this._onClickHandler,
            mouseover: this._onMouseOverHandler,
            mouseout: this._onMouseOutHandler,
            keydown: this._onKeyDownHandler,
            focus: this._onFocusHandler,
              blur: this._onBlurHandler 
          }, this);
    }
    add_click: function(handler) {
      // Expose an event in this class
        this.get_events().addHandler('click', handler);
    },
    remove_click: function(handler) {
        this.get_events().removeHandler('click', handler);
    },
    dispose: function() {
        // Potential for dispose to be called more than once
        if (this._handler) {
            $removeHandler(this.get_element(), 'click', 
                this._handler);
            delete this._handler;
        }
      ..
      // Alternative syntax that can remove multiple handlers
      // attached through $addHandlers
      $clearHandlers(this.get_element());
        Custom.Button.callBaseMethod(this, 'dispose');
    },
    _onClickHandler: function() {
      // Invoke any page developer handlers that may be attached
        var ev = this.get_events().getHandler(this._handler);
        if (ev) {
            ev (this, Sys.EventArgs.Empty);
        }
    }
}

Das Design zeigt das Muster, nach dem Ereignishandler zur erforderlichen Zeit erstellt werden. Es verwendet die statischen Methoden eines neuen Typs mit dem Namen DomEvent, um mit einem standardbasierten Modell die Ereigniseinbindung für die DOM-Elementereignisse selbst hinzuzufügen und zu entfernen. Genau genommen stellen diese abstrakten APIs Unterstützung für die Browserkompatibilität bereit. Beachten Sie, dass in diesem Beispiel die Aliase $addHandler, $removeHandler, $addHandlers und $clearHandlers gezeigt werden. Diese werden später beschrieben.

In Fällen, in denen Sie eine Reihe von DOM-Ereigniseinbindungen in Clientkomponenten erstellen und diese dann mit der Methode dispose entfernen, können Sie APIs oder Aliase nutzen, die mehr als eine Ereigniseinbindung umfassen und den Delegate für Sie erstellen.

Wenn Sie Ihren eigenen Handler schreiben, sieht der Code etwa folgendermaßen aus. Der Parameter event ist optional, ermöglicht Ihnen jedoch, das Ereignis zu prüfen, zum Beispiel um zu bestimmen, welche Schaltfläche den Klick verursacht hat.

RTM-Version:

var b = new Custom.Button();
b.add_click(OnClickHandler);
function OnClickHandler(event) {
    ..
}

Browserkompatibilität

In der CTP-Version wurde ein Abstraktionsmodell für Browserkompatibilität verwendet, das sich auf APIs konzentriert hat, die auf Internet Explorer basierten. Der Server wurde dazu verwendet, eine Kompatibilitätsebene bereitzustellen, wenn ein anderer Browser als Internet Explorer genutzt wurde. Dazu wurde eine zusätzliche JavaScript-Datei heruntergeladen.

In der RTM-Veröffentlichungsversion wird diese Abstraktion beibehalten, aber sie basiert nun auf Standards und anderen Verbesserungen am Design. Infolgedessen ist ein Eingreifen des Servers nicht mehr erforderlich. Stattdessen enthält der Client einfachen Browsererkennungscode, der auf Fähigkeiten basiert, und Abstraktions-APIs und andere komponentenbasierte APIs verwenden diese Abstraktionen. Das oben beschriebene Ereignismodell verwendet zum Beispiel die Methoden DomEvent.addHandler und DomEvent.removeHandler auf eine eher standardbasierte Weise. Beachten Sie das Benennungsmuster des Ereignisses, wenn Sie click statt onclick verwenden. Diese API-Namen sind auch mit den Benennungsmustern konsistent, die für Komponenten und Typen im Client verwendet werden.

Erstellen von Debug- und Versionsskripts

Für unsere Designszenarios benötigen wir eine robuste Toolfunktionalität für ASP.NET AJAX. Hierfür ist es nötig, Debugskripts und die Fähigkeit zur Erstellung von Versionsskripts für Produktionsumgebungen zu unterstützen.

In der CTP-Version gab es kaum einen Unterschied zwischen der Debug- und der Veröffentlichungsversion von Skripts – außer, dass die Veröffentlichungsversionen komprimiert waren, um unnötigen Leerraum zu beseitigen. In der RTM-Version wurden beträchtliche Anstrengungen unternommen, um ein Tool- und Programmiererlebnis bereitzustellen, in der die Verwendung von Debugversionen der Skripts maßgeblich ist. Debugversionen der Skripts enthalten jetzt:

• Unterstützung für Dokumentkommentare. Diese sind enthalten, um möglicherweise IntelliSense in einem Tool zu etablieren und jedem Entwickler, der die APIs verwendet, Informationen bereitzustellen.

• Fehlerbehandlungen durch die Verwendung der Error-Erweiterungen werden später beschrieben.

• Benannte Funktionen. Anstatt Funktionen anonym zu halten, sind sie pseudobenannt, sodass Sie zusätzliche Informationen abrufen können, z. B. Kontext innerhalb einer Stapelverfolgung.

Dokumentkommentare

Wenn Sie Komponenten entwickeln, können Sie jetzt Typbeschreibungsinformationen in den Debugskripts bereitstellen, die Ihre benutzerdefinierten Typen definieren. Diese Informationen werden nützlich sein, um möglicherweise die in Visual Studio „Orcas“ für IntelliSense und die Anweisungsvervollständigung definierten Typeninformationen zu erweitern. (In Visual Studio 2005 wird dies nicht unterstützt.) Außerdem ermöglichen es Dokumentkommentare, das Client FX-Validierungsmodell für compilermäßige Prüfungen zu verwenden.

Dokumentkommentare bieten die folgenden Funktionen:

• Sie können Kommentare sofort im Konstruktor und in Mitgliedern definieren.

• Sie können Kommentare in der Eigenschaft „getter“ definieren, der die Eigenschaft „setter“ folgt, sowie im Ereignis-Adder.

• Sie können Kommentare im Schnittstellenkonstruktor definieren.

• Kommentare unterstützen komplizierte Parameter oder Rückgabetypen.

Ein Beispiel für Dokumentkommentare in der RTM-Version ist im folgenden Ausschnitt eines Rahmenverhaltens zu sehen.

RTM-Version:

Type.registerNamespace('Custom.UI');

Custom.UI.BorderBehavior = function(element) {
    /// <summary>A border behavior</summary>
    /// <param name="element">Associated element</param>
    Custom.UI.BorderBehavior.initializeBase(this, [element]);
}
Custom.UI.BorderBehavior.prototype = {
    ...
    get_color: function() {
        /// <summary>Color</summary>
        /// <value type="String"/>
       return this._color;
    },
    ..
}

Definieren von Typbeschreibungen

In der CTP-Version haben Sie Objekte erstellt, die ICustomTypeDescriptorProvider als Ergebnis einer Vererbung der Basisklasse Component implementieren. Sie haben eine Methode getDescriptor erstellt und ein Objekt TypeDescriptor zurückgegeben, das dazu verwendet wurde, deklarative Blöcke und Bindungen in XML-Skripts zu unterstützen.

Das folgende Beispiel zeigt die Definition eines Button-Steuerelements in der CTP-Version. (Beachten Sie die Verwendung des Closuremodells).

CTP-Version:

Custom.Button = function(associatedElement) {
    Custom.Button.initializeBase(this, [associatedElement]);
    ..
    this.getDescriptor = function() {
        var td = Sys.UI.Button.callBaseMethod(this, 'getDescriptor');
        
        td.addProperty('command', String);
        td.addProperty('argument', String);
        td.addEvent('click', true);
        return td;
    }

In der RTM-Version wurden Typbeschreibungen aus mehreren Gründen entfernt:

• XML-Skript erfordert beträchtliche Mengen zusätzlichen Skripts und eine Ladeverarbeitungslogik, die die Skriptgröße und -leistung beeinflusst. Dies produzierte zusätzlichen, unnötigen Aufwand in den häufigen Fällen, in denen Serversteuerelemente reichhaltiges Clientverhalten produzieren.

• XML-Skript ist am deklarativen Programmiermodell des Clients orientiert, das derzeit nur in der Futures-Version enthalten ist.

• Jedes Verhalten, das mit deklarativem XML-Skript definiert wird, kann auch mit JavaScript-Code erstellt werden, ohne dass der Aufwand der XML-Skriptverarbeitung erforderlich ist. (Selbstverständlich kann ein deklaratives XML-Skript mit angemessener Toolunterstützung einfacher sein.)

• Es gibt derzeit keine Toolunterstützung für deklaratives XML-Skript, wodurch es für den Autor schwerfällig und zu ausführlich wird.

Die Funktionen der Futures-Version sind in der RTM-Version weiterhin voll funktionsfähig, einschließlich XML-Skript. Daher können Sie eine Komponente schreiben, die auch von Seitenentwicklern verwendet werden kann, die mit XML-Skript arbeiten. Um diese Möglichkeit zu unterstützen, enthält die Futures-Version ein Objekt TypeDescriptor und kann ein solches Objekt mit einem JSON-Feld, das von der Komponente selbst definiert wird, einfach erstellen. Dies ist in der RTM-Version ohne die Definition von Truetypen möglich.

Das folgende Beispiel entspricht dem vorherigen Beispiel eines Button-Steuerelements. In diesem Falle wurde das Ganze jedoch mit der RTM-Version erstellt.

RTM-Version:

Custom.UI.Button = function(associatedElement) {
    Sys.UI.Button.initializeBase(this, [associatedElement]);
}
Custom.UI.Button.prototype = {
..
}
Custom.UI.Button.descriptor = {
    properties: [ {name: 'color', type: String } ],
    methods: [ .. ],
    events: [ {name:'click'}, .. ]
}

Sie können das Attribut readOnly hinzufügen, wenn Sie gewährleisten möchten, dass die Eigenschaft einen Standardwert wie im folgenden Beispiel hat.

RTM-Version:

MyControl.descriptor = 
    { properties: [{name: "title", type: String, readOnly: true}] }

Wenn ein Verweis auf ein DOM-Element nötig ist, verwenden Sie isDomElement:true wie im folgenden Beispiel.

RTM-Version:

MyControl.descriptor = 
    { properties: [{name: "...", isDomElement:true }] }

Ähnlich verfahren Sie, wenn die Komponente eine Eigenschaft definiert, die ein Verweis auf eine andere Komponente (vielleicht in einem Kompositionsformular) ist. In diesem Falle sollte der TypeDescriptor auf den Typ verweisen. Der folgende Code dient als Beispiel.

RTM-Version:

MyControl.descriptor = 
    { properties: [{name: "...", type: Custom.Button }] }

Wenn Sie XML-Skript in der Futures-Version verwenden, können Sie ein Tag erstellen, das auf dem Namen des Typs basiert. Das Futures-Skript führt alle notwendigen Schritte durch, um die Typbeschreibung zu verwenden.

Komponentenframework höherer Ebene

Die Komponentenfunktionen höherer Ebene wurden infolge des Kundenfeedbacks, aus Leistungsgründen und aus Erwägungen zum Workingset geändert. Wie im obigen Beispiel des Button-Steuerelements gezeigt, verwendet die Klasse DomEvent einen standardbasierten Ansatz, um eine konsistente Abstraktions-API für die Einbindung eines DOM-Ereignisses bereitzustellen. Diese Abstraktion funktioniert mit verschiedenen Browsern.

Einige APIs wurden von den Orten, an denen sie sich in der CTP-Version befanden (oftmals die Klasse Control) in neue DomElement-Typen in der RTM-Version verschoben, wo sie als statische Funktionen definiert sind. Dies verringert die Größe der Control-Klasse und ermöglicht Ihnen außerdem, diese Hilfsmethoden zu verwenden, die normalerweise DOM-Elemente umgeben, ohne ein Control-Objekt zu instanzieren. Das folgende Beispiel zeigt, wie das DomElement Objekt zu verwenden ist.

RTM-Version:

Sys.UI.DomElement.getLocation($get('AddressLine1'));

Beachten Sie die Verwendung eines neuen $get-Aliases in diesem Beispiel. Dies wird später erklärt.

Komponenten-, Steuerelement- und Verhaltensklassen

Die CTP-Version enthielt die Klassen Component, Control und Behavior, die viele APIs definierten und umfangreiche Funktionalität bereitgestellt haben. Sowohl Control als auch Behavior gehören zum Typ Component.

Dieses Modell wird in der RTM-Version weitergeführt. Jedoch wurde die Semantik dieser Klassen aufgrund unserer Untersuchungen und aufgrund ihrer ursprünglichen Designimplikationen geändert. In der CTP-Version wurde zum Beispiel eine Control-Instanz einem besonderen DOM-Element zugeordnet (siehe Konstruktor), und Sie konnten über das DOM-Element auf das Steuerelement zugreifen. Verhaltensweisen erforderten jedoch eine Control-Instanz, obwohl sie indirekt einem DOM-Element zugeordnet waren und durch die Sammlungseigenschaft der Control-Instanz gepflegt wurden.

In der RTM-Veröffentlichungsversion ist die Arbeit mit DOM-Elementen weitaus flexibler. Control und Behavior sind vom Konzept her ähnlich und werden beide einem bestimmten DOM-Element zugeordnet. Jedoch sind sie jetzt unabhängig voneinander.

In der RTM-Version können Sie eine einzige Control-Instanz einem DOM-Element zuordnen, und Sie können (wie in der CTP-Version) durch das control-Expando darauf zugreifen. Wenn ein Verhalten eine Eigenschaft Name hat, können Sie auf das Verhalten auch durch ein auf dem Namen basierendes Expando verweisen. Dem DOM-Element können mehrere Verhalten zugeordnet werden. Das folgende Beispiel stellt $create vor und verwendet ein neues $get-Alias, das in der RTM-Version zum Verweis auf Steuerelement- und Verhaltenstypen definiert wurde.

RTM-Version:

// Add a control and behavior to the GoShopping DOM element.
$create(Custom.UI.Button, {}, {'click':'myHandler'}, {}
    $get('GoShopping'));
$create(Custom.UI.BorderBehavior, {'name':'border'}, {}, {}, 
    $get('GoShopping'));

// Page developer accesses Button using the DOM element directly.
var gs = $get('GoShopping');
gs.control.set_text('Sale items');
gs.border.set_color('red');

// Page developer obtains the behavior using the $ separator.
var bb = $find(‘GoShopping$border);

Erstellen und Finden von Komponenten und Elementen

In der CTP-Version konnten Sie Komponenten in JavaScript instanzieren, Eigenschaften festlegen und initialize aufrufen. Alternativ konnten Sie mit XML-Skript auf sie verweisen. Die Modelle für die Arbeit mit Komponenten in der RTM-Version:

• Erstellen Sie wie zuvor Komponenten in JavaScript.

• Verwenden Sie ein neues Alias $create für Komponenten, das die Komponente instanziert und Eigenschaften festlegt sowie initialize aufruft – und so weiter. Dies ist ein leistungsfähiges Modell, das auch von Serversteuerelementen wirksam eingesetzt wird.

• Verwenden Sie XML-Skript, das in der Futures-Version weiterhin unterstützt wird, und das dieselbe Logik einsetzt wie das Alias $create in der RTM-Version.

Wenn in der RTM-Version eine Komponente mit $create instanziert wird, wird dem globalen Application-Objekt ein Verweis auf die Komponente hinzugefügt. Anschließend ist ein Alias verfügbar, mit dem Seitenentwickler Komponenten in Fällen suchen können, in denen der Seitenentwickler die Komponente nicht erstellt hat – zum Beispiel wenn die Komponente als Ergebnis von XML-Skript erstellt wurde.

Aliase „$object“, „$find“ und „$create“

In der CTP-Version könnten Sie das Konstrukt $object('GoShopping‘) verwenden, um auf eine Komponente zu verweisen, die infolge von XML-Skript erstellt wurde. In der Futures-Version wird dieses Alias weiterhin unterstützt.

Im RTM-Versionscode haben wir die Methode $find eingeführt. Sie können mit dieser Methode alle Komponenten suchen, die entweder über XML-Skript oder durch das Alias $create in JavaScript erstellt wurden. Dies bedeutet, dass sie Verweise auf Objekte erhalten, die von Serversteuerelementen und Extendern sowie von Ihrem eigenen JavaScript und durch XML-Skriptdeklarationen erstellt wurden.

Hinweis In der Betaversion können mit der $find-Syntax Komponenten, Verhalten und Steuerelemente gefunden werden, die bei der Anwendung mit ihrer ID registriert sind. Steuerelemente erhalten ihre ID von der ID ihres DOM-Elements. Verhalten können eine eindeutige ID erhalten, die standardmäßig auf elementId$className basiert – z. B. AddressLine1$AutoCompleteBehavior – und sind bei der Anwendung registriert.

$create stellt eine leistungsfähige, präzise Syntax zum Erstellen einer Komponente im Client bereit. Wenn der Alias mit Application-Methoden kombiniert wird, unterstützt er sogar das Szenario, in dem Zirkelbezüge zwischen Komponenten im Client hergestellt werden können, wie im Abschnitt „Anwendungsobjekt und Lebenszyklus“ später in diesem Dokument beschrieben.

$ und $get

In der CTP-Version wurde ein globaler Alias $() definiert, der der Funktion document.getElementById zugeordnet ist. Der Alias $() wird in den RTM- und Futures-Versionen nicht unterstützt. Aufgrund unseres Ziels der Vermeidung von Konflikten mit anderen AJAX-Frameworks kann $() nicht verwendet werden, da andere Frameworks diese Funktion ebenfalls definieren. Stattdessen definiert die RTM-Version eine Funktion $get(), die die gleiche Aufgabe erfüllt.

$addHandler, $removeHandler

Die Aliase $addHandler und $removeHandler in der RTM-Version stellen eine Kurzschriftnotation für die Einbindung und das Entfernen von DOM-Ereignissen bereit. Einige Beispiele wurden im vorherigen Beispiel zum Button-Steuerelement in der RTM-Version gezeigt. Vor allem aber wird dem Handler eine Instanz Sys.UI.DomEvent übergeben, die zu einem browserkompatiblen Ereignisobjekt führt. Im CTP-Modell schrieben Sie Handler, die stattdessen auf dem globalen Verweis window.event basierten, der nicht browserunabhängig war.

$addHandlers, $clearHandlers

Änderung in Beta 2: Die Methoden $addHandlers und $clearhandlers wurden eingeführt.

In vielen Fällen ist es sinnvoll, an DOM-Ereignisse für die Komponente mehrere Handler (Delegates) anzubinden. Anstatt manuell alle Delegates und jeweils einen Handler zu erstellen, der dann mit dem Ereignis dispose entfernt wird, können Sie eine abgekürzte Syntax verwenden, um mehrere Handler hinzuzufügen und zu entfernen. Hier ein Beispiel.

RTM-Version:

...
initialize: function() {
    ...
    var el = this.get_element();
   $addHandlers(el, 
        {[    'mouseover': this._mouseHoverHandler,
              'mouseout': this._mouseOutHandler,
              'focus', this._focusHandler,
            'blur', this_blurHandler 
        ]}, this);
        Custom.UI.Hover.callBaseMethod(this, 'initialize');
  },
  dispose: function() {
    if (!disposed) 
        $clearHandlers();
    Custom.UI.Hover.callBaseMethod(this, 'dispose');
},
...

Anwendungsobjekt und Lebenszyklus

Änderung in Beta 2: Mehrere neue Ereignisse wurden eingeführt, die Fehler beim Laden von Skriptbibliotheken verarbeiten. Die Methode Sys.Application.initialize kann vor window.onload aufgerufen werden, aber erst nachdem das DOM bereit ist. Seitenentwickler müssen sicherstellen, dass ihre Seitenlogik in der Funktion pageLoad durchgeführt wird.

Änderung in Beta 2: Das Laden des Skripts wird durch ein Clientobjekt durchgeführt, das sicherstellt, dass vor dem Ereignis window.onload angefangen wird, Skripts sequenziell zu laden und Komponenten zu erstellen. Die Methode initialize der Komponente wird nach dem Ereignis init aufgerufen, das von Sys.Application verursacht wird.

Änderung im RC: Das Standardmodell zum Laden von Skripts wurde geändert. Bibliothekskripts werden deklarativ am oberen Ende des Formulars gerendert, statt dynamisch am Ende des Formulars durch einen Aufruf von Sys.Application.queueScriptReference eingefügt zu werden. Dies bedeutet, dass die Bibliothekskripts vor dem Laden des UIs verfügbar sind. In der RTM-Version besteht die Absicht darin, ein Flag auf dem Steuerelement ScriptManager bereitzustellen, mit dem Seitenentwickler den Skriptbibliothek-Ladeprozess (vor oder nach dem UI) auswählen und ihr Anwendungsszenario effektiv verwalten können.

Instanzskripts (die die Clientkomponenten mit der Methode $create generieren) werden weiterhin mit der Methode ScriptLoader am Ende des Formulars eingereiht. Seitenentwickler sollten weiterhin die Clientfunktion pageLoad für Ihre Clientseitenlogik verwenden. Komponentenentwickler möchten sich gegebenenfalls an das Ereignis load des Objekts Sys.Application anhängen.

Änderung in RTM: Eine Eigenschaft LoadScriptsBeforeUI mit einem Standardwert false wurde dem Steuerelement ScriptManager hinzugefügt. Das Flag ermöglicht es Entwicklern, das Steuerelement ScriptManager die Skriptverweise entweder vor dem UI-Markup der Seite oder danach rendern zu lassen. Skript nach der Benutzeroberfläche zu laden kann Änderungen an Ihrer Anwendung erforderlich machen, damit kein unerwartetes Verhalten stattfindet, bevor Ihre Anwendungsskripts geladen und die Komponenten initialisiert sind. Wenn Skripts nach der Benutzeroberfläche geladen werden, wird der Anfang der Seite schnell angezeigt, aber die Anwendung ist unter Umständen noch nicht initialisiert. Die Seite könnte noch nicht in ihrem endgültigen Zustand sein, oder Benutzer könnten mit Elementen interagieren, bevor das Skript den Download- und Ausführungsvorgang beendet hat.

Bedeutende Änderung in RTM: Der Typ Sys.ScriptLoader ist nun privat, und alle Mitglieder dieses Typs sind daher ebenfalls privat. Diese Änderung wurde analog zur oben beschriebenen Änderung des Modells für das Rendern von Skriptverweisen vorgenommen.

Bedeutende Änderung in RTM: Weil Skripts durch<script>-Tags geladen werden, sind die Sys.Application-Ereignishandler zum Laden von Skripts nicht mehr erforderlich und wurden daher entfernt. Dies betrifft die folgenden Ereignisse:

• Sys.Application.add_loadTimedout

• Sys.Application.remove_loadTimedout

• Sys.Application.add_scriptLoadFailed

• Sys.Application.remove_scriptLoadFailed

• Sys.Application.get_scriptLoadTimeout

• Sys.Application.set_scriptLoadTimeout

Die ScriptManager.ScriptLoadTimeout-Eigenschaft der ScriptManager-Klasse wurde entfernt.

Änderung in Beta 2: „Dynamisches“ Laden der Skriptbibliothek unterstützt den Safari-Browser. Dateibasierte Skriptbibliotheken müssen den folgenden Code am Ende ihrer Skriptdatei aufweisen, um das Objekt Sys.Application darüber zu informieren, dass sie geladen wurden:

if(typeof(Sys) !== “undefined”) Sys.Application.notifyScriptLoaded();

Änderung im RC: In Verweisen auf Skriptbibliotheken, die aus einer eingebetteten Internetressource resultieren (normalerweise von Extendersteuerelementen oder Skriptsteuerelementen), wird standardmäßig automatisch das vorangehende Skript am Ende der Skriptbibliothek eingefügt. Komponentenentwickler können jedoch steuern, ob dieses Skript angefügt wird, indem sie die Eigenschaft NotifyScriptLoaded auf einer ScriptReference-Sammlung einstellen.

Ähnlich ist es, wenn ein Seitenentwickler mit dem Steuerelement ScriptManager auf eine Skriptressource in einer Assembly verweist. Hierbei kann die Eigenschaft NotifyScriptLoaded deklarativ auf dem Element ScriptReference definiert werden.

Änderung in RTM: Das Hinzufügen eines Aufrufs zur Methode Sys.Application.notifyScriptLoaded in Skriptdateien ist nur für asynchrone Postbacks notwendig. Entwicklern wird jedoch empfohlen, dieser Methode einen Aufruf von Skriptdateien hinzuzufügen, die vom Datenträger stammen.

In der CTP-Version gab es sowohl das Konzept eines Runtime- als auch eines Application-Objekts. In der CTP-Version war das Objekt Application für die Einbindung von window-Ereignissen, für die Suche nach der Funktion pageLoad des Seitenentwicklers (dem Ereignishandler load) sowie nach der Funktion pageUnload (dem Ereignishandler unload) verantwortlich. Die Funktion pageLoad wurde garantiert aufgerufen, nachdem alle Skripts geladen und alle in XML-Skript definierten Objekte erstellt und initialisiert wurden.

Die RTM-Version fasst Runtime- und Application-Objekte in einem einzigen Application-Objekt zusammen. Die RTM-Version definiert weiterhin die Ereignisse load und unload, führt aber auch ein Ereignis init ein, das normalerweise zur Erstellung von Objekten (mit dem Alias $create) verwendet wird. Sie können wie zuvor das Ereignis load (zugeordnet zu pageLoad) dazu verwenden, Objekte zu manipulieren. In der RTM-Version wird das Ereignis load auch während partieller Seitenaktualisierungen ausgelöst, und Sie können daher in der Funktion pageLoad Code ausführen, um Objekte zu manipulieren, die infolge des Roundtrips neu erstellt wurden.

Objekte, die mit der Syntax $create erstellt wurden, werden garantiert instanziert. Gleichzeitig ist sichergestellt, dass die Methode beginUpdate aufgerufen wird, Eigenschaften festgelegt werden und die Methoden endUpdate und initialize der Komponente aufgerufen werden. Zusätzlich können Objekte über Application registriert werden, sodass es möglich ist, die Komponenten über $find zu verwalten und zu suchen.

Die Methode $create definiert den zu erstellenden Typ, einfache Eigenschaften, Einbindungen von Ereignissen, Verweiseigenschaften, und das optionale DOM-Element. $create kann mit Szenarios arbeiten, in denen Komponenten Verweise auf andere Komponenten beinhalten. Normalerweise müssen Seitenentwickler $create nicht aufrufen, weil das Server FX alle $create-Logiken von Extendersteuerelementen und Skriptsteuerelementen bearbeitet.

Eigenschaftenänderungsbenachrichtigung

Sowohl die CTP- als auch die RTM-Version definieren Eigenschaftänderungsereignisse. In der RTM-Version lösen Sie weiterhin das Eigenschaftenänderungsereignis für Eigenschaften in Ihren Komponenten aus, für die gegebenenfalls Bindung erforderlich ist, oder für externe Ereignislistener.

Der Basiskomponententyp ist INotifyPropertyChange.

Entfernen

In der CTP-Version ist der Basistyp Sys.Component in die Schnittstelle Sys.IDisposable implementiert, die die Methode dispose definiert. Dieses Modell wird in der RTM-Version fortgesetzt. Jedoch wurde eine weitere Schnittstelle mit dem Namen Sys.INotifyDisposing eingeführt, die in Sys.Component definiert wird. Diese Schnittstelle ermöglicht es, dass Bindungen in Futures auf das Entfernen von Objekten warten. Bindungen können daher getrennte Komponenten darstellen.

Objekte müssen löschbar sein, damit die UpdatePanel-Szenarios unterstützt werden. Deshalb sollten Sie sicherstellen, dass Sie die Methode dispose so implementieren, dass sie mehrfache Aufrufe verarbeiten kann. Im Beispiel zum Button-Steuerelement im Ereignisabschnitt zeigt die Methode dispose, wie der click-Handler geprüft wird und $removeHandler sowie delete nur aufgerufen werden, wenn sie definiert sind. Beim Aufrufen der Funktion $clearHandlers wird diese Logik automatisch für Handler durchgeführt, die mit der Funktion $addHandlers eingebunden wurden.

Ebenso sollten Sie sicherstellen, dass alle untergeordneten Komponenten oder Objekte, die manuell entfernt werden, geprüft werden, da mit Application die Reihenfolge beim automatischen Entfernen von Objekten nicht garantiert wird.

Bindungen und Aktionen

In der CTP-Version waren Bindungen für Komponenten definiert. Daher benötigte eine Bindung eine Komponente, sodass die Bindung der Komponente hinzugefügt werden konnte.

Die RTM-Version unterstützt Bindungen nicht direkt, aber durch die Schnittstelle Sys.INotifyDisposing können Bindungen in den Futures-Skripts zum Beispiel über zu entfernende Objekte informiert werden und daher als selbstverwaltend angesehen werden. Bindungen in den Futures-Skripts können dadurch ohne Komponente oder Nachfrage in der RTM-Version erstellt werden. Dies bedeutet auch, dass Bindungen freier deklariert werden können als in der CTP-Version.

Bindungen in der Futures-Version erhalten jetzt sowohl ein Quell- als auch ein Zielobjekt und können auf Entfernungsereignisse dieser Objekte warten. Wenn ein Objekt entfernt wird, kann die zugehörige Bindung sich jetzt unabhängig selbst löschen.

 

Debuggen

Bedeutende Änderung in RTM: Die Clientklasse Debug wurde in Sys.Debug umbenannt. Hierdurch werden mögliche Konflikte mit anderen Frameworks vermieden.

Die Klasse Sys.Debug ermöglicht es Ihnen, Debuginformationen zur Browserkonsole, zum Debugger-Ausgabefenster von Visual Studio und in Internet Explorer zu einem <textarea>-Element in der Seite auszugeben. Sys.Debug unterstützt Methoden zur Generierung von Verfolgungsinformationen, zum Auslösen einer Assertion und zur Anzeige eines Objektabbilds. Der folgende Ausschnitt zeigt ein einfaches Beispiel für die Verwendung eines <textarea>-Elements zur Anzeige von Debuggerinformationen.

Dies ist der Code in der Skriptdatei:

RTM-Version:

onClick: function(e) {
    this.set_checked(!this._checked);
        
    Sys.Debug.trace("Element: " + this.get_element());
    Sys.Debug.traceDump("Component: " + this);

Dies ist der Code in der .aspx-Datei:

RTM-Version:

<script type="text/javascript">
    function pageLoad() {
        $create(Custom.UI.CheckBox,{},{},{}, $get("checkbox"));  
    }
</script>
<body>
  <form id="form1" runat="server">
     <div>
      <asp:ScriptManager runat="server" ID="SM01">
        <Scripts>
            <asp:ScriptReference Path="CheckBox.js" /> 
      </Scripts>
    </asp:ScriptManager>
        
    <span id="checkbox" tabindex="0">Click me</span>
    <br /><br />
    <textarea id="traceConsole" 
      style="font-family:tahoma;font-size:small;" 
      cols="100" rows="20" ></textarea>
    </div>
    </form>
</body>

Die Ausgabe sieht folgendermaßen aus:

 

Globalisierung und Lokalisierung

Änderung in Beta 2: Globalisierung und Lokalisierungsfunktionen wurden hinzugefügt.

Globalisierung

Änderung im RC: In der RC-Version können Date- und Number-Analysen auch mit den Methoden parse und localeParse im Funktionssatz für die Globalisierung durchgeführt werden.

Bedeutende Änderung in RTM: Die Funktionen Date.parse und Number.parse wurden in Date.parselnvariant und Number.parseInvariant umbenannt. Analog hierzu heißen die Funktionen Date.localeParse und Number.localeParse nun Date.parseLocale und Number.parseLocale. Durch diese Änderungen werden die APIs konsistent gehalten. Darüber hinaus beseitigen sie möglicherweise Probleme bei Anwendungen, die sich auf das bestimmte Verhalten integrierter parse-Funktionen dieser Typen verlassen.

Globalisierung wird im Client FX durch den Typ Sys.CultureInfoTyp unterstützt. Dieser Typ definiert zwei JSON-Objekte, InvariantCulture und CurrentCulture.

In der CTP-Version wurde der Typ CurrentCulture durch einen Serverhandler festgelegt, der von der Clientanwendung aufgerufen wurde. In der RTM-Version wird dieser Typ inline auf die Seite geschrieben. Durch diese Änderung wird ein Rückruf zum Server eliminiert, aber ein Inlinetyp kann im Client nicht zwischengespeichert werden. Die Objekte sind jedoch klein.

Daw Serverframework kann Sys.CultureInfo. CurrentCulture im Client durch das Serialisieren des .NET-CultureInfo-Objekts für CurrentCulture des vorhandenen Threads beim Rendering im ScriptManager-Steuerelement erstellen. Dies bedeutet, dass Sie die Kultur programmgesteuert mit Serververfahren von ASP.NET 2.0 definieren können, die standardmäßig eine Zuordnung des ACCEPT_LANG-Headers der eingehenden Anforderung verwenden. Normalerweise setzen Sie Culture=”Auto” und UICulture=”Auto” in der @ Page-Direktive der Seite oder legen diese Werte direkt fest, z. B. durch Aufrufen der Methode InitializeCulture in der generierten Seitenklasse.

Im Client können Ihr Code und alle Typen, die aus Serverextendern resultieren die APIs format und localeFormat verwenden, die mit den Typen Number, Date und String hinzugefügt werden, sowie die APIs parseInvariant und parseLocale, die mit den Typen Date und Number hinzugefügt werden. Das folgende Beispiel zeigt, wie ein Date-Objekt mit einem vordefinierten CultureInfo-Objekt formatiert und die Eingabe für ein Date-Objekt analysiert wird.

CTP-Version:

var d = new Date();
$('DateLocale').innerHTML = d.toFormattedString("M");

// Rendered output assuming a CultureInfo obtained for Culture=”fr” 
// 31, octobre

In der RTM-Version ermöglichen die neuen APIs eine spezifische Formatierung.

RTM-Version:

var d = new Date();
$get('DateLocale').innerHTML = d.localeFormat("M");

// Rendered output assuming a CultureInfo obtained for Culture=“fr”
// 31, octobre

// Parse. This assumes that the input value follows the 'd' format'
var s = $get('TextBoxDate').value.trim();
var d = Date.parseLocale (s, "d");
$get('Date').innerHTML = d;

Um die Globalisierungsunterstützung zu verwenden, müssen Sie explizit die Eigenschaft ScriptManager.EnableScriptGlobalization auf true setzen, wie im folgenden Beispiel gezeigt. Wie erwähnt, werden Sie auf ein JSON-Objekt stoßen, das inline in die Seite geschrieben wurde.

RTM-Version:

<asp:scriptmanager runat=”server” EnableScriptGlobalization=”true” />

Lokalisierung

Änderung im RC: Die RC-Version enthält eine Reihe von Fehlerbehebungen. Insbesondere wurde die Unterstützung für ResourceUICultures auf pfadbasierten Skriptverweisen verbessert.

Weiterhin verfügt die RTM-Version nun über Unterstützung für Lokalisierung. Die folgenden Hauptszenarios werden unterstützt:

• Clientkomponenten verfügen über Benutzeroberflächenelemente, Ausnahmemeldungen und weitere Elemente, die private Elemente der Komponente sind. In diesem Falle können für die Clientkomponente auf zwei Arten lokalisierte Ressourcen bereitgestellt werden: mit einer eingebetteten Ressource (und daher einer Satellitenassembly) oder als Teil des Bibliothekskriptverweises selbst.

• Clientkomponenten haben öffentliche Eigenschaften, die durch den Seitenentwickler direkt eingestellt und daher lokalisiert werden können. Es gibt auch hier zwei mögliche Szenarios: Die Komponente wird von einem Serverextendersteuerelement oder Skriptsteuerelement verarbeitet, oder sie wird direkt im Client durch den Seitenentwickler erstellt.

Lokalisierte Ressourcen für eine Komponente werden als JSON-Objekt bereitgestellt, und auf sie wird in der Komponente über das Objekt verwiesen. Im Client FX werden zum Beispiel Ausnahmemeldungen in Debugskripts ausgelöst, in denen mit dem Typ Sys.Res<ExceptionMessageKey> auf die Nachricht verwiesen wird.

Diese Objekte werden normalerweise automatisch vom Skriptressourcenhandler an den Skriptverweis angehängt, wenn er Skripts von eingebetteten Ressourcen in Serverassemblys liest.

Lokalisierte Ressourcen von Serverassemblys

Änderung im RC: Der ScriptResource.axd-Handler kann für das Zwischenspeichern und Komprimieren konfiguriert werden. Der Handler unterstützt jetzt auch die Ressourcenaustauschlogik, die vom WebResource.axd-Handler unterstützt wird. Sie können Austauschverweise in der eingebetteten Webressource hinzufügen, die dann vom ScriptResource.axd-Handler verarbeitet werden.

Hinweis  : Der Austauschcode(<%= WebResource() %>) fügt einen Webresource.axd-URL ein, und der Code <%= ScriptResource() %> fügt einen ScriptResource.axd-URL ein.

Änderung im RC: Der benutzerdefinierte Clienttyp und der Namespace, der von der eingebetteten Serverressource generiert wird, werden automatisch registriert.

Die Ressourcen einer Skriptbibliothek werden abhängig vom eingehenden ACCEPT_LANG-Header des Browsers vom Server aufgerufen und erstellt. Der der RTM-Version hinzugefügte Skriptressourcenhandler ist für die Generierung eines Streams zum Client verantwortlich, der sowohl den Code der Skriptbibliothek als auch die automatisch generierte Ressource für den vorgegebenen Wert von UICulture enthält. Wenn nötig, können Sie ASP.NET-Code verwenden, um den Wert für UICulture festzulegen; die Verwendung von ACCEPT_LANG ist einfach das Standardmodell.

Komponentenentwickler können das .NET-Lokalisierungsmodell für Satellitenressourcen einsetzen (und so Dienstvorteile zusammenfassen) und sich auf die automatische Generierung verlassen, die die relevante Ressource über ein UICulture-Fallbackmodell abwickelt. Dies bedeutet, dass der normale .NET-Lokalisierungsworkflow und das Toolset zu diesem Modell beitragen.

Standardmäßig ist die Lokalisierung in einer Webseite nicht aktiviert. Um die Lokalisierung zu verwenden, müssen Sie die Eigenschaft ScriptManager.EnableScriptLocalization auf true setzen, wie im folgenden Beispiel gezeigt:

RTM-Version:

<asp:scriptmanager runat=”server” EnableScriptLocalization=”true” />

Der folgende Ausschnitt stellt dar, wie ein benutzerdefiniertes Extendersteuerelement mit lokalisierten Ressourcen erstellt wird. Auf diese Ressourcen wird durch einen benutzerdefinierten Typ im Client verwiesen. Nehmen Sie an, dass das Projekt eine Klassenbibliothek mit dem Namen „Custom.UI.ToggleButton“ sei.

RTM-Version:

// AssemblyInfo.cs
// Define the script resources attributes. 
// The WebResource defines the script library for the client behavior
[assembly:webResource("Custom.UI.ToggleButton.ToggleButtonBehavior.js"
    , "text/javascript")]
// The ScriptResource attribute references the WebResource attribute and  
// points to the name of the embedded RESX(as a resource), and defines the 
// custom client type.
[assembly: ScriptResource("Custom.UI.ToggleButton.ToggleButtonBehavior.js", 
    "Custom.UI.ToggleButton.ToggleButtonBehavior", "Custom.UI.Res")]

// ToggleButtonBehavior.js
// Marked as embedded resource in the class library.
  ..
  this.get_element().innerHTML = Custom.UI.Res.unhoverText;
  ..

// ToggleButtonBehavior.resx, ToggleButtonBehavior.fr.resx
// ToggleButtonBehavior.ja.resx, ..
// Marked as embedded resource. These are compiled by Visual Studio to 
// embedded .resource ‘files’ . 
// The neutral culture is embedded in the main assembly, and others are 
// embedded in satellite assemblies under the culture folder structure

In der Seite für diesen Extender deklarieren Sie den Extender und das Steuerelement ScriptManager wie zuvor gezeigt. Wenn die Seite ausgeführt wird, generiert das Steuerelement ScriptManager mit dem ScriptResource.axd-Handler einen Skriptverweis auf das Bibliothekskript. Die Anforderung weist den Handler an, das Bibliothekskript sowie die relevante Ressource für die gegebene UI-Kultur zu beziehen. Dieser Ressourcensatz wird dann zum angegebenen benutzerdefinierten Typ serialisiert, wie im Attribut ScriptResource oben angegeben.

Der folgende Ausschnitt stellt die Ausgabe der Skriptbibliothek dar, die an den Client gesendet wird.

RTM-Version:

..
// Type generated by the framework automatically
Type.registerNamespace('Custom.UI');
Custom.UI.Res={
    ""unhoverText":"©±",
    ""hoverText":"¤µ©±"
};

Lokalisierte Ressourcen von statischen, dateibasierten Skripts

Die Ressourcen einer Skriptbibliothek werden vom Server mithilfe eines Modells gerendert, das das Steuerelement ScriptManager umfasst. Es gibt jedoch keinen integrierten, dynamischen Prozess zur Kombination der Bibliothek mit den für die aktuelle UICulture relevanten Ressourcen. Stattdessen interpretiert der Server UICulture wie oben beschrieben. Es wird jedoch erwartet, dass die Skriptbibliothek und ihre Ressource bereits kombiniert wurden, möglicherweise durch einen Buildprozess. Der Buildprozess könnte die assemblybasierte Bibliothek und ihre Ressourcen sowie Satellitenassemblys beinhalten.

Um die richtige Skriptdatei auszuwählen, die die Anforderung abwickelt, geben Sie im Steuerelement ScriptManager mit einem Attribut auf dem Skriptverweis an, welche Werte der ResourceUICultures unterstützt werden, wie im folgenden Beispiel gezeigt:

RTM-Version:

<asp:scriptmanager runat="server" EnableScriptLocalization="true"  
  ScriptMode="Release">
  <scripts>
    <asp:scriptreference path="~/scripts/Custom.UI.js"
      ResourceUICultures="en-GB, fr-FR, fr-CA, ja-JP, de-DE" />
  </scripts>
</asp:scriptmanager>

// If the UICulture on the thread is ja-JP, the following 
// script reference is rendered.
// (Note that ScriptMode is set to "Release".)

<script src=”../scripts/Custom.UI.ja-JP.js />

Das Steuerelement ScriptManager folgert den Wert für UICulture aus dem Thread im Server, interpretiert den Skriptverweis (und stellt dabei eine Möglichkeit für ein Fallback bereit), und sendet eine Skriptbibliothek, die einer gegebenen UICulture entspricht.

 

Netzwerk

Aufrufen von Webdienstmethoden vom Skript

Das Clientproxydesign für Webdienste wurde geändert, um Methodenaufrufe zu vereinfachen und um größere Flexibilität bei der Zuordnung von Methodenaufrufen zu Rückruffunktionen bereitzustellen.

In der Methodendefinition der CTP-Version wurden Clientaufrufe und Rückrufe wie in den folgenden Beispielen gezeigt definiert. Das erste Beispiel zeigt den Servercode, der in der CTP-Version eine Webdienstmethode definiert.

CTP-Version:

public class MyService: System.Web.Services.WebService
{
[WebMethod]
public string MyWebMethod(int param1, string param2) {
    ...
}

Das nächste Beispiel zeigt den Clientcode, der die Methode aufruft.

CTP-Version:

// Invoke method, specifying a "succeeded" callback function.
MyNS.MyService.MyMethod(126, "my value", OnComplete, 
    OnTimeout, OnError, onAborted, "MyUserContext");

// Callback function.
function OnComplete(result, response, userContext) {
   // Use result.
}

Die weiteren zwei Beispiele zeigen die entsprechenden Methodendefinitionen der RTM-Version. Die Servermethode der RTM-Version sieht wie im folgenden Beispiel aus.

RTM-Version:

[ScriptService] 
public class MyService: System.Web.Services.WebService
{
    [WebMethod]
    public string MyMethod(int param1, string param2) {
        ...
    }

Der Clientcode zum Aufruf der Methode in der RTM-Version wird im folgenden Beispiel dargestellt.

RTM-Version:

// Invoke method, specifying callback functions and user context.
MyNS.MyService.MyMethod(126, "my value", OnSuccess, OnFailure, 
    "MyUserContext");

// Callback function
function OnSuccess(result, userContext, methodName) {
    // Use result.
}

In der RTM-Version können Sie Standardrückruffunktionen und einen Benutzerkontext angeben, sodass es beim Aufruf der Webdienstmethode nicht mehr erforderlich ist, diese als Parameter zu übergeben. Das folgende Clientskript legt Standardrückruffunktionen fest und ruft dann die Webdienstmethode zweimal mit verschiedenen Parametern auf.

RTM-Version:

var Fs = MyNS.MyService;
Fs.set_defaultSucceededCallback(OnSuccess);
Fs.set_defaultFailedCallback(OnFailure);
Fs.set_defaultUserContext("MyUserContext");
Fs.set_timeout(100);

// Invoke method without specifying callback functions or user context.
Fs.MyMethod(126, "value one");
Fs.MyMethod(456, "value two");

Serverattribute

In der CTP-Version wurden bereits im .NET Framework definierte Serverattribute zur Bestimmung von Verhalten beim Aufruf von Webdienstmethoden verwendet. In der RTM-Version werden neue Serverattribute definiert, um besonderes Verhalten festzulegen. Diese Änderung wurde aufgrund von Sicherheitsaspekten und zur Vermeidung der Wiederverwendung bestehender Attribute mit verschiedenen Semantiken vorgenommen.

Es wurden die folgenden spezifischen Änderungen an Webmethodenattributen vorgenommen:

• Ein Attribut [ScriptService] ist auf der Webdienstklasse erforderlich, um seine Methoden vom Clientskript aufrufen zu können.

• Das Attribut [ScriptIgnore] schließt Eigenschaften oder Felder von der JSON-Serialisierung aus, damit sie auf Skriptproxys für einen Servertyp nicht erscheinen. Dies entspricht dem Attribut [XmlIgnore] der CTP-Version.

• Das Attribut [GenerateScriptType()] generiert Skriptproxys für Servertypen, und zusätzlich Typen, die als Eingabeparameter oder Rückgabetypen auf Webmethoden verwendet werden. Dieses Attribut kann der Webdienstklasse oder jeder Webdienstmethode hinzugefügt werden. Es entspricht dem Attribut [XmlInclude()] der CTP-Version.

WebServiceProxy-Klasse

Die Klasse WebServiceProxy wurde hinzugefügt, um den Aufruf von Webdiensten zu ermöglichen, die nicht als Dienstverweise mit dem Steuerelement ScriptManager (mit dem Element <asp:ServiceReferences>) deklariert wurden. WebServiceProxy wird auch als abstrakte JavaScript-Basisklasse für generierte Javascript-Proxys für alle Webdienste verwendet, die in der Sammlung ServiceReferences angegeben sind.

Unterstützung für WCF-Webdienste

In der RTM-Version ist es nicht mehr möglich, Windows Communication Foundation (WCF)-Webdienste (.svc-Dateien) vom Skript aufzurufen. Diese Möglichkeit wird durch eine verbesserte Implementierung ersetzt, die wir wahrscheinlich einschließlich voller WCF-Integration in bevorstehenden „Orcas“-CTP-Versionen bereitstellen werden.

Erweiterte Netzwerkszenarios, die nicht in der RTM-Version verfügbar sind

Die folgenden Netzwerkfeatures der CTP-Version werden in der RTM-Version nicht mehr verfügbar sein:

• Der Exekutor Iframe. Dieses Feature bot Unterstützung für domänenübergreifende Aufrufe, ist jedoch unter anderem aus Sicherheitsgründen in der RTM-Version nicht mehr verfügbar.

• Folgende selten verwendete Features:

  • Assemblybasierte Methodenaufrufe

  • InitialData-Steuerelement

  • Batchverarbeitung von Webdienstaufrufen

 

Anwendungsdienste

Bedeutende Änderung in RTM: Die RTM-Version erfordert zusätzliche <httpHandler>-Zuordnungen in der Datei „Web.config“, die von den Clientanwendungsdienstproxys verwendet wird.

In der RTM-Version stellen wir ein vereinfachtes und flexibleres Design für die Verwendung der Authentifizierung und der Profildienste vom Skript bereit. Das Design ist konform mit dem Design für das Aufrufen benutzerdefinierter .asmx-Webdienste vom Skript (siehe „Aufrufen von Webdienstmethoden vom Skript“ weiter oben).

Für die Anwendungsdienste in der RTM-Version sind Einträge in der Datei „Web.config“ erforderlich. Weitere Informationen finden Sie im Abschnitt zur Konfiguration.

Profildienst

Die RTM-Veröffentlichungsversion des Profildiensts ist nicht als Komponente implementiert, was dem Webdienst-Skriptproxymodell entspricht. In der Futures-Version wird jedoch eine Implementierung des Profildiensts als Komponente bereitgestellt.

Die wichtigsten Änderungen im Profildienst von der CTP- zur RTM-Version sind:

• Der Klassenname wurde von Sys._Profile in Sys.Services. _ProfileService geändert.

• Die globale Instanz wurde von Sys.Profile in Sys.Services.ProfileService verschoben.

• Sie können Standardrückruffunktionen für Speichern, Laden und Fehler angeben.

• Die neuen Methoden save und load wurden hinzugefügt, und übernehmen ein Zeichenfolgenarray als Parameter.

• Profilgruppen werden jetzt unterstützt.

• Sie können Profileigenschaften vorab mit ScriptManager und dem Steuermarkup ProfileServiceManager laden.

• Die Funktion AutoSave wurde entfernt.

• Die Ereignisse saved, loaded und propertyChanged wurden entfernt.

Die Version des Profildienstes, die in der Futures-Version bereitgestellt wird, füllt die Lücke zwischen der Profilkomponente der CTP-Version und dem Profilproxy der RTM-Version. Sie bietet folgende Features:

• Der Klassenname ist Sys.Preview.Services.Components.Profile.

• Das XML-Skriptmarkup ist identisch (<profile...>).

• Die Komponente lädt das Profil automatisch beim Laden der Seite, wenn kein vorheriges Laden als Alternative angegeben ist.

• Die Komponente enthält das Feature AutoSave.

• Die Komponente enthält die Ereignisse saved und loaded.

• Die Komponente umfasst die Methoden getProperty()und setProperty().

• Die Komponente kann das Ziel oder die Quelle für eine Binding-Komponente sein.

Die folgenden Beispiele veranschaulichen die Verwendung des Profildiensts in der Futures-Version.

Das erste Beispiel zeigt, wie Profileigenschaften vorab geladen werden.

Futures-Version:

<!-- Preload specific properties with the page -->
<asp:ScriptManager>
  <ProfileService 
     Path = "~/myapp/profileserviceurl.asmx"
     LoadProperties = "SimpleProperty, Group.GroupedProperty" />
</ asp:ScriptManager>

Das folgende Beispiel zeigt, wie Profileigenschaften geladen werden.

Futures-Version:

// Load specific properties, after setting default completed
// and failed callback functions. Sys.Services.ProfileService.load(["SimpleProperty", 
    "Group.GroupedProperty"]); 

// Load all properties marked as "read access" in the Web service,
// after setting default completed and failed callback functions.
Sys.Services.ProfileService.load();

// Specify explicit callbacks rather than using defaults. "88" is 
// passed to the callback function as user context.
Sys.Services.ProfileService.load(props, loadCompletedCallback, 
    failedCallback, 88);

Das nachfolgende Beispiel illustriert Zugriffseigenschaften.

Futures-Version:

var x = Sys.Services.ProfileService.properties.SimpleProperty;

var x = Sys.Services.ProfileService.properties.Group.GroupedProperty1;

var x = Sys.Services.ProfileService.properties.Group.GroupedComplexTypeProperty.AddressLine1;

Das nächste Beispiel demonstriert die Änderung der Eigenschaftswerte.

Futures-Version:

Sys.Services.ProfileService.properties.SimpleProperty = "value";

if(!Sys.Services.ProfileService.properties.Group) {
      Sys.Services.ProfileService.properties.Group = 
          new Sys.Services.ProfileGroup();
}
Sys.Services.ProfileService.properties.Group.GroupedProperty1 = 
    "group value";
Sys.Services.ProfileService.properties.Group.GroupedComplexTypeProperty = 
    { AddressLine1: "abc", AddressLine2: "xyz" };

Das folgende Beispiel zeigt, wie Eigenschaftswerte gespeichert werden.

Futures-Version:

// Save specific properties, after setting default success and 
// fail callback functions.
Sys.Services.ProfileService.save(["SimpleProperty", 
    "Group.GroupedProperty"]); 
// Save all properties in the .properties object, after 
// setting default completed and failed callback functions.
Sys.Services.ProfileService.save(); 

// Specify explicit callbacks, rather than using defaults. "88" is 
// passed to the callback function as user context.
Sys.Services.ProfileService.save(props, saveCompletedCallback, 
    failedCallback, 88);

Das nachfolgende Beispiel demonstriert die vollständigen Rückruffunktionssignaturen.

Futures-Version:

function loadCompletedCallback(numPropertiesLoaded, userContext, methodName) {...} 

function saveCompletedCallback(numPropertiesSaved, userContext, methodName) {...}

Das letzte Beispiel zeigt die Fehlschlag-Rückruffunktionssignatur.

Futures-Version:

function failedCallback(errorObject, userContext, methodName) {...}

Authentifizierungsdienst

Folgende Änderungen wurden von der CTP- zur RTM-Version am Authentifizierungsdienst vorgenommen:

• Sie können jetzt Standardrückruffunktionen für login, logout und error festlegen.

• Die Funktionen login und logout können einen Parameter redirectUrl beinhalten, der einen URL angibt, auf den bei Beendigung umgeleitet wird.

• Die Funktion login beinhaltet einen Parameter customInfo, der zum späteren Gebrauch reserviert ist und auf Null festgelegt werden sollte.

• Die Methode get_isLoggedIn wurde hinzugefügt. Diese Methode nimmt keine Verbindung zum Server auf, sondern ist stattdessen bezüglich der Komponenten stets auf dem aktuellen Stand. Wenn Sie die Funktion login ohne redirectUrl-Parameter aufrufen, und die Anmeldung gelingt, gibt get_isLoggedIn den Wert true zurück.

• Die Methode verifyUser wurde entfernt.

Die folgenden Beispiele zeigen, wie in der RTM-Version Authentifizierungen durchgeführt werden.

RTM-Version:

var loggedIn = Sys.Services.AuthenticationService.get_isLoggedIn(); 

Sys.Services.AuthenticationService.login(userLogin, userPassword, 
    isPersistentCookie, customInfo, redirectUrl, 
    loginCompletedCallback, 
    failedCallback, userContext);

Sys.Services.AuthenticationService.logout(redirectUrl, 
    logoutCompletedCallback, failedCallback, userContext);

Das folgende Beispiel zeigt die Signatur für die abgeschlossene Rückruffunktion.

RTM-Version:

function loginCompleted(validCredentials, userContext, methodName) {..}

Das folgende Beispiel zeigt die Signatur für die fehlgeschlagene Rückruffunktion.

RTM-Version:

function loginFailed(errorObject, userContext, methodName) {..}

 

Änderungen am Server FX im Detail

Das ASP.NET AJAX-Serverframework unterstützt Komponentenentwickler, die neue Serversteuerelemente und Extendersteuerelemente schreiben, sowie Seitenentwickler, die diese Steuerelemente nutzen.

Das Serverframework führt auch das Steuerelement UpdatePanel sowie weitere Steuerelemente ein, die zusammen eine schrittweise Aktualisierung von ASP.NET-Seiten oder Webanwendungen mit AJAX-typischem Verhalten unterstützen.

Das Hauptsteuerelement im Server FX ist das Steuerelement ScriptManager und das nahe verwandte Steuerelement ScriptManagerProxy. Diese Steuerelemente definieren eine Seite im AJAX-Stil durch Liefern und Verwalten der Client FX-Bibliothekskripts.

Konfiguration

Einträge im Konfigurationsabschnitt

Die folgenden Einträge in der Datei „Web.config“ der Anwendung sind erforderlich, um einen Abschnitthandler für den Abschnitt <system.web.extensions> bereitzustellen.

Hinweis Einige Zeilen wurden aus Formatierungsgründen absichtlich aufgeteilt.

RTM-Version:

<configuration>
  <configSections>
    <sectionGroup name="system.web.extensions" 
      type="System.Web.Configuration.
        SystemWebExtensionsSectionGroup, 
        System.Web.Extensions, 
        Version=1.0.61025.0, Culture=neutral, 
        PublicKeyToken=31bf3856ad364e35">
      <sectionGroup name="scripting" 
        type="System.Web.Configuration.ScriptingSectionGroup, 
          System.Web.Extensions, Version=1.0.61025.0, 
          Culture=neutral, PublicKeyToken=31bf3856ad364e35">
        <section name="scriptResourceHandler" 
          type="System.Web.Configuration.
            ScriptingScriptResourceHandlerSection,      
            System.Web.Extensions, Version=1.0.61025.0, 
            Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
            requirePermission="false" 
            allowDefinition="MachineToApplication"/>
        <sectionGroup name="webServices" 
          type="System.Web.Configuration.
            ScriptingWebServicesSectionGroup, 
            System.Web.Extensions, Version=1.0.61025.0, 
            Culture=neutral, 
            PublicKeyToken=31bf3856ad364e35">
          <section name="jsonSerialization"      
            type="System.Web.Configuration.
              ScriptingJsonSerializationSection, 
              System.Web.Extensions, Version=1.0.61025.0, 
              Culture=neutral, 
              PublicKeyToken=31bf3856ad364e35" 
              requirePermission="false" 
              allowDefinition="Everywhere" />
          <section name="profileService"   
            type="System.Web.Configuration.
            ScriptingProfileServiceSection, 
            System.Web.Extensions, Version=1.0.61025.0,      
            Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
            requirePermission="false" 
            allowDefinition="MachineToApplication" />
          <section name="authenticationService" 
            type="System.Web.Configuration.
              ScriptingAuthenticationServiceSection, 
                 System.Web.Extensions, Version=1.0.61025.0, 
              Culture=neutral, 
              PublicKeyToken=31bf3856ad364e35" 
              requirePermission="false" 
              allowDefinition="MachineToApplication" />
        </sectionGroup>
      </sectionGroup>
    </sectionGroup>
</configSections>
..

Einträge im Konfigurationsabschnitt „system.web“

Das folgende Beispiel zeigt Einträge im Abschnitt System.Web der Datei „Web.config“ der Anwendung.

Hinweis Einige Zeilen wurden aus Formatierungsgründen absichtlich aufgeteilt.

RTM-Version:

<system.web>
  <pages>
    <controls>
      <add tagPrefix="asp" namespace="System.Web.UI" 
        assembly="System.Web.Extensions, Version=1.0.61025.0, 
        Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    </controls>
    ..
  </pages>
  <compilation debug="false">
    <assemblies>
      <add assembly="System.Web.Extensions, 
        Version=1.0.61025.0, Culture=neutral, 
        PublicKeyToken=31bf3856ad364e35"/>
    </assemblies>
    ..
  </compilation>

  <httpHandlers>
    <remove verb="*" path="*.asmx"/>
    <add verb="*" path="*.asmx" validate="false" 
      type="System.Web.Script.Services.ScriptHandlerFactory, 
        System.Web.Extensions, Version=1.0.61025.0, 
        Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    <add verb="*" path="*_AppService.axd" validate="false" 
      type="System.Web.Script.Services.ScriptHandlerFactory, 
        System.Web.Extensions, Version=1.0.61025.0, 
        Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    <add verb="GET,HEAD" path="ScriptResource.axd" 
      type="System.Web.Handlers.ScriptResourceHandler, 
        System.Web.Extensions, Version=1.0.61025.0, 
        Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
        validate="false"/>
  </httpHandlers>

  <httpModules>
    <add name="ScriptModule" 
      type="System.Web.Handlers.ScriptModule, 
      System.Web.Extensions, Version=1.0.61025.0, 
      Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
  </httpModules>
</system.web>

Einträge im Abschnitt „system.web.extensions“

Das folgende Beispiel zeigt den Abschnitt <system.web.extensions> der Konfigurationsdatei „Web.config“ der Anwendung.

Hinweis Einige Zeilen wurden aus Formatierungsgründen absichtlich aufgeteilt.

RTM-Version:

<system.web.extensions>
  <scripting>
    <webServices>
      <!-- Uncomment this line to customize maxJsonLength and 
        add a custom converter 
      <jsonSerialization maxJsonLength="500">
        <converters>
          <add name="ConvertMe" 
            type="Acme.SubAcme.ConvertMeTypeConverter"/>
        </converters>
      </jsonSerialization>
      -->
      <!-- Uncomment this line to enable the authentication 
        service. Include requireSSL="true" if appropriate
      <authenticationService enabled="true" 
        requireSSL= "true|false"/>
      -->
      <!-- Uncomment these lines to enable the profile 
        service. To allow profile properties to be retrieved
        and modified in ASP.NET AJAX applications, you need 
        to add each property name to the readAccessProperties
        and writeAccessProperties attributes. 
      <profileService enabled="true"
        readAccessProperties="propertyname1,propertyname2"
        writeAccessProperties="propertyname1,propertyname2" 
      />
      -->
    </webServices>
    <!--
    <scriptResourceHandler enableCompression="true" 
      enableCaching="true" />
    -->
  </scripting>
</system.web.extensions>

 

Erforderliche Einträge für IIS 7.0

Der folgende Abschnitt der Konfigurationsdatei stellt sicher, dass Ihre ASP.NET AJAX-Anwendung unter IIS 7.0 funktioniert.

Hinweis Einige Zeilen wurden aus Formatierungsgründen absichtlich aufgeteilt.

RTM-Version:

<system.webServer>
  <validation validateIntegratedModeConfiguration="false"/>
  <modules>
    <add name="ScriptModule" preCondition="integratedMode" 
      type="System.Web.Handlers.ScriptModule,  
      System.Web.Extensions, Version=1.0.61025.0, 
      Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
  </modules>
  <handlers>
    <remove name="WebServiceHandlerFactory-Integrated"/>
      <add name="ScriptHandlerFactory" verb="*" path="*.asmx" 
        preCondition="integratedMode"
        type="System.Web.Script.Services.
          ScriptHandlerFactory, System.Web.Extensions, 
          Version=1.0.61025.0, Culture=neutral, 
          PublicKeyToken=31bf3856ad364e35"/>
      <add name="ScriptHandlerFactoryAppServices" verb="*" 
        path="*_AppService.axd" preCondition="integratedMode"
        type="System.Web.Script.Services.
         ScriptHandlerFactory, System.Web.Extensions, 
         Version=1.0.61025.0, Culture=neutral, 
         PublicKeyToken=31bf3856ad364e35"/>
      <add name="ScriptResource" 
        preCondition="integratedMode" verb="GET,HEAD" 
        path="ScriptResource.axd" 
        type="System.Web.Handlers.ScriptResourceHandler, 
        System.Web.Extensions, Version=1.0.61025.0, 
        Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  </handlers>
</system.webServer>

Neuer Skriptressourcenhandler, Komprimierung und Crunching

Änderung in Beta 2: Ein neuer Skripthandler, der die Skriptgröße verringern kann.

Wichtige Änderung in Beta 2: Der neue Skripthandler muss in der Datei „Web.config“ registriert werden.

Änderung im RC: Der ScriptResource.axd-Handler kann für das Zwischenspeichern und Komprimieren konfiguriert werden. Der Handler unterstützt jetzt auch die Ressourcenaustauschlogik, die vom WebResource.axd-Handler unterstützt wird. Sie können Austauschverweise in der eingebetteten Webressource hinzufügen, die dann vom ScriptResource.axd-Handler verarbeitet werden.

Hinweis: Der Austauschcode <%= WebResource() %> fügt einen Webresource.axd-URL ein, und der Code <%= ScriptResource() %> fügt einen ScriptResource.axd-URL ein.

Bedeutende Änderung im RC: Das Skriptkomprimierungsmodul wird vollständig entfernt; dies wird komplett vom ScriptResource.axd-Handler verwaltet. Sie müssen den Verweis auf das Skriptkomprimierungsmodul in Web.config entfernen.

Skriptkomprimierung bedeutet, dass die Größe von Dateien verringert wird, was über eine Anforderung an den Handler erreicht wird. Crunching von Skripts erfolgt bei der Skripterstellung und bedeutet, dass Leerraum entfernt wird und lokale Variablennamen abgekürzt werden, um die Größe der Skriptdateien weiter zu verringern.

In der Betaversion der RTM-Version werden sowohl Debug- als auch Versionsskripts, die von ASP.NET verarbeitet werden, über ein Modul abgewickelt, das sie komprimiert. In Beta 2 wird diese Aufgabe vom neuen ScriptResource.axd-Handler verwaltet. Wenn auf statische, dateibasierte Skripts verwiesen wird, müssen Sie eine Komprimierung über IIS oder über ein anderes Komprimierungsprogramm ermöglichen.

Bei der Beta 2-Version extrahiert der neue ScriptResource.axd-Handler eingebettete Skriptbibliotheken, wickelt sie ab und hängt dazugehörige lokalisierte Ressourcen nach Bedarf an.

Hinweis Der neue Skripthandler wird vom Framework benötigt und ist eine bedeutende Änderung verglichen mit der älteren Betaversion. Sie müssen den Handler in der Datei „Web.config“ wie im folgenden Beispiel dargestellt registrieren.

Standardmäßig speichert der ScriptResource.axd-Handler Skripts zwischen und komprimiert diese nach Möglichkeit. Durch Ändern der Einstellungen in der Datei „Web.config“ können Sie dieses Verhalten wie unten dargestellt steuern.

Hinweis Für den Abschnitt <system.web.extensions> muss in der Datei „Web.config“ ein <configuration>-Abschnittseintrag vorhanden sein. Der ScriptResource.adx-Handler benötigt einen Eintrag für den Handler im Abschnitt <system.web><configuration>.

RTM-Version:

<system.web.extensions>
  <scripting>
    ..
    <scriptResourceHandler enableCompression="false" 
      enableCaching="false" />
    ..
  </scripting>
</system.web.extensions>

Steuerelemente „ScriptManager“ und „ScriptManagerProxy“

Skriptverweise

Änderung in Beta 2: Bei den Skriptverweisen wurden Updates eingeführt, um die Lokalisierung statischer, dateibasierter Skriptverweise zu unterstützen.

Änderung im RC: Skriptverweise verfügen über eine neue Eigenschaft, mit der gesteuert werden kann, ob das Benachrichtigungsskript an die assemblybasierten Skriptbibliotheken angehängt wird.

Änderung im RC: Wenn das Steuerelement ScriptManager verwendet wird und Skriptbibliothek-URLs gerendert werden, wird ausschließlich der ScriptResource.axd-Handler verwendet. Der WebResource.axd-Handler wird verwendet, wenn auf der Seite keine ScriptManager-Instanz vorhanden ist.

Bedeutende Änderung im RC: Auf Futures-Skripts wird mit einfacheren Namen verwiesen, die nicht mehr das Präfix Microsoft.Web.Resources.ScriptLibrary benötigen.

Bedeutende Änderung in RTM: Die Eigenschaft ScriptLoadTimeout der Klasse ScriptManager wurde entfernt. Diese Eigenschaft ist nicht mehr notwendig, da Skripts durch Inlinetags geladen werden, wenn kein asynchrones Postback durchgeführt wird.

Bedeutende Änderung in RTM: Standardmäßig leitet das Steuerelement ScriptManager seine Debug- oder Releaseeinstellung aus dem aktuellen Debugmodus auf dem Server ab. Bei der RTM-Version wird dieser Wert nur von der Einstellung Debug im Abschnitt <Compilation> der Datei „Web.config“ im Stammverzeichnis der Anwendung abgeleitet. Er wird nicht aus der Konfigurationshierarchie gelesen, wie das in vorherigen Versionen der Fall war.

Änderung in RTM: Das Steuerelement ScriptManager verwendet Überladungen bei den Skriptregistriermethoden, bei denen das Objekt Page als Parameter und nicht als Steuerelement verwendet wird. Dadurch können Sie Skripts während asynchroner Postbacks registrieren, ohne ein Steuerelement im Steuerelement UpdatePanel zu benötigen.

Mit den Steuerelementen ScriptManager und ScriptManagerProxy in der CTP-Version konnten erforderliche Client FX-Skripts wie die Skriptbibliothek MicrosoftAjax.js definiert werden, und es konnten auch Skriptverweise mit den Attributen Path oder Name angegeben werden. Das folgende Beispiel zeigt, wie das Steuerelement ScriptManager verwendet wird.

CTP-Version:

<atlas:ScriptManager runat="server" ID="ScriptManager">
    <Scripts>
        <atlas:ScriptReference ScriptName="AtlasUIGlitz" />
        <atlas:ScriptReference Path="~/Scripts/Custom.js" />
    </Scripts>
</atlas:ScriptManager>

Mehrere wichtige Szenarios, die in der CTP-Version eingeschränkt waren, wurden in der RTM-Version verbessert. Diese bietet dem Seitenentwickler tatsächlich viele Optionen. Hier wurde Folgendes geändert:

• Das Steuerelement ScriptManager unterstützt weiterhin erforderliche und optionale Skripts. Bei optionalen Skripts liegt der Hauptunterschied im Vergleich zur CTP-Version darin, dass keine ScriptName-Enumeration vorhanden ist. Diese Funktion wurde durch ein generisches Modell ersetzt, das es Dritten ermöglicht, assemblybasierte Webressourcenskripts zu liefern. Das folgende Beispiel zeigt das neue Modell und veranschaulicht, wie zusätzliche optionale Skripts bei der neuen Version verwendet werden.

  RTM-Version:

  <asp:ScriptManager runat="server" ID="ScriptManager">
    <Scripts>
      <asp:ScriptReference 
        Name="PreviewScript.js" Assembly="Microsoft.Web.Preview" />
      <asp:ScriptReference 
        Name="PreviewGlitz.js" Assembly="Microsoft.Web.Preview" />
      <asp:ScriptReference Path="~/Scripts/Custom.js" />
    </Scripts>
  </asp:ScriptManager>
  

• Mit dem Steuerelement ScriptManager können Sie vom Datenträger aus auf Skripts als statische Dateien verweisen, um die Leistung zu verbessern. Dies gilt sowohl für Client FX-Skripts als auch für benutzerdefinierte Skripts. Diese Funktion wird mit dem Attribut ScriptPath implementiert (das ein globaler Pfad ist). Dieses Attribut zeigt auf ein Stammverzeichnis, von dem aus der ursprüngliche Assemblyname und seine Version angehängt werden. Das bedeutet auch: Wenn Sie eine Komponente (z. B. System.Web.Extensions) mit einer neueren Version aktualisieren, funktioniert der Seitencode weiterhin, er verweist dann aber auf neue Skriptdateien. Das folgende Beispiel zeigt, wie das Attribut ScriptPath verwendet wird.

  RTM-Version:

  <asp:ScriptManager runat="server" ID="ScriptManager"
    ScriptPath=”~/Scripts”>
    <Scripts>
    <asp:ScriptReference 
    Name="PreviewScript.js" Assembly="Microsoft.Web.Preview" />
    <asp:ScriptReference 
      Name="PreviewGlitz.js" Assembly="Microsoft.Web.Preview" />
    <asp:ScriptReference Path="~/Scripts/Custom.js" />
    </Scripts>
  </asp:ScriptManager>
  

  Da die globale Einstellung ScriptPath (Stammverzeichnis) verwendet wird, bedeutet das bei diesem Modell, dass sich die in den Verweisen definierten Skriptdateien in einem endgültigen Verzeichnis befinden, das durch das Stammverzeichnis sowie die Assembly und ihre Version definiert ist. In diesem Beispiel gilt Folgendes:

  • Die Frameworkskripts sind:

    ~/Scripts/Microsoft.Web.Extensions/1.0.<build>.0/*.js.

  • Die optionalen Vorschauskripts sind:

    ~/Scripts/Microsoft.Web.Preview/1.0.0.0/*.js.

  Sie können weiterhin ein lokales Attribut Path bei einem Skriptverweis definieren, um den Wert ScriptPath außer Kraft zu setzen. Mithilfe des Attributs IgnoreScriptPath können Sie auch die Verwendung einer Assembly für einen gegebenen Skriptverweis erzwingen.

• Sie können mit dem Attribut Path auf benutzerdefinierte Skripts auf dem Datenträger verweisen, oder direkt auf bestimmte Client FX-Skripts zeigen. Wenn Sie die Client FX-Skripts anpassen, können Sie auf Ihre benutzerdefinierte Version verweisen und das Frameworkskript direkt, wie im folgenden Beispiel dargestellt, umgehen.

  RTM-Version:

  <asp:ScriptManager runat="server" ID="ScriptManager">
    <Scripts>
      <asp:ScriptReference Name="MicrosoftAjax.js" 
          Path="~/Scripts/MicrosoftAjax2.js" />
    </Scripts>
  </asp:ScriptManager>
  

• Mit dem Steuerelement ScriptManager definieren Sie webressourcenbasierte Skripts. Diese können möglicherweise vom Visual Studio „Orcas“-Tool für IntelliSense für Typen und APIs innerhalb der Skriptdatei interpretiert werden. Es gibt Attribute für den Namen und die Assembly auf dem Tag ScriptReference.

• Das Objekt ScriptReferences unterstützt die Eigenschaft NotifyScriptLoaded, mit der Sie steuern können, ob das Benachrichtigungsskript an die Skriptbibliothek angehängt wird.

  RTM-Version:

  <asp:ScriptManager runat="server" ID="ScriptManager"
    ScriptPath=”~/Scripts”>
    <Scripts>
      <asp:ScriptReference Name="Custom.Script.js" Assembly="Custom" 
      NotifyScriptLoaded=”false” />
    </Scripts>
  </asp:ScriptManager>
  

• Das Steuerelement ScriptManager unterstützt das Ereignis ResolveScriptReference, das für jeden Skriptverweis ausgelöst wird, einschließlich der Clientframeworkskripts. Sie verwenden das Ereignis ResolveScriptReference, um den Skriptverweis dynamisch zu ändern, z. B. um ihn auf ein anderes Verzeichnis zeigen zu lassen. So können Sie z. B. den Skriptverweis zu einem geografisch näher liegenden Server auf Grundlage der eingehenden IP-Adresse umleiten, um die Leistung zu verbessern. Das folgende Beispiel zeigt, wie das Ereignis ResolveScriptReference verwendet wird.

  RTM-Version:

  <asp:ScriptManager runat="server" ID="ScriptManager"
      OnResolveScriptReference="ResolveScriptReference">
  ..
    </asp:ScriptManager>
  
    <script runat="server">
        protected void ResolveScriptReference(object sender,  
            ScriptReferenceEventArgs e) {
                e.Script.Path = “~/newLocation/” + e.Script.Name;
            ...
        }
    </script>
  

Verwenden von Debug- und Versionsskripts

Bedeutende Änderung in RTM: Standardmäßig leitet das Steuerelement ScriptManager seine Debug- oder Releaseeinstellung aus dem aktuellen Debugmodus auf dem Server ab. Bei der RTM-Version wird dieser Wert nur von der Einstellung Debug im Abschnitt <Compilation> der Datei „Web.config“ im Stammverzeichnis der Anwendung abgeleitet. Er wird nicht aus der Konfigurationshierarchie gelesen, wie das in vorherigen Versionen der Fall war.

Bei der CTP-Version konnte das Steuerelement ScriptManager einen Verweis auf Debugversionen der Skripts anstatt auf Veröffentlichungsversionen definieren. Wie bereits erwähnt, unterscheiden sich Debug- und Versionsskripts hauptsächlich darin, dass bei Versionsskripts unnötiger Leerraum eliminiert wird. Die Entscheidung, eine Debug- oder Veröffentlichungsversion abzuwickeln, wurde über die Einstellung Debug=true in der Datei „Web.config“ getroffen.

Auf Grundlage des Kundenfeedbacks verwendet die RTM-Version ein neues Modell, das es dem Steuerelement ScriptManager ermöglicht, das Debuggen auf dem Server vom Debuggen auf dem Client zu trennen. Wenn die Eigenschaft ScriptMode des Steuerelements ScriptManager auf Auto oder Inherit gesetzt ist, verwendet das Steuerelement ScriptManager standardmäßig die Einstellung Debug des Elements <Compilation> in der Datei „Web.config“. Um den Debugmodus für Skripts unabhängig zu definieren, kann die Eigenschaft ScriptMode so festgelegt werden, dass der Debug- oder Retailmodus erzwungen wird.

Das Steuerelement ScriptManager leitet die Debugversionen der Skriptverweise über eine Namenskonvention für Skriptdateien ab, die sich auf dem Datenträger befindet oder als Webressourcen in einer Assembly eingebettet ist. Sie verweisen immer auf die Veröffentlichungsversionen der Skripts, entweder deklarativ oder programmgesteuert. Das Steuerelement ScriptManager bestimmt auf Grundlage der aktuellen Einstellung, ob Debug- oder Veröffentlichungsversionen gesendet werden, und verarbeitet einen Fallback, wenn die Debugversionen assemblybasierter Skripts nicht existieren.

Wenn Sie Skriptverweise über das Steuerelement ScriptManager registrieren, können Sie die Eigenschaft ScriptMode bei einzelnen Verweisen definieren, die dann den Wert im Steuerelement ScriptManager außer Kraft setzt. Der Standardwert der Eigenschaft ScriptMode für einen Skriptdateiverweis hängt davon ab, ob es sich um einen dateibasierten oder ein assemblybasierten Skriptverweis handelt. Z. B. wird bei einem dateibasierten Skript die Eigenschaft ScriptMode standardmäßig auf release gesetzt. Das bedeutet dann, dass Verweise niemals Debugskriptdateien berücksichtigen.

Wenn der Skriptverweis assemblybasiert ist, wird die Eigenschaft ScriptMode auf inherit gesetzt, was bedeutet, dass die Eigenschaft ihren Wert aus dem Steuerelement ScriptManager übernimmt. Das bedeutet, dass das Steuerelement ScriptManager standardmäßig den Dateinamen des Skriptverweises verwendet, um festzulegen, ob ein Debugskript geladen werden soll. Wenn das der Fall ist, prüft es, ob die Assembly über ein solches Skript verfügt, und leitet ein Fallbackverhalten ein, wenn das Skript nicht existiert.

Bei der RTM-Version werden sowohl die Veröffentlichungs- als auch die Debugkripts standardmäßig durch den Skriptressourcenhandler komprimiert. Bei dieser Version werden Veröffentlichungskripts auch „zerstampft“ (Crunching).

Skript- und andere Ressourcenregistrierungs-APIs

Änderung in RTM: Das Steuerelement ScriptManager verfügt über neue APIs, mit denen Sie Skripts während eines asynchronen Postbacks registrieren können. Diese APIs sind Überladungen vorhandener Methoden, aber anstelle einer Control-Instanz verwenden Sie als Parameter eine Page-Instanz. So können Sie Skripts ohne ein Steuerelement und unabhängig von einer Aktualisierung eines UpdatePanel registrieren. Die Methoden mit diesen neuen Überladungen sind:

• RegisterArrayDeclaration

• RegisterClientScriptBlock

• RegisterClientScriptInclude

• RegisterClientScriptResource

• RegisterHiddenField

• RegisterOnSubmitStatement

• RegisterStartupScript

Wie bereits im UpdatePanel-Abschnitt erläutert, umfasst das Steuerelement ScriptManager bei der RTM-Version neue APIs zur Registrierung von Skripts und anderen Ressourcen, mit denen der ScriptManager und das Steuerelement pageRequestManager auf dem Client festlegen, wie Änderungen bei Partial-Page Postbacks im UpdatePanel verfolgt werden.

Außerdem definieren neue Steuerelemente, einschließlich Extendersteuerelemente, durch die das Client FX in der RTM-Version verbessert wird, ihre eigenen Skriptbibliotheken und Clientobjektinstanzskripts mit dem Steuerelement ScriptManager, nachdem sie sich über ScriptManager registriert haben.

Extendersteuerelemente

Mithilfe von Extendersteuerelementen können Sie ein vorhandenes Serversteuerelement durch neue Funktionen oder ein neues Verhalten erweitern, indem Sie ein Clientverhalten an das Steuerelement anhängen. Bei der CTP-Version verwendeten Sie ein einziges Extendersteuerelement und Sie definierten die Eigenschaften des Extendersteuerelements, die (wie im folgenden Beispiel dargestellt) dem Zielserversteuerelement zugeordnet sind.

CTP-Version:

<asp:TextBox runat="server" ID="City" />
<br/>
<asp:TextBox runat="server" ID="CountryOrRegion" />

<atlas:AutoCompleteExtender runat="server" ID="AutoComplete1">
  <atlas:AutoCompleteProperties TargetControlID="City"
    Enabled="True" ServicePath="AutoCompleteWebService.asmx" 
    ServiceMethod="GetCompletionList" />
  <atlas:AutoCompleteProperties TargetControlID="CountryOrRegion"
    Enabled="True" ServicePath="AutoCompleteWebService.asmx" 
    ServiceMethod="GetCompletionList" />
</atlas:AutoCompleteExtender>

In der RTM-Version wurde dieses Modell auf Grundlage des Communityfeedbacks geändert, um das Konzept zu vereinfachen. In der RTM-Version sind Extender einfach direkt ihrem Zielsteuerelement zugeordnet, und mehrere Extender können sich auf das gleiche Steuerelement beziehen. Es gibt keine separaten Extendereigenschaften. Das folgende Beispiel veranschaulicht dies. (Hier sind nicht mehrere Extender für ein Steuerelement dargestellt).

Hinweis Die RTM-Version verfügt nicht über das AutoCompleteExtender-Steuerelement. Dieses Steuerelement ist Teil des ASP.NET AJAX-Steuerelement-Toolkits.

RTM-Version:

<asp:TextBox runat="server" ID="City" />
<asp:AutoCompleteExtender ID="CityAutoCompleteExtender" runat="server"
   TargetControlID="City" Enabled="True" 
   ServicePath="AutoCompleteWebService.asmx" 
   ServiceMethod="GetCompletionList" />
<br/>
<asp:TextBox runat="server" ID="CountryOrRegion" />
<asp:AutoCompleteExtender ID="CountryRegionAutoCompleteExtender" 
    runat="server” 
    TargetControlID="CountryOrRegion"  
    Enabled="True" ServicePath="AutoCompleteWebService.asmx" 
    ServiceMethod="GetCompletionList" />

Extendersteuerelemente und der Komponentenentwickler

Änderung in Beta 2: Extendersteuerelemente und Skriptsteuerelemente registrieren sich selbst in der PreRender-Phase.

Änderung im RC: Die Basisklasse ruft die Methode RegisterScriptDescriptors des Steuerelements ScriptManager während seiner Render-Methode auf. Das bedeutet, dass Extenders jetzt in Szenarios verwendet werden können, in denen die Render-Methode nicht aufgerufen wird, z. B. in geschlossenen Webparts. Wenn Sie stattdessen Steuerelemente erstellen, die die Schnittstelle IExtenderControl implementieren, müssen Sie der Methode RegisterScriptDescriptors einen Aufruf in der Methode Render des Steuerelements hinzufügen.

Änderung im RC: Es wurde eine Methode hinzugefügt, mit der Steuerelemente und Extender ihre Clientkomponenten als entfernbaren Objekte registrieren können, ohne dass ein DOM-Element benötigt wird. Dies erfolgt automatisch bei ScriptDescriptor-Typen.

In der CTP-Version konnten Komponentenentwickler die Basisklasse ExtenderControl und ihre Klasse ExtenderControlProperties verwenden. Der Entwickler war für das Erstellen des Clientskripts für das zugeordnete Verhalten, entweder als JavaScript oder als XML-Skript, und für das Rendering mit dem Objekt ScriptTextWriter verantwortlich, das der Methode RenderScript des Extenders übergeben wurde. Komponentenentwickler registrierten ihre Bibliothekskripts in einem besonderen Ereignis zur Verwaltung des Lebenszyklus von Steuerelementen, z. B. dem Ereignis PreRender.

Auf Grundlage von Feedback haben wir ein neues Modell implementiert, um die Komplexität zu verringern und eine zukünftige Erweiterbarkeit zu ermöglichen. Beim Modell der RTM-Version verwenden Komponentenentwickler direkt die Klasse ExtenderControl. Es stehen die Schnittstellen IScriptControl und IExtenderControl zur Verfügung, die von Komponentenentwicklern bei Bedarf direkt in ihre Steuerelemente implementiert werden können.

Extendersteuerelemente werden weiterhin über das Steuerelement ScriptManager registriert. Allerdings werden sie vom Framework aufgerufen, damit ihre Bibliothekskripts und ihre neuen ScriptDescriptor-Typen bereitgestellt werden – im Gegensatz zum alten Modell, bei dem der Entwickler der Steuerelemente diese zu einem von ihm gewählten Zeitpunkt innerhalb des Lebenszyklus des Steuerelements gerendert hat. ScriptDescriptor-Typen sind indirekt den Clienttypen Component, Behavior und Control zugeordnet. Dadurch wird die Erzeugung des Skripts für das Clientobjekt abstrahiert, und das Clientobjekt kann mühelos erstellt werden.

Hinweis In der Betaversion konnten Steuerelemente mit dem Steuerelement ScriptManager in der Init-Phase registriert werden. Ab der Version Beta 2 müssen sie in PreRender registriert werden.

Hinweis Wenn Sie mit der Schnittstelle IExtenderControl direkt ein Steuerelement erstellen, müssen Sie die Methode ScriptManager.RegisterScriptDescriptors in Ihrer Render-Methode aufrufen.

In diesem Modell muss das Serversteuerelement nicht die Form des zu rendernden Skripts kennen, wodurch eine künftige Erweiterbarkeit und Unterstützung ermöglicht werden. Das folgende einfache Beispiel veranschaulicht die Verwendung von ScriptDescriptor-Typen in der RTM-Version.

RTM-Version:

protected override IEnumerable<ScriptDescriptor> GetScriptDescriptors
    (Control targetControl) {
    ScriptBehaviorDescriptor descriptor =
        new ScriptBehaviorDescriptor("Sample.UI.BorderBehavior", 
            targetControl.ClientID);
            
    if (!Color.IsEmpty) {
       descriptor.AddProperty("color", ColorTranslator.ToHtml(Color));
    }
    if (Style != BorderStyle.NotSet) {
       descriptor.AddProperty("style", Style.ToString());
    }
    if (!Width.IsEmpty) {
        descriptor.AddProperty("width", Width.ToString());
    }
    yield return descriptor;
}

protected override void GetScriptReferences() {
    ScriptReference reference = new ScriptReference();
    Reference.Path = ResolveClientUrl(
        "~/ScriptControls/BorderBehavior.js"));
    yield return reference;
}

Dieses Beispiel zeigt, wie eine einfache AddProperty-API-Funktion bei einem ScriptDescriptor-Typen angewendet wird, um Eigenschaftswerte auf dem Clientobjekt festzulegen. Beachten Sie auch, dass Sie den Typ ScriptReference verwenden, um einen bestimmten Skriptverweis zu übergeben, der in diesem Fall ein statischer URL und kein webressourcenbasierter Verweis (oder ähnlicher Verweis) ist.

Skriptsteuerelemente

Änderung im RC: Die Basisklasse ScriptControl wurde hinzugefügt. Mit dieser Klasse sind Komponentenentwickler in der Lage, Steuerelemente zu erstellen, die die Schnittstelle IScriptControl implementieren. IScriptControl-Typen sind ähnlich wie die oben beschriebenen IExtenderControl-Schnittstellen konzipiert. Bei der Methode Render des Steuerelements ruft das Steuerelement (wie oben beschrieben) die Methode ScriptManager.RegisterScriptDescriptors auf.

Hinweis Wenn Sie mit der Schnittstelle IScriptControl direkt ein Steuerelement erstellen, müssen Sie die Methode ScriptManager.RegisterScriptDescriptors in Ihrer Render-Methode aufrufen.

Skriptbeschreibungen

Änderung im RC: Die Eigenschaft ClientID wurde dem Objekt ScriptComponentDescriptor hinzugefügt. Sie sollten diese Eigenschaft verwenden, wenn Sie in anderen Clientobjekten auf dieses Clientobjekt verweisen (wenn Sie z. B. einen Verweis auf dieses Objekt erstellen).

Änderung im RC: Die Klasse ScriptControlDescriptor löst eine Ausnahme in der ID-Eigenschaft der Accessormethode „Set“ aus. Die ID-Eigenschaft wird ausschließlich von der ID des DOM-Elements definiert.

Änderung im RC: Das Objekt ScriptBehaviorDescriptor gibt den Wert der ID-Eigenschaft über die ClientID-Eigenschaft zurück, wenn die ID nicht leer ist. Ansonsten gibt es den Wert von <ElementID>$<Name> zurück.

Änderung im RC: Die Methode AddScriptProperty wurde hinzugefügt, damit Sie eine Eigenschaft definieren können, die ein Skriptausdruck ist.

Änderung in RTM: Wenn Sie die Eigenschaft Name durch einen nicht leeren Wert definieren, wird der Wert der Funktion $create übergeben.

Die Basisklassen ExtenderControl und ScriptControl (die die Schnittstellen IExtenderControl und IScriptControl implementieren) registrieren sich selbst mithilfe des Steuerelements ScriptManager während der PreRender-Phase. Das Steuerelement ScriptManager ruft die Schnittstellenmitglieder auf, um deren Skriptverweise und Skriptbibliotheken zu abzurufen, die die Clientobjekte für das Steuerelement definieren.

Die Steuerelemente müssen auch die Methode ScriptManager.RegisterScriptDescriptors während der Render-Phase aufrufen, damit der ScriptManager zurückruft, um die Skriptdeskriptoren zu erhalten. (Dadurch wird sichergestellt, dass das Clientobjekt nur dann erstellt wird, wenn das DOM-Element, auf das verwiesen wurde, vorhanden ist.) Mit Skriptdeskriptoren wird ebenso wie mit der Funktion $create eine Instanz der Clientkomponente im Client erstellt.

Wenn Sie ein Komponentenentwickler sind, verwenden Sie die Skriptdeskriptorentypen, um Komponenten-, Verhaltens- und Steuerelementtypen zu erstellen, die im Client ausgeführt werden. Es gibt spezielle Skriptdeskriptoren, die folgende Methoden bieten:

• AddProperty: Definiert eine Eigenschaft des Clientobjekts (ruft die Accessorfunktionen „Get“ und „Set“ auf).

• AddElementProperty: Definiert eine Eigenschaft eines Clientobjekts, die ein Verweis auf ein DOM-Element ist. Daraufhin wird die Methode $get für die Eigenschaft im Client definiert.

• AddEvent: Definiert einen Ereignishandler des Clientobjekts (ruft die Funktionen add_ und remove_ auf).

• AddScriptProperty: Definiert einen Skriptausdruck als eine Eigenschaft eines Clientobjekts.

• AddComponentProperty: Definiert einen Clientobjektverweis als eine Eigenschaft eines Clientobjekts.

Steuerelement „UpdatePanel“

Szenarien, die das Steuerelement UpdatePanel verwenden, sind Schlüsselszenarien in ASP.NET AJAX Extensions. Wir erhalten viel Kundenfeedback zu diesem Steuerelement, zum Steuerelement UpdateProgress und zur Funktionalität beider Steuerelemente. Dementsprechend wurden zahlreiche Änderungen eingeführt, um das Partial-Page Rendering zu verbessern, und um das Erstellen von Steuerelementen zu unterstützen, die mit dem Steuerelement UpdatePanel kompatibel sind. Wir haben auch ein umfassendes Ereignismodell für den Lebenszyklus eines asynchronen Postbacks implementiert, damit Sie die Verarbeitung des Updates auf dem Client anpassen können.

Steuerelement „ScriptManager“

Änderung in Beta 2: Das Steuerelement ScriptManager stellt die Eigenschaft SupportsPartialRendering zur Verfügung, deren Anfangswerte auf dem Server von den Browserfunktionen abgeleitet werden. Bei Browsern, die kein Partial-Page Rendering unterstützen, werden die Steuerelemente UpdatePanel herabgestuft, um reguläre Postbacks zu verwenden.

Änderung in Beta 2: Das Steuerelement ScriptManager stellt die kompatible API-Funktion SetFocus bereit, mit der Entwickler den Fokus im Browser verwalten können.

Änderung in Beta 2: Das Steuerelement ScriptManager stellt die Methode RegisterDispose bereit, die aufgerufen werden kann, um Clientkomponenten als entfernbare Objekte zu registrieren. Das bedeutet, dass Komponenten ein zugeordnetes DOM-Element benötigen, um mit UpdatePanel-Steuerelementen zu funktionieren.

Änderung im RC: Die Methode RegisterDispose wurde bei der Klasse ScriptManager eingeführt, mit der Steuerelemente und Extender ihre Clientkomponenten als entfernbare Objekte registrieren können, ohne dass ein DOM-Element benötigt wird. Dies erfolgt automatisch bei ScriptDescriptor-Typen.

Änderung im RTM: Neue Überladungen für die statischen Skriptregistriermethoden, die das Objekt Page anstelle des Objekts Control als Parameter verwenden, sind im vorhergehenden Abschnitt beschrieben.

In der RTM-Version hat das Steuerelement ScriptManager die Eigenschaft EnablePartialRendering, die standardmäßig auf true gesetzt ist. Dadurch wird die Anzahl der Schritte reduziert, die notwendig sind, um ein asynchrones Postback mit dem Steuerelement UpdatePanel zu definieren.

Die Eigenschaft ErrorTemplate des Steuerelements ScriptManager wurde bei der RTM-Version entfernt, um die Komplexität des Steuerelements zu verringern. Das Fehlerbehandlungsmodell ist jetzt flexibler, z. B. beim Erstellen eines neuen, unabhängigen Serversteuerelements. Alternativ können Sie jetzt Fehler mit der Eigenschaft AsyncPostBackErrorMessage des Steuerelements ScriptManager behandeln. Diese legt nur die Standardfehlermeldung fest. Um die Fehlermeldung dynamisch anzupassen, können Sie das Ereignis AsyncPostBackError bearbeiten.

ScriptManager stellt jetzt die Eigenschaft AsyncPostBackTimeout zur Verfügung, um die Dauer des Timeouts während eines asynchronen Postbacks zu steuern.

Das Steuerelement ScriptManager unterstützt eine neue Registriermethode für Ressourcen, die von Serversteuerelementen benötigt werden können. Diese Methoden ermöglichen die Unterstützung von UpdatePanel-Szenarios und reduzieren die Komplexität des Steuerelements UpdatePanel im Vergleich zur CTP-Version. Ressourcen können Skripts, Formate, ausgeblendete Felder usw. umfassen. Die Skriptregistriermethoden entsprechen den ClientScriptManager-Methoden. Sie akzeptieren Steuerelementinstanzen als Parameter, weshalb das Steuerelement, durch das das Skript registriert wurde, nachverfolgt werden kann, falls es im Serversteuerelement UpdatePanel enthalten ist.

Dynamische UpdatePanel-Steuerelemente

Es gibt zwei Hauptszenarien, um die UpdatePanel-Steuerelemente dynamisch einer Seite hinzuzufügen. Diese wurden in der RTM-Version verbessert. Die Szenarien für die dynamischen UpdatePanel-Steuerelemente sind folgende:

• Entwickler von Steuerelementen können die UpdatePanel-Steuerelemente ihren benutzerdefinierten, kombinierten Steuerelementen hinzufügen. Somit sind asynchrone Postbacks innerhalb des benutzerdefinierten Steuerelements möglich, wenn die Seite ein Steuerelement ScriptManager besitzt und dessen Eigenschaft EnablePartialRendering auf true gesetzt ist. Damit besteht auch die Möglichkeit, auf reguläre Postbacks zurückzugreifen, wenn die Seite kein Steuerelement ScriptManager hat.

• Seitenentwickler können die UpdatePanel-Steuerelemente den Vorlagen anderer Steuerelemente hinzufügen.

Der folgende Code zeigt, wie ein Steuerelement UpdatePanel in einem benutzerdefinierten Steuerelement verwendet wird.

RTM-Version:

protected override void CreateChildControls() {
    base.CreateChildControls();

    ScriptManager sm = ScriptManager.GetCurrent(Page);
    Control parent;
    Control container;
    if (sm == null || !sm.EnablePartialRendering) {
        // If not doing partial rendering, use a
        // dummy control as the container.
        parent = container = new Control();
    }
    else {
        // Create an UpdatePanel control.
        UpdatePanel up = new UpdatePanel();

        // Instead of adding child controls directly to 
        // the UpdatePanel control, add them to its 
        // ContentTemplateContainer.
        container = up.ContentTemplateContainer;
        parent = up;
    }

    AddDataControls(container);
    Controls.Add(parent);
}

Clientereignisse bei asynchronen Postbacks

In der CTP-Version führt das Clientobjekt PageRequestManager asynchrone Postbacks durch, indem es ein Objekt XMLHttpRequest erstellt und die Antwort verarbeitet. In der RTM-Version verwendet das Objekt PageRequestManager Lebenszyklusereignisse für asynchrone Postbacks, weshalb Sie die Verarbeitung der Anforderung und Antwort anpassen können. Es stehen die folgenden Clientereignisse mit den zugehörigen Ereignisargumenten zur Verfügung, die zusätzliche Daten liefern.

• initializeRequest: Mit diesem Ereignis können Sie eine neue Anforderung für ein asynchrones Postback abbrechen, die gerade erstellt wird. Mit diesem Ereignis können Sie auch die Quelle des Postbacks bewerten und alle anderen notwendigen Aufgaben ausführen. Die Ereignisargumente sind vom Typ InitializeRequestEventArgs.

• beginRequest: Sie können dieses Ereignis für Aufgaben wie das Anzeigen des Status verwenden. Starten Sie die Anzeige während dieses Ereignisses, und blenden Sie sie im Ereignis endRequest aus. Die Ereignisargumente sind vom Typ BeginRequestEventArgs.

• pageLoading: Dieses Ereignis verwenden Sie für eine zusätzliche Verarbeitung von Bereichen, die aktualisiert oder gelöscht werden, wie z. B. das Ausführen eines Bereinigungscodes. Sie können auch beliebige zusätzliche Daten prüfen, die vom Server zur Anpassung gesendet werden. Die Ereignisargumente sind vom Typ PageLoadingEventArgs.

• pageLoaded: Dieses Ereignis funktioniert ähnlich wie pageLoading, liefert aber Daten über zusätzliche UpdatePanel-Steuerelemente, die infolge des asynchronen Postbacks erstellt wurden. Die Ereignisargumente sind vom Typ PageLoadedEventArgs.

• endRequest: Mit diesem Ereignis können Sie die Fehlerbehandlung anpassen und zusätzliche Daten vom Server verarbeiten. Mit ihm können Sie auch das Steuerelement UpdateProgress ausblenden. Die Ereignisargumente sind vom Typ EndRequestEventArgs.

Entwickeln von mit dem Steuerelement „UpdatePanel“ kompatiblen Steuerelementen

Bedeutende Änderung in RTM: In der endgültigen Version von ASP.NET 2.0 AJAX Extensions 1.0 wurde die Validierungsfunktion für die ASP.NET AJAX-Steuerelemente, die zur Gewährleistung der Kompatibilität mit asynchronen Postbacks in der Betaversion und in Version RC enthalten war, entfernt. Dadurch wurden Konflikte mit einem neuen Satz an Validierungsfunktionen vermieden, die mit dem nächsten Update von .NET Framework geliefert werden.

Anwendungsentwickler, die Validierungsfunktionen in ihren bereitgestellten Anwendungen benötigen, finden Angaben zum Entfernen der Validierungsfunktionen und zu Problemumgehungen bei der Verwendung von Validierungsfunktionen im Blogbeitrag ASP.NET AJAX-Validierungsfunktionen (in englischer Sprache). Der Blogbeitrag enthält den Quellcode für die Validierungsfunktionen, den Entwickler bei Bedarf in ihren Anwendungen verwenden können.

Installieren Sie das .NET Framework-Update, sobald es verfügbar ist, damit die gehosteten Anwendungen auf die aktualisierten Validierungsfunktionen zugreifen können.

In der CTP-Version verarbeitete das Steuerelement UpdatePanel viele zu rendernde Objekte, darunter auch einige, die sich nicht im Steuerelement UpdatePanel befanden, und versuchte dann, alle Änderungen auf die Seite anzuwenden. Dadurch wurden einige Steuerelemente mit dem Steuerelement UpdatePanel inkompatibel. So funktionierten z. B. in der CTP-Version die ASP.NET-Validierungssteuerelemente innerhalb eines UpdatePanel-Steuerelements nicht richtig, wenn diese dynamisch hinzugefügt oder entfernt wurden – z. B. in einem Steuerelement Wizard, das die Benutzereingabe bei jedem Schritt überprüft.

Dieses Modell wurde in der RTM-Version verbessert. Um Skripts oder Daten zum Client zu senden, müssen Sie diese über das Steuerelement ScriptManager registrieren, so wie Sie Skriptbibliotheken registrieren. Das folgende Beispiel zeigt ein benutzerdefiniertes Steuerelement in der RTM-Version, das mit dem Steuerelement UpdatePanel kompatibel ist.

RTM-Version:

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

    Control control = FindControl(_controlID);

   // Register scripts with new ScriptManager APIs.
   // The scripts hook up new PageRequestManager events.
   string script = String.Format(
   CultureInfo.InvariantCulture,
   @"var {0}_hover = new Microsoft.Samples.HoverExtender(document.getElementById('{1}'), '{2}');
{0}_hover.attach();
",
   ClientID,
   control.ClientID,
   ColorTranslator.ToHtml(BackgroundColor));

   ScriptManager.RegisterClientScriptInclude(
       this, typeof(HoverExtender), "HoverExtenderScript",
        ResolveClientUrl("~/ScriptLibrary/HoverExtender.js"));
        ScriptManager.RegisterStartupScript(
            this, typeof(HoverExtender), ClientID, script, true);
}

Senden von zusätzlichen Daten an den Client

Ein relativ schwieriges Szenario in der CTP-Version war, Steuerelemente außerhalb eines UpdatePanel-Steuerelements mit Daten zu aktualisieren, die vom Server während eines asynchronen Postbacks empfangen wurden. In der RTM-Version wird dazu eine Methode der Klasse ScriptManager bereitgestellt, mit der Sie ein Datenelement registrieren können.

Stellen Sie sich dazu ein Timer-Steuerelement auf dem Client vor, dessen Wert der Eigenschaft intervall oder enable während der Laufzeit in Servercode geändert wird, das aber nicht in einem UpdatePanel-Steuerelement enthalten ist. In der CTP-Version war eine solche Laufzeitänderung nicht möglich.

In der RTM-Version verfügt der ScriptManager auf dem Server über ein Wörterbuchobjekt, das Sie aktualisieren und dann mit der Methode RegisterDataItem registrieren können. Das Wörterbuch wird dann zum Client gesendet, ist in den Ereignissen pageLoading, pageLoaded und endRequest verfügbar und kann mit der Methode eventArgs.get_dataItems() aufgerufen werden.

Das folgende Beispiel zeigt, wie das Datenelement verwendet wird.

RTM-Version:

// Server control code.
...
Public int interval {
    get {…}
    set {
        _data = value;
    ...
    }
}

void PreRender() {
    ScriptManager sm1 = ScriptManager.GetCurrent(Page);
    if (sm1 != null && sm1.IsInAsyncPostBack) {
        ScriptManager.RegisterDataItem(this, _data.ToString());
    }

    // The control also needs to register script to handle the
    // endRequest event on the client and retrieve this value. 
    // The script below adds a handler for the current instance 
    // of the PageRequestManager object and calls the 
    // get_dataItem() method from eventArgs.
    ScriptManager.RegisterClientScriptBlock(this, this.GetType(), 
        key, script)
}

Benutzerdefinierte Fehlerbehandlung und Umleitung

In der CTP-Version konnte die Fehlerbehandlung nicht gesteuert werden, und benutzerdefinierte Fehlereinstellungen wurden nicht unterstützt. In der RTM-Version wurden diese Probleme gelöst.

Das Objekt ScriptManager stellt die Eigenschaft AllowCustomError zu Verfügung. Wenn diese Eigenschaft auf false gesetzt ist, setzt das Objekt ScriptManager die benutzerdefinierten Fehlerumleitungen außer Kraft und sendet stattdessen den Fehler an den Client, auf dem Sie die Fehlerdaten anzeigen können, ohne den Benutzer zu einer anderen Seite umleiten zu müssen.

In der RTM-Version wurde das Modul Redirect hinzugefügt, um Umleitungen zu verarbeiten. Daher können jetzt in der RTM-Version seitenübergreifende Bereitstellungsszenarien verwendet werden.

Trigger

In der CTP-Version verfügte das Steuerelement ScriptManager in der Triggersammlung über die Typen ControlValueTrigger und ControlEventTrigger, um Trigger an Steuerelemente auf der Seite zu binden. Diese Objekte wurden in der RTM-Version in einem einzigen Objekt AsyncPostBackTrigger zusammengefasst, um Klarheit im Hinblick auf die beiden Triggertypen zu schaffen.

Unter Berücksichtigung des Kundenfeedbacks haben wir es ermöglicht, komplette (synchrone) Postbacks innerhalb eines Steuerelements UpdatePanel mit dem Objekt PostBackTrigger auszuführen. Das Objekt Trigger kann jetzt auch auf Steuerelemente verweisen, die die Schnittstellen IPostbackEventHandler, IPostBackDataHandler oder INamingContainer implementieren.

Über die Steuerelemente AsyncPostBackTrigger ist es möglich, dass das Steuerelement UpdatePanel während eines asynchronen Postbacks aktualisiert wird, wenn der Trigger ausgelöst wird. Die Trigger können auf Steuerelemente außerhalb des Steuerelements UpdatePanel oder auf in der Steuerelementhierarchie übergeordnete Steuerelemente zeigen. Wenn ein Steuerelement, das ein Namenscontainer ist, als Trigger verwendet wird, verhalten sich alle untergeordneten Steuerelemente, die ein Postback verursachen, wie Trigger.

Das folgende Beispiel zeigt, wie das Objekt AsyncPostbackTrigger deklarativ verwendet wird.

RTM-Version:

<asp:Button runat=”server” id=”Button1” Text=”Go” />
<asp:UpdatePanel ID="UP1" UpdateMode="Conditional" runat="server">
    <ContentTemplate>...</ContentTemplate>
    <Triggers>
        <asp:AsyncPostbackTrigger ControlID="Button1" />
    </Triggers>
</asp:UpdatePanel>

Durch das Steuerelement PostBackTrigger wird erreicht, dass die verknüpften Steuerelemente innerhalb des Steuerelements UpdatePanel reguläre Postbacks ausführen. Diese Trigger müssen untergeordnete Steuerelemente des betreffenden Steuerelements UpdatePanel sein.

Steuerelement „UpdateProgress“

Die RTM-Version verfügt über ein verbessertes Steuerelement UpdateProgress mit zusätzlicher Funktionalität, damit das Steuerelement UpdateProgress benutzerdefiniert nur dann angezeigt wird, wenn das asynchrone Postback über ein vordefiniertes Zeitintervall hinaus andauert. Sie können außerdem definieren, wie das Steuerelement UpdateProgress gerendert wird, um festzulegen, ob das Steuerelement im ausgeblendeten Zustand Leeraum auf der Seite einnimmt – ähnlich wie das Attribut „dynamisch“ der Eigenschaft DisplayMode der ASP.NET-Validierungsfunktionen. Wenn die Statusanzeige auch über Abbruchfunktionen verfügen soll, müssen Sie nur ein paar Zeilen Code hinzufügen. Dies war in der CTP-Version nicht möglich.

Das folgende Beispiel zeigt, wie das Steuerelement UpdateProgress konfiguriert wird, damit die Statusanzeige nur eingeblendet wird, wenn die Anforderung länger als eine halbe Sekunde (500 Millisekunden) dauert.

RTM-Version:

<asp:updateprogress runat=server ID="Progress1" DisplayAfter="500">
  <ProgressTemplate>
    <b>Working on request...</b>
    <input type="button" id="abortButton" onclick="abortPB()" 
        value="Cancel" />
  </ProgressTemplate>
</asp:updateprogress>

<script type="text/javascript" >  function abortPB() {
    var obj = Sys.WebForms.PageRequestManager.getInstance();
    if (obj.get_isInAsyncPostBack()) {
    obj.abortPostBack();
    }
  }
</script>

Unterschiede in der Futures-Version

Änderung in RTM: Im Zusammenhang mit der Veröffentlichung der RTM-Version von ASP.NET AJAX Extensions wurde auch die Futures-Version geändert. Die Typen AutoCompleteExtender, AutoCompleteBehavior, PopupBehavior und HoverBehavior wurden dem ASP.NET AJAX-Steuerelement-Toolkit hinzugefügt. Die Futures-Version funktioniert in Verbindung mit der RTM-Version. Dieser Abschnitt beschreibt die Hauptunterschiede zwischen den Funktionen der Futures-Version und den entsprechenden Funktionen der CTP-Version.

Bei der Futures-Version wurden Funktionen in neue Namespaces auf dem Client und dem Server verschoben, um eine Verwechslung mit der RTM-Version zu vermeiden. In diesem Falle müssen Entwickler, die die CTP-Version verwenden, bestehende Web.config-Dateien mit neuen Einträgen aktualisieren, wenn ihre Anwendungen Funktionen verwenden, die in der Futures-Version definiert sind. Das folgende Beispiel zeigt einen Ausschnitt einer Web.config-Datei, der diese Änderungen veranschaulicht.

RTM-Version:

<system.web>
...
<pages ...>
  <controls>
    <add namespace=”Microsoft.Web.Preview.UI” 
      assembly=”Microsoft.Web.Preview” tagPrefix=”atlas” />
    <add namespace=”Microsoft.Web.Preview.UI.Controls” 
      assembly=”Microsoft.Web.Preview” tagPrefix=”atlas” />
  </controls>
</pages>
</system.web>

Sie können die Assembly für die Futures-Skripts und die Serverfunktionen dem Bin-Ordner einer Internetanwendung hinzufügen, wie das bei der CTP-Version der Fall war.

Hinweis In Beta 2 wurde der Assemblyname von Microsoft.Web.Atlas.dll in Microsoft.Web.Preview.dll geändert.

In der CTP-Version mussten Sie das Steuerelement ScriptManager nur einer Webseite hinzufügen, und die CTP-Hauptfunktionen (Atlas.js) waren standardmäßig enthalten. Allerdings waren einige Skriptdateien optional, wie z. B. die Datei „AtlasUIGlitz.js“. Sie gaben diese in Form von Skriptverweisen als Teil des Steuerelements ScriptManager manuell ein oder definierten sie im Abschnitt <references> im XML-Skript.

Um in der RTM-Version die Funktionen der Futures-Version zu nutzen, müssen Sie dem Steuerelement ScriptManager explizite Skriptverweise hinzufügen. Das folgende Beispiel zeigt, wie Skriptdateien in der Futures-Version definiert werden.

Hinweis Aufgrund der Abhängigkeitskette ist die Reihenfolge der Registrierung ist wichtig!

RTM-Version:

<asp:ScriptManager runat=”server” id=”ScriptManager1”>
  <Scripts>
     <asp:ScriptReference Assembly="Microsoft.Web.Preview"
      Name="PreviewScript.js"/>
    <asp:ScriptReference Assembly="Microsoft.Web.Preview" 
      Name="PreviewGlitz.js"/>
    <asp:ScriptReference Assembly="Microsoft.Web.Preview" 
      Name="PreviewDragDrop.js"/>
  </Scripts>
</ScriptManager>

Clientbasierte und serverbasierte Typen

Die in den Futures-Skripts definierten Typen wurden vom Namespace Sys.* in einen eigenen, separaten Namespace Sys.Preview.* verschoben. Dadurch wird eine Unterscheidung bei der Funktionalität garantiert. Entwickler, die zuvor während des CTP Funktionen verwendet haben, die in die Futures-Skripts verschoben wurden, müssen unter Umständen ihren JavaScript-Code aktualisieren. Ein Beispiel für eine solche Änderung ist die Komponente Sys.Services.Components.Profile, die nun den Namen Sys.Preview.Services.Components.Profile trägt.

Ebenso müssen Entwickler, die Serverfunktionen wie Steuerelemente und Extender im CTP verwenden, die ebenfalls in die Futures-Version verschoben wurden, die Einträge in der Datei „Web.config“ mit der neuen Namespacedefinition aktualisieren. Im CTP wurden Servertypen unter dem Namespace Microsoft.Web.* definiert. Dieser entspricht nun Microsoft.Web.Preview.*. Ein Beispiel dafür ist der Microsoft.Web.UI.Controls.DragOverlayExtender, der jetzt Microsoft.Web.Preview.UI.Controls.DragOverlayExtender heißt.

XML-Skript

Das XML-Skript funktioniert weiterhin in der Futures-Version, aber mit einigen Änderungen, die durch die RTM-Version verursacht wurden. Das deklarative XML-Skript wurde ebenfalls verbessert.

Hinweis Bei XML-Skripttags wird die Groß- und Kleinschreibung nicht berücksichtigt. Allerdings wird bei bestimmten Eigenschaftsattributen und -werten die Groß- und Kleinschreibung berücksichtigt, weshalb Sie unter Umständen Änderungen in Ihren Anwendungen vornehmen müssen.

Die Namen der XML-Skripttags folgen direkt dem Typennamen. Die folgenden in CTP-Skripts integrierten Tags wurden in Futures-Skripts geändert:

RTM-Version:

<opacity .../>
<layout .../>
<autoComplete .../>
<setProperty .../>
<invokeMethod .../>
<serviceMethod .../>
<postback .../>
<select .../>

In den Futures-Skripts handelt es sich dabei um die folgenden Tags:

Futures-Version:

<opacityBehavior .../>
<layoutBehavior .../>
<autoCompleteBehavior .../>
<setPropertyAction .../>
<invokeMethodAction .../>
<serviceMethodRequest .../>
<postbackAction .../>
<selector .../>

Definieren von Tagpräfixen

XML-Tags sind weiterhin auf die integrierten Skriptpräfixe begrenzt. Darüber hinaus wurde die Unterstützung für benutzerdefinierte Präfixe verbessert, um die folgende Syntax zu ermöglichen. Dadurch wird ein kommagetrenntes Namespaceformat möglich.

Futures-Version:

<script type="text/xml-script">
  <page xmlns ="https://schemas.microsoft.com/xml-script/2005"
    xmlns:prefix="JavaScript: Sys.UI,Sys">
    <components>
      ...
    </components>
  </page>
</script>

Erstellen von deklarativen Bindungen

Bindungen wurden von CTP-Skripts in die Futures-Skripts verschoben und werden im Markup auf allen Ebenen unterstützt, ohne dass sie innerhalb eines bestimmten Steuerelements verschachtelt werden. Wenn sie verschachtelt werden, leiten Bindungen ihren Kontext oder ihre Quelle von der übergeordneten Bindung ab. Im folgenden Beispiel wird die gleiche Bindung in der CTP-Version und in der Futures-Version verwendet.

Futures-Version:

<script type="text/xml-script">
  <page xmlns "https://schemas.microsoft.com/xml-script/2005">
    <components>
      <textbox id="Name" />
        <label id="FirstName">
          <bindings>
            <binding dataContext="Name" dataPath="text"               
              property="text"/>  
          </bindings>
        </label>
    </components>
  </page>
</script>

In den Futures-Skripts unterstützt das Bindungsattribut propertyKey eine Punktnotation, mit der Sie Untereigenschaften definieren können. Wenn Eigenschaften aus dem Basistyp Control (wie z. B. visible) entfernt wurden, können Sie auf diese als Untereigenschaften verweisen. Das folgende Beispiel zeigt die Einstellung einer Stileigenschaft bei einem Element, das dem Steuerelement Button zugeordnet ist.

RTM-Version:

<script type="text/xml-script">
  <page xmlns="https://schemas.microsoft.com/xml-script/2005"
    xmlns:prefix="javascript: Sys.UI,Sys">
    <components>
      <textbox id="Name" />
        <label id="FirstName">
          <bindings>
            <binding dataContext="Name" dataPath="text" 
                property="text"/>  
          </bindings>
        </label>
      <button id="button2">
        <click>
          <setPropertyAction target="text1" property="element" 
            propertyKey="style.borderColor" value="black" />
        </click>
      </button>
    </components>
  </page>
</script>

Dieses Beispiel zeigt die Aktion setPropertyAction, die durch Klicken auf das Steuerelement Button aufgerufen wurde.

Verweise

Im CTP konnten Sie Skriptverweise deklarativ dem XML-Skript hinzufügen. Dies wird derzeit in der Futures-Version nicht unterstützt.