tony722
La variable strCSSClass a menudo tiene un valor, pero a veces está vacía.
No quiero incluir una class=”” vacía en el HTML de este elemento de entrada, lo que significa que si strCSSClass está vacía, no quiero el atributo class= en absoluto.
La siguiente es una forma de hacer un atributo HTML condicional:
<input type="text" id="@strElementID" @(CSSClass.IsEmpty() ? "" : "class=" + strCSSClass) />
¿Hay una forma más elegante de hacer esto? Específicamente uno en el que podría seguir la misma sintaxis que se usa en las otras partes del elemento: class=”@strCSSClass” ?
erik portero
No lo escuchó de mí, el PM para Razor, pero en Razor 2 (Páginas web 2 y MVC 4) tendremos atributos condicionales integrados en Razor (a partir de MVC 4 RC probado con éxito), para que pueda escribir cosas como esto:
<input type="text" id="@strElementID" class="@strCSSClass" />
Si strCSSClass
es nulo, entonces el atributo de clase no se representará en absoluto.
Otras lecturas
-
Sí, definitivamente no deberías aceptar la mía como respuesta. Dicho esto, hoy en día no existe una forma más limpia de hacerlo (por lo tanto, estamos creando una forma más limpia de hacerlo). Probablemente la forma más limpia de hacerlo es usar Html.TextBox, pero eso tiene un conjunto diferente de cosas menos deseables. 🙁 Me alegro de que te guste lo que estamos agregando. 🙂
–Erik Porter
16 de noviembre de 2011 a las 23:07
-
Pero, ¿cómo puedo combinar los atributos de Razor con otro texto? Necesito hacer lo siguiente: … id=”track_@track.ID”. Esperaba algo como …id=”track_2″, pero generó el siguiente resultado: …id=”track_@track.ID”…
– Laserson
15 de enero de 2012 a las 17:57
-
Puede obligar a Razor a evaluar el código poniendo paréntesis a su alrededor. id=”pista_@(pista.ID)”
–Erik Porter
27 de enero de 2012 a las 18:42
-
Se agregó una nota que indica que esto funciona correctamente con MVC 4. Si está en MVC 3, vea mi respuesta a continuación.
– AaronLS
6 de noviembre de 2012 a las 20:29
-
@ErikPorter ¡POR FAVOR, NO SE MULTE CON MI HTML! también consulte stackoverflow.com/questions/9234467/… esto también para otros malos comportamientos
– tormenta de águila
15 de enero de 2014 a las 0:04
AaronLS
Tenga en cuenta que puede hacer algo como esto (al menos en MVC3):
<td align="left" @(isOddRow ? "class=TopBorder" : "style=border:0px") >
Lo que creía que era una navaja que agregaba comillas era en realidad el navegador. Como señaló Rism al probar con MVC 4 (no he probado con MVC 3 pero supongo que el comportamiento no ha cambiado), esto en realidad produce class=TopBorder
pero los navegadores pueden analizar esto bien. Los analizadores HTML son algo indulgentes con las comillas de atributos que faltan, pero esto puede fallar si tiene espacios o ciertos caracteres.
<td align="left" class="TopBorder" >
O
<td align="left" style="border:0px" >
Qué sale mal al proporcionar sus propias cotizaciones
Si intenta usar algunas de las convenciones habituales de C# para las comillas anidadas, terminará con más comillas de las que esperaba porque Razor intenta escapar de ellas de forma segura. Por ejemplo:
<button type="button" @(true ? "style=\"border:0px\"" : string.Empty)>
Este debería evaluar a <button type="button" style="border:0px">
pero Razor escapa a todos los resultados de C# y, por lo tanto, produce:
style="border:0px"
Solo verá esto si ve la respuesta a través de la red. Si usa un inspector de HTML, a menudo en realidad está viendo el DOM, no el HTML sin procesar. Los navegadores analizan HTML en el DOM, y la representación DOM posterior al análisis ya tiene algunos detalles aplicados. En este caso, el navegador ve que no hay comillas alrededor del valor del atributo, las agrega:
style=""border:0px""
Pero en el inspector de DOM, los códigos de caracteres HTML se muestran correctamente, por lo que realmente ve:
style=""border:0px""
En Chrome, si hace clic con el botón derecho y selecciona Editar HTML, vuelve a cambiar para que pueda ver esos desagradables códigos de caracteres HTML, lo que deja en claro que tiene comillas externas reales y comillas internas codificadas en HTML.
Entonces, el problema de tratar de hacer la cita usted mismo es que Razor se escapa de esto.
Si desea un control completo de las cotizaciones
Use Html.Raw para evitar que se escapen las cotizaciones:
<td @Html.Raw( someBoolean ? "rel="tooltip" data-container=".drillDown a"" : "" )>
Representa como:
<td rel="tooltip" title="Drilldown" data-container=".drillDown a">
Lo anterior es perfectamente seguro porque no estoy generando ningún HTML de una variable. La única variable involucrada es la condición ternaria. Sin embargo, tener cuidado que esta última técnica podría exponerlo a ciertos problemas de seguridad si crea cadenas a partir de datos proporcionados por el usuario. Por ejemplo, si creó un atributo a partir de campos de datos que se originaron a partir de datos proporcionados por el usuario, el uso de Html.Raw significa que la cadena podría contener un final prematuro del atributo y la etiqueta, luego comenzar una etiqueta de secuencia de comandos que hace algo en nombre de la persona que inició sesión actualmente. usuario (posiblemente diferente al usuario que inició sesión). Tal vez tenga una página con una lista de todas las imágenes de los usuarios y esté configurando una información sobre herramientas para que sea el nombre de usuario de cada persona, y un usuario se nombró a sí mismo. '/><script>$.post('changepassword.php?password=123')</script>
y ahora cualquier otro usuario que vea esta página tiene su contraseña instantáneamente cambiada a una contraseña que el usuario malintencionado conoce.
-
¡Ese es un muy buen punto! Y, de hecho, lo hace legible y utilizable en la mayoría de las situaciones.
– Dmitro Shevchenko
1 de mayo de 2012 a las 6:53
-
Eso es lo que estaba haciendo en el ejemplo de mi pregunta. Gracias por una explicación más elaborada y un ejemplo. 🙂
– tony722
1 de junio de 2012 a las 0:23
-
Eso sí, cuidado con los espacios. “estilo = pantalla: ninguno;” se muestra como ninguno;=”” :=”” style=”display”
– wmcainsh
30 de enero de 2013 a las 12:17
-
Entonces, ¿por qué no funciona esto re: comillas dobles mágicas Simplemente produce
– riesgo
29 de enero de 2015 a las 0:19
-
@AaronLS Sí, así es exactamente como son. No puedo entender cómo el navegador (Chrome 40/FF33.1/IE 10) afectaría algo ya que este es un marcado generado por el servidor y, de ser así, ¿cómo es que solo esos dos atributos de clase pero no para el atributo de clase del botón preguntar o incluso el tipo = atributos de “botón” de los tres botones. Definitivamente una cosa del servidor en mi humilde opinión, ya que también puedo RDP en un par de máquinas virtuales de Azure repartidas por todo el mundo para obtener el mismo resultado IE/Firefox/Chrome.
– riesgo
29 de enero de 2015 a las 3:50
Supongo que una forma un poco más conveniente y estructurada es usar el asistente Html. En su opinión, puede verse como:
@{
var htmlAttr = new Dictionary<string, object>();
htmlAttr.Add("id", strElementId);
if (!CSSClass.IsEmpty())
{
htmlAttr.Add("class", strCSSClass);
}
}
@* ... *@
@Html.TextBox("somename", "", htmlAttr)
Si de esta manera te será útil, te recomiendo que definas el diccionario. htmlAttr
en su modelo para que su vista no necesite ninguna @{ }
bloques lógicos (sea más claro).
-
-1, nunca recomiendo a alguien que ponga lógica en las vistas. Las vistas solo deben ser responsables de la representación. Agregue un ejemplo de HtmlHelper en su lugar y le daré +1.
– jgauffin
9 de noviembre de 2011 a las 8:13
-
Para probar cosas, puedo usar el bloque de código a la vista: es más rápido. Y mi recomendación fue mover este bloque al modelo.
– Yachur
9 de noviembre de 2011 a las 8:24
-
sí, pero las respuestas deben mostrar las mejores prácticas y no la versión rápida y sucia que hace que el mantenimiento del código sea una pesadilla.
– jgauffin
9 de noviembre de 2011 a las 8:28
-
@jgauffin Creo que el asistente Html aquí es innecesario. mira mi respuesta
– gdoron está apoyando a Mónica
9 de noviembre de 2011 a las 9:49
-
+1 @Yaschur Tu respuesta es inspiradora. Sigan con el buen trabajo. es decir. con la función de conversión explícita de C#, podemos mejorar aún más esta respuesta. No todo el código tenía que tener una forma determinada. Siempre hay una mejor manera de la que no somos conscientes. Y algunos proyectos están a favor de la organización del código. ¡La organización del código es práctica, no conceptos!
– Bambú
28 de diciembre de 2012 a las 10:41