Controles versus HTML estándar
https://stackoverflow.com/questions/22084
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Estoy entrando en ASP.NET (C#; sé que no importa para esta pregunta en particular, pero la divulgación completa y todo eso), y aunque me encanta que el asp:Los controles de estilo me ahorran un montón de tediosas tareas de creación de HTML y a menudo me siento frustrado con ciertos comportamientos.Anoche encontré uno cuando trabajaba con páginas maestras:mi <asp:BulletedList ID="nav">, cuando se convirtió a HTML, se convirtió <ul id="ct100_nav">.
Hay otros problemas: noté que cuando se completa automáticamente un DataGrid, se agregan atributos a la tabla resultante que no necesariamente quiero que estén ahí.
Sé que existe una cierta cantidad de "convenciones sobre configuración" que debes aceptar cuando confías en un marco para hacerse cargo de algunas de tus tediosas tareas, pero las "convenciones" en estos casos no son tanto convenciones establecidas. , sino más bien extras innecesarios.Sé por qué el ID agrega el prefijo, pero debería poder modificar y desactivar cosas como esta, especialmente porque, como evangelista de los estándares web, de todos modos no duplico los ID HTML en una sola página.
Entonces la pregunta aquí es para aquellos desarrolladores de ASP.NET más experimentados que yo:En sus experiencias en el desarrollo e implementación de aplicaciones, ¿cómo aprovecha estos controles?¿Te encuentras recurriendo a HTML codificado?¿Usas una mezcla?No quiero diseñar mi HTML en torno a peculiaridades idiosincrásicas de estos controles, pero, si es posible, me gustaría aprovecharlas cuando sea posible.
¿Qué debe hacer un chico?
Solución
Personalmente,
Creo que los controles estándar de ASP.NET están bien para cosas internas; rápido y sucio es bueno en ese escenario.Pero una vez trabajé con un desarrollador web que también era diseñador y se negó a usar los controles ASP.NET y solo codificar en HTML y agregar etiquetas runat="server" cuando fuera necesario.Esto se debía más a que quería saber exactamente cómo se iba a representar su HTML y, de todos modos, en ese momento, algunos de los controles de ASP.NET no se representaban según los estándares.
Me siento en algún punto intermedio: uso HTML cuando sea apropiado y no cuando no.Puedes obtener lo mejor de ambos mundos con el Adaptadores de control CSS
Otros consejos
De hecho, me alivia bastante ver que algunas opiniones aquí coinciden con la mía:ASP.NET como lenguaje de plantilla es muy pobre.
Sólo me gustaría refutar un par de los puntos profesionales planteados aquí (¡traje flameante!):
Dave Ward menciona colisiones de identificación; esto es cierto, pero qué mal manejado.Hubiera preferido ver los nodos a los que hacen referencia xpath o selectores de CSS profundos en lugar de hacer que la ID sea efectivamente inútil, excepto remitiéndola a elementos internos de ASP.NET como clientID; simplemente hace que escribir CSS y JS sea mucho más difícil y sin sentido.
Rob Cooper habla de cómo los controles reemplazan el HTML, así que todo está bien (parafraseando, perdóname, Rob). Bueno, no está bien, porque tomaron un lenguaje existente y bien comprendido y dijeron "no, tienes que hacer las cosas a nuestra manera". ahora", y su camino es muy mal implementado.p.ej.asp:panel representa una tabla en un navegador y un div en otro.Sin documentación o ejecución, el marcado de un control de inicio de sesión (y muchos otros) no es predecible.¿Cómo conseguirás que un diseñador escriba CSS contra eso?
Espo escribe sobre cómo los controles le brindan los beneficios de la abstracción si la plataforma cambia el HTML; bueno, esto es claramente circular (solo está cambiando porque la plataforma está cambiando, y no sería necesario si tuviera mi propio HTML allí) y realmente crea un problema.Si el control va a cambiar nuevamente con las actualizaciones, ¿cómo se supone que mi CSS debe lidiar con eso?
Los apologistas dirán "sí, pero puedes cambiar esto en la configuración" o hablarán sobre anular controles y controles personalizados.Bueno, ¿por qué debería hacerlo?El paquete de controles amigables con CSS destinado a solucionar algunos de estos problemas no tiene nada de marcado no semántico y no aborda el problema de ID.
Es imposible implementar MVC (el concepto abstracto, no la implementación 3.5) de forma inmediata con aplicaciones de formularios web porque estos controles vinculan estrechamente la vista y el control.Ahora existe una barrera de entrada para el diseñador web tradicional porque tiene que involucrarse con el código del lado del servidor para implementar lo que solían ser dominios separados de CSS y JS.Simpatizo con esta gente.
Estoy totalmente de acuerdo con el punto de Kiwi de que los controles permiten un desarrollo muy rápido para aplicaciones de un determinado perfil, y acepto que, por alguna razón, algunos programadores encuentren HTML desagradable y, además, que las ventajas que le brindan las otras partes de ASP.NET, que requiere estos controles, puede vale la pena el precio.
Sin embargo, I Resiento la pérdida de control, siento que el modelo de lidiar con cosas como clases, estilos y secuencias de comandos en el código subyacente es un paso atrás equivocado, y además siento que hay mejores modelos para crear plantillas (implementación de microformatos y xslt para esta plataforma). aunque reemplazar los controles por estos no es trivial.
Creo que ASP.NET podría aprender mucho de la tecnología relacionada en LAMP y el mundo de los rieles, hasta entonces espero trabajar con 3.5 MVC donde pueda.
(perdón que fue tan largo </rant>)
La respuesta corta es que nunca debes usar un asp:...versión de un control HTML estándar a menos que tenga una muy buena razón.
Los desarrolladores junior a menudo se dejan engañar por el uso de esos controles porque están cubiertos en la mayoría de los libros de ASP.NET, por lo que se supone que deben ser mejores.Ellos no están.En este punto, después de 8 años de desarrollo diario de ASP.NET, sólo puedo pensar en 2 o 3 casos en los que realmente tiene sentido usar un asp:...Control INPUT sobre uno HTML estándar.
En cuanto a las identificaciones en los controles del servidor:Puede encontrar la ID real que se escribirá en el navegador accediendo a ClientID.De esa manera, puede combinar secuencias de comandos del lado del servidor y del lado del cliente y aún así no tener que codificar _id="ct100_nav"_
Siempre trato de usar los controles incluidos en lugar de "piratear" HTML, porque si hay una actualización o alguna mejora más adelante, todo mi código seguirá funcionando simplemente reemplazando el marco y no tengo que cambiar ningún HTML.
Espero que esto ayude
@Brian, sí!Puedes controlar prácticamente todo el comportamiento.Considere la posibilidad de crear controles personalizados (hay tres tipos).Recientemente di una descripción general de ellos en mi pregunta. aquí.
me gustaría fuertemente Recomiendo echarles un vistazo, me ha ayudado muchísimo :)
Yo también estoy en mi aventura en ASP.NET y también he tenido frustraciones similares.Sin embargo, pronto te acostumbras.Usted sólo tiene que recordar, La razón por la que no tienes que realizar la tediosa creación de HTML es porque los controles ASP.NET lo hacen todo por ti..
Hasta cierto punto, puedes controlar/modificar estas cosas, incluso si eso significa heredar el control y modificar la salida HTML desde allí.
Tuve que hacer eso en el pasado, donde ciertos controles no pasaban la validación del W3C de forma predeterminada al colocar algunas marcas adicionales aquí y allá, así que simplemente anulé y edité según fuera necesario (una solución que también tomó literalmente un par de minutos).
Yo diría que aprenda cómo funciona el sistema de controles.Luego junte algunos usted mismo, esto realmente me ha ayudado a asimilar lo que sucede debajo del capó, así que si alguna vez tengo algún problema, tengo una idea de adónde ir.
El HTML se representa con ese tipo de ID porque es la forma en que ASP.NET previene las colisiones de ID.Cada control contenedor, como una página maestra o un control de asistente, antepondrá un "ID_" en los ID de sus hijos.
En el caso de su lista con viñetas, ListView proporciona un buen punto medio.Aún puedes vincularlo a una fuente de datos, pero te brinda un control mucho más estricto sobre el HTML renderizado.Scott Gu tiene una buena introducción a ListView aquí:
Si el prefijo de ID agregado por ASP.NET es un problema para que puedas acceder a ellos más tarde usando JS o algo así...tienes el lado del servidor de propiedad .ClientID.
Si la sobrecarga agregada por ASP.NET, debería considerar ASP.NET MVC (aún vista previa), donde tiene control total sobre el HTML emitido.
Me estoy mudando a MVC porque tampoco me gustan todas esas cosas agregadas...
Creo que la mayoría de las respuestas aquí adoptan el punto de vista de un diseñador.En un proyecto pequeño o mediano, puede parecer una sobrecarga sincronizar el código y CSS/HTML y hacerlos limpios y compatibles con los estándares.La manera que tiene un diseñador de hacerlo es tener control total sobre el HTML renderizado.Pero hay muchas maneras de tener ese control total en ASP.NET.Y para mí, tener el HTML requerido en el archivo aspx/ascx es la forma menos escalable y sucia de hacerlo.Si desea diseñar controles a través de CSS, siempre puede configurar una clase del lado del servidor a través de la propiedad CssClass.Si desea acceder a ellos a través de JS, puede volver a emitir el JS con los ID correctos en el lado del servidor.La única desventaja que esto ofrece es que un desarrollador y un diseñador tienen que trabajar juntos en estrecha colaboración.De todos modos, en cualquier proyecto grande esto es inevitable.Pero las ventajas que ofrece ASP.NET superan con creces estas dificultades.Aún así, si desea HTML compatible con los estándares, compatibilidad con aspectos y otras ventajas para controlar el marcado renderizado, siempre puede utilizar controles de terceros.
Como ya mencionó Dave Ward, "es la forma que tiene ASP.NET de prevenir colisiones de ID".
Un muy buen ejemplo de esto es si intenta colocar un control dentro de un control personalizado, luego use ese control personalizado en un repetidor, de modo que el HTML del control personalizado se genere varias veces para la página.
Como otros han mencionado, si necesita acceder a los controles de JavaScript, use la propiedad ClientScript que le dará acceso a ClientScriptManager y registrará sus scripts en la página de esta manera.Al escribir sus scripts, asegúrese de utilizar la propiedad ClientID en el control al que intenta hacer referencia en lugar de simplemente escribir el ID del control.
Si desea tener tanto control sobre el HTML renderizado, consulte ASP.NETMVC en cambio.
