Desarrolladores y diseñadores web de ASP.NET Webforms: ¿cómo interactuar?

Soy desarrollador de ASP.NET Webforms, y enfrento algunos problemas cuando trato con diseñadores.

Los diseñadores siempre se quejan de asp.net server controls. Prefieren simplemente tener un archivo html y crear cssarchivos junto con las imágenes necesarias para acompañarlos. A veces, si la fase de diseño se realiza de antemano, obtengo archivos html con archivos css relacionados, pero luego nos enfrentamos a muchos problemas al integrar el diseño con los aspxarchivos (los controles sever y telerik ... etc.).

Lo que quiero preguntar es:

• ¿Cómo supero estos problemas? Los diseñadores prefieren los desarrolladores de php y mvc debido a los problemas con los controles del servidor .net. Necesito saber cómo interactuar con los diseñadores de la manera correcta.
• ¿Existen herramientas o aplicaciones para proporcionar a los diseñadores el renderizado (página html) de las páginas .aspx? Con eso me refiero a la página en tiempo de ejecución en lugar de la aspx en Visual Studio. Usan Web Expression pero también quieren la página renderizada en html.

El ex diseñador aquí, se convirtió en Dev, y yo también solía orinar y gemir por los controles web. Honestamente, es MUCHO más barato para un diseñador ajustar sus prácticas que para un Desarrollador .NET profundizar en una implementación personalizada de un GridView porque el diseñador INSISTIÓ que cada TD tiene una etiqueta 'rel' (o lo que sea).

Como Arseni Mourzenko señaló muy sabiamente, la decisión de usar Webforms es una elección de la compañía que limita parte del control sobre el HTML al tiempo que otorga algunas eficiencias en la codificación. A menos que la empresa esté dispuesta a reconsiderar (lo que NO deben hacer solo para complacer a los diseñadores), los diseñadores deben aceptar esta realidad. Aquí hay algunas cosas que pueden hacer:

1) Deja de depender de las identificaciones para cualquier cosa . Aunque esto se sintió mal al principio, descubrí que la vida era mucho más fácil cuando diseñé todo con clases (y herencia, por supuesto). En primer lugar, ecualizó todos mis pesos selectores. En la herencia CSS, ID triunfa sobre CLASS. En realidad, fue un poco agradable que todo fuera un selector de niños y / o de clase, e hizo que descubrir el orden de especificidad fuera un poco más simple. Lo mismo en la capa JS, me dio CERO dolor cambiar mis selectores basados ​​en ID por otros basados ​​en clases.

2) Enséñeles en qué se convierten RadioButtonLists y CheckboxLists , junto con Label = span, Panel = div y otras cosas no obvias de control a html. La forma en que .NET los procesa en HTML fue un poco más extraño de lo que esperaba, y fue mucho más fácil para mí crear pantallas cuando sabía cómo saldría el HTML de esos controles.

3) Haga que hagan sus diseñadores EN ASPX DIRECTAMENTE , no HTML sin formato ( ! Importante ). Enseñe a los diseñadores los conceptos básicos de GridViews, ListViews, etc. Déles algunos fragmentos de código para insertar una colección de objetos anónimos en un control Grid / ListView. Si pueden aprender CSS, entonces pueden aprender a copiar y pegar este código. Pueden usar la versión gratuita de VS Web Express, que es bastante buena en CSS & JS ahora. Estos proyectos web ficticios le darán a los diseñadores la oportunidad de ingresar algunos controles y luego Ver código fuente para ver cómo se representan.

4) Explica cómo se usa la etiqueta FORM en .NET . Olvidé esto antes, pero otra cosa a la que el diseñador tiene que acostumbrarse es que, por lo general, una sola etiqueta FORM envuelve toda la página. Esto altera el comportamiento de los controles de formulario y no puede anidar etiquetas FORM sin efectos secundarios realmente extraños. Asegúrese de que los diseñadores entiendan esto o de lo contrario su formulario HTML será una pesadilla para convertir en WebForms.

5) Manténgase alejado de los temas y la piel . Aunque el marco .NET tiene estas herramientas para ayudar a los controles de estilo en una aplicación, son torpes y extraños para los diseñadores web normales, y nunca pensé que valieran la pena. Parecen una buena herramienta para desarrolladores que no están bien versados ​​en CSS, pero solo ralentizarán a los diseñadores. Deje que los diseñadores trabajen en su entorno natural (archivos html y css) y serán más felices y productivos.

6) Mantenga los proyectos "prototipo" en las soluciones de su sitio . Para asegurarse de que los desarrolladores siempre tengan un objetivo contra el cual codificar, haga que los diseñadores creen un proyecto web falso en su solución real para mantener sus páginas solo ASPX preservadas y sin tocar por los desarrolladores reales. Esto significa que los diseñadores pueden mirar hacia atrás a sus prototipos en la misma solución que el proyecto real para verificar cómo lo hicieron los desarrolladores, y los desarrolladores pueden ejecutar el prototipo en cualquier momento para asegurarse de que su trabajo coincida con la intención de los diseñadores.

Finalmente, resista cualquier queja para convertir a MVC, a menos que esté listo para volver a entrenar a sus desarrolladores. Personalmente me encanta MVC, pero si tienes un equipo con un montón de conocimientos de WebForms, no lo descartes sin ningún motivo. Si sus aplicaciones tienen problemas de ViewState, problemas de SEO o problemas de accesibilidad, entonces no deje de mirar a MVC. Pero llevará MUCHO más tiempo capacitar a los desarrolladores de WebForms en MVC que capacitar a los Diseñadores sobre cómo usar los Controles Web.

Al final del día, NO HABÍA UN DISEÑO A TRAVÉS, que no pudiera hacer personalmente el trabajo en WebForms, incluso si terminé jurando en ese maldito GridView durante una hora antes de resolverlo.

¿Existen herramientas o aplicaciones para proporcionar a los diseñadores el renderizado (página html) de las páginas .aspx?

Olvídate de la expresión (nunca me gustó). Obtenga la versión gratuita de Visual Studio (Web Developer Express). Se puede conectar a cualquier solución de control de fuente que tenga, y permitirá a los diseñadores ejecutar sus páginas ASPX y ver el HTML representado en un navegador. Las herramientas CSS y JS son mucho mejores de lo que solían ser, y hay algunas herramientas increíbles integradas en extensiones como Web Essentials. Transformación de 1 clic de las reglas CSS en todas sus desviaciones específicas del proveedor, selectores de color y paletas directamente en la interfaz VS, incrustación de imágenes con 1 clic en archivos css, transformaciones CSS 'MENOS' (puede 'codificar' en CSS), F12 'Navegar hacia' en JavaScript, más inteligencia real y mucho más. Es un tesoro para los diseñadores ahora, para su información,

Hay una solución a sus problemas, pero implica un cambio de patrón de diseño a MVP . Esta es una inversión inicial de tiempo que necesita una consideración seria antes de comenzar.

Básicamente, los problemas que estás experimentando no son nuevos. En resumen, debe introducir una abstracción de vista a través de la interfaz que identifica el modelo de datos que admite la vista.

Es un tema muy completo que tiene sentido ver el patrón como un ejemplo de vida. Encontraría este ejemplo bastante informativo para su caso: Mejores formularios web con el patrón MVP .

Editar: Si la sugerencia anterior es demasiado costosa (en términos de tiempo y recursos) para seguir, definitivamente recomendaría trabajar con su diseñador más de cerca . Creo que comunicar sus problemas dentro de un equipo debería ser de gran ayuda para resolver los impedimentos en su trabajo (del diseñador y desarrollador). ¡Este es un trabajo en equipo y una buena colaboración de los problemas para eliminar todos los obstáculos para realizar el trabajo es la forma de tener éxito en un proyecto en equipo ! Esto es algo que hacemos en nuestro proyecto.

ASP.NET es un marco que abstrae el código HTML generado. Esto significa que no se le puede pedir que reproduzca exactamente un código HTML dado en una aplicación ASP.NET, a menos que tenga un presupuesto suficiente para reescribir cualquier cosa generada por los controles ASP.NET .

Depende de las partes interesadas decidir: usar controles ASP.NET con sus puntos fuertes y desventajas, o cambiar a HTML manual (o ASP.NET MVC), lo que aumenta el costo del proyecto actual en miles de dólares. .

La incapacidad de personalizar HTML en este contexto es una restricción como cualquier otra. Los diseñadores deben considerar esta restricción técnica en su trabajo. El caso es muy similar a si el diseñador le dijera que un texto debe mostrarse en la fuente exacta con el tamaño exacto: es un soporte web, no impreso, lo que significa que el tamaño del texto variará.

En cuanto a las herramientas, no conozco las herramientas que convertirán HTML sin formato en una plantilla ASP.NET. ¿Cómo podría suponer que una tabla específica debe convertirse a un control ASP.NET específico?

En mi último trabajo, los desarrolladores crearían la aplicación y luego se la pasarían a los diseñadores para que parecieran que un grupo de programadores de software no la hizo. :)

Cuando comenzamos este proceso, había muchos intercambios entre los desarrolladores y los diseñadores. No entendieron las páginas que les dieron. ¡Dios no lo quiera si estuviéramos construyendo una página dinámicamente! Era muy similar a la situación que estás describiendo aquí.

Me senté con cada diseñador y les enseñé cómo instalar la aplicación web en su caja local. Les mostré cómo ejecutarlo y todo. Le expliqué cómo se representaban los controles asp en la pantalla. Y luego lo abrimos en el navegador y usamos firebug para ver el enlace entre los controles asp y lo que se renderizó.

Esto los ayudó mucho. Una vez que pudieron verlo y ejecutarlo en sus cajas y usar sus herramientas de diseño para ajustar y jugar con estilos, les facilitó la vida.

Después de hacer esto, tuve una reunión con los desarrolladores y les hice saber que deberían usar la etiqueta CssClass y asegurarme de que se definieran los estilos. Y todo lo que se estaba poniendo en la pantalla dinámicamente necesita tener una clase css adjunta porque los diseñadores no podrían agregarlo.

Fue un proceso A ambas partes les llevó algo de tiempo acostumbrarse al acuerdo. Pero abrió las líneas de comunicación. En lugar de quejarse de los controles utilizados, los diseñadores pudieron solicitar que se agregaran estilos a varios elementos.

Entonces, mi sugerencia sería sentarme con los diseñadores y mostrarles cómo se presenta la página. Use firebug para diseccionar la página y ver cómo se forma la página.

Aquí hay algunos enfoques útiles que he tomado en el pasado con los diseñadores cuando tienen que trabajar en un proyecto ASP.NET WebForms que se está desarrollando.

1. Implementar localmente: los desarrolladores proporcionan una versión intermedia del proyecto implementado localmente. Esto ahorra tiempo a ambos. El diseñador solicita un .aspx pero interactúa con el HTML representado en lugar de con el código del servidor. Este enfoque abstrae el código del servidor del diseñador. No necesita saber cómo se genera el HTML o cómo se entregan los archivos javscript y cssal cliente. Por supuesto, esto supone que los diseñadores son expertos en depuradores de navegadores / inspectores DOM. El diseñador puede aplicar todos sus csscambios dentro del navegador y luego aplicarlos a los cssarchivos.
2. Proporcione modelos: para que los diseñadores puedan trabajar con HTML de manera más sensata, proporcióneles un modelo del HTML representado por el control del servidor. Pueden modificar ese HTML hasta el punto que les guste y proponer los cambios que se aplicarán en la implementación del lado del servidor. Esto debe hacerse temprano y con frecuencia , porque no desea terminar con una estructura HTML en la que se basa la implementación del lado del cliente y luego para que el diseñador proponga cambios en esa estructura.

En general, los diseñadores deben tener la menor cantidad posible de puntos de contacto con el código del lado del servidor, así que abstraiga todo lo que pueda de ellos.

Como desarrollador híbrido, a mí mismo (después de haber trabajado mucho tanto en funciones de back-end como de front-end, a menudo juntas), también me disgusta desde hace mucho el modelo ASP.NET WebForms ... aunque es inicial el ímpetu del diseño fue proporcionar herramientas de diseño fáciles de arrastrar y soltar para democratizar el desarrollo web (de la misma manera que Visual Basic hizo que la programación de aplicaciones fuera accesible para los que no son CS-major), los métodos que utilizó para tratar de forzar el estado en un El entorno sin estado (la web) es forzado y forzado (oh ViewState, ¡cómo te odio!).

También violan algunos de los principios centrales del desarrollo y el estilo del marcado, solo por el hecho de que, por defecto, ASP.NET se hace cargo del atributo ID, lo que obliga a los diseñadores de CSS a usar las clases de la misma manera que las ID se utilizaron, capas de elementos en pilas profundas de divs y etiquetas anidadas que pueden hacer que el diseño de los controles sea una pesadilla en todos los sistemas, excepto en los más simples.

Teniendo en cuenta estas cosas, su camino no es fácil, ya que supongo que una reescritura para MVC sería prohibitiva en términos de costo o tiempo.

¿Hay alguna forma de proporcionar al diseñador un entorno en el que ejecutar la aplicación web, para que pueda ver sus cambios de CSS en tiempo real? Cuando realizo trabajos de diseño en ASP.NET WebForms, me resulta invaluable poder iniciar la aplicación web en mi propia máquina, hacer ajustes en el CSS y ejecutarla localmente para ver cómo afecta eso a la aplicación.

Una opción podría ser configurar una máquina virtual diseñada específicamente para el desarrollo de ASP.NET que el diseñador pueda ejecutar desde su estación de trabajo, de modo que no tenga que mezclar sus dos conjuntos de herramientas, y si resulta que arruinan algo en el desarrollo espacio, siempre se puede recargar desde una imagen en funcionamiento.

Sí, esto significa que el diseñador tendrá que aprender a presionar F5 para ejecutar la aplicación. (¡O simplemente deles acceso a FTP a los directorios donde se encuentran CSS, JS e imágenes, incluso, en un entorno de prueba!) También significa que verán una gran cantidad de código de fondo, aunque si les dice que lo hagan simplemente ignore sus archivos .cs o .vb, eso ayudará mucho a evitar que entren en pánico ... Por supuesto, eso significa que debe asegurarse de que no está haciendo cosas como establecer estilos desde sus archivos de código subyacente ... . (pero usted no haría eso, ¿verdad ?, ya que eso vincula los datos y la vista demasiado de cerca, ¿verdad?).

Si su sitio está bien estructurado, con archivos CSS y JS distintos, y no hay mucho estilo en línea forzado en el marcado, es posible que puedan hacer la mayor parte de su trabajo simplemente evitando las áreas <%%>. Por otro lado, también podría darle al diseñador un poco más de aprecio por lo que tiene que pasar, cuando intente traducir su HTML / CSS estático en algo que funcione para una aplicación dinámica.

Debe hacerlos hablar juntos, comprender las necesidades y preferencias de los demás. Es un "problema" que no puede resolverse con software y herramientas. No intentes complacer a ambas partes, eso nunca funcionará. Necesitan comprometerse, es como un matrimonio.

Una forma es organizar f.ex. talleres donde cada parte tiene la oportunidad de explicar por qué es así que prefieren lo que prefieren. La buena comunicación es siempre una clave en situaciones como esta. Reuniones como estas pueden verse como inversiones.

O simplemente dicho, el problema está orientado a la organización, no es técnico y ahí es donde debe proporcionar una solución.

La otra opción es aumentar el salario y decirles que se callen (por lo general, una solución a corto plazo ...).