Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

Microsoft Ajax 1.0 (beta) et Microsoft Control Toolkit disponible (détail des changements)

Patrice et Fox vous l'a déjà annoncé hier : Une nouvelle version de Microsoft Ajax Extensions (nom de code "Atlas") et des Toolkit est sortis. Mais voyons un peu plus en détail les changements.

Tout d'abord comme le dit Bertrand Leroy :

There are too many changes to enumerate here (we basically remodeled the house), but the idea is to provide a rock-solid core and continue to innovate with the value-add CTPs.
source : ASP.NET AJAX Beta 1 is out!

J'ai rapidement regardé le fonctionnement de cette nouvelle version et ils ont modifié de très nombreuses choses par rapport à la dernière CTP d'Atlas qui datait de Juillet : 4 mois ça laisse du temps pour faire beaucoup de modifications ...

Actuellement il y a 3 téléchargements pour Atlas : 

  1. Microsoft ASP.NET 2.0 Ajax Extensions : Cette partie est développé seulement par Microsoft et comme les autres produits Microsoft il aura un support technique de 10 ans. Ce projet contient les bases d'Atlas côté serveur et client. La partie cliente est connu sous le nom de Microsoft Ajax Library, elle fonctionne sous toutes les technologies, php, ColdFusion, ... et sera 100% Cross Browser (IE, Firefox, Safari ET Opera).
  2. Microsoft ASP.NET Ajax "Value-Add" CTP : Cette partie contient tout ce qui a été supprimé entre l'ancienne version d'Atlas et le projet Ajax Extensions, on y retrouve principalement toute l'interprétation du XML-Script. D'après ce que j'ai compris cette partie sera "community supported", ils continuent d'améliorer certains composants pour ensuite les déplacé dans le "core package". Cette partie est très floue, on ne sait pas si au final il y aura un téléchargement à part où alors cela sera intégré dans le Control Toolkit.
  3. Microsoft ASP.NET Ajax Control Toolkit : Cette partie est développé par Microsoft ET d'autres personnes communautaire, par conséquent les sources sont disponible sur CodePlex. Dans ce projet on retrouve 28 contrôles (vous pouvez voir une démo ici : Ajax Control Toolkit) mais d'autres vont arriver, Scott Guthrie avait annoncé entre 50 et 100 contrôles ...

 

Rentrons un peu dans les détails.

Mon premier reflexe lorsqu'il y a une nouvelle version d'Atlas est de désosser le fichier JavaScript. Première "surprise" il y a maintenant 2 fichiers : le premier contient Microsoft Ajax Library alors que le second est spécifique à ASP.net, ce n'est pas vraiment une surprise puisque Bertrand Leroy se posait la question. La vrai surprise est la taille des fichiers JavaScript : 67ko pour l'Ajax Library et 32ko pour les spécificités ASP.net soit 99ko contre 242ko ! Mais que c'est il passé ?

La mort du XML-Script

Après une rapide analyse du fichier j'ai découvert que le XML-Script n'existe plus dans le "core feature", ils ont déplacé cette techno dans le "Value-Add". Pour rappel le XML-Script est une techno qui permet de travailler avec des instances d'objet à partir d'une syntaxe XML, je vous avez fait un article de présentation : "Hello-world en XML-Script : le nouveau langage de script client d'Atlas". Atlas reposait en partie sur XMl-Script, tous les contrôles Atlas générait du XML-Script alors pourquoi avoir fait ce choix de le supprimer ? Il y a plusieurs raisons à cela :

  • le parseur XML-Script est très lourd, je n'ai pas regardé exactement mais avec les contrôles associés cela doit peser autour de 100ko.
  • le XML-Script est très verbeux, on peut faire en 3 lignes de JavaScript ce qui prend une bonne dizaine de ligne en Xml-Script, j'avais d'ailleurs expliqué comment convertir du XML-Script en JavaScript pour réduire la taille de nos pages ([Atlas] instancier un behavior via JavaScript : comment convertir du xml-script en JavaScript)
  • le XML-Script est gourmand en ressource, pour utiliser XML-Script JavaScript doit le parser, automatiquement c'est plus lent et plus lourd que de directement instancier les contrôles via JavaScript.
  • Il n'est pas facile de parser du XML avec le navigateur Opéra, en supprimant XML-Script Atlas devient compatible avec Opéra. Ce n'est pas tout à fait le cas, mais la barrière technologique qui empêchait Atlas d'être compatible Opéra a été supprimé. La version final d'Atlas sera compatible avec Opéra et ça c'est plutôt une bonne nouvelle.

J'aimais bien le XML-Script c'était une nouvelle façon de penser et de programmer, certes il était trés difficile d'écrire quelques lignes de XML-Script mais c'était vraiment très puissant. Microsoft n'a pour autant pas abandonné XML-Script à 100%, si vous avez commencé à écrire vos applications en utilisant XML-Script celles ci continueront de fonctionner avec le "Value-Add package" mais Atlas n'utilise plus cette technologie dans leurs propres contrôles.

Style "prototype" plutôt que "closure"

Deuxième chose notable est l'utilisation d'un style "prototype" plutôt que "closure" qu'est-ce que cela veut dire ? En JavaScript il existe pleins de méthode pour créer un objet, jusqu'a maintenant Atlas utilisait le style "closure" ce style est le plus naturel car il ressemble un peu aux langages traditionnels. Voici à quoi cela ressemble pour la création d'un type point :

function Point(x, y) { var _x = x; var _y = y; this.get_x() { return _x; } this.get_y() { return _y; } }

Le problème est lorsqu'on instancie cet objet (var p = new Point(3, 4)) on créé une méthode get_y et get_x pour chaque objet, donc si on créé 20 Points on aura 40 méthodes en mémoire alors qu'elles sont identique. La solution est donc d'externaliser ces méthodes à l'aide du mot clé prototype :

function Point(x, y) { this._x = x; this._y = y; } Point.prototype.get_x = function() { return this._x; } Point.prototype.get_y = function() { return this._y; }

De cette façon, si l'on instancie 20 Points, on aura seulement 2 méthodes en mémoire au lieu de 40 ... Puisque l'objet prototype est un objet, on peut utiliser une autre syntaxe qui nous fait gagner quelques octets :

function Point(x, y) { this._x = x; this._y = y; } Point.prototype = { get_x : function() { return this._x; }, get_y : function() { return this._y; } }

Il y a bien sur beaucoup de choses à prendre en considération en utilisant cette méthode, Bertrand Leroy a expliqué le détails des opération sur son blog : From closures to prototypes, Part 1 et  part 2

Documentation et validation des paramètres

On note désormais l'apparition de documentation intégré et de validation des arguments sur certaines des méthodes. Voici à quoi cela ressemble :

Function.createDelegate = function Function$createDelegate(instance, method) { /// <param name="instance" mayBeNull="true"></param> /// <param name="method" type="Function"></param> /// <returns type="Function"></returns> var e = Function._validateParams(arguments, [ {name: "instance", mayBeNull: true}, {name: "method", type: Function} ]); if (e) throw e;

L'écriture de cette documentation ainsi que le code de validation des arguments sera facilité par Visual Studio "Orcas".

Modification du ScriptManager : AsyncPostBackTimeOut, AsyncPostBackError, ...

Je vous en avais parlé sur ce billet : [Atlas] UpdatePanel et TimeOut dans Atlas la durée du TimeOut d'un UpdatePanel était hard codé et valait 90sec, ce problème a été résolu en rajoutant une propriété AsyncPostbackTimeOut sur le contrôle ScriptManagr.

Un nouvel événement a vu le jour sur le ScriptManager : AsyncPostBackError cet événement devra permettre une pris en charge des erreurs beaucoup plus facile qu'auparavant. J'avais d'ailleurs fait un HttpModule pour voir le détail des erreurs lors d'un AsyncPostBack je vais surement me servir de ces nouveautés pour faciliter le traitement.

D'autres nouveautés ont vu le jour dans le ScriptManager mais je n'ai pas encore eu le temps de toutes les détaillés ;-)

Modification de l'UpdatePanel

Encore une nouveauté très sympathique. Avec l'ancienne version d'Atlas tous les contrôles présent dans un UpdatePanel était "transformé" pour faire un AsyncPostBack plutôt qu'un classique postback. J'avais illustré ce problème ici : [Atlas] Cascading UpdatePanels et rafraichissement illogiques et c''est maintenant résolu.

<asp:UpdatePanel ID="updatePanel1" runat="server"> <ContentTemplate> <asp:LinkButton ID="LB1" runat="server">Classique PostBack</asp:LinkButton><br /> <asp:LinkButton ID="LB2" runat="server">AsyncPostBack</asp:LinkButton><br /> <%=DateTime.Now.ToLongTimeString() %> </ContentTemplate> <Triggers> <asp:PostBackTrigger ControlID="LB1" /> </Triggers> </asp:UpdatePanel>

qui est équivalent à :

<asp:UpdatePanel ID="updatePanel1" runat="server" ChildrenAsTriggers="false" UpdateMode="Conditional"> <ContentTemplate> <asp:LinkButton ID="LB1" runat="server">Classique PostBack</asp:LinkButton><br /> <asp:LinkButton ID="LB2" runat="server">AsyncPostBack</asp:LinkButton><br /> <%=DateTime.Now.ToLongTimeString() %> </ContentTemplate> <Triggers> <asp:PostBackTrigger ControlID="LB1" /> <asp:AsyncPostBackTrigger ControlID="LB2" EventName="Click" /> </Triggers> </asp:UpdatePanel>

Optimisation des échanges entre deux AsyncPostBack

C'est une des choses qui m'a vraiment bluffé, les échanges suite à une mis à jour d'un UpdatePanel ont vraiment été amélioré. Je ne vais pas détailler le nouveau fonctionnement des échanges mais ce qu'il faut savoir c'est qu'avec les anciennes versions d'Atlas on échangeait des données sous la forme XML dorénavant on échange du texte séparé par des |, regardons un exemple.

Avec l'ancienne version :

<delta><rendering> <head><title> Untitled Page </title><style type="text/css"> .atlas__delta { font-family:Lucida Console; } </style></head><form name="form1" method="post" action="Default2.aspx" id="form1"> <div> </div> <panelContent id="UpdatePanel1"><![CDATA[ 22:23:12 ]]></panelContent> <div> </div></form></rendering> <hiddenField id="__VIEWSTATE" value="/wEPDwUJOTU5ODMwMzIwZGSG7acgjCkfbTAshYo1QMAY/UQx9w==" /> <hiddenField id="__EVENTVALIDATION" value="/wEWAgK66vOtDgKM54rGBkrNFKcmd3fLquHq1PB194tx/33o" /> <deltaPanels>UpdatePanel1</deltaPanels> <pageRequestManager asyncPostbackControlIDs='Button1' updatePanelIDs='UpdatePanel1' /> <xmlScript> <page xmlns:script="http://schemas.microsoft.com/xml-script/2005"> <components /> </page></xmlScript> </delta>

Exactement la même chose mais avec la nouvelle version d'Atlas :

40|updatePanel|UpdatePanel1| 22:27:36 |52|hiddenField|__VIEWSTATE|/wEPDwUJNDc4MDYwNTkzZGStUtUw+7XYqaLJCKuPrau9/pYpFw==|48|hiddenField|__EVENTVALIDATION|/wEWAgLshqX9AQKM54rGBu8A4qYnvbSj2Y+pot5MZNwoiHfy|7|asyncPostBackControlIDs||Button1|0|postBackControlIDs|||13|updatePanelIDs||tUpdatePanel1|0|childUpdatePanelIDs|||12|panelsToRefreshIDs||UpdatePanel1|2|asyncPostBackTimeout||90|13|formAction||Default2.aspx|13|pageTitle||Untitled Page|

La taille de l'échange HTTP passe de 826 octets a 466 octets soit un peu plus de 40% d'économie !

Le contrôle UpdateProgress peut être rattaché à un seul UpdatePanel

J'avais prévu de blogger sur le sujet, l'UpdateProgress ne me satisfaisait pas du tout. Dorénavant le contrôle UpdateProgress peut être attaché a un UpdatePanel, ce qui est Très pratique. On a aussi une propriété DisplayAfter qui affiche l'updateProgress seulement après un certain laps de temps, ce qui évite d'avoir un clignotement d'un UpdateProgress à cause d'un traitement très rapide.

<asp:UpdateProgress runat="server" ID="UpdateProgress1" DisplayAfter="300" AssociatedUpdatePanelID="updatePanel1" > <ProgressTemplate> En cours </ProgressTemplate> </asp:UpdateProgress>

Par contre il y a un point qui ne me convient toujours pas, on ne peut pas choisir le RenderMode (inline ou block) comme c'est le cas pour les UpdatePanels. On peut attacher seulement un UpdatePanel par UpdateProgress, ce serait sympa de pouvoir avoir AssociatedUpdatePanelID="updatePanel1, updatePanel2"

Nouveautés sur les WebMethod et WebService

J'avais écrit ce billet : Atlas et les PageMethods : trés interessants mais ... qui expliquait le fonctionnement des PageMethod l'une de mes remarques était que l'attribut WebMethod ne devait pas être utilisée car cela risquait de créer des confusions. Comme l'explique Shawn Burn : Hint: Components that use Web Services with ASP.NET AJAX v1.0 Beta, l'attribut ScriptMethod doit être rajouté en plus de l'attribut WebMethod.

[WebMethod] [Microsoft.Web.Script.Services.ScriptMethod] public static string MyMethod() { return "MyMethod Called"; }

En vrac : choses diverses et variés

C'est un petit détail parmi les innombrables modifications mais la fonction $ qui était plus ou moins un alias de la fonction document.getElementById a été remplacé par la fonction $get. Ceci afin d'assurer une compatibilité avec d'autres Framework notamment prototype et Script.aculo.us.

Aprés avoir installé Microsoft Ajax Extensions (beta) la dll d'Atlas (Microsoft.Web.Extensions.dll) est enregistré dans le GAC (Global Assembly Cache) c'est à dire que vous n'avez plus besoin d'ajouter la dll dans le dossier /bin.

Il parait que tout le monde n'utilise pas Reflector pour savoir comment fonctionne une assembly, certains aiment aussi utiliser la documentation (si si j'en connais !), Atlas n'en est pas dépourvu : Documentation pour Microsoft ASP.net 2.0 Ajax Extensions

Je n'ai pas encore fait le tour de toutes les modifications apporté par cette nouvelle version d'Atlas, mais c'est plus qu'un simple Update c'est une véritable révolution, ils ont tout refait et je n'ai pas l'impression que ce soit finit. Un guide de 49 pages a été publié pour indiquer les changements entre la version final et la CTP de July : Changes between the ASP.NET AJAX (“Atlas”) CTP and the v1.0 Beta/RTM Release (version pdf)

 

En bref

En quelques points voici ce qu'il faut retenir de cette nouvelle version d'Atlas :

  • Une énorme réduction du fichier JavaScript, on passe de 242ko à 99ko ... les pages utilisant Atlas ainsi que les transfert AsyncPostBack ont également été allégé.
  • La mort de XML-Script : XML-Script a été déplacé dans le "Value-Add", ce qui améliore la vitesse de chargement des applications Atlas, et réduit la taille des échanges HTTP.
  • Annonce du support du navigateur Opéra.
  • Utilisation d'un style prototype plutot que "closure" pour les objets JavaScipt. Bertrand Leroy détaille ce point ici et .
  • Documentation et validation des paramètres.
  • Intégration dans Visual Studio Orcas : La plupart des changements du code JavaScript ont été pensé pour l'intégration dans Visual Studio Orcas, et cela promet d'être spéctaculaire.
  • Nombreuses nouveautés sur les contrôles ScriptManger, UpdatePanel, UpdateProgress, ...
  • les toolkits sont désormais disponible avecle tagkey : <ajaxToolkit: au lieu de <atlasToolkit:
  • 3 nouveaux contrôles Toolkit :
    • DropDown: Provides a dynamic drop-down functionality, similar to what is found in Windows Sharepoint Server. (j'adore)
    • MutuallyExclusiveCheckbox: Allows picklists of mutually-exclusive values.
    • ValidatorCallout: Adds great client-side UI to ASP.NET validators.

Si vous avez des applications existantes avec la CTP de July d'Atlas, vous pouvez vous poser la question de la migration, en effet il y a de nombreux changement et qui font que la migration risque d'être compliqué. Pour l'instant je ne vous conseille pas de migrer vos applications, il risque d'y avoir encore quelques changements, notamment au niveau du "Value-Add package" lorsqu'ils vont rebasculé certaines features (l'UpdateProgress entre autre) dans le "core-package", je conseil donc d'attendre la prochaine version bêta.

La date finale d'Atlas n'a pas été annoncé, mais Scott Guthrie a dit qu'Atlas sera en version final lorsque les clients estimeront qu'Atlas soit prêt :-)

Pour conclure

Avec cette nouvelle version, Microsoft a écouté les développeurs, pour preuve la plupart des critiques que j'ai bloggé ont été pris en compte. On note également de très grande modification pour l'amélioration de performance, pour notre plus grand bonheur.

Vivement la version finale :-)

Posted: samedi 21 octobre 2006 19:27 par cyril
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

CLaueR a dit :

Au chapitre des changements, il y a aussi celui-ci qui peut être assez problématique pour des applications déployées sur un hébergement mutualisé.

http://weblogs.asp.net/kencox/archive/2006/10/21/Full-Trust-Strikes-Again.aspx

J'espère un changement à ce niveau d'ici à la RTW.

# octobre 22, 2006 12:06

sebmafate a dit :

lol... tu vas finir par bosser dans l'équipe Atlas :p

# octobre 22, 2006 17:20

Laurent GEFFROY a dit :

Bonne galère d'une journée pour migrer mon appli

L'enregistrement de JAvascript dynamiquement ne fonctionnait plus. Il faut maintenant utiliser le Microsoft.Web.UI.ScriptManager.RegisterStartUpScript...

Heureusement, le forum de atlas.asp.net est assez fourni. Cependant, j'ai peur que la béta 1 soit moins stable qu'Atlas... A voir à l'usage

# octobre 23, 2006 12:32
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Emportez votre sélection de la MSDN dans la poche ? par Blog de Jérémy Jeanson le il y a 14 heures et 4 minutes

- [ #Office365 ] Pb de connexion du flux Yammer ajouté à un site SharePoint par Le blog de Patrick [MVP SharePoint] le il y a 19 heures et 25 minutes

- NFluent & Data Annotations : coder ses propres assertions par Fathi Bellahcene le il y a 19 heures et 34 minutes

- Installer un site ASP.net 32bits sur un serveur exécutant SharePoint 2013 par Blog de Jérémy Jeanson le 04-17-2014, 06:34

- [ SharePoint Summit 2014 ] Tests de montée en charge SharePoint par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 20:44

- [ SharePoint Summit 2014 ] Bâtir un site web public avec Office 365 par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 18:30

- Kinect + Speech Recognition + Eedomus = Dommy par Aurélien GALTIER le 04-16-2014, 17:17

- [ SharePoint Summit 2014 ] Une méthodologie simple pour concevoir vos applications OOTB SharePoint de A à Z par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 16:51

- //Lean/ - Apprendre à faire des Apps Windows universelles par Blog de Jérémy Jeanson le 04-16-2014, 12:57

- Une culture de la donnée pour tous… par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 11:00