2008-10-13 17 views
7

Con páginas vistas motor/plantilla aspx/ASHX de ASP.NET la manera de escupir a la pantalla parece ser:Microsoft MVC "eco/impresión/salida", etc

<%= Person.Name %> 

que estaba bien con formularios web como un montón de los datos del modelo estaban obligados a controlar programáticamente. Pero con MVC ahora estamos usando esta sintaxis más a menudo.

El problema que tengo es bastante trivial, pero molesto de cualquier manera. Esto es que parece romper la marca de arriba es decir .:

<% foreach(var Person in People) { %> 
    <%= Person.Name %> 
<% } %> 

Eso parece como un montón de etiquetas de apertura y cierre a mí!

Otros motores de la vista en el contrib MVC tienen un medio de escupir a la pantalla con un vistazo a abrir y cerrar las etiquetas de script utilizando palabra clave estándar, tales como "impresión, hacia fuera, echo" es decir, (ejemplo brail):

<% 
for element in list: 
     output "<li>${element}</li>" 
end 
%> 

Ahora, dije que esto puede parecer trivial, pero parece más fácil de leer de esta manera. Entonces, ¿cuáles son las ventajas de que MS tenga esta sintaxis y no proporcione un método de salida?

Cheers, Chris.

Respuesta

11

considerar algo como esto, en su lugar:

<% foreach(var Person in People) { 
    Response.Write(Person.Name); 
} %> 

Creo que va a trabajar. (Aunque yo no lo he probado, he hecho más que empezar con MVC y no tienen el conjunto de herramientas aquí en la oficina.)

EDIT: al parecer, se perdió la pregunta real ... :)

Microsoft proporciona un método de salida, pero no proporciona una sintaxis como la que describe. El método de salida es Response.Write(). No puedo responder esto directamente (creo que deberás consultar con Scott Hanselmann en MS :)), pero creo que no quisieron complicar las secuencias de comandos al agregar aún otro idioma para que aprendamos; Creo que querían aprovechar los idiomas (C#, VB, etc.) que los desarrolladores ya conocían.

EDIT # 2: Hice lo siguiente en un comentario, y en retrospectiva (para completar), debe ser parte de la respuesta.

Si se dirige hacia el Learn MVC site on ASP.NET, en la vista de tutorial (que es el enlace), verá el siguiente párrafo:

Ya que invocan Response.Write() por lo menudo, Microsoft le proporciona una atajo para llamar al método Response.Write(). La vista en El Listado 3 usa los delimitadores <%= y %> como un acceso directo para llamar al Response.Write().

En esencia, es el acceso directo <%= %> aceptado para Response.Write, y por lo tanto se puede utilizar el método completo Response.Write en cualquier lugar que tendría que utilizar <%= %>.

+0

Eso funciona perfectamente. –

+1

Aunque, necesitará un punto y coma al final de la Declaración Response.Write. –

+0

¡Malo! Actualizaré de nuevo. :) –

0

Lo que está buscando es probablemente un motor de visualización diferente: cada uno maneja código incrustado de esa manera a su manera.Consulte NHaml, un puerto ASP.Net del motor Haml de Rails.

Algunos motores más vista para mirar: Brail, NVelocity

0

Gracias chicos, yo no quiero específicamente para cambiar los motores de vista, aunque voy a tener tiempo para mirar a la otra disponible. Estoy seguro de que puedes entender que la mayoría de las casas de desarrollo de MS no tocan nada más que la tecnología de marca MS, así que solo quería saber si había una manera de hacerlo con el motor de vista predeterminado. O si no, ¿por qué no? ¿Hay alguna razón, si no es así, dónde podría sugerir que el compilador de vistas predeterminado agregue dicha clave?

John- Creo que Response.Write (Person.Name) simplemente mostrará la cadena en la parte superior de la página, antes de cualquier otra salida. No al 100% en eso, sin embargo, dale un buen golpe.

Editar:

Al parecer, Response.Write (Person.Name) funciona como se sugiere. Bueno, eso fue fácil. Gracias :-) John.

+0

Compruebe http://www.asp.net/learn/mvc/tutorial-04-cs.aspx. <%= %> es un atajo para Response.Write. –

0

He oído que están trabajando para mejorar esto para ASP.Net 4 mediante plantillas de cliente.

0

Otra opción que no sea Response.Write sería escribir XHtml con XSL transformations

+0

Cierto, pero ¿por qué hacerlo más complejo de lo necesario? –

+1

No dije que era una buena opción :) Usar un motor de vista diferente sería mucho más preferible que XSLT. Pero quién sabe; tal vez en algún lugar existe una situación a la cual XSLT es ideal. Podría ocurrir. –

1

Mi respuesta se basa en XP personal con cshtml MVC4 - se puede utilizar: @Html.Raw("SomeStringDirectlyInsideTheBrowserPageHTMLCode")

Esto hace que la cadena (dinámico) en su posición a diferencia de Response.Write(MyString) que, por lo que he notado, siempre reproduce la cadena al comienzo de la página del navegador.

Tenga en cuenta que las etiquetas HTML representadas por @Html.Raw(MyString) no pueden ser verificadas por el compilador. Quiero decir: @ Html.Raw ("< div .... >") no se puede cerrar por simple </div > porque obtendrá un error (< div .... > no es detectado por el compilador) por lo que debe cerrar la etiqueta con @ Html.Raw ("</div >")

PS
En algunos casos esto no funciona (por ejemplo, falla dentro de DevExpress) - use ViewContext.Writer.Write() o ViewContext.Writer.WriteLine() en su lugar.

+0

Creo que este es el método correcto para el motor Razor. – beawolf

Cuestiones relacionadas