asp.net - studio - sintaxis lenguaje asp net
¿Por qué los formularios web de ASP.NET necesitan el atributo Runat="Servidor"? (13)
¿Por qué tengo que especificar runat="server"
en todos mis controles ASP.NET cuando es un atributo obligatorio y el server
es la única opción disponible en mi conocimiento limitado de ASP.NET, y me da un error si no lo hago? usalo?
Entiendo que puedo usarlo opcionalmente en mis etiquetas HTML, y entiendo el paradigma cliente / servidor y lo que en realidad está especificando.
¿Es una etiqueta redundante que podría ser simplemente implícita porque el control es un control ASP.NET, o existe una razón subyacente?
Acabo de llegar a esta conclusión por prueba y error: se necesita runat = "servidor" para acceder a los elementos en tiempo de ejecución en el lado del servidor. Eliminarlos, recompilarlos y ver qué pasa.
Al enviar los datos al servidor web ASP.NET, los controles mencionados como Runat = "servidor" se representarán como objetos Dot Net en la aplicación de servidor. Puede escribir manualmente el código en los controles HTML o bien puede usar la opción Ejecutar como servidor haciendo clic derecho en la vista de diseño. Los controles ASP.NET obtendrán automáticamente este atributo una vez que lo arrastre desde la caja de herramientas donde normalmente los controles HTML no lo hacen.
Artículo de Microsoft Msdn The Forgotten Controls: HTML Server Controls explica el uso de runat = "server" con un ejemplo en el cuadro de texto <input type="text">
convirtiéndolo en <input type="text" id="Textbox1" runat="server">
Hacer esto le dará acceso programático al elemento HTML en el servidor antes de que la página Web se cree y se envíe al cliente. El elemento HTML debe contener un atributo id. Este atributo sirve como una identidad para el elemento y le permite programar elementos por sus ID específicos. Además de este atributo, el elemento HTML debe contener runat = "server". Esto le dice al servidor de procesamiento que la etiqueta se procesa en el servidor y que no debe considerarse un elemento HTML tradicional.
En resumen, para habilitar el acceso programático al elemento HTML, agregue runat="server"
.
Creo que Microsoft puede solucionar esta ambigüedad haciendo que el compilador agregue el atributo runat antes de que la página se compile, algo así como el borrado de tipo que Java tiene con los genéricos, en lugar de borrarlo, podría estar escribiendo runat = server donde quiera que vea. asp: prefijo para etiquetas, por lo que el desarrollador no tendría que preocuparse por eso.
Está ahí porque todos los controles en ASP .NET heredan de System.Web.UI.Control que tiene el atributo "runat".
en la clase System.Web.UI.HTMLControl, el atributo no es obligatorio, sin embargo, en la clase System.Web.UI.WebControl el atributo es obligatorio.
Edición: déjame ser más específico. Ya que asp.net es prácticamente un resumen de HTML, el compilador necesita algún tipo de directiva para que sepa que la etiqueta específica debe ejecutarse en el lado del servidor. si ese atributo no estuviera allí, entonces no sabría procesarlo primero en el servidor. si no está allí, asume que es un marcado normal y se lo pasa al cliente.
Los elementos HTML en los archivos ASP.NET se tratan, de forma predeterminada, como texto. Para hacer que estos elementos sean programables, agregue un atributo runat="server"
al elemento HTML. Este atributo indica que el elemento debe tratarse como un control de servidor.
Mi sospecha es que tiene que ver con cómo se identifican los controles del lado del servidor durante el procesamiento. En lugar de tener que verificar todos los controles en tiempo de ejecución por nombre para determinar si se debe realizar el procesamiento del lado del servidor, hace una selección en la representación del nodo interno por etiqueta. El compilador comprueba que todos los controles que requieren etiquetas de servidor los tengan durante el paso de validación.
No todos los controles que se pueden incluir en una página deben ejecutarse en el servidor. Por ejemplo:
<INPUT type="submit" runat=server />
Esto es esencialmente lo mismo que:
<asp:Button runat=server />
Elimine la etiqueta runat = server de la primera y tendrá un botón HTML estándar que se ejecuta en el navegador. Hay razones a favor y en contra de ejecutar un control en particular en el servidor, y ASP.NET no tiene forma de "asumir" lo que usted desea en función del código HTML que incluya. Podría ser posible "inferir" el servidor runat = para la familia de controles <asp:XXX />
, pero supongo que Microsoft consideraría un hackeo de la sintaxis de marcado y el motor ASP.NET.
Si lo usa en etiquetas html normales, significa que puede manipularlas programáticamente en controladores de eventos, etc. Por ejemplo, cambie el href o la clase de una etiqueta de ancla en la carga de la página ... solo haga eso si tiene que hacerlo, porque las etiquetas html vanilla vaya más rápido.
En cuanto a los controles de usuario y de servidor, no, simplemente no funcionarán sin ellos, sin haber profundizado en las entrañas del preprocesador aspx, no podría decir exactamente por qué, pero supondría que, por razones probablemente buenas, solo escribieron el analizador de esa manera, buscando cosas explícitamente marcadas como "hacer algo".
Si @JonSkeet está en cualquier lugar, él probablemente podrá dar una respuesta mucho mejor.
Siempre he creído que existía más para entender que puedes mezclar etiquetas ASP.NET y etiquetas HTML, y las etiquetas HTML tienen la opción de ser runat="server"
o no. No hace daño a nada dejar la etiqueta, y provoca que un error del compilador la elimine. Cuantas más cosas insinúe sobre el lenguaje web, menos fácil será para un programador en ciernes entrar y aprenderlo. Esa es una razón tan buena como cualquiera para ser detallado acerca de los atributos de las etiquetas.
Esta conversación se tuvo en el Blog Mike Schinkel entre él y Talbot Crowell de los Servicios Nacionales de Microsoft. La información relevante se encuentra a continuación (primer párrafo parafraseado debido a errores gramaticales en la fuente):
[...] pero la importancia de
<runat="server">
es más para la consistencia y la extensibilidad.Si el desarrollador tiene que marcar algunas etiquetas (viz.
<asp: />
) para que el motor de ASP.NET las ignore, también existe el problema potencial de colisiones de espacio de nombres entre etiquetas y futuras mejoras. Al requerir el atributo<runat="server">
, esto se niega.
Continúa:
Si se requiriera
<runat=client>
para todas las etiquetas del lado del cliente, el analizador tendría que analizar todas las etiquetas y eliminar la parte<runat=client>
.
Él continúa:
Actualmente, si mi suposición es correcta, el analizador simplemente ignora todo el texto (etiquetas o no etiquetas) a menos que sea una etiqueta con el atributo
runat=server
o un prefijo "<%
" o ssi "<!– #include
... (.. .) Además, dado que ASP.NET está diseñado para permitir la separación de los diseñadores web (foo.aspx) de los desarrolladores web (foo.aspx.vb), los diseñadores web pueden usar sus propias herramientas de diseño web para colocar HTML y clientes. JavaScript lateral sin tener que conocer las etiquetas o atributos específicos de ASP.NET.
Un atributo bastante redundante, considerando que la etiqueta "asp" es obviamente un elemento ASP y debería ser suficiente para identificarlo como un elemento accesible del lado del servidor.
En otros lugares, sin embargo, solía elevar las etiquetas normales para usarlas en el código subyacente.
Usualmente no me gusta adivinar, pero voy a hacer esto ...
Si recuerdas las exageraciones publicitarias de .NET de Microsoft en el pasado (2001?), Era difícil decir qué era incluso .NET. ¿Fue un servidor? ¿Una plataforma de programación? ¿un idioma? algo completamente nuevo? Dados los anuncios, era ambiguo todo lo que querías que fuera, solo resolvía cualquier problema que pudieras tener.
Entonces, supongo que hubo una gran visión oculta de que el código ASP.NET podría ejecutarse en cualquier lugar, del lado del servidor o del lado del cliente, en una copia de Internet Explorer vinculada al tiempo de ejecución de .NET. runat = "servidor" es solo un remanente vestigial, dejado atrás porque su equivalente del lado del cliente nunca llegó a producción.
¿Recuerdas esos anuncios raros?
Relacionado: Artículo de The Register con alguna historia .NET.
runat="Server"
indica que se producirá una devolución al servidor para el "control" de HTML.
Los formularios web utilizan la postback
constantemente para indicar al servidor que procese un evento de control de página.
.NET
páginas de .NET
MVC
NO usan postback
(excepto para un formulario "submit"
). MVC
confía en JQUERY
para administrar la página en el lado del cliente (evitando así la necesidad de muchos mensajes de postback
de datos al servidor).
Entonces: .NET
Web Forms ... use el atributo "runat"
mucho en el marcado de la página.
.NET
MVC
casi nunca usa el atributo "runat"
en el marcado de la página.
Espero que esto ayude a aclarar por qué es necesario runat
...