Pourquoi les formulaires Web ASP.NET ont-ils besoin de l'attribut Runat = "Server"?
Pourquoi dois-je spécifier runat="server" sur tous mes contrôles ASP.NET alors qu'il s'agit d'un attribut obligatoire et que server est la seule option disponible dans ma connaissance limitée d'ASP.NET et que j'obtiens une erreur si je ne l'utilise pas?
Je comprends que je peux éventuellement l’utiliser sur mes balises HTML et que je comprends le paradigme client/serveur et ce qu’il spécifie réellement.
S'agit-il d'une balise redondante qui pourrait simplement être impliquée par le contrôle en tant que contrôle ASP.NET ou existe-t-il une raison sous-jacente?
J'ai toujours pensé que c'était là le meilleur moyen de comprendre que vous pouvez mélanger des balises ASP.NET et des balises HTML, et que les balises HTML ont la possibilité d'être runat="server" ou non. Laisser la balise dedans ne fait pas de mal, et une erreur du compilateur la supprime. Plus vous indiquez de choses sur le langage Web, moins il est facile pour un programmeur en herbe de l’apprendre. C’est une raison aussi valable que celle d’être bavard sur les attributs de balises.
Cette conversation a eu lieu sur Blog de Mike Schinkel/entre lui-même et Talbot Crowell de Microsoft National Services. Les informations pertinentes sont les suivantes (premier paragraphe paraphrasé du fait d’erreurs de grammaire dans la source):
[...] mais l'importance de
<runat="server">concerne davantage la cohérence et l'extensibilité.Si le développeur doit marquer certaines balises (à savoir
<asp: />) que le moteur ASP.NET doit ignorer, le problème potentiel de collisions d'espaces de noms entre les balises et d'améliorations futures est également posé. En demandant l'attribut<runat="server">, cela est annulé.
Il continue:
Si
<runat=client>était requis pour toutes les balises côté client, l'analyseur aurait besoin d'analyser toutes les balises et d'extraire la partie<runat=client>.
Il continue:
Actuellement, Si ma supposition est correcte, l'analyseur syntaxique ignore simplement tout le texte (tags ou no tags) sauf s'il s'agit d'un tag avec le
runat=serverattribut ou un “<%” préfixe ou ssi “<!– #include… (...) En outre, puisque ASP.NET est conçu pour permettre la séparation des concepteurs de sites Web (foo.aspx) des développeurs Web (foo.aspx.vb), les concepteurs de sites Web peuvent utiliser leurs propres outils de conception Web pour placez du code HTML et JavaScript côté client sans avoir à connaître ASP.NET balises ou attributs spécifiques.
D'habitude, je n'aime pas deviner, mais je vais passer à celui-ci ...
Si vous vous souvenez du battage publicitaire marketing de .NET de Microsoft à l'époque (2001?), Il était difficile de dire ce que fut même .NET. Était-ce un serveur? une plate-forme de programmation? une langue? quelque chose de entièrement nouveau? Étant donné les publicités, tout ce que vous souhaitiez être ambigu était ambigu: cela résolvait tout problème éventuel.
Donc, je suppose qu'il y avait une grande vision cachée selon laquelle le code ASP.NET pouvait être exécuté n'importe où - côté client OR côté serveur, dans une copie d'Internet Explorer liée au moteur d'exécution .NET. runat = "serveur" n'est qu'un vestige résiduel, laissé parce que son équivalent côté client n'a jamais été rendu en production.
Rappelez-vous ces annonces étranges?
Connexes: Article de The Register avec un historique .NET.
Tous les contrôles pouvant être inclus dans une page doivent doivent être exécutés sur le serveur. Par exemple:
<INPUT type="submit" runat=server />
C'est essentiellement la même chose que:
<asp:Button runat=server />
Supprimez la balise runat = server du premier et vous disposez d'un bouton HTML standard qui s'exécute dans le navigateur. Il existe des raisons pour et contre l’exécution d’un contrôle particulier sur le serveur et ASP.NET n’a aucun moyen de "supposer" ce que vous voulez en fonction du balisage HTML que vous incluez. Il serait peut-être possible "d'inférer" le serveur runat = pour la famille de contrôles <asp:XXX />, mais je suppose que Microsoft considérerait cela comme un piratage de la syntaxe de balisage et du moteur ASP.NET.
Microsoft Msdn article Les contrôles oubliés: Contrôles de serveur HTML explique l'utilisation de runat = "server" avec un exemple dans la zone de texte <input type="text"> en la convertissant en <input type="text" id="Textbox1" runat="server">
Cela vous donnera un accès programmatique à l'élément HTML sur le serveur avant la page Web est créé et envoyé au client . L'élément HTML doit contenir un attribut id. Cet attribut sert en tant qu'identité pour l'élément et vous permet de programmer des éléments par leurs identifiants spécifiques. En plus de cet attribut, l'élément HTML doit contenir runat = "serveur". Cela indique au serveur de traitement que le Le tag est traité sur le serveur et ne doit pas être considéré comme un élément HTML traditionnel.
En bref, ajoutez runat="server" pour permettre l'accès par programme à l'élément HTML.
Je soupçonne que cela a à voir avec la façon dont les contrôles côté serveur sont identifiés pendant le traitement. Plutôt que de devoir vérifier chaque contrôle au moment de l'exécution par nom pour déterminer si un traitement côté serveur doit être effectué, il sélectionne la représentation du nœud interne par balise. Le compilateur vérifie que tous les contrôles nécessitant des balises de serveur en ont lors de l'étape de validation.
Les éléments HTML dans les fichiers ASP.NET sont, par défaut, traités comme du texte. Pour rendre ces éléments programmables, ajoutez un attribut runat="server" à l'élément HTML. Cet attribut indique que l'élément doit être traité comme un contrôle serveur.
Cela existe parce que tous les contrôles de ASP .NET héritent de System.Web.UI.Control qui a l'attribut "runat".
dans la classe System.Web.UI.HTMLControl, l'attribut n'est pas obligatoire; toutefois, dans la classe System.Web.UI.WebControl, l'attribut est requis.
edit: Permettez-moi d'être plus précis. asp.net étant à peu près un résumé de HTML, le compilateur a besoin d’une sorte de directive pour savoir qu’une balise spécifique doit être exécutée côté serveur. si cet attribut n'était pas là, il ne saurait pas le traiter d'abord sur le serveur. si ce n'est pas le cas, il suppose qu'il s'agit d'un balisage régulier et le transmet au client.
Je pense que Microsoft peut remédier à cette ambiguïté en faisant en sorte que le compilateur ajoute l'attribut runat avant que la page ne soit jamais compilée, quelque chose comme l'effacement de type que Java a avec les génériques, au lieu d'effacer, il pourrait écrire runat = server où qu'il soit asp: préfixe pour les balises, afin que le développeur n'ait pas à s'en soucier.
Si vous l'utilisez sur des balises html normales, cela signifie que vous pouvez les manipuler par programmation dans des gestionnaires d'événements, par exemple, changer le href ou la classe d'une balise d'ancrage lors du chargement de la page ... ne le faites que si vous devez, aller plus vite.
En ce qui concerne les contrôles utilisateur et les contrôles serveur, non, ils ne fonctionneront tout simplement pas sans eux, sans avoir plongé dans les entrailles du préprocesseur aspx, ils ne pourraient pas dire exactement pourquoi, mais ils devineraient que pour de bonnes raisons, ils ont juste écrit l’analyseur de cette façon, recherchant des choses explicitement marquées comme "faire quelque chose".
Si @JonSkeet existe quelque part, il sera probablement en mesure de fournir une bien meilleure réponse.
Attribut assez redondant, étant donné que la balise "asp" est évidemment un élément ASP et devrait suffire à l'identifier comme un élément accessible côté serveur.
Ailleurs cependant, il élève les balises normales à utiliser dans le code-behind.
Je suis arrivé à cette conclusion par essais et erreurs: Runat = "serveur" est nécessaire pour accéder aux éléments au moment de l'exécution sur le serveur . Supprimez-les, recompilez et observez ce qui se passe.
Lors de la soumission des données au serveur Web ASP.NET, les contrôles mentionnés sous Runat = "serveur" seront représentés par des objets Dot Net dans l'application serveur. Vous pouvez taper manuellement le code dans les contrôles HTML ou utiliser Exécuter en tant que serveur option en cliquant avec le bouton droit de la souris en mode création . Les contrôles ASP.NET obtiendront automatiquement cet attribut une fois que vous le faites glisser de la boîte à outils, généralement les contrôles HTML. ne pas.