Recomendado: ASP: Determine si el acceso proviene de un motor de búsqueda Para determinar si el acceso proviene de las funciones del motor de búsqueda, si está interesado, ¡puede probarlo! El siguiente es el contenido referenciado: <%'verifique si el usuario actual es una comprobación de funciones de Spider-Man (user_agent) LETS_AGE
Capítulo 10 ASP y datos del cliente¿Se discuten los datos del cliente en una monografía ASP? ¿Es esto contradictorio con la programación ASP del lado del servidor? Este no es el caso, porque aún no hemos conocido a un programador ASP que solo trabaje en la programación del lado del servidor. Aunque ASP es una tecnología del lado del servidor, es concebible que sea imposible que los programadores programen usando ASP solo. Los desarrolladores web que participan en la programación ASP aún deben interactuar con los datos del cliente.
Por lo tanto, al construir una aplicación alrededor de ASP, se debe considerar toda la situación de la aplicación, lo que también significa que el cliente debe ser considerado. Para obtener una aplicación bien administrada y de respuesta rápida, debe usar bien los datos del cliente.
Este capítulo analiza cómo usar datos en el lado del cliente. El enfoque especial estará en la investigación:
· Servicios de datos remotos (RDS), cómo transmitir datos a los clientes y recibir datos.
· Cómo unir un registro ADO establecido en un control HTML.
· Cómo usar componentes definidos por el usuario para proporcionar datos.
· Cómo actualizar los datos del cliente y volver a alimentarlo al servidor.
· Cómo obtener una imagen de una base de datos y mostrarla en una página web.
· Cómo crear una página web basada en la tabla.
La cobertura anterior es bastante amplia, y hay muchos métodos diferentes para lograr los mismos resultados, pero no es particularmente difícil de implementar.
10.1 Conjunto de registros desconectado
Lo primero que debe dominar es el concepto de datos desconectados. Hasta ahora, en el proceso de estudio de ADO, se han aprendido los métodos para obtener conjuntos de registros y cómo modificar los datos en estos conjuntos de registros. Para revisar, abrimos un conjunto de registros, hacemos algunas modificaciones a los datos y luego cerramos este conjunto de registros. Durante el proceso de operación del conjunto de registros, siempre mantenemos una conexión con el servidor. Esto es bastante obvio, pero no olvide que la web es de naturaleza sin estado. Si desea usar datos del cliente, ¿cómo mantiene siempre una conexión con el servidor? Es simple, esto es imposible, y es por eso que define el concepto de un conjunto de registros desconectado.
Un conjunto de registros desconectado es solo un conjunto de registros normal, pero no está conectado al servidor y se convierte en un objeto aislado. Se puede actualizar, agregar y eliminar como un conjunto de registros normal. Pero estos cambios solo ocurren dentro del conjunto de registros y no se vuelven al servidor, porque el conjunto de registros ya no tiene una conexión con el servidor. Esto no es una desventaja, ya que la conexión se puede restablecer con el servidor, mientras que el servidor puede actualizar cualquier modificación. Incluso si los datos del lado del servidor han cambiado, ADO todavía tiene formas de que los usuarios descubran estos cambios de manera oportuna para que los usuarios puedan decidir qué datos son correctos. Esto se llama resolución de conflictos.
Los registros desconectados nos permiten entregar registros con funcionalidad completa entre componentes, incluso entre servidores y clientes. Este capítulo explorará cómo crear un conjunto de registros desconectado dentro de un componente. Sin embargo, no planeamos hacer una investigación demasiado detallada sobre esto, porque los capítulos 13 a 18 de este libro han cubierto esta parte del contenido. Aquí solo daremos una breve introducción a cómo interactúan los componentes con los servicios de datos remotos.
10.2 Servicio de datos remotos
Remote Data Services (RDS) es un término general para una serie de servicios que nos permiten procesar los datos del cliente. No hay necesidad de preocuparse por este problema ahora, porque RDS en sí es parte de ADO y solo se usará cuando los datos del cliente deben transmitirse y usarse. De hecho, RDS está compuesto por varios componentes. La Figura 10-1 ilustra estos componentes y cómo funcionan juntos.
Figura 10-1 Composición de componente de RDS
Parece que hay muchos componentes, pero no todos se usan en todos los casos, y en realidad hay algunos que no son parte de RDS. Sin embargo, todos los componentes posibles se colocan en el diagrama aquí en caso de que lo necesite. La Figura 10-1 se divide en dos partes, porque el uso de datos del cliente requiere algunos métodos para transmitir datos al cliente. Al mismo tiempo, una vez que los datos llegan al cliente, también se requieren algunos métodos para administrar datos. Comencemos con el lado del servidor.
10.2.1 Componentes del servidor RDS
Si bien RDS se usa para transferir y acceder a los datos del cliente, tiene algunos componentes basados en servidor. Esto es necesario porque ciertamente existe la necesidad de alguna forma de transferir los datos al cliente. Por lo tanto, hay una serie de componentes del servidor que pueden acceder a los datos y permitir que los datos se envíen al cliente. Llamamos al mariscal de transmisión de datos real.
El extremo superior del diagrama de componentes del lado del servidor es el almacenamiento de datos, accedido por el proveedor de OLE DB. No es parte de RDS, pero esto significa que cualquier dato puede usarse en el cliente a través de RDS siempre que haya un proveedor OLE DB correspondiente. En cuanto a cómo procesar datos en el servidor, hay dos opciones:
· DataFactory es el componente predeterminado del lado del servidor para acceder al almacenamiento de datos. Se instala en la computadora como parte del componente RDS del lado del servidor. Además de obtener datos del almacenamiento de datos, también procesa los datos enviados hacia y desde el cliente para el servidor.
· Los componentes personalizados son solo componentes comunes comunes que proporcionan métodos de transferencia de datos. Los componentes personalizados se pueden usar cuando la fábrica de datos no puede proporcionar la funcionalidad requerida. Este capítulo presenta un ejemplo de componente simple, y hay un ejemplo más complejo más adelante en el libro.
Los servidores web usan estos dos componentes como interfaces para los datos del cliente y del servidor.
10.2.2 Componentes del cliente RDS
El cliente comienza con el objeto DataSpace en la parte inferior, que funciona junto con la fábrica de datos o los objetos personalizados como parte del cliente. El objeto DataSpace es un objeto proxy responsable de comunicarse con el servidor y también es un canal para la transmisión de datos (o comúnmente conocido como programación). Los objetos DataSpace son objetos COM creados en el lenguaje de secuencias de comandos del cliente o en etiquetas HTML. Verá ejemplos sobre esto más adelante en este capítulo.
Un objeto DataSpace es un objeto de fuente de datos (DSO) responsable de almacenar datos del cliente. Un objeto de origen de datos contiene un conjunto de registros de datos ADO que administra datos junto con el caché de datos del cliente. El almacenamiento en caché de datos del cliente es solo un servicio de cursor del cliente que administra los datos del cliente. Al mismo tiempo, el objeto de origen de datos es un objeto COM, similar al objeto DataSpace, y también se puede crear a través de scripts del cliente o utilizando la etiqueta <ject> en el idioma HTML. Del mismo modo, algunos ejemplos de este aspecto se introducirán más adelante en este capítulo.
Arriba, el objeto de origen de datos está el administrador de enlace de datos, y la tarea es establecer una conexión entre los controles HTML y los objetos de fuente de datos. Esto es lo que sabemos sobre la vinculación, que se puede lograr estableciendo las propiedades de DataSRC y DataFld de ciertos controles HTML. Estos se discuten a continuación y demuestran cómo usar datos fácilmente en el navegador.
10.2.3 navegadores que admiten RDS
Debe saber que RDS es la tecnología de Microsoft, por lo que solo puede funcionar en el navegador de Microsoft. De hecho, RDS solo es totalmente compatible en navegadores con IE 4.0 o superior.
Al escribir aplicaciones que dependen de RDS, es importante tener en cuenta que la versión RDS del cliente que accede a la aplicación puede ser diferente del lado del servidor. Por ejemplo, RDS 1.5 está en IE 4, mientras que RDS 2.0 está en IE 5, Office 2000 y Visual Studio 6. Hay dos formas de lidiar con este problema de compatibilidad:
· Asegúrese de que todos los usuarios hayan actualizado a la última versión de RDS. Si el cliente ejecuta Windows 2000, entonces la última versión de RDS ya se está ejecutando. De lo contrario, puede descargarlo de la URL www.microsoft.com/data. RDS 2.5 es actualmente la última versión lanzada con Windows 2000, y también es un paquete de software que se puede descargar por separado.
· Especifique el modo de la fábrica de datos cuando está conectado a una fuente de datos. Esto puede especificar qué versión del componente RDS se utiliza, y un ejemplo de esto se introducirá más adelante.
10.2.4 Objeto de origen de datos
Un objeto de origen de datos es un objeto cliente que almacena y administra los datos del cliente. Debido a que esta es la forma más fácil de usar RDS, primero mire estos objetos.
Aquí hay varios objetos de fuente de datos diferentes, cada uno para diferentes tipos de datos:
· Control de datos tabulares (TDC), utilizado para procesar archivos de texto en tabla o forma separada.
· El control de datos RDS, utilizado para conectarse a los almacenes de datos de OLE DB, puede especificar a qué almacén de datos conectarse y a qué datos se devuelven.
· Conector de base de datos Java, un applet Java conectado al almacenamiento de datos a través de Java Database Control (JDBC). No queremos discutir JDBC aquí, porque no proporciona funcionalidad que otros controles no puedan lograr.
· Los datos de objeto de origen de datos HTML (MSHTML) de Microsoft con HTML y los usan como fuente de datos.
· Los objetos de origen de datos XML usan datos XML, utilizados para XML estructurado o arbitrario estructurado.
El objeto de origen de datos para elegir depende de lo que desee hacer y de dónde provienen los datos. Si se requiere una pequeña cantidad de datos al cliente y el usuario no permite que el usuario modifique los datos, entonces un control de datos de tabla (TDC) puede ser más adecuado. Esta fuente de datos es un archivo de texto que no requiere ninguna base de datos, por lo que es relativamente simple de editar. Los controles de datos RDS son los más adecuados para situaciones en las que los datos se obtienen de la base de datos y pueden requerir actualizaciones. Para muchas fuentes de datos nuevas, encontrará que se necesitan controles de datos XML en este momento. Esto en realidad depende del tipo de aplicación web utilizada y de la funcionalidad requerida por el usuario.
Introduciremos estos controles de datos a su vez, y una vez que comprendamos cómo usarlos para transferir datos al cliente, presentaremos cómo usarlos.
Compartir: programación avanzada ASP 3.0 (35) 7.5.1 Técnicas generales de depuración En el Capítulo 2, hemos visto cómo usar el método Response.Write y la colección de solicitudes para mostrar el contenido de la colección. Si el código quiere usar el valor de la solicitud, lo primero que debe hacer es asegurarse de que exista el valor requerido. El problema que es fácil de ocurrir es incorrecto o