En una aplicación web, ¿es aceptable usar HTML en su código (lenguajes sin guiones, Java, .NET)?¿Debería HTML coexistir con el código?
Hay dos grandes sub-preguntas:
En general, es mejor mantener la presentación (HTML) separada de la lógica (código de "back-end"). Su código está desacoplado y es más fácil de mantener de esta manera.
Es fugly, y no tipo seguro. Pero la gente lo hace sin consecuencias. Prefiero usar un DOM o, como mínimo, clases diseñadas para escribir HTML usando semántica segura. Además, no es tan bueno mezclar la IU con la lógica ...
Siempre que el código de escritura de HTML sea independiente de la lógica de la aplicación, y se garantiza que el HTML estará bien formado de alguna manera, debería estar bien. .
El único código que debe mezclarse en las páginas basadas en marcado (es decir, las que contienen HTML literal) es el código utilizado para formatear el HTML (por ejemplo, un bucle para escribir una lista).
Existen intercambios, ya sea que ingrese el código con el código HTML o use código puro para escribir el código HTML utilizando literales entre comillas.
No, si desea construir un software bueno y fácil de mantener, y para lograr un acoplamiento flexible.
Si necesito métodos que generen HTML, generalmente los aíslo en una clase HtmlHelpers. De esta forma, mantiene un nivel de separación de. El Framework ASP.NET MVC hace esto con bastante éxito.
Si entiendo correctamente la pregunta, se pregunta si es una buena práctica mezclar el marcado con el código de fondo. No. Mientras esto se hace comúnmente, sigue siendo una mala idea.
Usted debe leer sobre el paradigma MVC, así como sobre las cuestiones existentes en la materia, tales como What is the best way to migrate an existing messy webapp to elegant MVC? y Best practices for refactoring classic ASP?
Si se refiere a imprimir HTML en su código, entonces no. A menos que tenga una buena razón para no hacerlo, debe usar templates
Incluso si cree que no necesita esto ahora, siempre hay una buena posibilidad de que lo necesite más adelante. Tal vez quiera dar salida en un formato diferente al HTML, o si desea una presentación diferente para la misma información. Por lo general, necesita estas cosas más adelante, por lo que es mejor usar una desde el principio.
El objetivo es mantener la lógica de visualización separada del resto del código. En cualquier sitio complejo, tendrá código mezclado con su HTML, pero el código debe ser solo para fines de visualización. No debería hacer ningún cálculo complejo.
Por ejemplo, las plantillas contendrán bucles y condicionales. Además, es probable que tenga una biblioteca de rutinas específicas de HTML, como imprimir una lista de < opción > basada en un objeto de lista.
Imagina que estás escribiendo una aplicación que tiene dos modos de salida: HTML y algo más. ¿Cómo lo escribirías para evitar duplicar el código? Eso probablemente te indique en la dirección correcta.
Odio cuando los desarrolladores imprimen() un montón de html. Es completamente innecesario y se ve feo en cualquier editor de texto que muestre las cadenas de impresión/eco en rojo.
El código HTML que conforma la vista debe enviarse de alguna manera al navegador. En .net, cada control de servidor emite su propio marcado HTML como parte del ciclo de vida de la página. Entonces sí, está bien usar HTML en el código del lado del servidor.
Quizás deba intentar seguir el patrón ASP.net. Cree un conjunto de controles que representen los elementos de la interfaz de usuario y haga que sean responsables de emitir su propio HTML en función de su estado.
Estoy de acuerdo con todos los demás en que debe intentar lo más que pueda para separar el marcado HTML/XHTML de la lógica de la aplicación. Sin embargo, a veces es necesario generar HTML/XHTML en la lógica de la aplicación por varias razones.
En estos casos, lo que he estado tratando de hacer es asegurar que la cantidad mínima de código de presentación esté mezclada con la lógica de la aplicación y trate de migrar todo lo demás al código de presentación. No vale la pena que en algunos casos haya situaciones en las que pueda mover todo a la capa de presentación, pero puede ser un poco más fácil generar el marcado como parte de la lógica de la aplicación. En esos casos, la mejor opción es seguir la ruta que tenga más sentido en términos de tiempo.
No creo que haya ninguna excusa para generar HTML dentro de la lógica de su negocio. Ni siquiera lo haga cuando sea solo una "solución rápida" o cuando "vuelva atrás y lo solucione más tarde", porque eso nunca sucede.
Para reiterar mi posición a partir de otras preguntas, usar alguna lógica de control (condicionales, bucles) dentro de HTML para construirlo está bien. NO haga ningún masaje de datos o lógica comercial en el HTML. Tienes que ser disciplinado, pero vale la pena. El mantenimiento es mucho más fácil si sus preocupaciones (como la lógica y la pantalla) están separadas.
Idealmente está apuntando a una separación de las preocupaciones entre su código de presentación (UI) y su código de dominio (lógica comercial).
La razón por la cual se debe evitar el acoplamiento de estas dos preocupaciones (en cualquier dirección) es simple ...
que sólo tendrá una de las razones para cambiar una pieza de código. ya sea por cambios estructurales/de diseño en su diseño html o por el cambio de las reglas de su negocio, solo debe realizar el cambio en un solo lugar.
En menor medida, aunque muchos puristas no estarían de acuerdo, por aspersión código HTML a través de su código de dominio o viceversa son crear ruido para la próxima desarrollador que viene a lo largo de leer/mantenerla.