VELOCIDAD DE ESCAPE

2005-05-06

---

RESUMEN Y EXPECTATIVAS VISUAL STUDIO

Si algunos de vosotros os dedicais como yo, a la creación de aplicaciones que residen en intranets corporativas, probablemente habéis llegado a la conclusión de que la mejor relación coste/beneficio implica usar el modelo cliente-servidor n-capas y ofrecer una interfaz web para vuestros clientes. El tiempo de desarrollo se acelera y los problemas de implementación e instalación son menores.
Pero claro, no todo son parabienes. En este modelo de desarrollo uno ha de enfrentarse a determinadas características inherentes al entorno, como son la ausencia de estado, lentitud de respuesta, riqueza e interactividad del interfaz, que intentamos solventar cada uno con sus propias ideas y conocimientos.
En mi caso el uso de una usabilidad estricta al estilo Jakob Nielsen (nada de imagenes ni chorraditas salvo las estrictamente necesarias) y un acercamiento al diseño del software basado en lo que el cliente desea ver en su pantalla más que en lo que el programa tiene que hacer entre "bambalinas". Vamos, que me siento con el usuario y definimos una a una las pantallas del programa y lo que quiere que suceda en cada caso.
Hasta ahora me ha ido bien con esta aproximación, pero claro, nos enfrentamos con las limitaciones características del ASP en mi caso y supongo que similares problemas con PHP o JSP. Queda claro desde el primer momento que no es lo mismo crear clientes pesados que aplicaciones ligeras que funcionan con navegador. El potencial de los clientes pesados está en estos momentos a mucha distancia de lo que una aplicación Web puede hacer aunque usemos tecnologías de servidor, y si habéis desarrollado una aplicación contable con generación de recibos y diversas operaciones matemáticas en cliente sabréis a qué me refiero. Más allá de los problemas que se presentan cuando el usuario deja un proceso a medias y se va a tomar café, o cuando quiere imprimir una relación de recibos en un formato determinado, o simplemente subir, bajar o generar archivos para uso posterior, que resolvemos con mejor o peor fortuna, nos encontramos con que tras la llegada de ASP NET a bombo y platillo NO EXISTE UN IDE REALMENTE ADECUADO PARA DESARROLLAR CON ASP NET.
Ni siquiera el Visual Studio, que considero el mejor entorno de desarrollo de aplicaciones existente, cumple su cometido si lo que queremos es desarrollar una simple página web que nos dé acceso a una aplicación con otra capa de datos y su correspondiente lógica de negocio.
Durante los últimos años la creación de Web dinámicas dirigidas por datos se ha convertido en un proceso casi estándar que permite la creación de entornos de desarrollo que aceleren cuantitativamente el proceso. Con el ASP tradicional y el uso de VBSCript no había problema ninguno porque un simple bloc de notas algo mejorado era suficiente. Yo he probado varios y que quedo con EditPlus o mejor aún Homesite.
Con la llegada del ASP NET tenemos una herramienta potente y versátil para matar moscas a cañonazos. Muy bueno lo de crear clases, lo de compilar, las herramientas de depuración...todo muy bonito. Pero claro, prueben ustedes simplemente a cambiar de la vista de código a la vista HTML y después vuelvan atrás. El galimatías generado es capaz de romperle los nervios al más templado. El formateado y las etiquetas han mutado a una jerigonza que para más inri no guarda ninguna adecuación con ningún estándar. Y eso para no hablar de que desaparecen las conexiones entre un evento y su manejador cuando menos te lo esperas.

Hay que reconocer que Visual Studio no fué diseñado teniendo en mente a los desarrolladores ASP. Muy bueno para crear las librerias de clases que necesitemos para nuestros proyectos (objetos de negocio, capa de acceso a datos, etc) y muy bueno también para los que trabajamos intensivamente con bases de datos (procedimientos almacenados, creación y vista de tablas), pero cuando hay que maquetar la interfaz el diseñador es el mayor fracaso que he visto en mi vida. Por su cuenta y riesgo asume que es más listo que nosotros y mete etiquetas donde le da la real gana además de que se pasa el estándar XHTML por el arco del triunfo.
No sólo eso. Cada vez que creamos un proyecto se crea un nuevo directorio virtual en IIS, una nueva carpeta, y un chorro de nuevos archivos que no sabemos realmente para qué demonios sirven. Como hagas muchas pruebas o seas un poco desordenado al final tienes el directorio C:\Inetpub\wwwroot que para busar algo allí hay que ir con casco de espeleólogo y látigo de Indiana Jones. Y no vamos a hablar de mover cualquiera de esos innumerables proyectos a otra máquina. Tarea nada fácil. Si habéis intentado facilitaros la vida planificando bien el diseño con una plantilla para el sitio, CSS, imagenes, y demás, al final habréis dejado el tema por imposible y recaído en los viejos vicios. El mío se llama DreamWeaver MX. Para rematar la faena, por narices tenemos que usar el Code-Behind en vez del Inline-Code, los controles de usuario son una caja tonta gris, no hay FTP para colocar los archivos en el server, etc...

Algunos dirán: ¡ pues usa WebMatrix !. Vale, WebMatrix tiene FTP, maneja mejor los controles de usuario en su vista de diseño, es ligero (1,3 MB) y fácil de usar. No necesita IIS sino que usa Cassini, un servidor Web interno que elimina dependencias del Sistema Operativo. Pero no tiene para mí lo más importante: intellisense y depuración asistida.

Por eso es que estoy (estamos) esperando con ansiedad la llegada del nuevo Visual Studio NET 2005 porque todo indica que a diferencia de su versión anterior, ha sido diseñado con los programadores Web en mente. El diseñador no toca las etiquetas, no necesita IIS para funcionar porque lleva un servidor web al estilo de Cassini y además podemos crear un proyecto web en cualquier parte del disco duro, no solo en WWWROOT, MasterPages para unificar el diseño, y controles de usuario correctamente renderizados en el diseñador. En la misma linea van las herramientas Expréss. Concretamente Visual Web Developer 2005 incluye para mí lo esencial, el intellisense y las herramientas de depuración. Con el añadido espectacular de que podemos utilizar Inline-code rodeando nuestro código con las etiquetas script dentro de la página ASPX y seguir accediendo a Intellisense y depuración para dicho bloque de código.

¿alguien da más?

Programación | jomaweb | 15 Comentarios | Enlace