Pourquoi les formulaires Web ASP.NET ont-ils besoin de l'attribut Runat = “Server”?

Question

Pourquoi dois-je spécifier runat = "serveur" sur tous mes contrôles ASP.NET lorsque cet attribut est obligatoire et que serveur est la seule option disponible dans ma connaissance limitée d'ASP.NET et 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?

Answer 1

J'ai toujours pensé qu'il était préférable de mélanger les balises ASP.NET et HTML, et les balises HTML ont la possibilité d'être runat = " serveur " ou ne pas. Cela ne fait pas de mal de laisser la balise dedans et cela provoque une erreur du compilateur. Plus vous indiquez de choses sur le langage Web, moins il est facile pour un programmeur en herbe de l’apprendre. C’est aussi une bonne raison que d’être bavard à propos des attributs de balises.

Cette conversation a eu lieu à propos du blog de Mike Schinkel entre lui-même et Talbot Crowell de Microsoft National Services. Les informations pertinentes se trouvent ci-dessous (premier paragraphe paraphrasé du fait d’erreurs de grammaire dans la source):

  

[...] mais l'importance de < runat = " serveur " > est plus importante en termes de cohérence et d'extensibilité.

     

Si le développeur doit marquer certaines balises (à savoir, & asp; /: ) pour que le moteur ASP.NET puisse les ignorer, le problème potentiel de collisions d’espace de nommage entre les balises et améliorations futures. En demandant l'attribut < runat = " server " > , cela est annulé.

Cela 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 le < runat = client > partie.

Il continue:

  

Actuellement,   Si ma supposition est correcte, l'analyseur   ignore simplement tout le texte (tags ou non)   balises) sauf s'il s'agit d'une balise avec le    runat = server attribut ou un " <% "   préfixe ou ssi “ <! - #include … (...)   De plus, comme 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 Web peuvent   utiliser leurs propres outils de conception Web pour   placer du code HTML et JavaScript côté client   sans avoir à connaître ASP.NET   balises ou attributs spécifiques.

Answer 2

D'habitude, je n'aime pas deviner, mais je vais passer à celui-ci ...

Si vous vous souvenez du battage publicitaire marketing de .NET par 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 était ambigu: vous avez résolu votre problème.

Donc, je suppose qu'il existe une grande vision cachée voulant que le code ASP.NET puisse être exécuté n'importe où, côté serveur OU côté client, dans une copie d'Internet Explorer liée au moteur d'exécution .NET. runat = " serveur " n’est qu’un vestige vestigial, laissé derrière parce que son équivalent côté client n’est jamais parvenu à la production.

Vous vous souvenez de ces publicités étranges?

En relation: article du registre avec un historique .NET .

Answer 3

Tous les contrôles pouvant être inclus dans une page ne doivent pas être exécutés sur le serveur. Par exemple:

< INPUT type = " submit " runat = serveur / >

Ceci est essentiellement identique à:

< asp: Bouton 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 il n’ya aucun moyen pour ASP.NET de "supposer". ce que vous voulez en fonction du balisage HTML que vous incluez. Il serait peut-être possible de "déduire" runat = server 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.

Answer 4

L'article Microsoft Msdn Les contrôles oubliés: Contrôles de serveur HTML explique l'utilisation de runat = " serveur " avec un exemple dans la zone de texte < input type = " text " > en le convertissant en < input type = " text " id = " Textbox1 " runat = " serveur " >

  

Cela vous donnera un accès programmatique à l'élément HTML sur   le serveur avant la création de la page Web et son envoi 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    La balise est traitée sur le serveur et ne doit pas être considérée comme une   élément HTML traditionnel.

Pour activer l'accès programmatique à l'élément HTML, ajoutez-lui runat = "serveur" .

Answer 5

Je pense que cela est lié à la manière 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 qui nécessitent des balises de serveur en ont lors de l'étape de validation.

Answer 6

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 = "serveur" à l'élément HTML. Cet attribut indique que l'élément doit être traité comme un contrôle serveur.

Answer 7

C’est là que tous les contrôles d’ASP .NET héritent de System.Web.UI.Control qui contient le symbole "runat". attribut.

dans la classe System.Web.UI.HTMLControl, l'attribut n'est pas obligatoire. Cependant, dans la classe System.Web.UI.WebControl, l'attribut est requis.

modifier: laissez-moi ê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. s'il n'y est pas, il suppose qu'il s'agit d'un marquage régulier et le transmet au client.

Answer 8

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 s'agir d'écrire runat = server. où il voit asp: préfixe pour les balises, afin que le développeur n'ait pas à s'en soucier.

Answer 9

Si vous l’utilisez sur des balises HTML normales, cela signifie que vous pouvez les manipuler par programmation dans les gestionnaires d’événements, etc., par exemple, changer la classe href ou la balise d’une ancre lors du chargement de la page ... ne le faites que si vous devez le faire, car les tags html vanilla vont 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 fouillé 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 le parseur de cette façon, cherchant des choses explicitement marquées comme "faire quelque chose".

Si @JonSkeet existe partout, il sera probablement en mesure de fournir une bien meilleure réponse.

Answer 10

Lors de la soumission des données au serveur Web ASP.NET, les contrôles mentionnés sous Runat = & # 8220; serveur & # 8221; seront représentés en tant qu'objets Dot Net dans l'application serveur. Vous pouvez saisir manuellement le code dans les contrôles HTML ou utiliser l'option Exécuter en tant que serveur en cliquant avec le bouton droit de la souris en mode Création. Les contrôles ASP.NET obtiennent automatiquement cet attribut une fois que vous l'avez fait glisser de la boîte à outils, contrairement aux contrôles HTML.

Answer 11

Attribut assez redondant, compte tenu de l'option "asp". Cette balise est évidemment un élément ASP et devrait suffire à l'identifier comme un élément accessible côté serveur.

Ailleurs, toutefois, il élevait les balises normales à utiliser dans le code-behind.

Answer 12

Je viens d'arriver à cette conclusion par essais et erreurs: runat = " serveur " est nécessaire pour accéder aux éléments au moment de l'exécution côté serveur. Supprimez-les, recompilez et observez ce qui se passe.

Answer 13

runat = "Serveur" indique qu'une publication sur le serveur se produira pour le "contrôle HTML".

Les formulaires Web utilisent postback pour indiquer en permanence au serveur de traiter un événement de contrôle de page.

Les pages

.NET MVC NE PAS utiliser publication (sauf pour le formulaire "submit" ). MVC s'appuie sur JQUERY pour gérer la page côté client (évitant ainsi le recours à de nombreux messages de publication sur le serveur). / p>

Donc: .NET Web Forms ... utilise beaucoup l'attribut "runat" dans le balisage de page.

.NET MVC n'utilise presque jamais l'attribut "runat & " dans la balise de page.

J'espère que cela vous aidera à comprendre pourquoi runat est nécessaire ...