Différences entre les modèles objets managés et les modèles objets ECMAScript

Article
09/24/2014

Dernière modification : jeudi 15 juillet 2010

S’applique à : SharePoint Foundation 2010

Vous devez prendre note des différences importantes suivantes entre le modèle objet client ECMAScript (JavaScript, JScript) et le modèle objet client managé.

La signature de la méthode peut être différente, comme avec le constructeur ClientContext() (JavaScript: ClientContext(serverRelativeUrl)). Dans JavaScript, ce constructeur accepte une URL relative au serveur, mais la version managée du constructeur prend soit une URL complète soit Uri.
Les deux modèles objet utilisent des types de valeur de données différents. Le modèle objet JavaScript n'a pas d'équivalent pour tous les types de valeur de données dans le modèle objet managé de .NET Framework. JavaScript considère StringCollection comme string[]. D'un autre côté, JavaScript possède certaines valeurs que .NET Framework n'a pas, par exemple NaN, ou l'infinité négative et positive.
Le modèle objet JavaScript autorise l'authentification par formulaires, mais vous ne pouvez pas spécifier au mécanisme d'authentification de se connecter au serveur. Pour des informations sur les modèles objet clients managés et l'authentification par formulaires, voir Authentification dans les modèles objet clients gérés.
Lorsque vous créez un élément et l'ajoutez à une collection existante, il n'est pas possible d'effectuer d'autres mises à jour avec cette collection pendant que la requête est en cours. Ce problème concerne l'ajout d'un élément à une collection ; autrement, plusieurs clients peuvent simultanément lire et écrire dans des éléments existants dans une collection.
Dans le cadre de la sécurité générale, vous ne pouvez pas utiliser le modèle objet JavaScript sur une page pour utiliser des données Microsoft SharePoint Foundation 2010 sauf si la page contient un contrôle de déchiffrement, par exemple <SharePoint:FormDigest runat="server"/>.
En règle générale, vous ne pouvez pas partager des variables entre des étendues, ce qui fait que vous ne pouvez pas utiliser des schémas de codage communs pour des instructions try/catch/finally.
Un objet RoleDefinitionBindingCollection utilisé pour créer des affectations de rôles n’a pas d’identité d’objet. Par conséquent, si vous créez un nouvel objet RoleDefinitionBindingCollection puis que vous essayez de l’utiliser après la création d’une affectation de rôle, une erreur est retournée.
Certaines comparaisons sensibles à la casse ne fonctionnent pas de la même façon sur le client que sur le serveur. Certaines comparaisons côté serveur utilisent les paramètres régionaux du site Web pour effectuer une comparaison, mais le client peut uniquement utiliser une culture indifférente pour éviter de fréquents allers-retours. SharePoint Foundation 2010 ne prend pas en charge les comparaisons sensibles à la casse si le serveur utilise les paramètres régionaux d'un site Web.
En raison des limitations d'une publication asynchrone, vous pouvez constater qu'un script inline n'est pas appelé quand la page se trouve en certains modes, par exemple lorsqu'une page Wiki est en mode édition. En ce cas, utilisez un contrôle ScriptManager et sa méthode RegisterStartupScript() pour inscrire un bloc de script de démarrage pour exécuter votre code, au lieu d'utiliser un script inline.