ES2280283T3 - Objetos de control del lado del servidor para el procesamiento de elementos de la interfaz de usuario del lado del cliente. - Google Patents

Abstract

Un método para el procesamiento del lado del servidor de al menos un elemento de interfaz de usuario del lado del cliente (106, 108, 110) incorporado en una página web (104) visualizada en un cliente (100), comprendiendo el método: lectura (203) de una declaración de un recurso (310, 400); generación (204) de una pluralidad de objetos de control del lado del servidor existentes de manera simultánea (318, 320, 322) que se corresponden de manera lógica con el elemento de la interfaz de usuario del lado del cliente, basada en la declaración; procesamiento (206) de eventos del elemento de la interfaz de usuario del lado del cliente usando los objetos de control del lado del servidor existentes de manera simultánea; y generación (208) de datos de lenguaje de creación a partir de los objetos de control del lado del servidor existentes de manera simultánea para incorporar el elemento de la interfaz de usuario del lado del cliente en la página web, con posterioridad a la operación de procesamiento.

Description

Objetos de control del lado del servidor para el procesamiento de elementos de la interfaz de usuario del lado del cliente.

Campo técnico

La invención se refiere en general a una estructura de servidor web y, más en particular, a objetos de control del lado del servidor que procesan elementos de interfaz de usuario del lado del cliente de una página web.

Antecedentes de la invención

Un navegador web típico recibe datos desde un servidor web que define la apariencia y el comportamiento elemental de una página web para la visualización en un sistema de cliente. En un escenario típico, un usuario especifica un localizador uniforme de recursos ("URL"), una dirección global de un recurso de la Red Mundial, para acceder a un sitio web deseado. Por lo general, el término "recurso" se refiere a datos o rutinas a los que se puede acceder mediante un programa. Un ejemplo de URL es "http://www.microsoft.com/ms.htm". La primera parte del ejemplo de URL indica un protocolo dado (es decir, "http") para ser usado en la comunicación. La segunda parte especifica el nombre de dominio (es decir,"www.microsoft.com") donde está ubicado el recurso. La tercera parte especifica el recurso (es decir, un fichero llamado "ms.htm") dentro del dominio. De forma correspondiente, un navegador genera una petición HTTP (protocolo de transporte de hipertexto) asociada al ejemplo de URL para obtener los datos asociados al fichero ms.htm dentro del dominio www.microsoft.com. Un servidor web que aloje el sitio www.microsoft.com recibe la petición HTTP y devuelve el recurso o página web solicitada en una respuesta HTTP al sistema de cliente para la visualización en el navegador.

El fichero "ms.htm" del ejemplo de arriba incluye código HTML estático (lenguaje de marcado de hipertexto). EL HTML es un lenguaje de creación de texto plano usado para crear documentos (por ejemplo, páginas web) en la Red Mundial. Como tal, un fichero HTLM puede ser recuperado desde un servidor web y visualizado como página web en un navegador para presentar la rica experiencia gráfica que los usuarios vienen a esperar mientras ven información de Internet. Usando HTML, un desarrollador puede, por ejemplo, especificar texto formateado, listas, formularios, tablas, enlaces de hipertexto, imágenes y sonidos incorporados, y gráficos de fondo para la visualización en el navegador. No obstante, un fichero HTML, es un fichero estático que no soporta inherentemente la generación dinámica de contenido de página web.

En algunas circunstancias, una página web puede necesitar visualizar contenido dinámico en un navegador, tal como un precio de productos cambiante o información de tráfico. En tales situaciones, un programa de aplicación del lado del servidor es desarrollado normalmente para obtener los datos dinámicos y formatearlos en HTML que es enviado al navegador para la visualización en una página web cuando la página web es actualizada.

De forma adicional, estos mismos programas de aplicaciones del lado del servidor pueden ser usados en situaciones donde los datos no son estrictamente dinámicos pero donde hay tantos valores diferentes que pueden ser visualizados en una página web estática que sería poco viable crear el número requerido de páginas web estáticas. Por ejemplo, una página de planificación de viajes puede visualizar dos calendarios: un calendario para la fecha de salida y un calendario para la fecha de regreso. Más que desarrollar cientos de páginas estáticas con cada posible par de combinaciones de calendarios, un programa de aplicación del lado del servidor puede generar de manera dinámica la página estática apropiada con los calendarios apropiados visualizados.

Muchas páginas web permiten que el usuario interactúe con la página visualizada en el navegador mediante la selección de elementos visuales de la página. Por ejemplo, en la página de planificación de viajes mencionada arriba, el calendario puede permitir al usuario interactuar con ella, haciendo clic sobre un día para seleccionar esa fecha, o haciendo clic sobre un icono para ir un mes hacia delante o hacia detrás. En las soluciones existentes, un navegador presentará una petición HTTP de vuelta al programa de aplicación del lado del servidor. La petición HTTP puede incluir parámetros codificados en la secuencia de consultas, como variables de correo de forma, o algún otro formato de datos para describir eventos o datos del lado del cliente (por ejemplo, sobre cuyo control hizo clic el usuario). Por ejemplo, los parámetros pueden incluir los datos que el usuario seleccionó en un calendario, junto con la fecha visualizada actualmente en el otro calendario.

La comunicación de eventos y datos de vuelta al servidor se llama un "post back", puesto que el navegador envía normalmente la petición usando una petición HTTP POST. El programa de aplicación del lado del servidor puede procesar la petición HTTP y generar el código HTLM apropiado para página web con un calendario calculado recientemente para reflejar la acción del usuario para la transmisión al cliente en una respuesta HTTP. Después de esto, el documento resultante es transmitido a un sistema de cliente en una respuesta HTTP, donde es visualizado en el navegador como una página web que muestra los calendarios actualizados.

El desarrollo de un programa de aplicación del lado del servidor puede ser una tarea compleja que requiera no sólo la familiaridad con la codificación HTML normal que se usa para configurar una página web, sino además con las nociones elementales de programación, incluidos uno o más lenguajes de programación (por ejemplo, C++, Perl, Visual Basic, or Jscript), y el protocolo HTTP, incluido cómo los datos son enviados entre el navegador y el servidor. Los diseñadores de páginas web, por otra parte, son frecuentemente diseñadores gráficos y editores, quienes pueden carecer de experiencia en programación. Asimismo, la simplificación del complejo desarrollo de una página web puede acelerar el desarrollo de nuevo contenido web mediante cualquier desarrollador.

Por lo general, el desarrollo de un programa de aplicación del lado del servidor habitual también requiere un gran esfuerzo, tanto, de hecho, que los desarrolladores son frecuentemente reacios a intentarlo. El desarrollador no sólo debe entender el código HTML que debe ser generado para visualizar una página web deseada, sino que el desarrollador debe entender cómo la interacción del usuario y los datos del cliente de la página web tendrán como resultado operaciones de post back. En consecuencia, es deseable proporcionar una estructura de desarrollo que permita a un desarrollador crear y procesar dinámicamente una página web con la programación mínima.

Un enfoque para minimizar los requisitos de programación de generación de páginas web dinámicas ha sido la estructura de página de servidor activo (ASP), proporcionada por Microsoft Corporation. Un recurso ASP incluye normalmente código Visual Basic o Jscript, por ejemplo, para procesar una petición HTTP que especifique el recurso ASP como el recurso deseado y, tras ello, para generar el código HTML resultante en una respuesta HTTP al cliente. Asimismo, un recurso ASP puede hacer referencia a componentes de biblioteca del lado del cliente de terceras partes o predesarrollados (por ejemplo, controles ACTIVEX del lado del cliente) para facilitar un esfuerzo de una programación de aplicación dada. Sin embargo, en las estructuras actuales de aplicación del lado del servidor, la programación requerida para gestionar de manera dinámica los elementos de interfaz de usuario del lado del cliente (por ejemplo, cuadros de texto, cuadros de lista, botones, enlaces de hipertexto, imágenes, sonidos, etc.) dentro de las aplicaciones del lado del servidor todavía pueden requerir capacidades de programación sofisticadas y un esfuerzo considerable. Existe un problema sin respuesta en el encapsulamiento adecuado de la programación requerida para procesar elementos de interfaz de usuario, incluido el manejo de eventos de postback, de manera que se permita al desarrollador de páginas web centrarse en otros aspectos de la página web.

Más información perteneciente a la técnica anterior se puede encontrar en la patente estadounidense 5.991.802 que expone un método y sistema para invocar mediante un sistema informático del cliente una función de un objeto de una clase de objetos proporcionada por un sistema informático del servidor. El cliente envía una petición a un servidor que comprende un localizador universal de recursos ("URL") que identifica un script, una clase de objetos, y una función de la clase de objetos que han de invocarse. En respuesta a la recepción de la petición, el servidor comienza el script y transfiere control al script. El script instancia un objeto de la clase de objetos identificada en el URL de la petición recibida e invoca la función identificada en el URL de la petición recibida. La función invocada lleva a cabo el comportamiento de la función, crea una respuesta que ha de ser enviada al cliente, y envía la respuesta al cliente. La respuesta contiene información del estado describiendo un estado del objeto después de que se realice el comportamiento de la función. Cuando el cliente envía posteriormente una petición para invocar una función de la clase de objetos, la información del estado se incluye en la petición de forma que la función puede realizar su comportamiento basándose en la información del estado.

La WO 98/21651 enseña una máquina de estado de software genérico para implementar una aplicación de software en un entorno orientado al objeto que incluye un conjunto de objetos de entidad definidos para elementos de software de la aplicación de software, un conjunto de objetos de estado definidos para cada representante de objetos de entidad de estados en los que el elemento de software puede introducirse, y un conjunto de objetos de evento definidos para cada representante de objetos de estado de entradas que el elemento de software puede recibir o acciones con las que el elemento de software puede encontrarse mientras está en el estado representado por el objeto de estado. Un método y sistema de construcción de objetos dinámicos para una aplicación de software incluye los pasos de lectura y análisis de un fichero de la configuración principal mediante un objeto maestro, obteniendo un ID de objeto para cada objeto dinámico especificado en el fichero de la configuración principal, creando, mediante un objeto de fábrica, una instancia de cada objeto dinámico especificado en el fichero de la configuración principal y obtiene una dirección física para cada objeto creado, almacenando los ID de objeto y las direcciones físicas de las instancias de objetos creados en un diccionario de objetos, invocando el método de inicio de cada objeto almacenado en el diccionario de objetos, e iniciando cada objeto creado.

La "Chapter 6 Session Management Service", guía de JavaScript del lado del servidor, [en línea]1999, páginas 125-126; XP002193608, recuperado de Internet el 19 de marzo de 2002 del URL: http: //developer.netscape.com/docs/
manuals/ssjs/1_4/ssjs.pdf describe los objetos del servicio de gestión de la sesión disponibles en JavaScript del lado del servidor para compartir datos entre peticiones de cliente múltiples para una aplicación, entre usuarios múltiples de una única aplicación, o incluso entre aplicaciones múltiples en un servidor.

Resumen de la invención

Conforme a la presente invención, el problema de arriba y otros son resueltos mediante la provisión de una estructura de objetos de control del lado del servidor para gestionar el procesamiento y la generación de elementos de interfaz de usuario del lado del cliente. Asimismo, una jerarquía de objetos de control del lado del servidor puede cooperar para generar el código de lenguaje de creación resultante, tal como el estándar HTML, para la visualización de una página web en un cliente. El cliente puede ser, por ejemplo, cualquier navegador que soporte el estándar HTML u otro lenguaje de creación. La operación de procesar el elemento de la interfaz de usuario del lado del cliente puede incluir una o más de una operación de manejo de eventos postback, una operación de manejo de datos postback, una operación de enlace de datos, o una operación de gestión de estado relacionada con el estado de un objeto de control del lado del servidor.

Una gran utilidad de una forma de realización de la presente invención se encuentra en la encapsulación mejorada del procesamiento del lado del servidor de elementos de la interfaz de usuario del lado del cliente (por ejemplo, entrada recibida de elementos de la interfaz de usuario y salida usada para generar elementos de la interfaz de usuario) y la funcionalidad relacionada. Uno o más objetos de control del lado del servidor pueden ser generados para corresponderse de manera lógica con uno o más elementos de la interfaz de usuario. Por ejemplo, dado un elemento de la interfaz de usuario que represente un mes en la visualización de un calendario, se puede generar una jerarquía de objetos de control del lado del servidor correspondiente a la visualización del calendario y sus diversos subelementos. En una configuración, un objeto de control "month" puede contener jerárquicamente múltiples objetos de control "week", donde cada objeto de control "week" contiene jerárquicamente siete objetos de control "day".

Además, en una forma de realización de la presente invención, los objetos de control del lado del servidor pueden cooperar para procesar los elementos de la interfaz de usuario correspondientes de manera lógica. Esta ventaja resulta, en parte, de la existencia concurrente de múltiples objetos de control del lado del servidor durante el procesamiento de una petición del cliente y la generación de una respuesta. Por ejemplo, al detectar un primer evento postback recibido del cliente (por ejemplo, un clic sobre un elemento de botón "next month" en la visualización de un calendario), un objeto de control puede hacer levantar un segundo evento (por ejemplo, la selección del mes siguiente para la visualización mediante el objeto de control "month") que es detectado tras ello y procesado mediante uno o más objetos de control existentes de manera simultánea. Esta cooperación proporciona la encapsulación de la interacción de control complejo dentro de los mismos objetos de control del lado del servidor, minimizando de esta forma el manejo de eventos habitual requerido del desarrollador de páginas web.

Se prevén un método y un producto de programa informático que procesan un elemento de interfaz de usuario del lado del cliente incorporado en una página web visualizada en un cliente. Se recibe una petición que hace referencia a una memoria de datos de declaración del lado del servidor. Una declaración es introducida desde la memoria de datos de la declaración del lado del servidor. Se genera y se programa un objeto de control del lado del servidor para proporcionar la funcionalidad del elemento de interfaz de usuario basándose en la declaración. El elemento de interfaz de usuario es procesado usándose el objeto de control del lado del servidor. Los datos de lenguaje de creación se generan a partir del objeto de control del lado del servidor para visualizar el elemento de interfaz de usuario en la página web.

Se prevé una jerarquía de objetos de control del lado del servidor, ejecutables por un ordenador, para procesar uno o más elementos de interfaz de usuario del lado del cliente incorporados en una página web visualizada en un cliente. Uno o más objetos hijo del lado del servidor se corresponden con el o más elementos de interfaz de usuario del lado del cliente. Cada objeto hijo del lado del servidor trata la entrada recibida del cliente y genera datos de lenguaje de creación para la visualización del elemento de interfaz de usuario del lado del cliente en el cliente. Se recibe al menos un identificador jerárquico del cliente en asociación con la entrada que especifica uno de los objetos hijo del lado del servidor. Un objeto de página del lado del servidor contiene los objetos hijo del lado del servidor y recibe la entrada para la distribución a uno de los objetos hijo del lado del servidor de acuerdo con el identificador jerárquico.

Breve descripción de los dibujos

Fig. 1 ilustra un servidor web para generar de forma dinámica contenido do página web para la visualización en una forma de realización de la presente invención.

Fig. 2 ilustra un diagrama de flujo de operaciones para procesar y renderizar elementos de interfaz de usuario del lado del cliente usando objetos de control del lado del servidor en una forma de realización de la presente invención.

Fig. 3 ilustra módulos de ejemplo en un servidor de web usado en una forma de realización de la presente invención.

Fig. 4 ilustra un ejemplo de recurso de contenido dinámico (por ejemplo, un recurso ASP+) en una forma de realización de la presente invención.

Fig. 5 ilustra un ejemplo de sistema útil para implementar una forma de realización de la presente invención.

Fig. 6 ilustra un diagrama de flujo de proceso que representa el procesamiento de un objeto de página en una forma de realización de la presente invención.

Fig. 7 ilustra un ejemplo de clase Control del lado del servidor en una forma de realización de la presente invención.

Fig. 8 ilustra un ejemplo de clase ContainerControl del lado del servidor en una forma de realización de la presente invención.

Fig. 9 ilustra un ejemplo de clase ControlCollection del lado del servidor en una forma de realización de la presente invención.

Fig. 10 ilustra un ejemplo de clase Page del lado del servidor en una forma de realización de la presente invención.

Descripción detallada de la invención

Una forma de realización de la presente invención incluye un objeto de control del lado del servidor para procesar y generar un elemento de la interfaz de usuario del lado del cliente para la visualización en una página web. Asimismo, una jerarquía de objetos de control del lado del servidor puede cooperar para generar el código del lenguaje de creación resultante, tal como el estándar HTML, para la visualización de una página web en un cliente. El cliente puede ser, por ejemplo, cualquier navegador que soporte HTML estándar u otro lenguaje de creación. En una forma de realización de la presente invención, los objetos de control del lado del servidor se corresponden de forma lógica con elementos de la interfaz de usuario del lado del cliente y generan en un servidor el código del lenguaje de creación que ha de ser usado por el navegador del lado del cliente para visualizar y procesar una página web. La operación de procesamiento del elemento de la interfaz de usuario del lado del cliente puede incluir una o más de una operación de manejo de eventos postback, una operación de manejo de datos postback, una operación de enlace de datos, y un operación de gestión del estado. La operación de gestión del estado se refiere al estado de un objeto de control del lado del servidor.

La figura 1 ilustra un servidor web para generar de forma dinámica contenido de página web para la visualización en un cliente en una forma de realización de la presente invención. Un cliente 100 ejecuta un navegador 102 que visualiza una página web 104 en un dispositivo de visualización del cliente 100. El cliente 100 puede incluir un sistema informático del cliente que tenga un dispositivo de visualización, tal como un monitor de video. Un navegador "INTERNET EXPLORER", comercializado por Microsoft Corporation, es un ejemplo de un navegador 102 en una forma de realización de la presente invención. Otros ejemplos de navegadores incluyen sin limitación "NETSCAPE NAVIGATOR" y "MOSAIC". El ejemplo de página web 104 incorpora un control de cuadro de texto 106 y dos controles de botón 108 y 110. El navegador 102 puede recibir código HTML en la respuesta HTTP 112 desde un servidor web 116 y visualiza la página web como se describe mediante el código HTML. Aunque el HTML es descrito con referencia a una forma de realización, otros lenguajes de creación, incluidos sin limitación el SGML (lenguaje estandarizado de marcado generalizado, el XML (lenguaje extensible de marcado), y el WML (lenguaje de marcado inalámbrico), el cual es un lenguaje de marcado basado en XML, diseñado para especificar el contenido y las interfaces de usuario de dispositivos inalámbricos de banda estrecha, tales como buscapersonas y teléfonos móviles, se consideran dentro del ámbito de la presente invención. Asimismo, aunque aquí es expuesto principalmente el HTML 3.2 estándar, se puede considerar cualquier versión de HTML dentro del ámbito de la presente invención.

Las comunicaciones entre el cliente 100 y el servidor web 116 pueden ser dirigidas usando una secuencia de peticiones HTTP 114 y respuestas HTTP 112. Aunque el HTTP es descrito con referencia a una forma de realización, otros protocolos de transporte, incluido el S-HTTP sin limitarse al mismo, se consideran dentro del ámbito de la presente invención. En el servidor web 116, un módulo del canal de HTTP 118 recibe una petición HTTP 114, resuelve el URL, e invoca un manejador apropiado 120 para el procesamiento de la petición. En una forma de realización de la presente invención, se prevé una pluralidad de manejadores 120 para manejar diferentes tipos de recursos en el servidor web 116.

Por ejemplo, si el URL especifica un recurso de contenido estático 122, tal como un fichero HTML, un manejador 120 accede al recurso de contenido estático 122 y devuelve el recurso de contenido estático 122 a través del canal de HTTP 118 para la comunicación con el cliente 100 en una respuesta HTTP 112. De forma alternativa, en una forma de realización de la presente invención, si el URL especifica un recurso de contenido dinámico 124, tal como un recurso ASP+, un manejador 120 accede al recurso de contenido dinámico 124, procesa los contenidos del recurso de contenido dinámico 124, y genera el código HTML resultante para la página web 104. En una forma de realización de la presente invención, el código HTML resultante incluye el código estándar HTML 3.2. Por lo general, un recurso de contenido dinámico es una memoria de datos de declaraciones del lado del servidor (por ejemplo, un recurso ASP+) que puede usarse para generar dinámicamente el código de lenguaje de creación que describe una página web para ser visualizada en un cliente. El código HTML para la página web es pasado entonces a través del canal de HTTP 118 para la comunicación al cliente 100 en una respuesta HTTP 112.

Durante su procesamiento, un manejador 120 también puede acceder a bibliotecas de código de terceras partes o predesarrollado para simplificar el esfuerzo de desarrollo. Una biblioteca tal es una biblioteca de control de clases del lado del servidor 126, desde la cual el manejador 120 puede instanciar objetos de control del lado del servidor para procesar elementos de la interfaz de usuario y generar los datos HTML resultantes para la visualización de una página web. En una forma de realización de la presente invención, uno o más objetos de control del lado del servidor mapean a uno o más elementos de la interfaz de usuario, visibles u ocultos, en la página web descrita en el recurso de contenido dinámico 124.

Una segunda biblioteca, por el contrario, es una biblioteca de clases de control del lado del cliente 128, tal como una biblioteca que incluya componentes "ACTIVEX" de Microsoft Corporation. Un control "ACTIVEX" es un objeto COM ("Component Object Model") que sigue ciertos estándares en cómo interactúa con su cliente y otros componentes. Un control "ACTIVEX" del lado del cliente, por ejemplo, es un componente basado en COM que puede ser descargado automáticamente a un cliente y ejecutado por un navegador web en el cliente. Los componentes ACTIVEX del lado del servidor (no mostrados) son componentes basados en COM que pueden ser implementados en un servidor para realizar una variedad de funciones del lado del servidor, tales como la provisión de la funcionalidad del lado del servidor de una aplicación de búsqueda de precio de productos o componente de base de datos. Se puede encontrar una discusión más detallada de ACTIVEX en "Understanding ACTIVEX and OLE", David Chappell, Microsoft Press, 1996.

A diferencia de los controles "ACTIVEX", un objeto de control del lado del servidor en una forma de realización de la presente invención, siendo especificado en un recurso de contenido dinámico 124, se corresponde lógicamente con un elemento de la interfaz de usuario que es visualizado en el cliente. El objeto de control del lado del servidor también puede generar código HTML válido que puede incluir, por ejemplo, una marca HTML y un localizador que haga referencia a un control "ACTIVEX" del lado del cliente dado. Si el navegador ya tiene el código para el control "ACTIVEX" del lado del cliente dentro de su sistema de almacenamiento, el navegador ejecuta el control "ACTIVEX" dentro de la página web en el cliente. De lo contrario, el navegador descarga el código para el control "ACTIVEX" del recurso especificado por el localizador y entonces ejecuta el control "ACTIVEX" dentro de la página web en el cliente. Un objeto de control del lado del servidor en una forma de realización de la presente invención también puede levantar eventos a un objeto "ACTIVEX" del lado del servidor usado para implementar una aplicación de búsqueda de productos en el servidor.

Un manejador 120 también tiene acceso a uno o más componentes del servidor de la interfaz de no usuario 130 que ejecutan en el servidor web 116 o en otro servidor web accesible. Se puede hacer referencia a un componente del servidor de la interfaz de no usuario 130, tal como una aplicación de búsqueda del precio de productos o componente de base de datos, en o asociado a un recurso de contenido dinámico 124 que es procesado por un manejador 120. Los eventos del lado del servidor levantados por los objetos de control declarados en el recurso de contenido dinámico 124 pueden ser procesados por el código del lado del servidor, el cual llama a métodos apropiados en el componente del servidor de la interfaz de no usuario 130. Como resultado, el procesamiento previsto por los objetos de control del lado del servidor simplifica la programación del componente del servidor de la interfaz de no usuario 130 mediante el encapsulamiento del procesamiento y la generación de los elementos de la interfaz de usuario de una página web, lo cual permite al desarrollador del componente del servidor de la interfaz de no usuario 130 concentrarse en la funcionalidad específica de la aplicación, más que en cuestiones de la interfaz de usuario.

La figura 2 ilustra un diagrama de flujo de operaciones para procesar y generar elementos de la interfaz de usuario del lado del cliente usando objetos de control del lado del servidor en una forma de realización de la presente invención. En la operación 200, el cliente transmite una petición HTTP al servidor. La petición HTTP incluye un URL que especifica un recurso, tal como un recurso ASP+. En la operación 202, el servidor recibe la petición HTTP e invoca el manejador apropiado para procesar el recurso especifico. El recurso ASP+ es leído en la operación 203. La operación 204 genera una jerarquía de los objetos de control del lado del servidor basada en los contenidos del recurso de contenido dinámico especifico (por ejemplo, el recurso ASP+).

En la operación 206, los objetos de control del lado del servidor de la jerarquía de objetos de control llevan a cabo una o más de las siguientes operaciones: el manejo de eventos postback, el manejo de datos postback, la gestión del estado, y el enlace de datos. Los eventos y datos postback (en conjunto "entrada de postback") de los elementos de interfaz de usuario están comunicados desde el cliente al servidor para el procesamiento. Un evento postback, por ejemplo, puede incluir sin limitación un evento de "clic de ratón" desde un elemento de botón del lado del cliente o un evento de "cambio de datos" desde un elemento de cuadro de texto del lado del cliente que está comunicado con el servidor. Los datos postback, por ejemplo, pueden incluir sin limitación texto introducido por un usuario en un elemento de cuadro de texto o un índice de un elemento seleccionado de un cuadro desplegable. Una operación postback, no obstante, puede resultar de otros eventos, y no simplemente de la interacción del usuario.

En la operación 208, se llama a cada objeto de control del lado del servidor en la jerarquía para generar (o renderizar) datos, tales como código HTML, para la visualización de elementos de la interfaz de usuario del lado del cliente en la página web. Observe que, aunque el término "renderizar" puede ser usado para describir la operación de visualizar gráficos en una interfaz de usuario, el término "renderizar" también es usado aquí para describir la operación de generar datos de lenguaje de creación que pueden ser interpretados por la aplicación del cliente, tal como un navegador, para la visualización y la funcionalidad del lado del cliente. Se proporciona una discusión más detallada de la operación de procesamiento 206 y la operación de renderización 208 en relación con la figura 6. En una forma de realización, las llamadas a métodos de renderización () en objetos de control individuales son realizadas usando una secuencia de recorrido de árbol. Eso es, una llamada al método de renderización () de un objeto de página resulta en un recorrido recursivo a través de objetos de control del lado del servidor apropiados en la jerarquía. También se pueden emplear métodos alternativos para llamar a los métodos de renderización () para objetos de control apropiados, incluidos una señalización de eventos o enfoque de registro de objetos. Los paréntesis designan la etiqueta "render ()" como indicador de un método, comparada con un valor de datos.

En una forma de realización de la presente invención, la creación real de los objetos de control del lado del servidor individuales puede ser diferida hasta que se acceda al objeto de control del lado del servidor (tal como cuando se maneja entrada de postback, se carga un estado, se renderiza código HTML a partir del objeto de control, etc.) en las operaciones 206 ó 208. Si nunca se accede a un objeto de control del lado del servidor para una petición dada, la creación de objetos de control deferida optimiza el procesamiento del servidor mediante la eliminación de una operación de creación de objetos innecesaria.

La operación 210 transmite el código HTML al cliente en una respuesta HTTP. En la operación 214, el cliente recibe el código HTML asociado a una nueva página web para ser visualizada. En la operación 216, el sistema del cliente incorpora (por ejemplo, dispositivos visualizadores) los elementos de la interfaz de usuario de la nueva página de acuerdo con el código HTML recibido a partir de la respuesta HTTP. Debería entenderse, no obstante, que la incorporación de un elemento de interfaz de usuario puede incluir operaciones que no sean de visualización, tales como la provisión de salida táctil o audio, la lectura y escritura a la memoria, el control de la operación de scripts, etc. En la operación 212, se termina la jerarquía de objetos de control del lado del servidor. En una forma de realización de la presente invención, los objetos de control del lado del servidor en la jerarquía son creados en respuesta a una petición HTTP que haga referencia a un recurso ASP+ asociado, y destruidos después de la renderización de datos de lenguaje de creación (por ejemplo, datos HTML). En una forma de realización alternativa, la operación 212 puede ser realizada después de la operación 208 y antes de la operación 210.

La figura 3 ilustra un ejemplo de módulos en un servidor de web usados en una forma de realización de la presente invención. El servidor web 300 recibe una petición HTTP 302 en el canal de HTTP 304. El canal de HTTP 304 puede incluir diversos módulos, tales como módulos para el registro de estadísticas de página web, la autenticación del usuario, y el caché de salida de páginas web. Cada petición HTTP entrante 302 recibida por el servidor web 300 es procesada en último lugar por una instancia específica de una clase de IHTTPHandler (mostrado como manejador 306). El manejador 306 resuelve la petición de URL e invoca una fábrica de manejadores apropiada (por ejemplo, un módulo de fábrica de páginas 308).

En la figura 3, un módulo de la fábrica del página 308 en relación con el ASP+ recurso 310 es invocado para manejar la instanciación y configuración del ASP+ recurso 310. En una forma de realización, un recurso ASP+ puede ser identificado mediante la designación de un sufijo particular (o una extensión de archivo tal como ".aspx") con el recurso. Cuando una petición para un recurso ASP+ dado es recibido en primer lugar por el módulo de fábrica de páginas 308, el módulo de fábrica de páginas busca el sistema de ficheros para el fichero apropiado (por ejemplo, el fichero .aspx 310). El fichero puede contener texto (por ejemplo, datos de lenguaje de creación) u otro formato de datos (por ejemplo, datos en código byte o datos codificados) que el servidor puede interpretar o al que puede acceder más tarde para atender la petición. Si el archivo físico existe, el módulo de fábrica de páginas 308 abre el archivo y lee el archivo a la memoria. Si no se puede encontrar el archivo, el módulo de fábrica de páginas 308 devuelve un mensaje de error apropiado "fichero no encontrado".

Después de leer el recurso ASP+ 310 a la memoria, el módulo de fábrica de páginas 308 procesa el contenido del fichero para construir un modelo de datos de la página (por ejemplo, listas de bloques de script, directivas, zonas de texto estático, objetos de control jerárquicos del lado del servidor, propiedades de control del lado del servidor, etc.). El modelo de datos es usado para generar un recurso que liste una nueva clase de objetos, tal como una clase COM+ ("Component Object Model+"), que extiende la clase base de páginas. La clase base de páginas incluye el código que define la estructura, propiedades, y la funcionalidad de un objeto de página básico. En una forma de realización de la presente invención, el recurso que lista es entonces compilado de manera dinámica a un lenguaje intermedio y, más tarde, justo a tiempo, compilado a las instrucciones nativas de plataforma (por ejemplo, X86, Alpha, etc.). Un lenguaje intermedio puede incluir código de lenguaje general o realizado según la costumbre, tal como un código COM+ IL, códigos byte Java, código Modula 3, código SmallTalk, y código Visual Code. En una forma de realización alternativa, se pueden omitir las operaciones de lenguaje intermedias, de forma que las instrucciones nativas son generadas directamente a partir del recurso que lista o el fichero del recurso (por ejemplo, el recurso ASP+ 310). Se puede acceder a una biblioteca de clases de control 312 mediante el módulo de fábrica de páginas 308 para obtener clases predefinidas de control del lado del servidor usadas en la generación de la jerarquía de objetos de control.

El módulo de fábrica de páginas 308 produce un objeto de página 314, el cual es un objeto de control del lado del servidor que se corresponde con la página web 104 de la figura 1. El objeto de página 314 y sus hijos (es decir, un objeto de cuadro de texto 318, un objeto de botón 320, y otro objeto de botón 322) comprenden un ejemplo de jerarquía de objetos de control 316. También se considera de conformidad con la presente invención otro ejemplo de objetos de control, incluidos sin limitación objetos correspondientes a los controles HTML de la tabla 1, así como objetos de control habituales. El objeto de página 314 se corresponde con la página web 104 de la figura 1. El objeto de cuadro de texto 318 se corresponde con el cuadro de texto 106 de la figura 1. Asimismo, el objeto de botón 320 se corresponde con el botón de adición 108 de la figura 1, y el objeto de botón 322 se corresponde con el botón de borrado 110 de la figura 1. El objeto de página 314 está relacionado jerárquicamente con otros objetos de control en el servidor. En una forma de realización, un objeto de página es un objeto de contenedor que contiene jerárquicamente sus objetos de control hijo. En una forma de realización alternativa, se pueden emplear otras formas de relación jerárquica, incluida una relación de dependencia. En una jerarquía de objetos de control más compleja con múltiples niveles de hijos, un objeto hijo puede ser un objeto de contenedor para otros objetos hijo.

En la forma de realización ilustrada, los objetos de control en la jerarquía de objetos de control 316 son creados y ejecutados en el servidor 300, y cada objeto de control del lado del servidor se corresponde de forma lógica con un elemento de la interfaz de usuario correspondiente del cliente. Los objetos de control del lado del servidor también cooperan para manejar la entrada de postback a partir de la petición HTTP 302, para gestionar los estados de objetos de control del lado del servidor, para realizar el enlace de datos con bases de datos del lado del servidor, y para generar datos de lenguaje de creación (por ejemplo, código HTML) usados para visualizar una página web resultante en el cliente. Los datos de lenguaje de creación resultantes son generados (por ejemplo, renderizados) a partir de la jerarquía de objetos de control del lado del servidor 316 y transmitidos al cliente en una respuesta HTTP 324. Por ejemplo, el código HTML resultante puede plasmar cualquier construcción HTML válida y puede hacer referencia a controles tipo ACTIVEX, miniaplicaciones JAVA, scripts, y otros recursos web cualesquiera que den como resultado elementos de la interfaz de usuario del lado del cliente (por ejemplo, botones de control, cuadros de texto, etc.) cuando son procesados por un navegador.

En virtud de declaraciones hechas en el recurso ASP+ 310, los objetos de control del lado del servidor también pueden acceder a uno o más componentes del servidor de la interfaz de no usuario 330 para proporcionar interacción entre el componente del servidor de interfaz de no usuario 330 y elementos de la interfaz de usuario del lado del cliente. Por ejemplo, en respuesta a la entrada de postback, los objetos de control del lado del servidor pueden levantar eventos del lado del servidor a los componentes del servidor de la interfaz de no usuario registrados para esos eventos. De este modo, el componente del servidor de la interfaz de no usuario 330 puede interactuar con el usuario a través de elementos de la interfaz del usuario sin programar el código requerido para visualizar y procesar estos elementos.

La figura 4 ilustra contenidos de un ejemplo de recurso de contenido dinámico en una forma de realización de la presente invención. En la forma de realización ilustrada, el fichero 400 contiene declaraciones en texto plano en un ejemplo de formato del recurso de contenido dinámico (por ejemplo, ASP+). Cada declaración proporciona instrucciones a un compilador de páginas que lee el fichero 400, crea e invoca los objetos de control del lado del servidor apropiados para procesar el elemento de la interfaz de usuario del lado del cliente y, en último lugar, combina el código HTML renderizado para la transmisión al cliente en una respuesta HTTP. Como tal, una declaración describe o hace referencia a la funcionalidad de un elemento de la interfaz de usuario del lado del cliente, el cual es implementado por un objeto de control del lado del servidor. El objeto de control del lado del servidor genera entonces el código HTML usado para definir una nueva versión de la página web en el cliente.

La primera línea del fichero 400 incluye una directiva en el formato:

<%@directive{attribute=value}%>

donde la directiva puede incluir sin limitación "page", "cache", o "import". Las directivas son usadas por el compilador de páginas cuando se procesa un recurso de contenido dinámico para determinar tales características como semánticas de búfer, requisitos del estado de la sesión, esquemas de manejo de error, lenguajes de script, semánticas de transacción, y direcciones de importación. Las directivas puede estar situadas en cualquier lugar dentro de un fichero de páginas.

En la segunda línea, <html> es una etiqueta de inicio HTML estándar, la cual es pasada a través al código HTML resultante como un literal (es decir, sin procesamiento adicional para renderizar el código HTML resultante). En HTML, la <html> indica el comienzo del fichero HTML y está emparejada con la etiqueta de cierre en la línea 21, </html>, la cual también es un literal.

Un bloque de declaraciones del código está situado en las líneas 3 a 10 del fichero 400. Por lo general, los bloques de declaraciones del código del lado del servidor definen el objeto de página y controlan variables y métodos del elemento de objeto de control que son ejecutados en el servidor. En el formato:

<script runat="server"[lanquage="language"][src="extemalfile"]>

.........................

</script>

donde el lenguaje y los parámetros src son opcionales. En una forma de realización de la presente invención, los bloques de declaraciones del código son definidos usando etiquetas <script> que contienen un atributo "runat" con un valor fijado en "server". De manera opcional, se puede usar un atributo "language" para especificar la sintaxis del código interno. El lenguaje por defecto puede representar la configuración del lenguaje de la página total; no obstante, el atributo "language" en el bloque de declaración del código permite a un desarrollador usar diferentes lenguajes dentro de la misma implementación de página web incluidos, por ejemplo, Jscript y PERL (lenguaje práctico de extracción e informe). De manera opcional, la etiqueta <script> también puede especificar un fichero "src", el cual es un fichero externo a partir del cual se inserta el código en el recurso de contenido dinámico para el procesamiento mediante el compilador de páginas. Debería entenderse que la sintaxis expuesta se usa en una forma de realización, no obstante,
las formas de realización alternativas pueden emplear sintaxis diferentes dentro del ámbito de la presente invención.

En la figura 4, están declaradas dos subrutinas en formato Visual Basic dentro del bloque de declaraciones del código: AddButton_Click y DeleteButton_Click. Las dos subrutinas toman dos parámetros de entrada, "Source" y "E", y son ejecutadas en el servidor en respuesta a la petición HTTP cuando un evento de clic del lado del cliente es detectado en el botón correspondiente. En la subrutina AddButton_Click, el texto en un cuadro de texto UserName está concatenado sobre la palabra "Add" y cargado en el elemento de datos Text de Message. En la subrutina DeleteButton_Click, el texto en el cuadro de texto UserName está concatenado sobre la palabra "Delete" y cargado en el elemento de datos Text de Message. En la subrutina DeleteButton_Click, el texto en el cuadro de texto UserName está concatenado sobre la palabra "Delete" y cargado en el elemento de datos Text de Message. Aunque no mostrados en la figura 4, las variables del elemento de objetos de control del lado del servidor pueden estar declaradas en el bloque de declaraciones de código del fichero 400. Por ejemplo, usando una sintaxis Visual Basic, el espacio de la palabra clave "DIM" declara una variable de datos de un objeto de control del lado del servidor.

Un "bloque de renderización de código" (no mostrado) también puede ser incluido en un recurso de contenido dinámico. En una forma de realización de la presente invención, un bloque de renderización de código ejecuta en un única método "de renderización" que ejecuta en el tiempo de renderización de página. Un bloque de renderización de código satisface el siguiente formato (aunque se contemplan otros formatos en formas de realización alterna-
tivas):

<%InlineCode%>

donde InlineCode incluye bloques de código completos e independientes o bloques de flujo de control que ejecutan en el servidor en el tiempo de renderización de página.

Las expresiones Inline también pueden ser usadas dentro de un bloque de renderización de código, usando la sintaxis del ejemplo:

<%=InlineExpression%>

donde la expresión contenida en un bloque InlineExpression está comprendida en último lugar por una llamada a "Response.Write (InlineExpression)" en un objeto de página, la cual escribe el valor resultante de InlineExpression en un retenedor de lugar apropiado en la declaración. Por ejemplo, InlineExpressions puede estar incluido en un bloque de renderización de código como sigue a continuación:

<font size="<%=x%>">Hola<%=Name%>, usted tiene <%=Age%>!<font>

lo cual produce un saludo y una afirmación sobre la edad de una persona en una fuente almacenada en el valor "x". El nombre y edad de la persona están definidos como secuencias en un bloque de declaración de código (no mostrado). El código HTML resultante es renderizado en el servidor para la transmisión al cliente en la respuesta HTTP para incluir los valores de las InlineExpressions en lugares apropiados:

<font size="12">Hola Bob, ¡tiene 35 años!

En la línea 11 del fichero 400, <body> es una etiqueta HTML estándar para definir el comienzo del cuerpo del documento HTML. En la línea 20 del fichero 400, también se muestra la etiqueta de cierre </body>. Tanto la <body> como </body> son literales en una forma de realización de la presente invención.

Dentro de la sección del cuerpo del fichero HTML 400, en la línea 12, la etiqueta de inicio, <form>, de un bloque de forma HTML se encuentra en la figura 4. La etiqueta de fin, </foral>, del bloque de forma se encuentra en la línea 19 del fichero HTML 400. También se puede incluir un parámetro adicional "id" en la etiqueta de control HTML,<form>, para asociar un identificador dado con el bloque de forma, permitiendo de esta forma que se incluyan múltiples bloques de forma en un único fichero HTML.

En la línea 18 del fichero 400 se declara una etiqueta del lado del servidor, identificada mediante "Message". La etiqueta "Message" es usada en el código declarado en las líneas 5 y 8 del fichero 400 para visualizar una etiqueta en la página web.

Dentro de un bloque de forma, se muestran tres ejemplos de etiquetas de control HTML, correspondientes a los elementos de interfaz de usuario 106, 108, y 110 de la figura 1. El primer elemento de interfaz de usuario es declarado en la línea 13 del fichero 400 correspondiente a un cuadro de texto. El literal del texto "User Name:" declara una etiqueta posicionada a la izquierda del cuadro de texto. La etiqueta de entrada con type="Text" declara un objeto de control del lado del servidor del cuadro de texto con un id igual a "UserName" como un objeto de control del lado del servidor que renderiza un elemento de la interfaz de usuario del lado del cliente del cuadro de texto. Las líneas 15 y 16 del fichero 400 declaran los elementos de la interfaz de usuario del lado del cliente mostrados como los botones 108 y 110 de la figura 1, respectivamente. Observe que el parámetro "OnServerClick" especifica la subrutina apropiada declarada en el bloque de declaraciones de código del fichero 400. Como tales, los objetos de control de botón del lado del servidor generados en respuesta a las declaraciones del fichero 400 renderizan el código HTML para los botones del lado del cliente y un código del lado del servidor asociado para implementar los eventos de clic de
botón.

El cuadro de texto y botones declarados en el fichero 400 son ejemplos de declaraciones de control de servidor HTML. Por defecto, todas las etiquetas HTML dentro del recurso ASP+ son tratadas como contenido de texto literal y son inaccesibles programáticamente para los desarrolladores de páginas. No obstante, los creadores de páginas pueden indicar que una etiqueta HTML debería ser analizada y tratada como una declaración de control de servidor inaccesible marcándola con un atributo "runat" con un valor fijado en "server". Cada objeto de control del lado del servidor puede ser asociado opcionalmente con un atributo "id" único para posibilitar la referencia programática del objeto de control correspondiente. Los argumentos de propiedad y enlaces de eventos sobre objetos de control del lado del servidor también pueden ser especificados usando pares de atributos declarativos name/value sobre el elemento de etiqueta (por ejemplo, el par OnServerClick igual a "MyButton_Click").

\newpage

En una forma de realización de la presente invención, una sintaxis general para declarar objetos de control HTML es como sigue a continuación:

<HTMLTag id=”Optional Name” runat=server>

.........................

</HTMLTag>

donde el OptionalName es un identificador único para el objeto de control del lado del servidor. En la Tabla 1 se ilustra una lista de etiquetas HTML soportadas actualmente y la sintaxis asociada y la clase COM+, aunque otras etiquetas HTML se consideran dentro del ámbito de la presente invención.

TABLA 1

1

2

Además de las etiquetas de control HTML estándar, una forma de realización de la presente invención permite a los desarrolladores crear componentes reutilizables que encapsulan la funcionalidad programática común fuera del conjunto de etiquetas HTML estándar. Estos objetos de control del lado del servidor habituales son especificados usando etiquetas declarativas dentro del fichero de páginas. Las declaraciones de objeto de control del lado del servidor habituales incluyen un atributo "runat" con un valor fijado en "server". De manera opcional, el atributo único "id" puede ser especificado para permitir la referencia programática del objeto de control habitual. Asimismo, los pares de atributos declarativos name/value sobre un elemento de etiqueta especifican argumentos de propiedad y enlaces de eventos sobre un objeto de control del lado del servidor. También se pueden enlazar parámetros modelo en línea a un objeto de control del lado del servidor mediante la provisión de un elemento hijo del prefijo "template" apropiado al objeto de control del servidor padre. Un formato para una declaración de objeto de control del lado del servidor habitual es:

<servercntrlclassname id="OptionalName"[propertyname="propval"]runat=server/>

donde servercntrlclassname es un nombre de una clase de control de servidor accesible, OptionalName es un identificador único del objeto de control del lado del servidor, y propval representa un valor de propiedad opcional en el objeto de control.

A través del uso de una sintaxis de declaración alternativa, se pueden usar prefijos de etiqueta XML para proporcionar una notación más precisa para especificar objetos de control del lado del servidor dentro de una página, usando el siguiente formato:

<tagprefix:calssname id = "OptionalName" runat = server/>

donde tagprefix está asociado a una biblioteca de espacio de nombres de control dada y classname representa un nombre de un control en la biblioteca de espacio de nombres asociados. También se soporta un propertyvalue opcional.

En resumen, una forma de realización de la presente invención incluye objetos de control del lado del servidor que son creados y ejecutados en el servidor para generar código HTML que es enviado a un cliente. El código HTML puede representar cualquier construcción HTML válida y puede, por ejemplo, hacer referencia a controles tipo ACTIVEX, miniaplicaciones JAVA, scripts, y cualesquiera otros recursos web para producir botones de la interfaz de usuario y otros elementos de la interfaz en el cliente. Un usuario en el cliente puede interactuar con estos elementos de la interfaz de usuario, los cuales se corresponden de manera lógica con los objetos de control del lado del servidor, y envían una petición de vuelta al servidor. Los objetos de control del lado del servidor son recreados en el servidor para procesar los datos, eventos, y otras características de los elementos de la interfaz de usuario para generar la siguiente ronda de código HTLM que ha de transmitirse en una respuesta al cliente.

Haciendo referencia a la figura 5, un ejemplo de sistema informático para formas de realización de la invención incluye un dispositivo informático de aplicaciones generales en la forma de un sistema informático 500, incluida una unidad procesadora 502, una memoria del sistema 504, y un bus del sistema 506 que une diversos componentes del sistema incluida la memoria del sistema 504 a la unidad procesadora 500. El bus del sistema 506 puede ser cualquiera de distintos tipos de estructuras de bus incluido un bus de memoria o controlador de memoria, un bus periférico y un bus local usando cualquiera de una variedad de arquitecturas de bus. La memoria del sistema incluye memoria de sólo lectura (ROM) 508 y memoria de acceso aleatorio (RAM) 510. Un sistema básico de entrada/salida 512 (BIOS), el cual contiene rutinas básicas que ayudan a transferir información entre elementos dentro del sistema informático 500, es almacenado en la ROM 508.

El sistema informático 500 incluye además una unidad de disco duro 512 para leer desde ella y escribir a un disco duro, una unidad de disco magnético 514 para leer desde ella o escribir a un disco magnético extraíble 516, y una unidad de disco óptico 518 para leer desde ella o escribir a un disco óptico extraíble 519 tal como un CD ROM, DVD, u otros medios ópticos. La unidad de disco duro 512, la unidad de disco magnético 514, y la unidad de disco óptico 518 son conectadas al bus del sistema 506 mediante una interfaz de la unidad de disco duro 520, una interfaz de la unidad de disco magnético 522, y una interfaz de la unidad óptica 524, respectivamente. Las unidades y sus medios asociados legibles por ordenador proporcionan almacenamiento no volátil de instrucciones legibles por ordenador, estructuras de datos, programas, y otros datos para la sistema informático 500.

Aunque el entorno del ejemplo descrito aquí emplea un disco duro, un disco magnético extraíble 516, y un disco óptico extraíble 519, se pueden usar otros tipos de medios legibles por ordenador que pueden almacenar datos en el sistema del ejemplo. Ejemplos de estos otros tipos de medios legibles por ordenador que pueden ser usados en el ejemplo de entorno operativo incluyen cintas magnéticas, tarjetas de memoria flash, discos digitales de video, cartuchos Bernoulli, memorias de acceso aleatorio (RAMs), y memorias de sólo lectura (ROMs).

Un número de módulos de programa puede ser almacenado en el disco duro, el disco magnético 516, el disco óptico 519, la ROM 508 o la RAM 510, incluido un sistema operativo 526, uno o más programas de aplicación 528, otros módulos de programa 530, y datos del programa 532. Un usuario puede introducir órdenes e información en el sistema informático 500 a través de dispositivos de entrada tales como un teclado 534 y un ratón 536 u otro dispositivo de puntero. Ejemplos de otros dispositivos de entrada pueden incluir un micrófono, una palanca de mando, un tablero de juego, un plato parabólico, y un escáner. Éstos y otros dispositivos de entrada están conectados frecuentemente a la unidad de procesamiento 502 a través de una interfaz de puerto serie 540 que está acoplada al bus del sistema 506. No obstante, estos dispositivos de entrada también pueden estar conectados mediante otras interfaces, tales como un puerto paralelo, un puerto de juego, o un bus de serie universal (USB). Un monitor 542 u otro tipo de dispositivo de visualización también está conectado al bus del sistema 506 por medio de una interfaz, tal como un adaptador de video 544. Además del monitor 542, los sistemas informáticos incluyen normalmente otros dispositivos periféricos de salida (no mostrados), tales como altavoces e impresoras.

El sistema informático 500 puede operar en un entorno en red usando conexiones lógicas a uno o más ordenadores remotos, tales como un ordenador remoto 546. El ordenador remoto 546 puede ser un sistema informático, un servidor, un router, un ordenador personal de red, un dispositivo entre iguales u otro nodo de red común, y normalmente incluye muchos de o todos los elementos descritos arriba relativos al sistema informático 500. Las conexiones de la red incluyen una red de área local (LAN) 548 y una red de área ancha (WAN) 550. Tales entornos de trabajo en red son habituales en oficinas, redes informáticas a nivel empresarial, intranets e Internet.

Cuando se usa en un entorno de trabajo en red LAN, el sistema informático 500 está conectado a la red local 548 a través de una interfaz de red o adaptador 552. Cuando se usa en un entorno de trabajo en red WAN, el sistema informático 500 incluye normalmente un módem 554 u otros medios para establecer comunicaciones por la red de área ancha 550, tales como Internet. El módem 554, el cual puede ser interno o externo, está conectado al bus del sistema 506 por medio de la interfaz de puerto serie 540. En un entorno de red, los módulos de programa representados relativos al sistema informático 500, o partes del mismo, pueden estar almacenados en el dispositivo remoto de almacenamiento de memoria. Se considerará que las conexiones de la red mostradas son ejemplos, y que se pueden usar otros medios de establecimiento de un enlace de comunicación entre los ordenadores.

En una forma de realización de la presente invención, el ordenador 500 representa un servidor web, donde el procesador 502 ejecuta un módulo de fábrica de páginas en un recurso ASP+ almacenado en al menos uno de medios de almacenamiento 516, 512, 514, 518, 519, o la memoria 504. Las respuestas y las peticiones HTTP son comunicadas por la LAN, 548, la cual está conectada al ordenador del cliente 546.

La figura 6 ilustra un diagrama de flujo del proceso que representa el procesamiento del lado del servidor de un objeto de página y otros objetos de control en una forma de realización de la presente invención. En la operación 600, se llama a un constructor de objetos de página mediante el módulo de fábrica de páginas 308 (ver la figura 3). Como resultado, se crea un objeto de página (ver, por ejemplo, el objeto de página 314 en la figura 3) para que se corresponda de manera lógica con el elemento de interfaz de usuario de página web en el cliente. En la operación 602, el módulo de fábrica de páginas llama a la función del elemento ProcessRequest() del objeto de página, el cual inicia las operaciones por fases para el procesamiento de la petición HTTP recibida de un cliente. En una primera fase de una forma de realización de la presente invención, una operación Crear del lado del servidor (no mostrada) crea los objetos de control del lado del servidor descendiente contenidos en la jerarquía de objetos de control del objeto de página, es decir, se llama a los constructores para objetos de control hijo de manera recurrente para crear los objetos de control durante la duración del procesamiento de la petición HTTP.

En una forma de realización alternativa, no obstante, la creación de objetos de control hijo es deferida hasta que el objeto de control es requerido para un paso de procesamiento dado (por ejemplo, el manejo de un evento postback, el manejo de datos postback, la carga o guardado de un estado de vista, la resolución de enlace de datos, o la renderización de código HTML para el elemento de la interfaz de usuario correspondiente). La última forma de realización, la cual se dice que implementa "la creación deferida de objetos de control", es una optimización que puede aliviar la UCP y utilización de memoria innecesarias. Por ejemplo, un evento de entrada de usuario recibido del cliente puede tener como resultado la creación de una página web completamente diferente. En este caso, no es necesario instanciar una jerarquía completa de objetos de control de la página anterior sólo para procesar un evento que tiene como resultado inmediatamente la terminación de la jerarquía de objetos de control y la instanciación de una nueva y diferente jerarquía de objetos de control para una nueva página.

En respuesta a la llamada del servidor al método ProcessRequest del objeto de página, el objeto de página y objetos de control descendientes individuales pueden ejecutar las operaciones 604 a 620, dependiendo en parte de los datos de una petición HTTP dada. En una forma de realización de la presente invención, las operaciones 604 a 620 son realizadas para cada objeto individual en el orden ilustrado en la figura 6; no obstante, una operación dada para un objeto puede producirse fuera del orden o no con respecto a una operación dada de otro objeto, dependiendo de la petición HTTP. Por ejemplo, un primer objeto puede realizar su operación Init 604 y su operación Init 606, y comenzar la operación de procesamiento de datos postback 608, antes de que un objeto de control descendiente realice su propia operación Init 604 y la operación Cargar 606 en virtud de la creación deferida de objetos de control. El orden de procesamiento de operaciones mediante el objeto de página y objetos de control descendientes depende de diversos factores, incluidos sin limitarse a los mismos la naturaleza de los datos en la petición HTTP, la configuración de la jerarquía de objetos de control, el estado actual de los objetos de control, y si la creación diferida de objetos de control está implementada.

La operación Init 604 inicializa un objeto de control después de que éste sea creado mediante la ejecución de cualquier código del lado del servidor asociado a la inicialización en el recurso de contenido dinámico. De esta forma, cada objeto de control del lado del servidor puede ser adaptado con la funcionalidad del lado del servidor específica que es declarada en el recurso de contenido dinámico. En una forma de realización de la presente invención, el código de contenido dinámico destinado a adaptar o extender las clases base de control de página como se declara mediante el desarrollador de páginas en el recurso ASP+ en el servidor. Cuando el recurso ASP+ es compilado, el código declarado es incluido en el código de inicialización apropiado (por ejemplo, los métodos Init() del objeto do página y los objetos de control descendentes). La operación Init 604 ejecuta este código para adaptar o extender la clase base de página y las clases base para objetos de control descendentes.

En una forma de realización de la presente invención, la gestión del estado de los objetos de control del lado del servidor es soportada en una operación Cargar 606 y una operación Guardar 616, las cuales usan una estructura de estado transportable para alojar el modelo sin estado para sistemas cliente-servidor mediante la restauración de objetos de control del lado del servidor para sus estados previos. En una forma de realización, el estado es comunicado a y desde servidor en un o más campos HTML ocultos de un par petición/respuesta HTTP, aunque otras estructuras de estado transportables se consideran dentro del ámbito de la presente invención.

En una secuencia dada de peticiones y respuestas relacionadas con la página actual entre un cliente y un servidor, los estados de uno o más objetos de control son registrados en una estructura de estado transportable por la operación Guardar 616 después del procesamiento de una petición previa. En una forma de realización de la presente invención, también se incluye información adicional del estado en la estructura de estado transportable, incluida información jerárquica o identificadores de objetos de control para permitir al servidor asociarse a un estado dado con el objeto de control apropiado. En una petición HTTP posterior, la información del estado es devuelta al servidor en la estructura de estado transportable. El servidor extrae la información del estado de la estructura de estado transportable recibida y carga los datos del estado en los objetos de control apropiados dentro de la jerarquía de objetos de control para restaurar cada objeto de control a su estado como existía antes de una respuesta HTTP previa. Después de que la petición actual sea procesada, los estados de uno o más objetos de control del lado del servidor son registrados otra vez en la estructura de estado transportable por la operación Guardar 616, y la estructura de estado transportable es devuelta al cliente en la siguiente respuesta HTTP.

Como resultado de la operación Cargar 606, cada objeto de control del lado del servidor es colocado en un estado concordante con su estado antes de una respuesta HTTP anterior. Por ejemplo, si un objeto de control de cuadro de texto incluye un valor de propiedad igual a "JDoe" antes de una respuesta HTTP anterior, la operación Cargar 606 restaura el mismo objeto de control a su estado anterior, en parte cargando la secuencia de texto "JDoe" en el valor de propiedad. Además, si el estado de un objeto dado es almacenado y restaurado es configurable.

Resumiendo una forma de realización de la presente invención, el estado de uno o más objetos de control del lado del servidor es "guardado" después del procesamiento. La información del estado guardada es transmitida al cliente en una respuesta. El cliente devuelve la información del estado guardada al servidor en una respuesta siguiente. El servidor carga la información del estado en una jerarquía de objetos de control del lado del servidor recién instanciados, tales que el estado de la jerarquía es restaurado a su estado previo.

Una forma de realización alternativa puede mantener la información del estado en el servidor o en alguna otra ubicación web accesible por el servidor durante el viaje de ida y vuelta del servidor al cliente, y luego de vuelta al servidor. Después de que la petición del cliente sea recibida por el servidor, esta información del estado puede ser recuperada por el servidor y cargada en el/los objeto(s) de control del lado del servidor apropiado(s) en la jerarquía de objetos de control.

En la operación 608, se procesan datos postback recibidos de la petición HTTP. Se pueden incluir datos postback en la carga útil de la petición HTTP en pares de valores de tecla, en una representación jerárquica (por ejemplo, XML), o en otras representaciones de datos, tales como RDF ("Marco de Descripción de Recursos"). La operación 608 analiza la carga útil para identificar un identificador único de un objeto de control del lado del servidor. Si se encuentra el identificador (por ejemplo "page1:text1") y el objeto de control del lado del servidor identificado existe en la jerarquía de objetos de control, los datos postback correspondientes son pasados al objeto de control. Por ejemplo, haciendo referencia a la figura 1, un identificador único asociado con el cuadro de texto 106 y el texto "JDoe" son comunicados en la carga útil de la petición HTTP 114 al servidor web 116. La operación 608 analiza la carga útil de la petición HTTP y obtiene el identificador único del cuadro de texto 106 y su valor asociado (es decir, "JDoe"). La operación 608 resuelve entonces el identificador único del cuadro de texto 106 para identificar el objeto de control del lado del servidor correspondiente y pasa el valor "JDoe" al objeto objetivo para el procesamiento.

Como se ha discutido con respecto a la operación Cargar 606, los valores de propiedad de objetos de control del lado del servidor pueden ser restaurados a sus estados previos. En respuesta a la recepción de datos postback, el objeto de control del lado del servidor determina si el valor del postback pasado causa un cambio a partir del valor anterior de la propiedad correspondiente. Si es así, el cambio es registrado en una lista de cambios para indicar un cambio de datos para el objeto de control asociado. Después de que todos los datos postback hayan sido procesados dentro de la jerarquía de objetos de control, se puede hacer una llamada a un método de objetos de control para levantar uno o más eventos cambiados de datos postback a uno o más componentes del servidor de la interfaz de no usuario, tales como una aplicación de búsqueda de precios de productos que se ejecuta en el servidor. Un ejemplo de un evento cambiado de datos postback es un evento que indique que esos datos postback han causado que cambie una propiedad de un objeto de control del lado del servidor. En un ejemplo de forma de realización, un evento de tales características puede ser enviado a una cola de eventos provista por el sistema, para que el código del lado del servidor, el cual puede ser registrado para procesar el evento, pueda ser invocado. El código del lado del servidor puede llamar entonces a un método del componente del servidor de la interfaz de no usuario. De esta forma, un componente del servidor de la interfaz de no usuario del lado del servidor puede responder a eventos activados por un cambio en los datos de un objeto de control del lado del servidor. También se consideran dentro del ámbito de la presente invención métodos alternativos de implementación de eventos, incluidos el uso de colas de eventos provistas por la aplicación, sondeo, e interrupciones del procesamiento.

En la operación 610, se manejan los eventos postback. Los eventos postback pueden ser comunicados en la carga útil de la petición HTTP. La operación 610 analiza un objetivo de evento especificado (por ejemplo, "_EVENTTARGET" etiquetado en una forma de realización de la presente invención) que identifica el objeto de control del lado del servidor al cual se dirige el evento. Asimismo, la operación 610 analiza los argumentos del evento localizados, si los hubiera, y proporciona el argumento del evento (por ejemplo, "_EVENTARGUMENT" etiquetado en una forma de realización de la presente invención) al objeto de control del lado del servidor especificado. El objeto de control levanta sus eventos para el procesamiento mediante el código del lado del servidor, el cual llama a un método de un componente del servidor de la interfaz de no usuario (por ejemplo, una aplicación de búsqueda de precios de productos del lado del servidor) asociado al recurso de contenido dinámico.

La operación 612 resuelve las relaciones de enlace de datos entre los objetos de control del lado del servidor y una o más bases de datos accesibles por el servidor, actualizando de este modo en las propiedades de los objetos de control con los valores de las bases de datos y/o actualizando los campos de las bases de datos con los valores de las propiedades de los objetos de control. En una forma de realización de la presente invención, se pueden asociar (o enlazar a los datos) las propiedades de los objetos de control del lado del servidor a propiedades de un contenedor de enlace de datos padre, tales como una tabla en una base de datos de la aplicación del lado del servidor. Durante la operación de enlace de datos 612, la estructura de la página puede actualizar una propiedad de objetos de control enlazada a datos con el valor de la propiedad del contenedor de enlace de datos padre correspondiente. De esta forma, los elementos de la interfaz de usuario en la página web de la siguiente respuesta reflejan con exactitud valores de las propiedades actualizados, puesto que las propiedades de objetos de control a las cuales corresponden los elementos de la interfaz de usuario han sido actualizadas automáticamente durante la operación de enlace de datos 612. Asimismo, las propiedades de los objetos de control también pueden ser actualizadas a los campos del contenedor de enlace de datos padre, actualizando de esta forma una base de datos de la aplicación del lado del servidor con entrada de postback de un objeto de control del lado del servidor.

La operación 614 realiza diversas operaciones de actualización que pueden ser ejecutadas antes de que se guarde el estado del objeto de control y se renderice la salida. La operación 616 solicita información del estado (es decir, estado de la vista) de uno o más objetos de control en la jerarquía de objetos de control y almacena la información del estado para la inserción en una estructura del estado transportable que está comunicada con el cliente en la carga útil de la respuesta HTTP. Por ejemplo, un objeto de control de "retícula" puede guardar una página de índice actual de una lista de valores, de manera que el objeto de control de "retícula" pueda ser restaurado a su estado después de una petición HTTP posterior (es decir, en la operación 606). Como se describe arriba, la información del estado de la vista representa el estado de la jerarquía de objetos de control antes de cualquier acción posterior del cliente. Cuando la información del estado de la vista es devuelta, será usada para colocar la jerarquía de objetos de control en ese estado anterior antes del procesamiento de cualquier entrada de postback del cliente o enlace de datos.

La operación de renderización 618 genera la salida de lenguaje de creación apropiada (por ejemplo, datos HTML) para la comunicación al cliente en una respuesta HTTP. La renderización se efectúa a través de un recorrido de árbol jerárquico descendente de todos los objetos de control del lado del servidor y del código de renderización empotrado. La operación 620 realiza cualquier trabajo de limpieza final (por ejemplo, el cierre de ficheros o de conexiones de bases de datos) antes de que se finalice la jerarquía de objetos de control. El procesamiento vuelve entonces a la operación 602 y procede a la operación 622 donde el objeto de página es terminado llamando a su destructor.

La figura 7 ilustra una representación de un ejemplo de clase de control del lado del servidor en una forma de realización de la presente invención. La clase de control del lado del servidor define los métodos, propiedades y eventos comunes a todos los objetos de control del lado del servidor en una forma de realización de la presente invención. Las clases de control más específicas (por ejemplo, un objeto de control de botón del lado del servidor que se corresponda con un botón del lado del cliente en una página web) derivan de la clase de control. Una clase de control 700 está ilustrada incluyendo memoria que almacena las propiedades 702 y los métodos 704. Otras formas de realización de clase de control con una combinación diferente de elementos y métodos de datos también se consideran dentro del ámbito de la presente invención.

En la forma de realización ilustrada, las propiedades 702 son públicas. La propiedad "ID" es un valor de secuencia legible y escribible que indica un identificador de objetos de control. La propiedad "Visible" es un valor boleano legible y escribible que indica si los datos del lenguaje de creación para un elemento de la interfaz de usuario del lado del cliente correspondiente debería ser renderizado. La propiedad "MaintainState" es un valor boleano legible y escribible que indica si el objeto de control debería guardar su estado de vista (y el estado de vista de sus hijos) al final de la petición de página actual (es decir, en respuesta a una operación de guardado 616 de la figura 6). La propiedad "Parent" es una referencia legible a un ControlContainer (ver la figura 8) asociado al objeto de control actual en la jerarquía de objetos de control. La propiedad "Page" es una referencia legible al objeto de página raíz en el cual está hospedado el objeto de control actual. La propiedad "Form" es una referencia legible a un objeto FormControl en el cual está hospedado el objeto de control actual. La propiedad "Trace" es una referencia legible que permite a un desarrollador escribir un registro de rastro. PropertyBindingContainer es una referencia legible al contenedor de enlace de datos inmediato del objeto de control. "Bindings" es una referencia legible a una colección de las asociaciones de enlaces de datos del objeto de control.

Los métodos 704 incluyen métodos para procesar peticiones y elementos de datos de acceso del objeto de control. En una forma de realización, se hace referencia a los métodos mediante punteros almacenados en el espacio de memoria del objeto de control. Estos medios de referencia también se emplean en formas de realización de otros objetos del lado del servidor, incluido un objeto de control del contenedor, un objeto de colección de controles, y un objeto de página. El método "Init()" es usado para inicializar objetos de control hijo después de que sean creados (ver la operación 604 de la figura 6). El método "Load()" es usado para restaurar la información del estado de vista a partir de una petición HTTP anterior (ver la operación 606 de la figura 6). El método "Save()" es usado para guardar información del estado de vista para uso con una petición HTTP posterior (ver la operación 616 de la figura 6). El método "PreRender()" es usado para realizar cualesquiera pasos de prerrenderización necesarios antes de guardar el estado de vista y renderizar el contenido (ver la operación 614 de la figura 6). El método "Render (TextWriter output)" es usado para la salida del código del lenguaje de creación para el elemento de la interfaz de usuario correspondiente al objeto de control actual (ver la operación 618 de la figura 6). El código es comunicado a través de la corriente de salida (pasado a ella en el parámetro "output") para almacenar el código en la respuesta al cliente. El método "Dispose()" es usado para realizar el trabajo de limpieza final antes de finalizar el objeto de control (ver la operación 620 de la
figura 6).

El método "GetUniqueID()" obtiene un identificador de secuencias único, calificado jerárquicamente para el objeto de control actual. El método "GetControlWithID(String id)" devuelve una referencia a un objeto de control hijo inmediato con el identificador provisto ("id"). El método "GetControlWithUniqueID(String id)" devuelve una referencia a un objeto de control hijo con un identificador jerárquico único ("id").

El método "PushControlPropertyTwoBindingContainer (String prop Name)" es usado para actualizar un contenedor de enlace para el enlace de datos de dos caminos a partir de datos postback cuando el valor de los datos postback cambia dentro del objeto de control del lado del servidor. El método "PushBindingContainerPropertyTwoControl(String prop Name)" es usado para actualizar una propiedad del objeto de control del lado del servidor con un valor del contenedor de enlace actual. El método "HasBindings()" devuelve del valor boleano indicando si un objeto de control tiene alguna asociación de enlace. Estas tres funciones son usadas para resolver relaciones de enlace entre propiedades de objetos y atributos de control del lado del servidor en memorias de datos del lado del servidor (ver la operación de enlace de datos 612 de la figura 6).

La figura 8 ilustra un ejemplo de clase de ContainerControl del lado del servidor en una forma de realización de la presente invención. La clase ContainerControl proporciona una implementación que soporta objetos de control hijo anidados, y automáticamente señaliza y deserializa información del estado de vista a la estructura del estado transportable. Una clase ContainerControl 800 incluye memoria que almacena las propiedades 802 y los métodos 804. La propiedad "Controls" es una referencia legible a una "ControlCollection" de los objetos de control hijo en la jerarquía de objetos de control. (Ver la figura 9). La propiedad "StateCollection" es una referencia legible a un diccionario de información del estado de vista usado para mantener el estado de un objeto de control a través de múltiples peticiones de página. El método "HasControls()" devuelve un valor boleano indicando si el objeto de control tiene algún objeto de control hijo.

En una forma de realización alternativa, las propiedades y métodos de los elementos de la clase ContainerControl 800 pueden ser combinados en la clase Control 700 de la figura 7, de tal forma que cada objeto de control puede en y de sí mismo soportar hijos. Si un objeto de control de una forma de realización de estas características no incluye objetos hijo, no obstante, el elemento Controls (de tipo ControlCollection) estaría vacío (es decir, no tiene objetos hijo).

La figura 9 ilustra un ejemplo de clase ControlCollection del lado del servidor en una forma de realización de la' presente invención. Una clase ControlCollection 900 incluye memoria para las propiedades 902 y los métodos de almacenaje 904. La propiedad "All" es una cadena instantánea legible y escribible de todos los objetos de control hijo del objeto de control actual, ordenado mediante un índice. La propiedad "this [index]" es una referencia legible a un objeto de control indexado con números ordinales dentro de la colección de controles. La propiedad "Count" es un valor legible que indica el número de objetos de control hijo de la colección.

El método "Add(Control child)" es usado para añadir un objeto de control especificado a la colección actual. El método "IndexOf(Control child)" devuelve el índice ordinal del objeto de control hijo especificado a la colección. El método "GetEnumerator(bool AllowRemove)" devuelve el enumerador de todos los objetos de control hijo dentro de la colección. El método "Remove(Control value)" quita el objeto de control especificado de la colección actual. El método "Remove(int index)" quita un objeto de control especificado de la colección actual basada en el índice provisto. El método "Clear()" quita todos los objetos de control de la colección actual.

La figura 10 ilustra un ejemplo de objeto de página del lado del servidor en una forma de realización de la presente invención. Un clase base de página define los métodos, las propiedades y los eventos comunes a todas las páginas manipuladas por el servidor dentro de un forma de realización de la presente invención. Un objeto de página 1000 incluye propiedades 1002 y métodos de almacenamiento de memoria 1004. La propiedad "ErrorPage" es una secuencia legible y escribible que es renderizada en el evento de una excepción de página no manejada. De esta forma, un objeto de página devuelve una página de error legible al cliente en una respuesta HTTP. La propiedad "Requests" es una referencia legible a una HTTPRequest, la cual es provista por la estructura del servidor web que proporciona la funcionalidad para acceder a los datos de petición HTTP entrantes. La propiedad "Response" es una referencia legible a una respuesta HTTP, provista por la estructura del servidor web, el cual proporciona la funcionalidad para transmitir datos de respuesta HTTP a un cliente. La propiedad "Application" es una referencia legible a una HTTPApplication, provista por la estructura del servidor web. La propiedad "Session" es una referencia legible a una HTTPSession, provista por la estructura del servidor web. La propiedad "Server" es una referencia legible a un ServerObject, la cual es un objeto de utilidad compatible con la página del servidor de la aplicación. La propiedad "Context" es una referencia legible a todos de los objetos del servidor web provistos por la estructura del servidor web, la cual permite a un desarrollador obtener acceso a objetos expuestos de módulo de canal adicionales. La propiedad "IsFirstLoad" es un valor boleano legible que indica si el objeto de página está siendo cargando y se está accediendo a él por primera vez o en respuesta a una petición postback del cliente.

El método "Load()" es usado para inicializar el objeto de página y restaurar la información del estado de vista a partir de la petición de página previa. El método "Save()" es usado para guardar la información del estado de vista para uso con una petición de página posterior. El método "HandleError(Exception errorInfo)" es usado para manejar un error no manejado producido durante una ejecución de página. En este evento, la implementación de la clase base redirige el cliente a un URL con una página web de error predeterminado. El método "GetPostbackScript(Control target, String name, String arg)" devuelve un método de script del lado del cliente asociado a un objeto de control dado. El método "RegisterClientScriptBlock(String key, String script)" es usado para eliminar bloques duplicados del código de script del lado del cliente que está siendo enviado al cliente. Los bloques duplicados son scripts con el mismo valor de tecla. El método "IHTTPHandler.ProcessRequest(HTTPContext Context)" es usado para procesar peticiones web. El IHTTPHandler.ProcessRequest es llamado para iniciar el procesamiento de una petición HTTP recibida de un cliente (ver la operación 602 de la figura 6). El método "IHTTPHandler.IsReusable()" indica si un objeto de página puede ser reutilizado para atender múltiples peticiones web.

Las formas de realización de la invención descritas aquí son implementadas como pasos lógicos en uno o más sistemas informáticos. Las operaciones lógicas de la presente invención son implementadas (1) como secuencia de pasos implementados por procesador que se ejecutan en uno o más sistemas informáticos y (2) como módulos de máquina interconectados dentro de uno o más sistemas informáticos. La implementación es una cuestión de elección, dependiente de los requisitos de funcionamiento del sistema informático que implementa la invención. De manera correspondiente, se hace referencia a las operaciones lógicas que componen las formas de realización de la invención descritas aquí de manera diversa como operaciones, pasos, objetos o módulos.

La descripción, los ejemplos y los datos de arriba proveen una descripción completa de la fabricación y el uso de la composición de la invención. Además, muchas formas de realización de la invención pueden realizarse sin partir del ámbito de la invención como se define en las reivindicaciones anexas a continuación.

Claims (8)

1. Un método para el procesamiento del lado del servidor de al menos un elemento de interfaz de usuario del lado del cliente (106, 108, 110) incorporado en una página web (104) visualizada en un cliente (100), comprendiendo el método:

lectura (203) de una declaración de un recurso (310, 400);

generación (204) de una pluralidad de objetos de control del lado del servidor existentes de manera simultánea (318, 320, 322) que se corresponden de manera lógica con el elemento de la interfaz de usuario del lado del cliente, basada en la declaración;

procesamiento (206) de eventos del elemento de la interfaz de usuario del lado del cliente usando los objetos de control del lado del servidor existentes de manera simultánea; y

generación (208) de datos de lenguaje de creación a partir de los objetos de control del lado del servidor existentes de manera simultánea para incorporar el elemento de la interfaz de usuario del lado del cliente en la página web, con posterioridad a la operación de procesamiento.

2. El método de la reivindicación 1 donde la operación de generar una pluralidad de objetos de control del lado del servidor existentes de manera simultánea comprende:

generación de un primer objeto de control del lado del servidor que se corresponde con un primer elemento de la interfaz de usuario del lado del cliente; y

generación de un segundo objeto de control del lado del servidor que se corresponde con un primer elemento de la interfaz de usuario del lado del cliente, de tal forma que el primer y el segundo objeto de control del lado del servidor existen de manera simultánea.

3. El método de las reivindicaciones 1 ó 2, donde la operación de procesamiento comprende:

levantamiento de un evento del lado del servidor asociado a un primer objeto de control del lado del servidor.

4. El método de cualquiera de las reivindicaciones 1 a 3, donde la operación de procesamiento comprende además:

manejo del evento del lado del servidor usando un segundo objeto de control del lado del servidor.

5. El método de cualquiera de las reivindicaciones 1 a 4, donde la operación de procesamiento comprende además:

manejo del evento del lado del servidor usando un componente del servidor de la interfaz de no usuario.

6. El método de cualquiera de las reivindicaciones 1 a 5, donde la operación de generar una pluralidad de objetos de control del lado del servidor existentes de manera simultánea comprende:

generación de un primer objeto de control del lado del servidor que se corresponde con un elemento de la interfaz de usuario del lado del cliente; y

generación de un segundo objeto de control del lado del servidor que se corresponde con el elemento de la interfaz de usuario del lado del cliente, de tal forma que el primer y el segundo objeto de control del lado del servidor existen de manera simultánea.

7. Una señal de datos informáticos incorporada en una onda portadora legible por un sistema informático (500) y que codifica un programa informático el cual, cuando es ejecutado en dicho sistema informático, ejecuta todos los pasos del método de la reivindicación 1.

8. Un medio de almacenamiento del programa informático (516) legible por un sistema informático (500) y que codifica un programa informático el cual, cuando es ejecutado en dicho sistema informático, realiza todos los pasos del método según la reivindicación 1.