La próxima versión de asp.net introducirá un cambio que creo será agradecido por muchos desarrolladores, y es la posibilidad de poder controlar la generacion de los IDs de los controles, de manera que podamos evitar las típicas cadenas “ctl00_ctl…” etc. que tanto dificultan el acceso DOM a los elementos mediante javascript o librerías como jQuery o Mootools.
El modo por defecto seguirá siendo el que ya conocemos, pero se podrá cambiar a nivel de página a alguno de los siguientes valores:
- Static el ID no tendrá antepuesta la concatenación de los identificadores de los contenedores padres, lo que facilita el acceso a un control que se puede encontrar en diferentes páginas en diferentes tipos de contenedores, facilitando la programación en el cliente.
- Predictable muy útil para controles con plantillas de repetición (item templates), como por ejemplo un Datalist o un Gridview.
- Inherit el control heredará el modo que use su control padre.
- AutoID el modo habitual como en cualquier versión de asp.net
Como hemos comentado esto se puede hacer a nivel de página
<%@ Page Language=”C#” AutoEventWireup=”true”
CodeFile=”Default.aspx.cs”
Inherits=”_Default”
ClientIDMode=”Predictable” %>
o a nivel de web.config para todo el sitio
<system.web>
<pages clientIDMode=“Predictable“>pages>
system.web>
Eso sí, cuidado de no generar IDs que no sean únicos. Ahora esto es nuestra responsabilidad si escogemos algunos de los modos que nos permiten controlar este aspecto.
Sería además una delicia que esto se pudiera hacer también con SharePoint 2010, que para customizarlo con jquery o similares ofrece a veces un acceso farragoso a los controles.
Saludos
Con las sucesivas versiones del MVC para asp.net que vienen apareciendo desde Octubre del 2007, el equipo de Scott Guthrie nos ofrece un framework que trasciende el modelo de eventos al que estamos acostumbrados, y nos ofrece varias ventajas nuevas, que para ser aprovechadas nos obliga a cambiar el modo de desarrollar habitual de asp.net.
No obstante, las ventajas son muchas:
- Separación clara de dónde tiene que ir cada tipo de lógica (separation of concerns). Esto nos facilita el mantenimiento y la escalabilidad de la aplicación, además de facilitar el desarrollo en paralelo de las distintas partes o módulos.
- Suporte al desarrollos por medio de metodología TDD por defecto (Test Driven Development). Por tanto facilidad para crear mock tests y para poder correr los tests desde fuera del proceso de asp.net. Gran diferencia con respecto a como se tenían que hacer las pruebas anteriormente, o bien a mano, o bien con torpes y complejas macros para disparar eventos en la interfaz.
- Arquitectura “pluggable” y extensible, en la que los componentes pueden ser aumentados o extendidos, algo que ya se podía hacer en las versiones anteriores de asp.net, pero que ahora va más allá. Ahora podemos usar inyectores de dependencia como Castle Windsor, Spring.net o Unity.
- Motor de routing (asociación de una URL concreta con el controller correcto) para tener url más legibles, al estilo REST.
- No hay ViewState ni ciclo de vida de las páginas. Menos peso, menos complejidad.
- Control total del HTML generado. No tenemos controles que añaden su propio markup. Esto nos permite ademas integrar más fácilmente librerías como JQuery o MooTools, y olvidarnos de todo el código que asp.net inyecta para el mantenimiento del estado y el ViewState.
Conviene recordar que MVC no suplanta o elimina el desarrollo “tradicional” mediante webforms. Se trata simplemente de una alternativa que hay que sopesar según la situación y el tipo de proyecto. No olvidemos que asp.net webforms nos ofrece también un modelo de eventos familiar a todos los desarrolladores, mantenimiento del estado entre requests, numerosos controles de otros vendedores. No se trata de despreciar ahora este estupendo modelo de desarrollo.
Es necesario, por tanto, escoger el modelo en cada caso. Asp.Net MVC nos viene bien, o no, si queremos
- Desarrollar según TDD.
- Necesitamos controlar el HTML generado completamente.
- Operaciones atómicas que no necesitan estado entre peticiones. Si la aplicación es muy orientada a datos y necesitamos estado, no es la opción adecuada.
- Podemos prescindir de los eventos o sustituirlos mediante javascript y invocaciones web via ajax.
- No es la opción adecuada si tenemos que usar controles ya generados o crear prototipos rápidos mediante drag & drop. Para eso, mejor webforms.
En el PDC 2008 Stephen Walters, reconocido autor y experto en Asp.Net, anunciaba la futura integracion de jQuery con Visual Studio, incluyendo soporte intellisense, y además sin crear una versión propia, sino ofreciendo jQuery tal y como es, con el aliciente añadido, para las grandes empresas sobre todo, de tener soporte 24/7 de Micro.
jQuery vendrá con Asp.Net MVC. Sin duda esto son buenas noticias para la apasionada comunidad de jQuery, y también para los que no conocen o no trabajan esta librería de tan solo 15kB. Venir de la mano de Microsoft, creo que le vendrá muy bien para entrar donde antes este tipo de productos no podían llegar.