control - ¿Cuál es el estado de las etiquetas runat="server" en ASP.NET MVC?
input asp net (4)
Acabo de leer en este tutorial:
http://www.asp.net/learn/mvc/tutorial-12-cs.aspx
que necesitas el
<head runat="server">
para poder definir fácilmente el título de la página en sus vistas.
Algunos textos en ASP.NET MVC indican que "no hay etiquetas de servidor runat", incluso este artículo de MSDN dice esto, cuando, justo encima de esa declaración, hay un ejemplo de código con una etiqueta de servidor runat en el elemento HEAD:
Y en las conversaciones de StackOverflow leo
"El hecho de que quiera usar controles" runat = server "significa que debería estar haciendo una aplicación ASP.NET tradicional.
Y, por supuesto, en la página Site.Master hay atributos de runat server en ContentPlaceHolders.
Lo único que veo ausente de ASP.NET MVC en términos de servidor runat es la omnipresente etiqueta FORM = "server" en cada página / vista .aspx.
Pero, ¿qué pasa con el resto de las etiquetas de servidor runat en ASP.NET MVC, qué quieren decir las personas cuando dicen que ASP.NET MVC no las tiene?
No significa que no pueda usar runat = "servidor", sino que no es necesario usar controles del lado del servidor, generalmente, en MVC. Si encuentra que necesita un control del lado del servidor y está trabajando con él en código subyacente, eso es una indicación de que la aplicación está volviendo a los formularios web. Todas las cosas que normalmente suceden en su shoulo de código subyacente ahora se manejan en su controlador o en la lógica de la vista.
Si usa una etiqueta runat = "server" en CUALQUIER elemento, como un DIV, representará ese código como un método separado en la página compilada.
Si está convirtiendo código ''heredado'', es una buena idea eliminar todas las etiquetas runat desde el principio, de lo contrario terminará en una situación en la que un código como el siguiente le da un error.
<% foreach (var cat in cats) { %>
<div runat="server">
<span class="name"> <%= cat.name %> </span> is a
<span class="breed"> <%= cat.breed %> </span>
</div>
<% } %>
Este código fallará diciéndole algo de locura acerca de que ''cat'' esté fuera de alcance. Eventualmente, cuando mires el código completo generado, verás que el <div> se ha generado como su propio método completo, que es, por supuesto, un alcance diferente sin gatos a la vista.
Volver por un segundo a la plantilla predeterminada para una aplicación MVC:
Verás que la plantilla actual te da esto para la head :
<head runat="server">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title><%= Html.Encode(ViewData["Title"]) %></title>
<link href="../../Content/Site.css" rel="stylesheet" type="text/css" />
</head>
Esto me dejó pensando: si estamos usando la sintaxis <% = para escribir el título directamente en la etiqueta del title , entonces ¿por qué tendríamos que hacerlo runat?
Resulta que sospechaba que el código detrás de la head busca un valor existente dentro de la etiqueta del título (que hubiera sido generado aquí por <%= Html.Encode(ViewData["Title"]) %> . Si encuentra uno ( que será el caso de todas las vistas de muestra en la plantilla de MVC), entonces no hará nada más. Si no existe un título (si ViewData ["Title"] es nulo o está vacío) se establecerá de forma predeterminada a lo que esté definido en su ver por el atributo Title :
<%@ Page Language="C#" MasterPageFile="~/Views/Shared/RRMaster.Master"
Title="View Products" AutoEventWireup="true" CodeBehind="ViewProduct.aspx.cs"
Inherits="RR_MVC.Views.Products.ViewProduct" %>
En mi página maestra, habría eliminado la etiqueta runat=''server'' , ya que no creo que alguna vez quiera rellenar el título de mi página desde la propiedad Title de la vista. Pero me estoy retrasando haciendo esto pendiente de la publicación de blog prometida de Phil sobre el tema, en caso de que el servidor runat me brinde algo útil también para mi CSS y JS.
MVC es solo una capa sobre webforms. Mis controles de formularios web personalizados también requieren que la etiqueta de cabecera esté accesible en el lado del servidor para el registro de scripts. Estos controles personalizados se representan en el lado del cliente y no usan viewstate ni eventos en el servidor. Debido a esto, también se pueden usar en MVC con el motor de visualización ASPX.