Mensaje dentro de Tutoriales ASP.NET

 
#1 - 17/03/2006 18:55:35 Reporta abuso | Link Permanente
jau
Fecha de registro: 03/12/2006
0 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Tutorial de ASP.NET

Traducción del tutorial oficial que podemos encontrar en la web www.asp.net.
Los ejemplos los encontraréis en C#. Si deseáis verlos en cualquier otro lenguaje no tendréis más remedio que acudir a la web del tutorial. De todas formas, estamos trabajando en conseguir poco a poco que tengáis disponibles todos los lenguajes.
Esperamos que sea de vuestro agrado.

NOTA: este tutorial está en proceso de traducción. A medida que vayamos acabando de traducir alguna parte, la iremos publicando. En el caso que alguien encuentre algún error, rogamos nos lo hagáis saber para corregirlo. Muchas gracias a tod@s.
Volver arriba

Respuestas
Mostrar de en 15 Ir a página Siguientes >>
#2 - 23/01/2013 18:38:00 Reporta abuso | Link Permanente
ASDFASF
Usuario no registrado
ASFDASF

ASDASDFASDFAS
Volver arriba

#3 - 11/06/2007 23:30:06 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Gridview

he ASP.NET GridView control is the successor to the v1.x DataGrid, adding the ability to take advantage of specific capabilities of ASP.NET data source controls. Whereas the v1.x DataGrid required a page developer to write custom code to handle simple operations such as paging, sorting, editing or deleting data, the GridView control can automatically handle these operations provided its bound data source control supports these capabilities. The GridView also offers some functionality improvements over the DataGrid, such as the ability to define multiple primary key fields, and some UI customization improvements, such as new field types and templating options. It also exposes a new model for page developers to handle or cancel events.

The following example demonstrates the GridView control bound to a SqlDataSource control to produce a read-only tabular report.

C# GridView-SqlDataSource
Run Sample View Source

In the preceding example, the GridView control reflected against the fields of the data records returned by SqlDataSource in order to dynamically generate the columns of the grid. You can also specify explicit column fields to display by adding DataControlField objects to the GridView's Columns collection. This allows you to specify exactly which columns to display and their relative order. The following example demonstrates a collection of BoundField and CheckBoxField objects in the GridView Columns collection. Other field types that can be assigned to this collection are ImageField, HyperLinkField, CommandField, ButtonField, and TemplateField.

C# GridView-SqlDataSource (BoundFields)
Run Sample View Source

One of the key advantages of the GridView control over other data-bound controls is its ability to automatically take advantage of data source capabilities. Instead of relying on page code to manually sort or page data, the GridView control can perform these operations automatically as long as the data source is configured to support these operations. The following example shows a GridView control with sorting enabled.

C# GridView Sorting
Run Sample View Source

You can also enable paging UI in the GridView by setting the AllowPaging property to true. The GridView can automatically page over any return value from a data source that supports the ICollection interface. The DataView returned by SqlDataSource when in DataSet mode supports this interface, so GridView can page over the result. When in DataReader mode, the GridView cannot page over the data returned by SqlDataSource. The following example demonstrates the GridView paging UI against a SqlDataSource in DataSet mode.

C# GridView Paging
Run Sample View Source

GridView also supports a special mode for paging and sorting that takes advantage of client-side callbacks to the server to obtain data for the new page or newly sorted data. To enable this feature, set the EnableSortingAndPagingCallbacks property to true. Notice that when a page or sort operation is performed, the page does not need to postback in order to retrieve new values (although a client script callback to the server is made). This feature is not supported when the GridView contains templated fields. Showing a Select button in a CommandField is also not supported when this feature is enabled.

C# GridView Paging and Sorting Callbacks
Run Sample View Source

Just like sorting and paging, the GridView control can also automatically render UI for modifying data through Update and Delete operations, provided the associated data source is configured to support these capabilities. The SqlDataSource control supports Update operations when its UpdateCommand property is set and Delete operations when its DeleteCommand property is set to a valid update or delete command or stored procedure. The UpdateCommand or DeleteCommand should contain parameter placeholders for each value that will be passed by the GridView control.

To enable the UI in the GridView for Updates or Deletes, you can either set the AutoGenerateEditButton and AutoGenerateDeleteButton properties to true, or you can add a CommandField to the GridView control and enable its ShowEditButton and ShowDeleteButton properties. The GridView supports editing or deleting one row at a time. For editing, the user places the row in edit mode by clicking the Edit button, and then confirms the Update by clicking the Update button while the row is in edit mode. The user can also click the Cancel button to abort the edit operation and return to read-only mode. The following example shows the a GridView and SqlDataSource configured for updating data rows.

C# GridView Updating
Run Sample View Source

An important property that plays a special role in Update and Delete operations is the DataKeyNames property. This property is typically set to the names of fields from the data source that are part of a primary key used to match a given row in the data source. Multiple keys are comma-separated when specifying this property declaratively, although it is common to only have one primary key field. The values of fields specified by the DataKeyNames property are round-tripped in viewstate for the sake of retaining original values to pass to an Update or Delete operation, even if that field is not rendered as one of the columns in the GridView control. When the GridView invokes the data source Update or Delete operation, it passes the values of these fields to the data source in a special Keys dictionary, separate from the Values dictionary that contains new values entered by the user while the row is in edit mode (for update operations). The contents of the Values dictionary are obtained from the input controls rendered for the row in edit mode. To exclude a value from this dictionary, set the ReadOnly property to true on the corresponding BoundField in the Column collection. If you are using the GridView designer in Visual Studio, the ReadOnly property is set to true for primary key fields by default.

For more information and examples that demonstrate the use of the GridView control, refer to the Performing Data Access section.
Volver arriba

#4 - 11/06/2007 21:38:16 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Gridview

he ASP.NET GridView control is the successor to the v1.x DataGrid, adding the ability to take advantage of specific capabilities of ASP.NET data source controls. Whereas the v1.x DataGrid required a page developer to write custom code to handle simple operations such as paging, sorting, editing or deleting data, the GridView control can automatically handle these operations provided its bound data source control supports these capabilities. The GridView also offers some functionality improvements over the DataGrid, such as the ability to define multiple primary key fields, and some UI customization improvements, such as new field types and templating options. It also exposes a new model for page developers to handle or cancel events.

The following example demonstrates the GridView control bound to a SqlDataSource control to produce a read-only tabular report.

C# GridView-SqlDataSource
Run Sample View Source

In the preceding example, the GridView control reflected against the fields of the data records returned by SqlDataSource in order to dynamically generate the columns of the grid. You can also specify explicit column fields to display by adding DataControlField objects to the GridView's Columns collection. This allows you to specify exactly which columns to display and their relative order. The following example demonstrates a collection of BoundField and CheckBoxField objects in the GridView Columns collection. Other field types that can be assigned to this collection are ImageField, HyperLinkField, CommandField, ButtonField, and TemplateField.

C# GridView-SqlDataSource (BoundFields)
Run Sample View Source

One of the key advantages of the GridView control over other data-bound controls is its ability to automatically take advantage of data source capabilities. Instead of relying on page code to manually sort or page data, the GridView control can perform these operations automatically as long as the data source is configured to support these operations. The following example shows a GridView control with sorting enabled.

C# GridView Sorting
Run Sample View Source

You can also enable paging UI in the GridView by setting the AllowPaging property to true. The GridView can automatically page over any return value from a data source that supports the ICollection interface. The DataView returned by SqlDataSource when in DataSet mode supports this interface, so GridView can page over the result. When in DataReader mode, the GridView cannot page over the data returned by SqlDataSource. The following example demonstrates the GridView paging UI against a SqlDataSource in DataSet mode.

C# GridView Paging
Run Sample View Source

GridView also supports a special mode for paging and sorting that takes advantage of client-side callbacks to the server to obtain data for the new page or newly sorted data. To enable this feature, set the EnableSortingAndPagingCallbacks property to true. Notice that when a page or sort operation is performed, the page does not need to postback in order to retrieve new values (although a client script callback to the server is made). This feature is not supported when the GridView contains templated fields. Showing a Select button in a CommandField is also not supported when this feature is enabled.

C# GridView Paging and Sorting Callbacks
Run Sample View Source

Just like sorting and paging, the GridView control can also automatically render UI for modifying data through Update and Delete operations, provided the associated data source is configured to support these capabilities. The SqlDataSource control supports Update operations when its UpdateCommand property is set and Delete operations when its DeleteCommand property is set to a valid update or delete command or stored procedure. The UpdateCommand or DeleteCommand should contain parameter placeholders for each value that will be passed by the GridView control.

To enable the UI in the GridView for Updates or Deletes, you can either set the AutoGenerateEditButton and AutoGenerateDeleteButton properties to true, or you can add a CommandField to the GridView control and enable its ShowEditButton and ShowDeleteButton properties. The GridView supports editing or deleting one row at a time. For editing, the user places the row in edit mode by clicking the Edit button, and then confirms the Update by clicking the Update button while the row is in edit mode. The user can also click the Cancel button to abort the edit operation and return to read-only mode. The following example shows the a GridView and SqlDataSource configured for updating data rows.

C# GridView Updating
Run Sample View Source

An important property that plays a special role in Update and Delete operations is the DataKeyNames property. This property is typically set to the names of fields from the data source that are part of a primary key used to match a given row in the data source. Multiple keys are comma-separated when specifying this property declaratively, although it is common to only have one primary key field. The values of fields specified by the DataKeyNames property are round-tripped in viewstate for the sake of retaining original values to pass to an Update or Delete operation, even if that field is not rendered as one of the columns in the GridView control. When the GridView invokes the data source Update or Delete operation, it passes the values of these fields to the data source in a special Keys dictionary, separate from the Values dictionary that contains new values entered by the user while the row is in edit mode (for update operations). The contents of the Values dictionary are obtained from the input controls rendered for the row in edit mode. To exclude a value from this dictionary, set the ReadOnly property to true on the corresponding BoundField in the Column collection. If you are using the GridView designer in Visual Studio, the ReadOnly property is set to true for primary key fields by default.

For more information and examples that demonstrate the use of the GridView control, refer to the Performing Data Access section.
Volver arriba

#5 - 23/01/2007 23:47:48 Reporta abuso | Link Permanente
jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Autenticación Basada en Formularios

La autenticación basada en formularios es un servicio de autenticación de ASP .NET que permite a las aplicaciones proporcionar su propia Interfaz de Usuario para el inicio de sesión y hacer su propia verificación de credenciales. ASP .NET autentica usuarios, redirecciona uusarios no autenticados a la página de inicio de sesión y ejecuta toda la administración de cookies necesaria. Este tipo de autenticación es una técnica muy popular usada en muchos sitios web.

Para que una aplicación utilice autenticación basada en formularios, tendremos que fijar el valor de  <authentication> a Forms, y denegar el acceso a usuarios anónimos. El siguiente ejemplo muestra como puede realizarse esto en el fichero Web.config para la aplicación deseada:

<configuration>
  <system.web>
    <authentication mode="Forms"/>
    <authorization>
        <deny users="?" />
    </authorization>
  </system.web>
</configuration>

Los administradores usremos la autenticación basada en formularios para configurar el nombre de la cookie a utilizar, el tipo de protección, la URL de la página de login, tiempo de vida de la cookie y la ruta a utilizar para la cookie emitida. La siguiente tabla muestra los atributos válidos para los elementos <Forms>, el cual es un subelemento de <authentication>, mostrado en el siguiente ejemplo:

<authentication mode="Forms">
<forms name=".ASPXCOOKIEDEMO" loginUrl="login.aspx" defaultUrl="default.aspx"
protection="All" timeout="30" path="/" requireSSL="false"
slidingExpiration="true" enableCrossAppRedirects="false"
cookieless="UseDeviceProfile" domain="">
<!-- protection="[All|None|Encryption|Validation]" -->
<!-- cookieless="[UseUri | UseCookies | AutoDetect | UseDeviceProfile]" -->
</forms>
</authentication>



Atributo         Descripción
cookieless Los formularios de autenticación de ASP.NET 2.0 pueden almacenar los tickets de autenticación de los formularios con o sin la representación en la URL de una cookie. El valor por defecto de UseDeviceProfile indica que ASP .NET determina dónde almacenar el ticket basado en el perfil del navegador pre-calculado. La opción de AutoDetect hace que ASP.NET determine dinámicamente si el navegador soporta cookies o no. UseUri y UseCookies fuerza el uso de tickets sin y con cookies, respectivemente.
defaultUrl Especifica la URL por defecto a la que la petición es redireccionada después de un ingreso válido. Este valor se usa si no existe una URL de redirección en la Autenticación por Formularios.
domain Especifica el valor de la propiedad Domain en la HttpCookie que contiene los tickets del formulario de autenticación. Configurar este atributo explícitamente permite a las aplicaciones compartir la misma cookie siempre que las aplicaciones compartan una porción común de un espacio de nombres de DNS (ej: appA.contoso.com y appB.contoso.com podrían compartir una cookie si el domain attribute tiene el valor "contoso.com").
enableCrossAppRedirects Los formularios de autenticación de ASP.NET 2.0 permiten enviar los tickets de autenticación del formulario entre aplicaciones tanto en una variable cadena-petición como en una variable POST de formulario. Poner este atributo a true permite al FormsAuthenticationModule extraer el ticket tanto de una cadena-petición como de una variable POST de formulario.
loginUrl Especifica la URL a la cual la petición es redireccionada para usuarios no autenticados. Esta puede estar en la misma máquina o una remota. Si está en una remota, ambas máquinas necesitan estar usando el mismo valor para los atributos decryptionkey y validationKey que se encuentran en el elemento de configuración machineKey.
name Nombre de la cookie HTTP a usar para propósitos de autenticación. Observad que si más de una aplicación quiere usar servicios de autenticación basados en formularios en una sóla máquina, y cada aplicación quiere que la cookie del formulario de autenticación sea exclusiva para la aplicación, entonces cada una debería configurar un único valor de cookie. Para evitar causar dependencias en las URLs, ASP .NET también usa “/” como valor de Path cuando configura cookies de autenticación, de modo que son devueltas a cada aplicación en el sitio web.
path Path o ruta que usa la cookie emitida. El valor por defecto es “/” para evitar dificultades en caso de ausencia de path, debido a que los navegadores distinguen entre mayúsculas y minúsculas cuando devuelven las cookies. Las aplicaciones en un entorno de servidor compartido deberían usar estas directivas para mantener las cookies privadas. (Alternativamente, pueden especificar el path en tiempo de ejecución utilizando APIs para la cookie emitida).
protection

Método usado para proteger los datos de las cookies. Los valores permitidos son los siguientes:

  • All: Usa tanto validación como encriptación para proteger la cookie. El algoritmo validación de datos está basado en el elemento <machinekey>. Se usa AES por defecto para la encriptación, y si la clave es suficientemente larga (48 caracteres). All es el valor por defecto (y aconsejado).
  •  None: Se usa para sitios que solo usan cookies para la personalización y tienen requerimientos de seguridad poco estrictos. Tanto la encriptación como la validación se pueden desactivar. Aunque se deberiamos tener cuidado si usamos las cookies de este modo, esta configuración proporciona las mejores prestaciones de cualquier método de personalización usando el Framework de .NET.
  • Encryption: Encripta la cookie utilizando AES, TripleDES o DES, pero no se realiza una validación sobre la cookie. Este tipo de coolie puede estar sujeta a determinados ataques “choose plaintext”.
  • Validation: No encripta  los contenidos de la cookie, pero valida el que los datos de la cookie no hayan sido alterados durante el trayecto. Para crear la cookie, la clave de validación es concatenada en un buffer con los datos de la cookie y una MAC es calculada y añadida a la cookie de salida.
requireSSL Si el valor está a true, la Autenticación por Formularios configura el bit de seguridad en la cookie del formulario de autenticación. Los navegadores “conformistas” sólo devolverán la cookie a ASP .NET a través de una conexion SSL. Observad que esta configuración no tiene efecto en formularios de autenticación sin cookies.
slidingExpiration Si el valor está a true, los Formularios de Autenticación actualizarán periódicamente el tiempo de vida para los tickets del formuario de autenticación. Esto ocurre independientemente de si el ticket está o no contenido en una cookie, o en los formatos sin cookie en la URL.
timeout Cantidad de tiempo en minutes enteros, después del cual la cookie expira. El valor por defecto es 30. El atributo timeout es un variable, que expira a los n minutos de haber recibido la última petición. Para evitar prestaciones que nos afecten negativamente o múltiples avisos del navegador (para aquellos que tengan los avisos de cookier activados), la cookie se actualiza si el tiempo transcurrido es más de la mitad del valor configurado. (Esto puede conllevar una pérdida de precision en algunos casos).

Después de que la aplicación haya sido configurada, necesitamos proporcionar una página de registro. El siguiente ejemplo muestra una sencilla página de registro. Cuando se ejecuta el ejemplo, solicita la página Default.aspx. Las peticiones no autenticadas se redireccionan a la página de registro (Login.aspx), qué presenta un sencillo formulario solicitando una dirección de correo electrónico y un password. (Como credenciales utiliza Username=”someone@www.contoso.com” and Password=”password”).

Después de validar las credenciales, la aplicación realiza la siguiente llamada:



Volver arriba

#6 - 20/03/2006 11:26:15 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Configuración de la Caché

ASP.NET 2.0 incluye nuevas características para la configuración de la caché<a name="profiles">

Perfiles de Caché

Los perfiles de caché permiten que la configuración de la caché para cientos de páginas sea implantada de forma central desde la configuración. De forma individual las páginas siguen pudiendo sobreescribir la configuración del perfil. especificándolo en la directiva <%@ OutputCache %>, pero por motivos de administración podemos hacer que simplemente hereden la mayoría o toda la configuración del perfil de caché. En el siguiente ejemplo, la página utiliza un perfil de caché con el atributo CacheProfile, con la configuración de la caché localizada en el perfil, en la sección <outputcachesettings> del grupo de sección de configuración <caching>.

C# Perfiles de Caché


<a name="properties">

Propiedades de la Caché en la Configuración

ASP.NET 2.0 incluye soporte para configurar la cuota de recursos utilizados para la caché. Las secciones de configuración de la caché se dividen en 3 secciones de nivel superior, contenidas en el grupo de sección <caching>, que se incluye bajo <system.web>:

  • cache. Contiene la configuración de la aplicación referente a la caché, incluyendo el uso de memoria y las características deshabilitadas.
  • outputCache. Contiene la configuración de la aplicación referentes a la caché de salida, incluyendo la deshabilitación de la caché de salida o de fragmento.
  • outputCacheSettings. Contiene los ajustes de caché que pueden ser utilizados por las páginas/controles de la aplicación y se pueden declarar en cualquier nivel.
  • Contains cache settings that can be used by individual pages/controls within the app and can be declared at any level.


Para más detalles de la configuración de la caché, podemos acudir a la documentación de ASP.NET 2.0.
Volver arriba

#7 - 20/03/2006 11:25:59 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Invalidación de la cache SQL (Nuevo en 2.0 )

En el ejemplo anterior, los datos eran guardados en cache durante 60 segundos, sin tener en cuenta si los datos han cambiado en la base de datos. El mecanismo de invalidación de la cache de SQL le permite establecer un elemento de la cache dependiente dela base de datos, de forma que el elemento de la cache se borrará cuando la base de datos cambie.

<a name="polling">

Invalidación basada en sondeos 

Este mecanismo usa un sondeo para comprobar si una tabla ha sido actualizada desde que la página se guardó en la caché. Para habilitar la caché basada en tabla se requieren los siguientes pasos:

1)

Habilitar las notificaciones de la base de datos utilizando la herramienta aspnet_regsql.exe

>aspnet_regsql.exe -S ".\SQLExpress" -E -d "pubs" -ed

Este paso sólo hace falta hacerlo una vez por cada base de datos.

2)

Habilitar las notificaciones para la tablas o las tablas que quiere que tenga las dependencias utilizando la herramienta aspnet_regsql.exe


>aspnet_regsql.exe -S ".\SQLExpress" -E -d "pubs" -et -t "authors"

3)

Registrar la notificacion en el fichero de configuraciónd de la aplicación:


<system.web>
        <caching>
                <sqlCacheDependency enabled="true" pollTime="1000" >
                        <databases>
                                <add name="PubsDB" connectionStringName="Pubs" />
                        </databases>
                </sqlCacheDependency>
        </caching>
</system.web>

El tiempo de sondeo indica la frecuencia con que la aplicación comprueba si los datos han cambiado
 

4)

Ahora ya se puede utilizar una dependencia SQL en la directiva OutputCache:



<%@ OutputCache Duration="999999" SqlDependency="Pubs:Authors" VaryByParam="none" %>

O bien, indicarlo directamente en el control DataSource:

<asp:SqlDataSource EnableCaching="true" CacheDuration="Infinite" SqlCacheDependency="PubsDB:Authors" ... />

El siguiente ejemplo usa una cacheé de salida para un datasource de sql usando una notificación basada en tablas. Observad el valor de fecha y hora al final de la aplicación qué debería permanecer estático. Puede usar el ejemplo del GridView para editar los datos. El refresco de la página debería actualizar los datos y poner un nuevo valor de fecha y hora

 
C# SqlCacheDependency


Invalidación Caché basada en Notificaciones de SQL Server 2005

Este mecanismo usa el mecanismo de notificación de cambios en las consultas de SQL Server 2005 para detectar cambios en el resultados de las consultas. Al contrario que la invalidación de SQL Server 7.0 y 2000 basado en los sondeos, esta invalidación requiere mucho menos trabajo de configuración.

  1. Al contración que en la validación por sondeos, no se necesita indicar la entrada <sqlCacheDependency> en la configuración de la aplicación. Además, tampoco hace falta una configuración especial utilizando la herramienta aspnet_regsql.exe

  2. Se configura una notificación basada en dependencia de sql en la directiva OutputCache, utilizando la cadena CommandNotification. Este valor le indica a ASP.NET que se va a utilizar una dependencia basada en notificaciones para la página o un control DataSource

    Para la página:


    <%@ OutputCache Duration="999999" SqlDependency="CommandNotification" VaryByParam="none" %>

    Para el control Datasource:


    <asp:SqlDataSource EnableCaching="true" SqlCacheDependency="CommandNotification" CacheDuration="Infinite" ... />

  3. Se debe llamar al metodo System.Data.SqlClient.SqlDependency.Start() en algun lugar de la aplicación antes de que se ejecute la primera consulta SQL. Esta llamada puede ponerse en el evento Application_Start() del fichero global.asax.

  

Siempre que un comando está relacionado con SQL Server 2005, ASP.NET y ADO.NET automáticamente crearán una dependencia de caché que escuche las notificaciones de cambios enviados por SQL Server. Cuando se cambia un dato en SQL Server, esta notificación provocará la invalidación de las consultas en la caché del servidor web. La proxima vez que se solicite una pagina o control DataSource asociado con la dependencia, la página o el control serán ejecutados en vez de obtener la información del caché.

Algunos puntos a tener encuenta para que las notificaciones funcionen correctamente son:

  1. Las consultas deben indicar explicitamente los nombres de las columnas en la clausula Select. Si se usa "SELECT *" los resultados de la consulta no se registraran para las notificaciones de SQL 2005.
  2. Los nombres de las tablas deben incluir el nombre del propietario. Por ejemplo, si quiere obtener una consulta de la tabla author de la base de datos pubs, la consultade debe referenciar a la tabla como "dbo.authors".
  3. El usuario de SQL Server 2005 que está ejecutando la consulta tiene que tener permiso para registrar consultas para notificaciones. El siguiente comando Transact SQL otorga esos derechos : GRANT SUBSCRIBE QUERY NOTIFICATIONS TO username.
  4. El usuario de SQL Server 2005 que está ejecutanto la consulta tambien tiene que tener derechos para enviar notificaciones desde SQL Server 2005. El siguiente comando Transact SQL otorga esos derechos: GRANT SEND ON SERVICE::SqlQueryNotificationService TO username.

Nota: Hay un determinado número de restricciones en la sintaxis de las consultas SQL para soportar notificaciones. Para obtener la lista completa de restricciones, acudid al punto "Crear una consulta SQL para notificaciones" en los libros en linea de SQL Server 2005. Tambien, si nos encontramos con consultas que no son guardades en la cache y son ejecutadas en cada petición de la página, es probable que o bien no cumplan con las restricciones requeridas por SQL Server 2005 o bien que SQL Server 2005 esté generando un error cuando intenta establecer las notificaciones para esas consultas. Actualmente, estas situaciones no producen ningun mensaje de error con el resultado final de que las dependencias de la caché son siempre no válidas y, por tanto, cualquier consulta asociada se ejecuta siempre con cada petición de página

Volver arriba

#8 - 20/03/2006 11:25:45 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Cacheando los datos de la página

ASP.NET dispone de un motor de caché completo que puede ser usado por las páginas para almacenar y recuperar cualquier tipo de objeto a través de las peticiones HTTP. La caché de ASP.NET es privada para cada aplicación y almacena los objetos en memoria. La duración de la cache es equivalente a la duración de la aplicación; esto significa que cuando una aplicación se reinicia, la cache se vuelve a crear.

La caché proporciona una interface con un Diccionario simple que permite a los programadores facilmente poner objetos en la caché y recuperarlos. En elcaso más simple, volcar un elemento en la cache es como añadir un elemento a un diccionario:

 Cache["myKey"] = myValue;

La recuperación de datos del cache es muy simple. Hay que tener en cuenta que debe de comprobarse la existencia del objeto en cache antes de recuperarlo, como se muestra en el ejemplo siguiente:



myValue = Cache["mykey"];
if(myValue != null ) {
DisplayData(myValue);
}

Usando los datos de la Caché

El siguiente ejemplo muestra otro uso sencillo de la caché. Ejecuta una consulta a la base de datos y guarda en caché el resultado, qué se seguirá usando durante la vida de la aplicación. Cuando ejecutéis el ejemplo, observad el mensaje en la parte inferior de la página. Con la primera petición, indica que los datos han sido recuperados de la base de datos. Despues de refrescar la página, se apunta que se ha usado la copia de la caché.

C# Datos de Caché

El siguiente ejemplo muestra un elemento de la caché que depende de un fichero XML. Es similar al primer ejemplo pero en este caso, el dato es recuperado de una fuente XML en vez de un servidor de base de datos.  Cuando el dato es guardado en la caché, el fichero XML se le añade como una dependencia. Cuando se añade un nuevo registro usando el formulario al final de la página, el fichero XML se actualiza y el elemento de la caché se refresca.

C# Data Cache 2

Fíjese que el fichero de dependencia se añade usando Cache.Insert y mediante un objeto CacheDependency referenciando al fichero XML. Puede usarse el mismo mecanismo para dependencias personalizadas.


Cache.Insert("MyData", Source,
new CacheDependency(Server.MapPath("authors.xml")));

Un elemento de la caché puede depender de uno o varios ficheros o claves. Como vimos antes, una aplicación también puede establecer la política de caducidad de un elemento de la cache. El siguiente código establece un tiempo de caducidad absoluto para el objeto de la caché.


Cache.Insert("MyData", Source, null,
DateTime.Now.AddHours(1), TimeSpan.Zero);

El parametro más importante es la llamada a DateTime.Now.AddHours(1), que indica que el elemento caduca una hora después de que se ha insertado. El último argumento, TimeSpan.Zero, indica que no hay una política relativa de caducidad en este item.

El siguiente código muestra como estableces una política de caducidad relativa. Se inserta un item en la caché que caduca 20 minutos después de su último acceso. Observad el uso de DateTime.MaxValue, que indica que no se establece una política absoluta de caducidad para este elemento.


Cache.Insert("MyData", Source, null, DateTime.MaxValue,
TimeSpan.FromMinutes(20));

Para aquellas aplicaciones que necesitan una funcionalidad más sofisiticada, el cache de ASP.NET suporta barrido, caducidad y dependencias de ficheros y de claves.

Barrido de los elementos de cache

La técnica del barrido es el proceso que intenta quitar de la caché elementos poco usados o no importantes cuando la memoria empieza a escasear. Si un programador quiere controlar como se ejecuta el barrido puede establecer las características de barrido de los objetos cuando se insertan en al cache, indicando la importancia del elemento y la frecuencia con la que el elemento debe utilizarse para mantenerse disponible en cache.

Caducidad de los elementos de cache

La caducidad permite a los programadores indicar a cada elemento de la caché su tiempo de duración. Pueden indicarse se forma explicita ( por ejemplo, caduca a las 6:00) o puede indicarse de forma relativa a la ultima vez que el elemento fue usado( por ejemplo, caduca 20 minutos después de que se usó por ultima vez). Cuando un elemento caduca, es eliminado de la cache y los siguientes intentos de recuperarlo devolveran un valor null a menos que vuelva a ser insertado en la caché.

Dependencias de la cache

Las dependencias de la caché permiten establecer la validez de un elemento de la cache basado en un fichero externo o en otro elemento de la cache. Cuando una dependencia cambia, el elemento de la cache dependiente se invalida y es eliminado de la cache. Para ver un ejemplo de como usar esta prestación, imaginemos el siguiente escenario: una aplicación lee información financiera de un fichero xml que se actualiza periodicamente. La aplicación procesa los datos del fichero y crea un gráfico de objetos que representan los datos de forma visible. La aplicacion guarda en cache los datos e inserta una dependencia del fichero del cual los datos se leen. Cuando el fichero se actualiza, los datos se eliminan de la cache y la aplicación puede volver a leer el fichero e insertar la copia actualizada de los datos en la cache.

ASP.NET 2.0 permite la herencia de la clase System.Web.Caching.CacheDependency, facilitando que cualquier programador pueda reescribir su propia implementación de una dependencia de caché. Desarrollando su propiar dependencia de cache, puede aprovechar las ventajas del mecanismo de invalidación  para mantener el contenido de la caché actualizado con el origen de los datos. ésta es una forma mas eficaz y rentable de asegurar la validez de los datos y habilitar la sincronización de la cache que la utilización de la expiración de los elementos de la cache frecuentemente. ASP.NET dispone de dos tipos de dependencias construidas sobre la base de CacheDependency: AggregateCacheDependency, qué permite el uso de múltiples dependencias para elementos de cache complejos que dependan de mas de un tipo de recurso, y SqlCacheDependency, que se describe en Invalidación de la Caché SQL.


Volver arriba

#9 - 20/03/2006 11:25:30 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Cacheado por fragmentos de página

Además de poder cachear la salida de una página entera, ASP.NET te proporciona una forma simple de cachear la salida de regiones de contenido de página, a la que se le ha dado el nombre de cacheado por fragmentos. Podemos delimitar áreas de nuestra página mediante un cotnrol de usuario, y marcarlas para que sean cacheadas usando la directiva @OutputCache de la que hemos hablado en la sección anterior. Esta directiva especifica la duración (en segundos) que debe estar cacheado en el servidor el contenido de salida del control de usuario, así como cualquier otra condición opcional por la cual debiera cambiar. Por ejemplo, la siguiente directiva le dice a ASP.NET que meta en la caché de salida al control de usuario durante 120 segundos, y que cambie el caché usando las cadenas de búsqueda "CategoryID" y "SelectedID" o los parámetros de envío del formulario.


  <%@ OutputCache Duration="120" VaryByParam="CategoryID;SelectedID"%>


El atributo VaryByParam es extremadamente potente y permite a los creadores de controles de usuario ordenar a ASP.NET para que almacene en caché múltiples instancias de una región de caché de salida en el servidor. Por ejemplo, las siguientes URLs distinguen entre distintas instancias de contenido del control de usuario del ejemplo anterior.

http://localhost/mypage.aspx?categoryid=foo&selectedid=0
http://localhost/mypage.aspx?categoryid=foo&selectedid=1

Por lo tanto, la lógica dentro de un control de usuario puede generar dinámicamente contenido diferente (que se cachea por separado) dependiendo de los argumentos que reciba. Además de permitir el atributo VaryByParam, el cacheado por fragmentos también permite un atributo VaryByControl. Mientras que el atributo VaryByParam cambia los resultados cacheados basándose en pares nombre-valor enviados mediante POST o GET, el atributo VaryByControl cambia el fragmento cacheado en base a controles dentro del control de usuario. Por ejemplo:

 
<%@ OutputCache Duration="120" VaryByParam="CategoryID;SelectedID"%>



Tened en cuenta que, como con las páginas con caché de salida, se requiere el uso explícito tanto de VaryByParam como de VaryByControl incluso si no se usa ninguno de los dos. Si el control de usuario contiene un control de lista desplegable llamado Categoría podríamos variar los resultados del control de usuario dependiendo del valor seleccionado dentro de la lista desplegable. El siguiente código de ejemplo muestra cómo meter en caché dos sección de menú de una página mediante un control de usuario declarativo.

<%@ Page Language="C#" %>
<%@ Register TagPrefix="Acme" TagName="Menu" Src="Menu.ascx" %>

<html>
<body>
<table>
<tr>
<td>
<Acme:Menu Category="MenuIzquierdo" runat=server/>
</td>
<td>
<h1>Hola, la hora actual es: <%=DateTime.Now%> </h1>
</td>
<td>
<Acme:Menu Category="MenuDerecho" runat=server/>
</td>
<tr>
</table>
</body>
</html>
C#

El siguiente ejemplo demuestra la implementación del control de usuario "Acme:Menu" con soporte para caché.

<%@ Control Language="C#" ClassName="AcmeMenu" %>
<%@ OutputCache Duration="120" VaryByParam="none" %>

<script runat=server>

public String Category;

void Page_Load(Object sender, EventArgs e) {

AdoConnection conn = new AdoConnection("MyDSN");

MyMenu.DataSource = conn.Execute("select * from menu where category=" + Category );
MyMenu.DataBind();
}

</script>

<asp:datagrid id="MyMenu" runat=server/>
C#

Tened en cuenta que este ejemplo mete en la caché de salida la respuesta de cada control de usuario durante un periodo de 120 segundos. Toda la lógica necesaria para recrear cada control de usuario de tipo menú en caso de producirse un fallo en la caché (sea porque han pasado los 120 segundos o porque la memoria en el servidor se ha quedado corta) se ha encapsulado limpiamente dentro del control de usuario.

El siguiente ejemplo demuestra un cacheado de fragmentos simple. El ejemplo cachea la salida de un control que recupera datos desde una base de datos SQL Server, mientras que mantiene las propiedades dinámicas de la página padre. Se puede ver que la página es dinámica porque la hora se actualiza con cada refresco, mientras que el control de usuario sólo se actualiza cada 60 segundos.

Caché por fragmentos en C#


Nota: Cualquier intento de manipular mediante programación un control con la salida cacheada desde su página contenedora dará como resultado un error. Por ejemplo, intentar usar una expresión de enlace de datos declarativa en el control de usuario genera errores de parser, como vemos en el siguiente código.

<!-- Las siguientes etiquetas generan errores de parser -->

<Acme:Menu Categoria='<%# Container.DataItem("Categoria")' runat="server" />


La razón de esto es sencilla. En aquellos casos en los que el contenido de un control de usuario tenga su salida cacheada, se crea una instancia del control sólo en la primera petición que se le hace; de esa manera, una vez en la caché, el control ya no está disponible. En lugar de ello, deberíamos encapsular toda la lógica necesaria para crear el contenido de un control de usuario directamente dentro del mismo control; normalmente dentro de los eventos Page_Load o Page_PreRender del control de usuario.

Se pueden declarar y usar otros parámetros de propiedades declarativas al personalizar el control. Por ejemplo, podríamos personalizar el anterior control de usuario de la siguiente manera:

<Acme:Menu Categoria="MenuIzquierdo" runat="server"/>

<Acme:Menu Categoria="MenuDerecho" runat="server" />

Estas declaraciones hacen que el compilador de la página genere y ejecute el código apropiado en caso de que se haya creado al control como resultado de un fallo de caché. Así, los desarrolladores del control de usuario pueden acceder a estas propiedades tal y como lo harían con un control de usuario no cacheado.

API de cacheado de fragmentos Nuevo en 2.0

Además de usar la directiva @OutputCache, podemos ajustar mediante programación las opciones de caché para controles de usuario usando la CacheAPI. En el siguiente ejemplo, el control cambia el tiempo que permanece en caché basándose en el estado que se seleccione del control de lista desplegable. Puedes ver la hora a la que se dibujó el control y la hora a la que se limpiará la entrada de caché.

API de Caché por Fragmentos en C#

Volver arriba

#10 - 20/03/2006 11:25:18 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Cacheado de la página de salida

El cacheado de salida es una potente técnica que incrementa la respuesta de las peticiones y respuestas metiendo en la caché el contenido generado por páginas dinámicas. El cacheado de salida está habilitado por defecto, pero el resultado de una respuesta determinada no se cachea a menos que se especifique esa respuesta como cacheable.

Para hacer que sea posible cachear una respuesta, debe tener una política válida de caducidad o validación y visibilidad pública de su caché. Podemos hacer esto o bien usando la API de bajo nivel OutputCache o la directiva de alto nivel @OutputCache. Cuando se habilita el caché de salida, se crea una entrada de caché de salida en la primera petición GET a la página. Todas las peticiones GET o HEAD posteriores se sirven desde la caché de salida hasta que la petición cacheada caduca. La caché de salida también permite variaciones de pares nombre/valor GET o POST cacheados.

La caché de salida respeta las políticas de caducidad y validación de las páginas. Si una página está en el caché de salida y ha sido marcado con una política de caducidad que indica que la pagina caduca a los 60 minutos de haber sido cacheada, se quita a la página del caché de salida a los 60 minutos. Si se recibe otra petición después de ese intervalo, el código de la página se ejecuta y la página puede ser cacheada de nuevo. Se llama caducidad absoluta a este tipo de política de caducidad - una página es válida durante cierto tiempo.

La Directiva de caché de salida

El siguiente ejemplo demuestra una forma simple de cachear respuestas de salida mediante la directiva @OutputCache. Este ejemplo simplemente muestra la hora a la que se generó la respuesta. Para ver el cacheado de salida en acción, cargad la página y observa la hora a la que se generó la respuesta. Entonces refrescad la página y observad que la hora no ha cambiado, lo que indica que se está sirviendo la segunda respuesta desde el caché de salida.

Caché de salida en C#

La siguiente directiva activa el caché de salida en la respuesta:

 <%@ OutputCache Duration="60" VaryByParam="none"%>

Esta directiva indica sencillamente que la página debe cachearse durante 60 segundos y que la página no variará por ningún parámetro GET o POST. Las peticiones que se reciban mientras la página esté en la caché serán respondidas desde la caché. Después de 60 segundos, se quita a la página de la caché; se maneja la siguiente petición de forma explícita y se vuelve a cachear la página.

Por supuesto, en el ejemplo anterior se ahorra muy poco trabajo mediante el cacheado de salida. El siguiente ejemplo demuestra la misma técnica de cacheado de salida, pero realizando una llamada a una base de datos y mostrando los resultados en una tabla.

Caché de salida en C# 2

Cambiar mediante parámetros

En este ejemplo modificamos ligeramente la aplicación para permitir al usuario que busque de forma selectiva autores en varios estados. El ejemplo muestra el cacheado de peticiones que cambien los pares nombre/valor de la cadena de consulta usando el atributo VaryByParam de la directiva OutputCache.

<%@ OutputCache Duration="60" VaryByParam="state" %>

Por cada estado en el conjunto de datos, hay un vínculo que pasa el estado deseado como parte de la cadena de consulta. Entonces la aplicación construye la consulta apropiada a la base de datos y muestra sólo aquellos autores que pertenezcan al estado seleccionado.

Observa que la primera vez que hacemos clic en el vínculo de un estado determinado se genera una nueva etiqueta de fecha en la parte inferior de la página. A partir de ahí, cada vez que se vuelva a introducir una búsqueda por ese estado en el espacio de un minuto, la etiqueta muestra la fecha y hora a la que se cacheó la petición original.

Cacheado de salida VaryByParam en C#



Notificación de Caché SQL nuevo en 2.0

En el ejemplo anterior los datos se cacheaban durante 60 segundos, sin importar si los datos habían cambiado en la base de datos. La invalidación de caché SQL te permite hacer que la caché de entrada dependa de la base de datos, de tal manera que el caché de entrada solamente se limpiará cuando los datos en la base de datos hayan cambiado. Para más detalles, ver la página Notificación de Caché SQL.


Sustitución post-caché nuevo en 2.0

En ASP.NET 1.0, las páginas que eran estáticas en su mayor parte pero que contenían una pequeña región dinámica, como el nombre de usuario o la hora actual, eran forzadas con frecuencia a no usar cacheado o a dividir la página en múltiples controles de usuario cacheados con caché de fragmentos. ASP.NET 2.0 permite que estas páginas se aprovechen del cacheado de salida, permitiendo que las páginas de salida cacheadas puedan insertar nuevo contenido dinámico en cada solicitud.

En el siguiente ejemplo, la página con salida cacheada inserta una llamada dinámica a un método estático que devuelve la fecha actual mediante la API Response.WriteSubstitution. Esta llamada dinámica se ejecuta en cada solicitud, y el resultado se inserta en la cadena de caché de respuesta que se sirve desde el caché de salida.

Sustitución Post-caché, C#

El siguiente ejemplo realiza la misma acción que el anterior, pero usa un control asp:Substitution para insertar el contenido dinámico.

Control de Sustitución en C#


Usando el API de Caché

Aquellas aplicaciones que necesiten más control sobre los encabezados HTTP relacionados con el caché pueden usar la funcionalidad proporcionada por la clase System.Web.HttpCachePolicy. El siguiente ejemplo muestra el código equivalente a las directivas de página de ejemplos anteriores:

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);

C#

Podemos convertirla en una política de caducidad deslizante, haciendo que la hora de caducidad se vuelva a establecer cada vez que se hace una petición a la página, estableciendo la propiedad SlidingExpiration como en el siguiente ejemplo.

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetSlidingExpiration(true);
C#

Nota: Cuando se habilita la caducidad deslizante (SetSlidingExpiration(true) ), cada petición hecha al servidor de origen siempre genera una respuesta. La caché deslizante es útil en escenarios donde existen cachés hacia el cliente que pueden satisfacer peticiones de cliente, si el contenido no ha caducado aún, sin solicitar el contenido del servidor de origen.


Volver arriba

#11 - 20/03/2006 11:25:00 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Eliminando un Perfil

Con el paso del tiempo, la cantidad de datos de perfil de un sitio crecerá, especialmente para sitios que utilizan perfiles anónimos. La clase ProfileManager proporciona un número de métodos para eliminar los datos de Perfiles. El ejemplo muestra el uso de ProfileManager.DeleteProfile para eliminar el perfil del usuario que ha iniciado sesión. Para ejecutar el ejemplo, tenemos primero que iniciar sesión. Una ves lo hemos hecho, pordemos hacer clic en el botón para eliminar los datos del perfil. A continuación seremos redirigidos a la página de propiedades del perfil. Observad que, en este momento, todos los datos del anterior perfil se han borrado y necesitamos volver a introducir lo nuevos datos del perfil en el formulario.

En entornos de producción, normalmente utilizaremos ProfileManager en una tarea programada de manteniemito. Por ejemplo, podemos crear una tarea diaria que ejecute una aplicación de consola que utilice ProfileManager para eliminar los perfiles que han estado inactivos durante más de treinta días. Como la característica Perfil es soportada en entornos no-ASP.NET (por ejemplo aplicaciones de consola o servicios de aplicaciones NT), podemos crar operaciones orientadas a aplicaciones mediante la clase ProfileManager.

C# Eliminando un Perfil

Volver arriba

#12 - 20/03/2006 11:24:47 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Automatic Profile Save Behavior

La función Perfil determinará de forma automática si un Perfil está sucio. Si el Perfil parece estar sucio, el ProfileModule, que se ejecuta al final de cada petición de una página, llamará al método Save del Perfil, guardando así los datos mediante el(los) proveedore(s) configurados. Sin embargo, la función Perfil solo puede detectar de forma segura los cambios en los datos cuando los datos se escriben como un System.String o un tipo primitivo, como System.Int16, System.Int32, etc. Si un Perfil contiene tipos de datos más compejos, el comportamiento por defecto del Perfil es asumir que el Perfil está sucio y siempre intentará salvar los datos. Para optimizar el rendimiento, un desarrollados puede implementar lógica en sus páginas para determinar si el Perfil está realmente sucio. Si un desarrollador determina que el Perfil no ha cambiado, puede enganchar el evento ProfileAutoSaving escribiendo un manejador de eventos en global.asax. El argumento del evento incluye una propiedad llamada ContinueWithProfileAutoSave. Si el desarrollador establece dicha propiedad a false, el ProfileModule no intentará salvar el Perfil.

Ejecutamos el ejemplo, iniciando sesión de nuevo si es necesario. Esta página es la misma que la utilizada antes para mostrar las propiedades de los perfiles, pero se le ha añadido un segundo botón. Si editamos alguno de los datos del perfil y luego hacemos clic en el botón que cancela la función de salvado automático, cuando la página se recarga, los antiguos valores de la propiedad se mostrarán. El código ejemplo muestra como subscribir el evento
ProfileAutoSaving en el fichero global.asax y cancelar el guardado si una propiedad se ha fijado en el grupo HttpContext.Items. El manejador del evento clic del botón de la página establece este ítem para indicar que el comportamiento de guardado automático debe cancelarse.

Observad que si el desarrollador no quiere que el
ProfileModule intente guardar, el comportamiento de guardado automático se puede cancelar estableciendo el atributo de elemento automaticSaveEnabled dentro de <profile> a false.

C# Controlando el Guardado Automático del Perfil


Volver arriba

#13 - 20/03/2006 11:24:34 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Definiendo las Propiedades del Perfil con una Classe Base Personalizada

El web.config mostrado antes incluía un atributo llamado inherits en el elementeo <profile>. Este atributo instruye a ASP.NET a autogenerar una clase para la propiedad Profile herendando de una clase personalizada. En este ejemplo, el nombre de la clase es UserDefinedProfileClass y se encuentra en el directorio App_Code. La clase personalizada hereda de ProfileBase porque la clase autogenerada para la propiedad Profile debe tener siempre ProfileBase en la jerarquía de herencia. Cualquier propiedad pública definida en una clase base personalizada es visible y utilizable desde la propiedad Profile.

Ejecutamos el ejemplo e iniciamos sesión. En la página de propiedades, los datos del listbox ,que contienen las preferencias de comida basura, se almacenan mediante la propiedad definida en la clase base personalizada. De la misma forma que con otras propiedades del Perfil, las preferencias de comida se acceden mediante la sintaxis estándar de una propiedad:
Profile.JunkFood.

La ventaja de definir una clase base personalizada reside en que los desarrolladores pueden "interceptar" los sets y gets de las propiedades e implementar una lógica de negocio compleja en los métodos get y set de las propiedades. En el código del ejemplo, la clase base personalizada define una propiedad utilizando Generics. La definición de la propiedad muestra los requerimientos mínimos: la implementación de la propiedad debe llamar a la clase base, ya que ésta clase
(ProfileBase) es la que contiene la lógica para serializar los datos, así como para comunicarse con el/los proveedor/es subyacentes.

Esquema de perfil en web.config

C# Utilizando una Clase Base Personalizada


Volver arriba

#14 - 20/03/2006 11:24:21 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Migrando Perfiles Anónimos a Perfiles Autenticados

En Ejemplos anteriores quedó demostrado que el color de fondo para un usuario anónimo era pasado al usuario autenticado. Podemos verificar esto ejecutando el ejemplo de abajo. Si ya nos hemos autenticado, hacemos click en el vínculo de Logout al final de la página. En la página de inicio, seleccionamos un color diferente del dropdown en la esquina superior izquierda de la página. La página de inicio se refrescara y se mostrará usando el color de fondo seleccionado. Además, la página tendrá un texto diciendo "Hello Anonymous User" porque la propiedad name en el Profile es solo soportada por usuarios autenticados. Autentiquémonos en el sitio usando el control login de la página de inicio. Notamos como una vez nos autenticamos, el color de fondo de la página del perfil refleja la selección que se hizo previamente como un usuario anónimo.

En la página de propiedades del perfil, hacemos clic en el link que nos lleva de vuelta a la página de inicio. Observad que en la página de inicio el nombre que se muestra está basado en el valor establecido para la propiedad Profile.Name. Ahora que estamos de vuelta en la página de inicio como usuarios autentificados, seleccionamos un color diferente de la lista desplegable y hacemos clic en el botón a actualizar. La página se refresca y usa el color de fondo actualizado. Si posteriormente hacemos clic en el link que os lleva de vuelta a la página de propiedades del perfil veremos que el color de fondo se mantiene.

Una vez que estemos de vuelta en la página de propiedades del perfil hacemos clic en el botón de desconexión. Esto nos redirigirá de vuelta a la página de inicio. Daos cuenta que cuando se nos redirige a la página de inicio nuestras selecciones previas para el color de fondo ya no son efectivas. Hay dos razones para esto. Primeramente, una vez que nos hemos desconectado el sitio considera que somos usuarios anónimos y como resultado cualquier color de fondo que hubiera sido seleccionado en el perfil de usuario autentificado no está disponible. En segundo lugar, cualquier selección de color que hubiera sido hecha anteriormente como usuario anónimo ya no está disponible. La razón para esto es que una vez que un usuario anónimo se autentifica, la cookie que contenía el identificador anónimo autogenerado se borra del navegador. Como resultado, cuando nos autentificamos y posteriormente nos volvemos a desconectar el sitio considera que somos usuarios anónimos completamente nuevos. Esta interacción entre usuarios anónimos y usuarios autentificados conduce a la necesidad de migrar datos desde los perfiles anónimos hacia los perfiles autentificados.

La característica de perfil expone un evento llamado MigrateAnonymous. Podemos suscribirnos a este evento colocando un manejador de eventos en global.asax llamado Profile_MigrateAnonymous. Este evento se dispara simpre que un identificador anónimo está disponible (bien como una cookie o bien como un ticket sin cooquies) y el usuario se autentifica. En el manejador de eventos podemos cargar el Perfil del usuario anónimo llamando a Profile.GetProfile y pasándole el ID de usuario anónimo (el ID de usuario anónimo es una de las propiedades disponibles de los argumentos del evento). Una vez que tenéis una referencia al Perfil anónimo podemos transferir las propiedades establecidas desde el Perfil anónimo hacia el Perfil autentificado. El global.asax del ejemplo demuestra la transferencia del color de fondo desde el perfil anónimo al perfil autentificado. El código también elimina el perfil anónimo de la base de datos. Finalmente, el código llama a un método en identificación anónima para eliminar la cookie que contiene el identificador anónimo. Observad que los programadores deben elegir explícitamente eliminar el identificador anónimo en la petición, de otro modo ASP.NET no eliminará automáticamente el identificador. Cuando el evento MigrateAnonimous finalice, ASP.NET habrá expedido una cabecera Http para eliminar el identificador anónimo en el navegador y en la siguiente petición de página el evento no se volverá a disparar

C# Migrando datos de perfil de un usuario anónimo a un usuario autenticado

Volver arriba

#15 - 20/03/2006 11:24:08 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Perfiles autentificados

En este ejemplo entraremos como usuarios autentificados y estableceremos valores para todas las propiedades del perfil. La primera vez que ejecutemos el ejemplo estaremos en una página de inicio accesible tanto para usuarios anónimos como autentificados. Observad que el color de fondo se establece al valor que seleccionamos como usuarios anónimos en el ejemplo anterior. Hacemos click en el enlace que permite crear un usuario nuevo (este enlace está en la parte inferior del control de autentificación). Escribimos un nombre de usuario y una contraseña y hacemos click en el botón para crear un nuevo usuario. Después de crear el nuevo usuario hacemos click en el botón para continuar hacia la página que muestra las propiedades del perfil para usuarios autentificados.

Cuando veamos la página por primera vez con todas las propiedades de vuestro perfil, os veremos que el color de fondo está definido en el color que elegimos como usuarios anónimos en el ejemplo anterior. La razón de esto se explica con mayor detalle en el ejemplo siguiente. Por ahora observad que podemos definir valores para todas las propiedades del perfil. Daos cuenta también que inicialmente el punto del precio del automóvil está establecido a su valor por defecto definido en el esquema del perfil.

Después de introducir los nuevos valores en el formulario HTML, presionaremos el botón "Update preferences" (actualizar preferencias). Ahora haremos click en el botón de cierra de sesión para que se borre la cookie de "Forms Authentication" de nuestra máquina.A continuación cerramos el navegador.Si ahora volvemos a entrar en la página, se nos volverán a pedir las credenciales. Tras introducirlas y iniciar sesión, observad como la página muestra correctamente la información que habíamos introducido. Si hacmos click en el link que nos devuelve a la página de inicio veremos que la página de inicio usa tanto el nombre como el color de fondo que seleccionamos para el usuario autentificado. Esto demuestra como se pueden usar los perfiles entre páginas seguras y no seguras en un sitio. En la página de inicio el color de fondo y el nombre se muestran usando o el Perfil de usuario anónimo (si aún no nos hemos autentificado) o bien el perfil de usuario autentificado (una vez que hemos iniciado sesión).

Como en el ejemplo anónimo, este ejemplo demuestra como la sintaxis del Perfil sigue la sintaxis de acceso a propiedades de VB.NET y C#. Observad que la sintaxis para acceder a propiedades en un grupo de propiedades usa dos niveles de acceso a propiedades: Profile.AutomobilePreferences.PricePoint. El grupo de propiedades simplemente actúa como una propiedad intermedia. El código para manipular Profile.AutomobilePreferences.CarModels muestran el uso de un System.Collections.Arraylist como propiedad de un perfil. La cadena que se escribe en el formulario HTML debe ser un conjunto de nombres delimitado por comas. El código de la página lo convierte en un System.Array de cadenas antes de añadir los valores del array a la propiedad Profile.AutomobilePreferences.CarModels. Cuando obtenemos los modelos de coche, los Profile.AutomobilePreferences.CarModels se enumeran usando para cada uno sintaxis estándar.

C# Almacenando datos de perfiles para usuarios autentificados

Volver arriba

#16 - 20/03/2006 11:23:54 Reporta abuso | Link Permanente
Jau
Fecha de registro: 03/12/2006
1 post en este tema
164 posts en tutoriales asp.net
6 posts en todos los foros
Perfiles anónimos

El esquema de perfil mostrado en el último ejemplo permite tanto a usuarios autentificados como anónimos guardar su color de fondo preferido. En la página de ejemplo un usuario anónimo puede elegir desde una selección de colores. Cuando la página se refresca lo hará usando el color seleccionado. Daos cuenta que si cerráis el navegador, y volvéis a ejecutar el ejemplo se recuerda la selección de color. La razón para esto es que la característica Identificación de Anónimos (Anonymous Identification) se ha habilitado para todos los ejemplos (por defecto la Identificación de Anónimos está deshabilitada). La característica Identificación de Anónimos genera automáticamente un identificador aleatorio para un usuario anónimo y lo almacena en una cookie. En las siguientes visitas al sitio se usa el identificador de la cookie como "id" sustituto cuando se recupera la información de perfil para un usuario anónimo.

En la página de ejemplo, podemos recuperar o definir el color de fondo usando la sintaxis Profile.PreferredBackgroundColor. El estilo de código para usar una propiedad Profile es el mismo que para acceder a propiedades en cualquier otra clase. En este ejemplo la página usa alguna conversión común disponible en la estructura System.Drawing.Color para recuperar o definir Profile.PreferredBackgroundColor.

C# Almacenando datos de perfil para usuarios anónimos


Volver arriba
Mostrar de en 15 Ir a página Siguientes >>