Este es un error muy típico en algunas aplicaciones y me he acordado de él a raí [Más]

A la hora de trabajar con sesiones en C#, el mayor problema es que, al contrario que en VB, no se facilita el manejo directo de los valores como si fueran propiedades del objeto Session ni se transforman al tipo correcto para hacer operaciones como Session("Contador")++ y similares. Además, adicionalmente, hay que comprobar que las variables existan antes de poder hacer todas estas operaciones. Por ejemplo, si queremos trabajar con una cadena de texto en sesión y poder asignarle un valor, se trata de algo tan sencillo como lo es en VB ya que sólo debes asignarla directamente, así: 1: Session["TextoAGuardar"] = "Este es el texto que quiero almacenar"; Sin embargo si lo necesitamos es realizar una operación matemática es un poco más lioso ya que deberemos comprobar primero que la variable existe y contiene un valor, y ademas convertirla desde "object" que es lo que devuelve por defecto una variable de sesión, al tipo correc... [Más]

Hasta ahora con Transfer y Execute hemos visto que podemos ejecutar otras páginas del mismo tipo sin necesidad de redirección desde el lado cliente. Sin embargo un efecto secundario que tiene su uso es que, como no se regenera la petición sino que se ejecutan dentro del contexto de la petición actual, no entran en juego los controles de seguridad y otros eventos del pipeline HTTP para la segunda página. Es por ello por lo que en nuestro ejemplo se ha podido mostrar el contenido de la página "P2.aspx" a pesar de que estaba protegida. Existe una variante de estos métodos llamada TransferRequest que permite conseguir una petición completa desde el propio servidor, sin pasar por el cliente como ocurría con Redirect. Este método se utiliza del mismo modo que Transfer pero en este caso la segunda página pasa por todo los estadios de una petición HTTP normal, como si hubiera sido hecha desde el cliente desde... [Más]

En la entrega anterior de esta serie vimos a fondo cómo funcionaba el método Transfer. Seguimos ahora profundizando en otros métodos relacionados. El método Transfer por debajo lo único que hace es llamar al método Execute de la misma clase HttpUtility: Este método es prácticamente idéntico a Transfer, como vemos en este código, por lo que a todos los efectos podemos sustituir las llamadas a Transfer por llamadas a Execute y no perder funcionalidad. Además, si nos fijamos en el código de Transfer de una figura anterior, llama continuación a Response.End. Esto como ya vimos en la primera parte con Redirect, tiene algunas implicaciones respecto al rendimiento debido a la generación de excepciones ThreadAbortException, por lo que en sitios muy grandes donde cada milésima cuenta puede ser interesante sustituir las llamadas a Transfer por llamadas a Execute con una posterior a CompleteRequest (repasa el primer post para verlo). Si hacemos lo mismo que antes pero llamando a Execute en ... [Más]

En el post anterior de esta serie vimos cómo la forma más sencilla de transferir a un usuario desde una página a otra es mediante el uso de una redirección en el lado cliente, usando Redirect o RedirectPermanent. Sin embargo esto implica dos secuencias de petición-respuesta al servidor y además se visualiza la página final en la barra de direcciones del usuario. Muchas veces (la mayoría) es probable que sea lo que queremos, pero hay otras situaciones en las que no será así y lo que necesitaremos es que la ejecución se cambie en el servidor, de manera inadvertida para el usuario, por ejemplo: Ejecutar código común a varias páginas que hace uso de controles y genera elementos para la interfaz de usuario. En la mayor parte de los casos podríamos usar una biblioteca común o un control de usuario, pero si involucra páginas complejas o, simplemente, si ya tenemos la funcionalidad hecha en un ASPX y no queremos repetir el trabajo, nos vendrá bien poder transferir la ejecución a esta pág... [Más]

En ASP.NET existen muchos métodos para conseguir que cuando un usuario solicita una página en el servidor, acabe obteniendo el resultado de ejecutar otra página o recurso diferente. ¿Para qué querríamos hacer algo así? Por múltiples motivos, y en realidad es algo que se usa constantemente: Redirigir a los usuarios a una página nueva Ejecutar una funcionalidad que reside en otra página o recurso Ofrecer al usuario rutas amigables cuando por debajo usamos una estructura de páginas más compleja Hacer que las URLs antiguas de una aplicación sigan funcionando aunque hayamos cambiado la estructura del sitio .... El framework de ASP.NET ofrece muchos métodos diferentes de cambiar el recurso utilizado para responder a una petición, y cada uno tiene sus aplicaciones específicas. Así que ¿Cuál utilizar? Vamos a verlos todos para resolver las dudas y conocer bien sus diferencias y mejores aplicaciones. El ejemplo Para ilustrar en la práctica todos estos métodos he crea... [Más]

En ocasiones es muy útil poder engañar al servidor web y hacerle creer que te estás conectando con cualquier navegador, aunque en realidad estés usando Internet Explorer o Chrome bajo Windows, por ejemplo. Como sabes, los controles de ASP.NET Web Forms tienen lo que se llama renderizado adaptativo, que consiste en que generan un HTML diferente según el dispositivo que solicite la página, pudiendo así adaptarse a las características de cada navegador de la mejor forma posible. Así puedes ver qué efecto causa sobre el HTML que renderiza tu aplicación si estás usando un navegador muy viejo (Netscape?) o saber si cambia según sea el sistema operativo (puedes decir que estás trabajando desde Linux o Mac aunque estés en Windows), etc.. Un caso muy habitual es, por ejemplo, si estás probando una aplicación móvil y quieres ver qué HTML te devolvería cuando te conectas con un iPhone o un Windows Phone, puedes engañar al servidor fácilmente y hacerte pasar por uno de estos navegadores simpleme... [Más]

En ASP.NET Web Forms algunos controles disponen de un par de propiedades interesantes para mejorar la usabilidad de la interfaz de usuario. Se trata de DefaultButton y DefaultFocus que permiten decidir respectivamente qué botón del formulario va a ser el que se ejecute al pulsar ENTER y qué control tendrá el foco en el formulario cuando éste cargue. Esto, que parece una tontería, es muy útil ya que es frecuente encontrarse por ahí páginas bastante mal hechas en las que, por ejemplo, vas a buscar algo en un cuadro de búsqueda, le das a ENTER tras introducir los términos de búsqueda en el cuadro de texto correspondiente, y en lugar de efectuarse la búsqueda lo que ocurre es que simplemente se recarga la página. El motivo es que cuando pulsas ENTER en un cuadro de texto, por defecto lo que hace cualquier navegador es enviar el formulario al servidor. Si resulta que tu código de búsqueda está en el evento Click de un botón o un ImageButton, no se lanza este evento de servidor y por lo tan... [Más]

En septiembre de 2009 Krasis Press lanzó al mercado mi libro “Tecnologías ASP.NET 4.0 (Saltando desde la versión 2.0)”. Fue un libro que se adelantaba en varios meses a la futura versión de la plataforma y el entorno de desarrollo. En el momento de escribirlo, en Julio de 2009, las últimas noticias sobre el lanzamiento del producto apuntaban a Octubre de 2009, y que muy pocos cambios iban a aparecer en la versión final. Por ello, a pocos meses vista de esa versión definitiva, aún con la Beta 1 de la plataforma, nos decidimos a lanzarlo al mercado. Trabajar con las Betas de Microsoft tiene muchas ventajas, pues te permite estar al cabo de la calle y adelantarte al mercado en las tecnologías que vendrán. Pero también tiene algunos inconvenientes, entre ellos que puede haber cambios de última hora que echen a perder el tiempo invertido. Al final, la versión definitiva de .NET 4.0 se fue retrasando y apareció el 12 de Abril de 2010. Este mayor ciclo de vida para las versiones previas del ... [Más]

En la directiva de página de los Web Forms de ASP.NET existe un atributo importante denominado AutoEventWireUp. Por defecto está establecido como True. Esto quiere decir que la infraestructura de la página se encargará automáticamente de enlazar los eventos de la página con aquellos métodos definidos en ésta que tengan los nombres y las firmas apropiados. Por ejemplo, si tenemos un método definido de esta manera: 1: private void Page_Load(object sender, System.EventArgs e) 2: { 3:  4: } Se llamará de manera automática al cargar la página (evento Load del ciclo de vida de la página). Lo mismo en Visual Basic: 1: Public Sub Page_Load(ByVal Sender As System.Object, ByVal e As System.EventArgs) 2:  3: End Sub Estos métodos tiene la misma firma que un evento estándar de tipo EventHandler, es decir, no devuelven nada y toman como parámetros un objeto y un objeto de tipo Even... [Más]