Mantener la posicion de un Div después de un postback asíncrono

Cuando queremos mantener la posición del scroll de un elemento como puede ser un Div ó un Panel despues de una postback asíncrono, tenemos que recurrir de nuevo al potente javascript. Parece claro que lo que tenemos que lograr es almacenar la posición del scroll antes del postback y después restaurlarla. Eso es exactamente lo que hace el siguiente script. Es importante que este situado siempre después del ScriptManager.

Lo que hacemos es añadir dos manejadores BeginRequestHandler y EndRequestHandler, el primero se ejecuta justo antes de realizar el postback, en él obtenemos la posición del scroll y la almacenamos, en el segundo restauramos esa posición.

Novedades Asp.Net 4.0 parte II

En este post vamos a continuar tratando algunas de las novedades de Asp.Net 4, es este caso quiero comentaros la nueva forma de gestionar y controlar la cache.

Output cache

Con la aparición de la primera versión de asp.net se introdujo el concepto de output cache, esto permite a los desarrolladores almacenar páginas, controles y las respuestas Http en la memoria de forma que las siguientes peticiones Web, asp.net puede servirlas de forma mucho más rápida y eficiente ya que solo tiene que acudir a la memoria y coger el código genera anteriormente para la página, editándose así una nueva generación del código de salida de la página.

Asp.Net 4 añade un punto más a esta funcionalidad permitiendo al desarrollador añadir uno o varios proveedores personalizados de output-cache. Estos proveedores (providers) permiten usar cualquier mecanismo de almacenamiento para persistir el código HTML. Esta nueva funcionalidad permite al desarrollador crear diversos providers en función del tipo de almacenamiento que precise en cada situación (discos remotos o locales, almacenamiento en la nube, motores de cache distribuida), combinandolos a su gusto.

Para crear un Cache provider personalizado debemos crear una clase y heredar de System.Web.Caching.OutputCacheProvider. Una vez creado el nuevo proveedor de cache tendremos que dar un paso mas para poder utilizarlo, este paso ya os lo podréis imaginar... si, tenemos que configurarlo en el Web.config, para ello, dentro de la sección de providers se ha creado una nueva subsección llamada outputcache. El siguiente fragmento de código nos muestra la sección de un web.config en el que se configura la cache para que se almacene en memoria. Este es el tipo de almacenamiento que se usa por defecto Asp.net 4.

Ademas de esto, podemos añadir un mayor nivel de detalle especificando a nivel de control o de petición. La manera mas sencilla de configurar un nuevo proveedor para un Control se usuario es utlizando la sintaxis declaratia. Para ello se ha creado un nuevo atributo llamado providerName, a continuación vemos como como utilizarlo

<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %>

Si por el contrario lo que queremos es configurar un proveedor difirente dependiendo de la página que se vaya a solicitar tendremos un poco más de trabajo. Es necesario sobreescribir el método GetOuputCacheProviderName en el Global.asax para especificar manualmente que proveedor corresponde con cada petición de página.

public override string GetOutputCacheProviderName(HttpContext context) 
{ 
  if (context.Request.Path.EndsWith("Advanced.aspx"))
    return "DiskCache"; 
  else
    return base.GetOutputCacheProviderName(context);
}

Después de ver de forma muy resumida esta nueva caracteristica que nos ofrece asp.net a cada desarrollador se le pueden ocurrir algunas situaciones en las que podremos sacar provecho de esto, por ejemplo podemos combinar los distintos tipos de proveedores para conseguir accesos mas rápidos almacenando las páginas mas visitadas en memoria y aquellas que lo son menos en disco.

Visual Studio 2010, Retrasado.

Parece ser que vamos a tener que esperar un poco más para tener en nuestras manos la versión definitiva del Visual Studio 2010 y del Framework 4. Según la propia compañia este retraso se debe a que "El feedback recibido denotan que el rendimiento y el uso de la memoria virtual en VS2010 no es el adecuado para la nueva versión". Microsoft ha decidido ofrecer una versión Release Candidate (RC), la cual estara disponible en Febrero. La RC vendra con una licencia "go live" que soportora despliegue de aplicaciones en producción, "El objetivo de esta RC es obtener todo el feedback sobre el producto. Para asegurarnos que somos capaces de recibir todo el feedback y reaccionar a el, hemos decidido retrasar unas semanas el lanzamiento de VS2010 y el Framework 4".

Novedades Asp.Net 4.0

Estos días en los que el trabajo nos da un poco mas de respiro me he decidido a revisar algunas de las novedades que vamos a poder disfrutar con el lanzamiento de la nueva versión del Framework y del Visaul Studio 2010. Este es el primero de una serie de post en los que iremos viendo algunas novedades que afectaran a los desarrolladores que trabajen con ASP.NET Web.Config Limpios A lo largo de las distintas versiones de asp.net el fichero de conflagración ha ido creciendo, incorporando nuevas características como Ajax, routing o la interacción con IIS. Este aumento nos genere un fichero mucho mas grande y menos legible (el fichero web.config que se añade en un nuevo proyecto en el Visual Studio 2008 sp1 ocupa alrededor de 126 lineas), resulta bastante complicado modificar dicho fichero sin una herramienta como Visual Studio. Pero todo esto ha cambiado en la nueva versión, ahora cuando creemos un nuevo proyecto asp.net 4.0 podremos observar un web.config como este: Esto es posible gracias a que la mayoría de los elementos de conflagración han sido movidos al fichero machine.congif de forma que ahora las aplicaciones heredan del mismo. Esta novedad no aporta funcionalidad alguna pero si permite mayor legibilidad del código que teniendo en cuenta la cantidad de información que tenemos que manejar no es poco. Feliz año nuevo a todos, menos framework y mas Champagne!!

Cache de Objectos .Net: Applications Block

Hoy quiero hablar sobre la utilización de la cache en las aplicaciones Asp.net, cuando nos encontramos ante una aplicación que hace numerosas consultas a la base de datos y la mayoría de estas consultas no cambia habitualmente, nos encontramos ante un entorno perfecto para usar la cache. Las ventajas de cachear objetos son obvias, nos permite reducir los tiempos de respuesta de las aplicaciones ya que reducen el número de consultas a la base de datos y esto al final supone la mayoría del tiempo de procesamiento de una página. Llegado este punto en el que tenemos claro que queremos que nuestra aplicación use la cache, debemos decidir dónde vamos a utilizarla y qué vamos a cachear.

Output Cache a nivel de página

Es la forma mas simple de cache, mantiene una copia del HTML que ha sido enviado como respuesta.

Fragment Caching y user controls

Esta técnica se utiliza cuando solo queremos cachear determinadas partes de la página. Estas partes se encapsulan dentro de controles de usuario y luego se marcan con la directiva @OutputCache, indicando el tiempo que se mantendrá el control en memoria.

Caching API, usando el Objeto Cache

Utilizando el objeto cache puedes almacenar cualquier objeto serializable, permite controlar la expiración del objeto en función de varios parámetros, tiempo transcurrido desde su creación, modificación del objeto, modificación del otros objetos, cambios en tablas de la base de datos, ...

Applicattions Block

"Application Blocks son pequeñas (ahora no tan pequeñas) partes de la aplicación, en general bastante necesarias para el desarrollo de aplicaciones corporativas. Se pueden encontrar ejemplos de dichos Application Blocks en http://www.microsoft.com/resources/practices/code.mspx."

Para usas estos bloques de código es necesario instalar el Enterprise Library, una vez instalado ya podremos empezar a configurar la cache, aunque funciona sin necesidad de modificar nada en la configuración.

Este application block soporta la cache en memoria y en almacenamientos de soporte (bases de datos o almacenamientos aislados) .

Configuración

Enterprise Library viene con una herramienta de configuración que nos permite cambiar de forma graficas las opciones de los distintos Blocks.

Lo primero que tenemos que hacer es cargar en la herramienta de configuración el fichero de configuración (web.config) del proyecto en el que queremos utilizar la cache. Si habéis almacenado alguna cadena de conexión en el web.config veréis como la herramienta las reconoce y las sitúa dentro del Application Block de Data Access.

A continuación vereis como se ha creado una nueva sección que corresponde a la cache. Para el ejemplo vamos a mantener los valores por defecto, esto es, tiempo cache 60 segundos, número máximo de elementos en cache 1000, cuando se llega al tope se sacaran de la cache 10 elementos. Guardamos los cambios y cerramos la herramienta.

Uso de la cache

1- Añadir namespaces

using Microsoft.Practices.EnterpriseLibrary.Caching;
using Microsoft.Practices.EnterpriseLibrary.Caching.Expirations;

1- Instanciar object CacheManager

CacheManager cacheManager;
cacheManager = CacheFactory.GetCacheManager("MyCacheManager");

//Cache Manager es el nombre que le hemos dado al CacheManger en la herramienta de configuración

3- Cache de objetos

Usuario user = new Usuario("jorge", "españa", "28");
cacheManager.Add(user.nombre, user, CacheItemPriority.Normal, null, new SlidingTime(TimeSapn.FromMinutes(5)));

Con este ejemplo no se intuye la verdadera necesidad de utilizar este Block, pero si imaginamos situaciones en las que necesitemos realizar la cache en la capa de acceso a datos se vuelve un instrumento de gran importancia.

Descubriendo HtmlAgilityPack

Hace algunos años, antes de la popularización de los servicio web y los RSS, era bastante frecuente la tarea de buscar información dentro de una pagina web, recorriendo su código html. Esta tecnica se denomina Screen Scrapping, consiste en descargarse una pagina web, parsear el código Html y sacar la información necesaria. Este trabajo podia convertirse en una tarea complicada. El principal recurso que disponiamos para parsear el código Html eran las expresiones regulares, con ellas se consiguen unos buenos resultados pero tienen el inconveniente de ser muy complejas de construir. HtmlAgilityPack, una gran ayuda! Se trata de una libreria desarrollada en .Net que nos permite bajarnos código html a nuestra memoria, recorrerlo, extraer información y hasta modificarlo. La liberia nos permite ejecutar consultas XPath (Estándar de la W3C que permite realizar consultas los documentos Xml, teniendo en cuenta su estructrura jerarquica) ademas de soportar el tratamiento de páginas mal formadas, algo que es bastante habitual en la red. Bueno y ahora vamos a lo que nos interesa, vamos a ver algo de lo que podemos hacer con este nuevo juguete. Lo primero que tenemos que hacer es descargar la libreria, la podemos encontrar en Codeplex, despues añadimos una referencia en nuestro proyecto a HtmlAgilityPack.dll. En las siguientes lineas de código vamos obtener el titulo de los post de este blog.

static void Main(string[] args)
{
    var client = new System.Net.WebClient();
    client.Encoding = System.Text.Encoding.UTF8;
    var document = new HtmlAgilityPack.HtmlDocument();
    document.LoadHtml(client.DownloadString("http://irokhes.blogspot.com/"));

    //Obtenemos el titulo de cada uno de los post
    foreach (HtmlAgilityPack.HtmlNode node in
          document.DocumentNode.SelectNodes("//h3[@class='post-title entry-title']"))
          Console.WriteLine(node.InnerText.Trim());
}

En el siguiente ejemplo podemos ver como modificar el código de una página, en este caso se trata de como podriamos reparar los enlaces de una página.

 HtmlDocument doc = new HtmlDocument();
 doc.Load("file.htm");
 foreach(HtmlNode link in doc.DocumentElement.SelectNodes("//a[@href"])
 {
    HtmlAttribute att = link["href"];
    att.Value = FixLink(att);
 }
 doc.Save("file.htm");

Por último vamos a ver como Usar sentencias de Linq sobre una página web. En este ejemplo vamos a obtener la url de todas las imagenes que aparecen en el blog.

static void Main(string[] args)
{
   string url = "http://irokhes.blogspot.com/";            
   WebClient client = new WebClient();
   string html = client.DownloadString(url);

   // Load the Html into the agility pack
   HtmlAgilityPack.HtmlDocument doc = new HtmlAgilityPack.HtmlDocument();
   doc.LoadHtml(html);

   List imageNodes = null;
   imageNodes = (from HtmlNode node in doc.DocumentNode.SelectNodes("//img")
             where node.Name == "img"
             select node).ToList();

   foreach (HtmlNode node in imageNodes)
   {
          //Se escribe el atributo src de cada una de las imagenes
          Console.WriteLine(node.Attributes["src"].Value);
   }
}
//

Creo que con estos ejemplos se puede ver la sencillo que es usar la libreria, basta con conocer alguans sentencias de Xpath para poder acceder a cualquier elemento de una págino. Si a usamos esta libreria en conjunto con alguna herramienta como Internet explorer developer toolbar o Firebug podremos examinar la información de cualquier web aunque esta no disponga de una Api especifica para ello.

Usar jQuery con MasterPage

Si alguien ha intentado usar las librerias de jQuery en una proyecto asp.net que las páginas hereden de una página maestra, se habra dado cuenta de que jQuery no funciona. Esto es debido a que la página maestra se encuentra en un nivel de directorios distintos al que se encuentras las paginas hijas. Para solucionar podemos utilizar un pequeño truco, para referenciar el archivo de jquery en la MasterPage lo haremos de la sigueinte manera:

<script src="<%= Page.ResolveUrl("~/Js/ui.core.js") %>"
 language="javascript" type="text/javascript"></script>