moure.es – Alfonso Moure Ortega

Se escucha desde hace mucho tiempo el sonido distante de éste mismo problema: ¿afecta la existencia del ViewState de ASP.NET en el indexado de Google? La respuesta solo puede tomar dos valores: sí o no. Y cada persona, cada SEO, cada gurú de Internet, os responderá una cosa diferente. Por supuesto, yo también tengo mi teoría.

Y es la siguiente: sí, el ViewState de ASP.NET afecta al posicionamiento en Google. ¿Por qué? Os doy varias razones:

1. Por su tamaño: en páginas demasiado complejas y con una gran carga de controles ASP.NET, ocupará tanto espacio que nos arriesgamos no solo a perjudicar a los usuarios menos favorecidos en su velocidad de conexión, sino que también nos arriesgaremos a producir un timeout en las consultas de Google.
2. Por el desplazamiento de contenido: Google utiliza como criterio de posicionamiento, como todos bien sabemos, la posición de la información y metainformación dentro del documento HTML. Un ViewState demasiado grande moverá los datos realmente importantes (es decir, todo el BODY) hacia abajo.
3. Por su incoherencia como información: El contenido del ViewState es incomprensible, no solo para un humano, sino también para una máquina ajena a la aplicación ASP.NET en ejecución. Incluso a veces es incomprensible para ella misma.

¿Cómo evitar su existencia? No siempre es posible. El uso de callbacks en ASP.NET, aunque es algo muy cómodo, no es ni de lejos recomendable para atraer a Google. Todos lo sabemos. Pero a veces, se hace inevitable.

De todas maneras, si podéis evitar el uso de ViewState (y por favor, no uséis variables de sesión, porque os volveréis majaras trabajando con ellas), os digo un modo bien sencillo de desactivarlo: en la etiqueta inicial de vuestra página ASP.NET, no hay más que activar EnableViewState como false:

<%@ Page Language=”C#” EnableViewState=”False” %>

Lógicamente podéis usar este mismo atributo en cualquier control de vuestra página, pero gracias a realizarlo a nivel de Page, os aseguraréis de que se extiende como es debído y que nada se os pase por alto. Recordad así mismo que podéis establecer EnableViewState como false a nivel de página, pero como true a nivel de control, simplemente indicandolo en la etiqueta propia del elemento que queréis que pueda usar nuestro valioso espacio de control de estado.

¿Dudas? Dejad un comentario y gustoso os echaré una mano.

Bookmark

Desde pasar variables en campos ocultos (hidden fields) hasta guardarlas como variables de sesión, pasando por enviar QueryStrings absurdamente largos. Estas son algunas de las salidas que muchos programadores utilizan para poder pasarse información entre diferentes callbacks en ASP.NET, para conservar valores de variables o datos de los usuarios. ¿Os imagináis guardar datos personales de los usuarios en campos ocultos HTML? Aberrante.

Algunas personas utilizarán otros métodos, pero yo os voy a sugerir mi preferido y el que más uso normalmente. Es recomendable no usarlo en situaciones donde la seguridad sea extremadamente importante, pese a que decodificar la cadena del ViewState en el resultado renderizado de la página sea un acto casi faraónico.

Mi propuesta es la siguiente: muchos queremos poder mantener el estado y contenido de nuestras variables entre un callback y el siguiente, de manera sencilla y cómoda. Para ello vamos a usar el ViewState.

Para los profanos: ¿qué es el ViewState?

Cuando uno programa en ASP.NET, comunmente utiliza eventos para controlar la interacción de los usuarios clientes en la página. Estos eventos nos permiten detectar, por ejemplo, cuándo un usuario selecciona una opción de un desplegable DropDownList. Cuando el cliente hace ésto, por arte de magia el código de lado de servidor recibe un mensaje que lanza un método señalado como capturador del evento. Por ejemplo:

Código ASP.NET:

<asp:DropDownList runat=”server” ID=”dropdownPrueba” OnSelectedIndexChanged=”procesarCambio”>
<asp:ListItem Text=”Opción 1″ Value=”1″></asp:ListItem>
<asp:ListItem Text=”Opción 2″ Value=”1″></asp:ListItem>
</asp:DropDownList>

Código C#

protected void procesarCambio(object sender, EventArgs e)
{
Response.Write(this.dropdownPrueba.SelectedItem.Text);
}

Fijaros bien en algo. En la función C# anterior, estoy recogiendo el texto contenido en el item seleccionado en el desplegable. ¿Cómo sabe ASP.NET lo que está seleccionado? ¿Cómo sabe los items que había antes en el desplegable? La pregunta tiene fácil respuesta: el ViewState.

El ViewState es el modo en que ASP.NET guarda el estado general de una aplicación web dentro del ámbito de una misma página y sus consecuentes callbacks. Automáticamente, guarda el estado de todas las variables de los controles de usuario ASP.NET (siempre y cuando tengamos activada la opción EnableViewState en el control), de manera que se conservan y son accesibles en cada callback de la página.

Pero, ¿cómo puede esto servirnos para guardar datos entre una llamada a servidor y otra? Los chicos de Redmon nos han dejado una pequeña puerta trasera para acceder al ViewState e introducir y recuperar información.

Su uso es bien sencillo: podemos acceder al ViewState como una variable estática global, de la siguiente manera y desde cualquier punto de nuestro proyecto web:

Código C#

//Introducimos un dato en el ViewState…

ViewState["midato"] = “vamos a guardar esto en el ViewState de la página”;

//y ahora lo recuperamos

string este_era_el_dato = ViewState["midato"];

Por supuesto, podéis probar esto y añadir cada línea en callbacks diferentes para poder comprobar su correcto funcionamiento.

Mi sugerencia

Cada desarrollador tiene sus propias manías, y yo no soy una excepción. Por ello, conservo determinados valores entre diferentes llamadas del servidor cuando es necesario y apropiado. Aquí os dejo un ejemplo:

private string __variable;

public string Variable
{
get { if (ViewState["variable"] != null) return ViewState["variable"].ToString(); else return this.__variable; }
set { ViewState["variable"] = value; this.__variable = value; }
}

De esta manera, si haceis uso de la propiedad llamada Variable en cualquier punto de la clase, ésta se conservará entre callbacks. Recordad que, aunque la propiedad Variable, aunque la haya definido como pública, podeis usarla como prefiráis (private, protected…). No useis la variable __variable, pues será sobreescrita por la propiedad cada vez que la llaméis, no es más que un punto de control.

Como nota personal, siempre tiendo a encerrar este tipo de composiciones en una misma región, quedando mucho más organizado y ordenado.

Bookmark