ES2824263T3

ES2824263T3 - Un sistema para sincronización de cambios en sitios web editados y aplicaciones interactivas

Info

Publication number: ES2824263T3
Application number: ES15748685T
Authority: ES
Inventors: Yuval Goldstein; Amit Kaufman; Oren Hollander
Original assignee: Wix com Ltd
Current assignee: Wix com Ltd
Priority date: 2014-02-11
Filing date: 2015-02-11
Publication date: 2021-05-11
Anticipated expiration: 2035-02-11
Also published as: EP3783521A1; AU2015216608A1; AU2023204128A1; AU2021202623A1; IL283386B2; AU2015216608B2; BR112016018374B1; US9805134B2; AU2021202623B2; CA2938813A1; IL247188B; AU2019219824B2; EP3105688A4; US20180025013A1; IL283386B1; EP3105688A1; BR112016018374A2; US20240265061A1; US10540419B2; IL264170A

Abstract

Un sistema para modificar un sitio web o una aplicación interactiva, siendo el sistema implementable en un dispositivo informático, el sistema caracterizado por: una base de datos publicada (130) accesible a través de un servicio de datos de usuario final para presentar al menos la versión más actualizada de los objetos de dicho sitio web, siendo dichos objetos al menos uno de definido por esquema y definido por sistema y visual, visible y editable por al menos un usuario; una base de datos de borradores (140) accesible a través de un servicio de datos de diseñador y visible y editable por al menos un diseñador para almacenar al menos ediciones en dichos objetos de dicha base de datos publicada; un manejador de solicitudes de bases de datos publicadas (105) para coordinar la visualización y actualización simultáneas de dichos objetos entre dicho servicio de datos de usuario final y dicha base de datos publicada (130) mientras se ejecuta dicho sitio web; un manejador de solicitudes de base de datos de borradores (110) para coordinar la visualización, edición y actualización simultáneas de dichos objetos entre dicho servicio de datos de diseñador y dicha base de datos de borradores (140) y para fusionar al menos una de las ediciones y actualizaciones de dichos objetos de dicha base de datos publicada (130) y edita y actualiza dichos objetos en dicha base de datos de borradores (140) y para devolver la versión fusionada de dichos objetos a dicho al menos un diseñador a través de dicho servicio de datos de diseñadores sin modificar dicha base de datos publicada (130) mientras se ejecuta dicho sitio web; un sistema auxiliar (120) para actualizar dicha base de datos publicada (130) sobre la base de dicha edición y actualización de dichos objetos en dicha base de datos de borradores a través de dicho servicio de datos de diseñador; un solucionador de conflictos (113) para resolver conflictos provocados por dichas ediciones y actualizaciones entrantes de múltiples fuentes, comprendiendo dicho solucionador de conflictos (113) un comparador y un fusionador de componentes (116) para realizar una comparación y una fusión orientadas a objetos para determinar diferentes versiones de dichos objetos.

Description

DESCRIPCIÓN

Un sistema para sincronización de cambios en sitios web editados y aplicaciones interactivas

Referencia cruzada a solicitudes relacionadas

Esta solicitud reivindica la prioridad de la solicitud de patente provisional de EE. UU. n.° 61/938.166, presentada el 11 de febrero de 2014.

Campo de la invención

La presente invención se refiere a sitios web y aplicaciones interactivas en general y a la actualización de versiones en particular.

Antecedentes de la invención

A menudo se crean sitios web interactivos a gran escala utilizando un sistema de construcción de sitios web. Este sistema de construcción de sitios web a menudo se encarga de la construcción del sitio web, así como de su implementación. En tal escenario, el sistema de construcción de sitios web proporciona el entorno de diseño, así como la infraestructura de servidor que sirve páginas a los usuarios del sitio web. Dichos sistemas de construcción e implementación de sitios web generalmente brindan capacidades de construcción y edición de datos de usuario final, lo que permite que el contenido generado por usuario se agregue al sitio web (así como la modificación y eliminación de contenido generado por usuario).

Estas capacidades pueden incluir soporte de contenido generado por usuario de varios niveles, p. ej. permitiendo que algunos usuarios diseñen un sitio de creación de blogs, algunos usuarios creen nuevos blogs, algunos usuarios agreguen entradas de blog y algunos usuarios solo agreguen contestaciones a las entradas de blogs existentes. El sistema de construcción e implementación de sitios web puede permitir además diferentes capacidades de edición y diseño visual en cada nivel.

Por tanto, no existe una separación clara entre diseñadores y usuarios finales. Además, algunos usuarios pueden tener destreza técnica y estar familiarizados con el sistema (por ejemplo, diseñadores profesionales) y algunos pueden ser usuarios más incidentales y posiblemente no técnicos.

Muchos sistemas de construcción e implementación de sitios web utilizan una base de datos interna subyacente o un repositorio para almacenar los detalles de los sitios web, las páginas, los componentes y la información relacionada. En tales sistemas, las páginas mostradas se generan en función de la estructura de objetos subyacente del sitio web. Algunos sistemas de construcción e implementación de sitios web también pueden proporcionar capacidades adicionales de acceso a base de datos (por ejemplo, para la capacidad de lista de datos, integración de bases de datos, integración de sistemas de gestión de contenido y similares). Dichos sistemas de gestión de contenido / base de datos pueden ser internos al sistema de implementación y construcción de sitios web, o un sistema de gestión de contenido / base de datos externo al que accede el sistema de implementación y construcción de sitios web.

Un sistema de gestión de contenido / base de datos de este tipo también se puede utilizar para almacenar algunos componentes de sitio web, elementos de contenido específicos generados por el usuario o cualquier otro dato. Según el ejemplo anterior, el sistema de construcción e implementación de sitios web puede almacenar la definición de blog en su repositorio interno, pero almacenar entradas de blog y comentarios de blogs en dos bases de datos externas adicionales.

En muchos sistemas, los sitios web implementados (publicados) deben permanecer y estar funcionamiento en todo momento; no hay forma de cerrar el sitio web, lo que puede ser fundamental para el negocio del propietario del sitio. Sin embargo, el desarrollo y el mantenimiento del sitio pueden requerir cambios en el sitio web. Dichos cambios en el sitio web pueden requerir la modificación de varias áreas en la base de datos y, por lo tanto, "romper" el sitio web si se publica antes de ser completado. Además, dichos cambios en el sitio web deben probarse antes de estar disponibles para los usuarios del sitio web. Los diseñadores responsables de la modificación a menudo necesitan la opción de aplicar cambios o descartarlos, y posiblemente la opción de retroceder a una versión anterior del sitio web incluso después de que los cambios se hayan aplicado al sistema en ejecución.

Además, varios diseñadores (o usuarios) pueden estar trabajando en cambios en el sitio web que deben aplicarse al sistema en ejecución mientras se resuelven conflictos entre estos cambios. Esto podría ser un único gran cambio o varios cambios separados (posiblemente de varias áreas).

Algunos sistemas de construcción e implementación de sitios web admiten la integración de información de bases de datos (también conocidas como listas de datos). Esta información de base de datos puede formatearse, teniendo una estructura dada definida por uno o más esquemas de base de datos. Los cambios en el sitio web podrían requerir que se modifiquen algunos de los esquemas. Sin embargo, el sitio web debería seguir funcionando mientras se cambia el esquema. El cambio de esquema podría ser parte de un cambio mayor, por lo que se requieren cambios adicionales en el sitio web para que todo el cambio combinado sea efectivo. Además, a medida que el sitio web continúa funcionando, los diseñadores y usuarios (en varios niveles) podrían continuar agregando o modificando datos que están formateados de acuerdo con versiones de esquema anteriores.

La solución común es que los diseñadores utilicen una copia o versión separada del sitio web, conocida como la versión de desarrollo del sitio web. Los cambios se "publican" en la versión públicamente disponible del sitio (conocida como versión de producción o pública del sitio) solo cuando están terminados y probados.

Además, los diseñadores suelen utilizar un sistema de control de versiones para gestionar los elementos del sitio web que se están editando. Los sistemas de control de versiones permiten al diseñador crear ramas del conjunto de elementos gestionados, realizar cambios, confirmar cambios, descartar cambios y retroceder a una versión anterior.

El documento US 2005/0289454 A1 divulga un sistema en el que el contenido de un sitio web interactivo es gestionado por una aplicación que comprende dos sistemas de información. El sistema visual reproduce un programa interactivo que depende y está determinado por el sistema administrativo que proporciona acceso a varias bases de datos y permite al usuario recuperar y configurar los diversos componentes de la base de datos en pantallas únicas que se pueden ver a través de comandos activados.

Resumen de la presente invención

El objeto de la invención se resuelve mediante las características de las reivindicaciones independientes. Otras realizaciones son el objeto de las reivindicaciones dependientes. Se proporciona, según una realización preferida de la presente invención, un sistema para modificar un sitio web o una aplicación interactiva, el sistema se puede implementar en un dispositivo informático, el sistema incluye una base de datos publicada accesible a través de un servicio de datos de usuario final para presentar al menos la versión más actualizada de los objetos de sitio web, siendo los objetos al menos uno de definido por esquema, definido por sistema y visual, visible y editable por al menos un usuario. El sistema también incluye una base de datos de borradores accesible a través de un servicio de datos de diseñador y visible y editable por al menos un diseñador para almacenar al menos ediciones de los objetos de la base de datos publicada; un manejador de solicitudes de base de datos publicada para coordinar la visualización y la actualización simultáneas de los objetos entre el servicio de datos de usuario final y la base de datos publicada mientras se ejecuta el sitio web; un manejador de solicitudes de base de datos de borradores para coordinar la visualización, edición y actualización simultáneas de los objetos entre el servicio de datos de diseñador y la base de datos de borradores y para fusionar al menos una de las ediciones y actualizaciones de los objetos de la base de datos publicada y las ediciones y actualizaciones de los objetos en la base de datos de borradores y devolver la versión fusionada de los objetos al por lo menos un diseñador a través del servicio de datos de diseñadores sin modificar la base de datos publicada mientras el sitio web está en funcionamiento; y un sistema auxiliar para actualizar la base de datos publicada sobre la base de la edición y la actualización de los objetos en la base de datos de borradores a través del servicio de datos de diseñador.

Además, según una realización preferida de la presente invención, el sistema incluye un solucionador de conflictos para resolver conflictos provocados por ediciones entrantes y actualizaciones de múltiples fuentes.

Además, según una realización preferida de la presente invención, el sistema incluye una base de datos de listas para almacenar listas y listar aplicaciones.

Además, según una realización preferida de la presente invención, las listas incluyen artículos de lista definidos de acuerdo con un esquema, y cuando una única lista incluye al menos uno de los artículos construidos de acuerdo con una única versión de esquema, artículos construidos de acuerdo con múltiples versiones de un esquema dado y artículos construidos según múltiples esquemas.

Además, según una realización preferida de la presente invención, el sistema incluye un sistema de control de versiones.

Además, según una realización preferida de la presente invención, la base de datos de borradores incluye una base de datos de objetos eliminados para almacenar un identificador único de los objetos eliminados de la base de datos de borradores.

Además, según una realización preferida de la presente invención, la base de datos de borradores y la base de datos publicada se combinan en una única base de datos.

Además, según una realización preferida de la presente invención, el manejador de solicitudes de base de datos publicada y el manejador de solicitudes de base de datos de borradores comprenden al menos uno de: un adaptador de artículos para realizar la adaptación de los artículos de lista a diferentes versiones de esquema de acuerdo con las solicitudes utilizando al menos uno de manejo basado en ID y manejo basado en cambios y devolver los artículos de lista adaptados a través de al menos uno del servicio de datos de usuario final y el servicio de datos de diseñador; y un reescritor de consultas para modificar consultas de lectura realizadas en al menos una de la base de datos publicada y la base de datos de borradores para respaldar la recuperación de los artículos de lista guardados en diferentes versiones de un esquema dado basado en el análisis de las condiciones de consulta contra al menos uno del campo de valores predeterminados y el campo de valores predeterminados eliminados en diferentes versiones de esquema.

Además, según una realización preferida de la presente invención, el manejador de solicitudes de base de datos de borradores incluye un manejador de cambios de tipo de artículo para gestionar modificaciones de definición de tipo de los objetos de sitio web de acuerdo con las solicitudes.

Además, según una realización preferida de la presente invención, el solucionador de conflictos incluye un comparador y un fusionador de componentes para realizar una comparación y una fusión orientadas a objetos para determinar diferentes versiones de los objetos.

Además, según una realización preferida de la presente invención, el sistema auxiliar incluye al menos uno de: un actualizador automático para notificar al por lo menos un diseñador a través del servicio de datos de diseñador en cuanto a los cambios realizados a un sitio web actualmente editado por otro al menos un diseñador y fusionar los cambios en el sitio web editado actualmente; un publicador para publicar al menos uno de los cambios totales y un subconjunto de cambios de la base de datos de borradores a la base de datos publicada y para borrar los cambios de la base de datos de borradores; un archivador para almacenar y recuperar al menos una de versiones archivadas totales o parciales de los objetos en una base de datos de archivo; un registrador de historial de edición para registrar el historial de edición durante la edición por el al menos un diseñador en una base de datos de historial de edición; un analizador de historial de edición para analizar el historial de edición en la base de datos de historial de edición; un revertidor para revertir los objetos contenidos en la base de datos de borradores a una versión de la base de datos archivada, siendo la versión al menos una anterior o posterior a la versión editada actualmente, y donde la versión de la base de datos archivada se convierte en la versión actualmente editada y donde la reversión se limita a datos que no están en la lista e incluye soporte para etiquetar cambios de atributos a través del seguimiento del historial de edición de etiquetas o la coincidencia de ID de etiqueta; un clonador para crear copias de la base de datos publicada y la base de datos de borradores; y un creador de la base de datos para crear la base de datos publicada y la base de datos de borradores la primera vez que se utilizan.

Además, según una realización preferida de la presente invención, el actualizador automático incluye un distribuidor de línea de base para monitorizar cambios desde una versión de línea de base definida de los objetos de sitio web editado actualmente en la base de datos de borradores.

Además, según una realización preferida de la presente invención, el solucionador de conflictos incluye un solucionador de conjuntos de cambios para cambiar la clasificación de conjuntos para integrar conjuntos de cambios recibidos de al menos dos del servicio de datos de usuario final, el servicio de diseñador y el sistema de control de versiones.

Además, según una realización preferida de la presente invención, el sistema también incluye un clasificador de solicitudes para realizar la clasificación de las solicitudes entrantes del servicio de datos de usuario final y del servicio de datos de diseñador en al menos una comunidad; y un clasificador de usuarios para acceder a perfiles de usuario desde un repositorio de perfiles de usuario.

Además, según una realización preferida de la presente invención, el solucionador de conflictos es al menos uno entre automático, semiautomático y manual.

Además, según una realización preferida de la presente invención, el sistema de control de versiones también incluye un manejador de ramas para manejar operaciones de rama en el sitio web.

Además, según una realización preferida de la presente invención, la base de datos publicada y la base de datos de borradores son al menos una de una base de datos, un repositorio de objetos, una colección de archivos de lenguaje de marcado y un sistema de archivos.

Además, según una realización preferida de la presente invención, la base de datos publicada y la base de datos de borradores son al menos una de las que se encuentran en memoria, almacenadas localmente, almacenadas remotamente y almacenadas en la nube.

Además, según una realización preferida de la presente invención, las ediciones son al menos una de adición, supresión o modificación.

Además, según una realización preferida de la presente invención, las ediciones y actualizaciones son al menos una de adición de esquema, eliminación de esquema o cambio de esquema.

Además, según una realización preferida de la presente invención, las ediciones son al menos una originada por el usuario, originada por el diseñador y originada por el sistema.

Además, según una realización preferida de la presente invención, la al menos una comunidad es al menos una de entre la clase de usuario, el tipo de usuario, los criterios definidos por el diseñador, la ubicación física de usuario, el tipo de dispositivo de acceso de usuario, el tipo de método de acceso de usuario y la ubicación geográfica de usuario.

Además, según una realización preferida de la presente invención, el distribuidor de línea de base se activa mediante al menos uno de los ajustes de tiempo y frecuencia, solicitud de diseñador, cantidad de cambios acumulados, criticidad de los cambios acumulados y preajuste de diseñador.

Además, según una realización preferida de la presente invención, la clasificación es al menos una de la interfaz utilizada para crear el conjunto de cambios; el método utilizado para crear el conjunto de cambios dentro de la interfaz específica; la identidad del usuario que creó el conjunto de cambios; el tipo de objeto u objetos que se cambiaron en el conjunto de cambios; los objetos específicos que se cambiaron en el conjunto de cambios; el tipo de cambios incluidos en el conjunto de cambios; el alcance de los cambios incluidos en el conjunto de cambios y la especificación del diseñador de aplicación.

Además, según una realización preferida de la presente invención, la clasificación es de acuerdo con al menos uno del número de objetos modificados incluidos en un conjunto de cambios; la existencia de cambios específicos en atributos de objetos específicos; el efecto visual combinado de un conjunto de cambios y reglas y pautas predefinidas. Se proporciona, según una realización preferida de la presente invención, un método para modificar un sitio web o una aplicación interactiva, el método incluye presentar una versión actualizada de los objetos de una base de datos publicada del sitio web, siendo los objetos al menos uno de definido por esquema, definido por sistema y visual, visible y editable por al menos un usuario; ver y editar una base de datos de borradores del sitio web donde la base de datos de borradores almacena al menos las ediciones de los objetos de la base de datos publicada; coordinar la visualización y actualización simultáneas de los objetos entre el servicio de datos de usuario final y la base de datos publicada mientras se ejecuta el sitio web; coordinar la visualización, edición y actualización simultáneas de los objetos entre el servicio de datos de diseñador y la base de datos de borradores y fusionar al menos una de las ediciones y actualizaciones de los objetos de la base de datos publicada y las ediciones y actualizaciones de los objetos en la base de datos de borradores y devolver la versión fusionada de los objetos para al menos un diseñador a través del servicio de datos de diseñadores sin modificar la base de datos publicada mientras se ejecuta el sitio web; y actualizar la base de datos publicada basándose en la edición y la actualización de los objetos en la base de datos de borradores a través del servicio de datos de diseñador.

Además, según una realización preferida de la presente invención, el método incluye resolver conflictos provocados por ediciones entrantes y actualizaciones de múltiples fuentes.

Además, según una realización preferida de la presente invención, el método incluye almacenar listas y aplicaciones de listas en una base de datos de listas.

Además, según una realización preferida de la presente invención, el método incluye usar un sistema de control de versiones. Además, según una realización preferida de la presente invención, el método también incluye almacenar un identificador único de objetos eliminados de la base de datos de borradores en una base de datos de objetos eliminados.

Además, según una realización preferida de la presente invención, la coordinación de la visualización y actualización simultáneas de los objetos entre el servicio de datos de usuario final y la base de datos publicada y la coordinación de la visualización, edición y actualización simultáneas de los objetos entre el servicio de datos de diseñador y la base de datos de borradores y la fusión y actualización comprenden al menos uno de realizar la adaptación de artículos de lista a diferentes versiones del esquema de acuerdo con las solicitudes usando al menos uno de manejo basado en ID y manejo basado en cambios; y devolver los artículos de lista adaptados a través de al menos uno del servicio de datos de usuario final y el servicio de datos de diseñador; y modificar las consultas de lectura realizadas en al menos una de las bases de datos publicadas y la base de datos de borradores para respaldar la recuperación de los artículos de lista guardados en diferentes versiones de un esquema dado en función del análisis de las condiciones de la consulta frente al menos a uno del campo de valores predeterminados agregado y el campo de valores predeterminados eliminado en diferentes versiones de esquema.

Además, según una realización preferida de la presente invención, la coordinación de la visualización, edición y actualización simultáneas de los objetos entre el servicio de datos de diseñador y la base de datos de borradores y la fusión y actualización incluye el manejo de modificaciones de definición de tipo de los objetos de sitio web según las solicitudes.

Además, según una realización preferida de la presente invención, la resolución de conflictos incluye realizar una comparación orientada a objetos y fusionar para determinar diferentes versiones de los objetos.

Además, según una realización preferida de la presente invención, la coordinación de la visualización, edición y actualización simultáneas de los objetos entre el servicio de datos de diseñador y la base de datos de borradores y la fusión y actualización incluyen el manejo de modificaciones de definición de tipo de los objetos de sitio web de acuerdo con las solicitudes.

Además, según una realización preferida de la presente invención, la actualización incluye al menos una de notificar al por lo menos un diseñador a través del servicio de datos de diseñador en cuanto a los cambios realizados en un sitio web actualmente editado por otro al menos un diseñador y fusionar los cambios al sitio web editado actualmente; publicar al menos uno de los cambios totales y un subconjunto de cambios de la base de datos de borradores a la base de datos publicada y borrar los cambios de la base de datos de borradores; almacenar y recuperar al menos una de las versiones archivadas total o parcial de los objetos en una base de datos de archivo; registrar el historial de edición durante la edición por parte del al menos un diseñador en una base de datos de historial de edición; analizar el historial de edición en la base de datos de historial de edición; revertir los objetos contenidos en la base de datos de borradores a una versión de la base de datos archivada, siendo la versión al menos una anterior o posterior a la versión editada actualmente, y donde la versión de la base de datos archivada se convierte en la versión actualmente editada y donde la reversión está limitada a datos que no están en la lista e incluye soporte para cambios de atributos de etiquetas mediante el seguimiento de historial de edición de etiquetas o la coincidencia de ID de etiquetas; crear copias de la base de datos publicada y de la base de datos de borradores; y crear la base de datos publicada y la base de datos de borradores la primera vez que se utilizan.

Además, según una realización preferida de la presente invención, la notificación y la fusión incluyen monitorizar los cambios de una versión de línea de base definida de los objetos de sitio web actualmente editado en la base de datos de borradores.

Además, según una realización preferida de la presente invención, la resolución de conflictos incluye resolver la clasificación de conjunto de cambios para integrar los conjuntos de cambios recibidos de al menos dos del servicio de datos de usuario final, el servicio de diseñador y el sistema de control de versiones.

Además, según una realización preferida de la presente invención, el método incluye realizar la clasificación de las solicitudes entrantes del servicio de datos de usuario final y del servicio de datos de diseñador en al menos una comunidad; y acceder a perfiles de usuario desde un repositorio de perfiles de usuario.

Además, según una realización preferida de la presente invención, la resolución de conflictos es al menos automática, semiautomática y manual.

Además, según una realización preferida de la presente invención, el método incluye el manejo de operaciones de ramas en el sitio web.

Además, según una realización preferida de la presente invención, las ediciones y actualizaciones son al menos una originada por el usuario, originada por el diseñador y originada por el sistema.

Además, según una realización preferida de la presente invención, los cambios de monitorización se activan mediante al menos uno de los ajustes de tiempo y frecuencia, solicitud de diseñador, cantidad de cambios acumulados, criticidad de los cambios acumulados y preajuste de diseñador.

Además, según una realización preferida de la presente invención, la clasificación de ejecución es al menos una de las interfaces utilizadas para crear el conjunto de cambios; el método utilizado para crear el conjunto de cambios dentro de la interfaz específica; la identidad del usuario que creó el conjunto de cambios; el tipo de objeto u objetos que se cambiaron en el conjunto de cambios; los objetos específicos que se cambiaron en el conjunto de cambios; el tipo de cambios incluidos en el conjunto de cambios; el alcance de los cambios incluidos en el conjunto de cambios y la especificación del diseñador de la aplicación.

Además, según una realización preferida de la presente invención, la clasificación de ejecución es de acuerdo con al menos uno del número de objetos modificados incluidos en el conjunto de cambios; la existencia de cambios específicos en atributos de objetos específicos; el efecto visual combinado del conjunto de cambios y las reglas y directrices predefinidas.

Breve descripción de los dibujos

El objeto considerado como la invención se señala en particular y se reivindica claramente en la parte final de la memoria descriptiva. Sin embargo, la invención, tanto en la organización como en el método de funcionamiento, junto con los objetos, características y ventajas de la misma, se puede entender mejor haciendo referencia a la siguiente descripción detallada cuando se lea con los dibujos adjuntos en los que:

La Figura 1 es una ilustración esquemática de un sistema para sincronizar modificaciones a sitios web, construidos y operativos de acuerdo con la presente invención.

Las Figuras 2A y 2B son ilustraciones esquemáticas de los elementos de dos realizaciones del procesador de modificaciones de la Figura 1, construidas y operativas de acuerdo con la presente invención;

La Figura 3 es una ilustración esquemática de los elementos del subsistema auxiliar del procesador de modificaciones de la Figura 2; construido y operativo de acuerdo con la presente invención;

Las Figuras 4A y 4B son ilustraciones esquemáticas de los manejadores de solicitudes de las Figuras 2A y 2B, construidos y operativos de acuerdo con la presente invención;

La Figura 5 es una ilustración esquemática de posibles operaciones de lectura y de modificación.

Las Figuras 6A, 6B, 6C y 6D son ilustraciones esquemáticas de diferentes escenarios de reversión para el sistema de la Figura 1, construido y operativo de acuerdo con la presente invención;

La Figura 7 es una ilustración esquemática de la función del actualizador automático de la Figura 3; construido y operativo de acuerdo con la presente invención;

Las Figuras 8, 9 y 10 son ilustraciones esquemáticas de realizaciones alternativas al sistema de la Figura 1, construido y operativo de acuerdo con la presente invención; y

La Figura 11 es una ilustración esquemática de una realización alternativa al solucionador de conflictos de la Figura 3, construido y operativo de acuerdo con la presente invención.

Se apreciará que por simplicidad y claridad de ilustración, los elementos mostrados en las figuras no se han dibujado necesariamente a escala. Por ejemplo, las dimensiones de algunos de los elementos pueden exagerarse en relación con otros elementos por claridad. Además, cuando se considere apropiado, los números de referencia pueden repetirse entre las figuras para indicar elementos correspondientes o análogos.

Descripción detallada de la presente invención

En la siguiente descripción detallada, se exponen numerosos detalles específicos con el fin de proporcionar una comprensión completa de la invención. Sin embargo, los expertos en la técnica entenderán que la presente invención se puede poner en práctica sin estos detalles específicos. En otros casos, no se han descrito en detalle métodos, procedimientos y componentes bien conocidos para no oscurecer la presente invención.

Los solicitantes se han dado cuenta de que un sistema de construcción de sitios web debe permitir hacer modificaciones por separado del sitio en ejecución, de modo que los cambios puedan evaluarse y probarse, y no afectar al sitio web en ejecución. Dicho sistema también debería soportar operaciones de confirmación y retroceso para versiones de sitios web creados.

Los solicitantes se han dado cuenta además de que esto requiere la capacidad de modificar y probar los cambios mientras el sitio web está en funcionamiento. Este requisito se ve agravado por la necesidad de admitir varios cambios, posiblemente realizados por varios usuarios, que deben integrarse en el sitio web en ejecución.

Los solicitantes también se han dado cuenta de que el uso de un sistema de control de versiones como se discutió en el presente documento anteriormente tiene varios inconvenientes y dificultades. Por ejemplo, algunos sitios web son muy grandes y posiblemente contienen grandes cantidades de datos que se están proporcionando, por lo que el sitio web no se puede duplicar fácilmente y los diseñadores tendrían que trabajar en el sitio web existente, o al menos en una rama del sitio web mantenido por el sistema de control de versiones. La creación de ramas también puede ser difícil o llevar mucho tiempo en un sitio web a gran escala.

La mayoría de los sistemas de control de versiones comerciales están destinados al mantenimiento y manejo del código fuente de programa, que es esencialmente un conjunto de archivos de texto. Sin embargo, los elementos subyacentes gestionados por el sistema de construcción e implementación de sitios web son típicamente conjuntos de objetos o registros de bases de datos y no archivos de texto (los archivos HTML mostrados se generan dinámicamente y no se gestionan por separado).

Los sistemas de control de versiones también hacen un uso intensivo de la operación de fusión, por ejemplo, al fusionar una rama modificada con una versión de línea de base que también se modificó. Los algoritmos de fusión de alta calidad o semiautomáticos ayudan enormemente en la integración de versiones modificadas y la resolución de conflictos (por ejemplo, resultantes de cambios realizados por varios desarrolladores). Sin embargo, los sistemas de control de versiones también suelen incluir algoritmos de fusión basados en texto, que se centran en las diferencias y la fusión de líneas de texto. Estos algoritmos no se adaptan bien a los repositorios basados en objetos. Además, estos algoritmos no utilizan la información de estructura del objeto (o base de datos) para ayudar en la comparación.

Los sistemas actuales también asumen que los usuarios se dividen en dos clases separadas y distintas: diseñadores, que pueden modificar el sitio web y trabajar a través de un sistema de control de versiones integrado con el sistema de construcción e implementación de sitios web y usuarios finales, que solo pueden ver el sitio web, y trabajar a través del sistema de construcción e implementación de sitios web que genera las páginas vistas sin usar el sistema de control de versiones. Sin embargo, este enfoque dicotómico puede resultar problemático cuando hay varios "niveles de diseñador" y los usuarios finales también pueden modificar el sitio web.

En otro escenario, algunos de los usuarios que modifican el sitio web pueden ser usuarios no técnicos (y posiblemente incidentales), que no están familiarizados con el funcionamiento y la metodología del sistema de control de versiones, p. ej. solo quieren agregar publicaciones a un sitio web de blogs y realizar algunos trabajos de diseño en el disposición de la publicación de blog. Si se requiere que estos usuarios no técnicos utilicen el sistema de control de versiones, es posible que encuentren el sistema demasiado difícil de usar. Por un lado, el sistema de control de versiones podría requerir el control del repositorio subyacente, de modo que todos los cambios a este repositorio deben realizarse a través del sistema de control de versiones, lo que imposibilita la omisión del sistema de control de versiones. Por otro lado, si el sistema permite que los usuarios no técnicos eludan el sistema de control de versiones (al acceder al sitio directamente a través del sistema de construcción e implementación de sitios web), el sistema puede perder las ventajas conferidas por el sistema de control de versiones (por ejemplo, gestión de versiones), capacidad de fusión, etc.)

Además, cuando un diseñador cambia un sitio web (trabajando en una rama), otros diseñadores o usuarios aún pueden realizar modificaciones sustanciales en el sitio web principal. Por lo tanto, el diseñador podría estar trabajando en una rama separada y "congelada" del sitio web y podría que no esté al tanto de estos otros cambios, que podrían ser relevantes para su trabajo.

Se apreciará que para un sitio web que incluye una base de datos integrada, un esquema puede estar asociado con un gran número de artículos de datos en la base de datos integrada. Cambiar el esquema (por ejemplo, agregar un campo) podría requerir que se realicen cambios en todos los artículos asociados. Tal cambio puede llevar mucho tiempo, en particular si los cambios deben realizarse a través de un sistema de control de versiones que mantiene un registro de auditoría de todos los cambios. Esto también puede ser un problema si el sitio web está bloqueado mientras se realiza el cambio.

Ahora se hace referencia a la Figura 1 que ilustra un sistema 100 para sincronizar modificaciones a sitios web según una realización de la presente invención. Se apreciará que aunque el sistema 100 se describe en relación con sitios web, también puede usarse junto con otras aplicaciones interactivas en línea.

El sistema 100 puede gestionar la edición y visualización simultáneas de un sitio web grande basado en objetos que también puede incluir listas de datos de múltiples usuarios y diseñadores. Se apreciará que el sistema 100 puede emplear múltiples bases de datos para las versiones en borrador (actualmente editadas) y la versión publicada actual, así como bases de datos que contienen archivos de versiones anteriores de bases de datos publicadas. El sistema 100 se puede usar sin un sistema de control de versiones o se puede usar para complementar la funcionalidad de un sistema de control de versiones como se describe con más detalle a continuación.

El sistema 100 comprende un servidor de sistema de construcción de sitios web 10, un cliente de usuario 20 y un cliente de diseñador 30. El servidor de sistema de construcción de sitios web 10 comprende además un servicio de datos de usuario final 40, un servicio de datos de diseñador 50 y un procesador de modificaciones 60. Se apreciará que el servicio de datos de usuario final 40 y el servicio de datos de diseñador 50 pueden recibir solicitudes tanto de los usuarios como de los diseñadores del sitio web pertinente del cliente usuario 20 y del cliente diseñador 30 a través de un medio de comunicación adecuado como internet. El procesador de modificaciones 60 puede procesar cualquier solicitud de actualización como se describe con más detalle a continuación.

Se apreciará además que el cliente de usuario 20 puede comprender una interfaz de usuario sin editor, como un visualizador de usuario 24 para ver la versión del sitio web que se va a modificar y una base de datos almacenada en caché de usuario 25 para mantener páginas (y otras entidades) localmente mientras se edita y ve. El cliente de diseñador 30 también puede comprender un visualizador y un editor 34 y una base de datos en caché de diseñador 35 para mantener las páginas (y otras entidades) localmente mientras se edita y visualiza. En una realización alternativa, el cliente de usuario 20 puede comprender un visualizador y un editor para permitir que un usuario realice cambios menores en un sitio web como se describe con más detalle a continuación.

Se apreciará que las actualizaciones de datos al sistema 100 pueden llegar de múltiples fuentes, incluidas las originadas por el diseñador, las originadas por el usuario y las originadas por el sistema. Las actualizaciones pueden incluir agregar, eliminar o modificar datos. La modificación puede incluir varios atributos del objeto que se modifica.

También se apreciará que los diseñadores pueden realizar cambios en el sitio web utilizando un módulo de interfaz de usuario de editor (el editor) a través del visualizador y editor 34. Estos cambios pueden afectar el contenido de sitio (por ejemplo, texto e imágenes), información de lista (por ejemplo, artículos) y lista de tipos de artículos. Los diseñadores también pueden manipular los artículos de lista directamente, p. ej. utilizando una herramienta de carga masiva, en lugar de a través del editor.

Los usuarios pueden realizar más cambios menores en un sitio web a través del visualizador 24 cuando introducen o editan contenido generado por usuario en componentes que permiten tales cambios (por ejemplo, agregar entradas al componente de blog). Los usuarios también pueden realizar cambios que afecten a una lista de artículos (por ejemplo, agregar/eliminar/editar artículos en la lista). Los usuarios pueden tener derechos de edición limitados y específicos (por ejemplo, el derecho a editar componentes dentro de un contenedor específico). Los usuarios que acceden a una base de datos externa o un sistema de gestión de contenido pueden incluir una lista de artículos asociada con la aplicación.

Las bases de datos en caché 25 y 35 pueden estar en forma de en memoria, en disco o ser una base de datos remota y pueden usarse para mantener páginas (y otras entidades) localmente mientras se editan y visualizan.

Los cambios originados en el sistema pueden incluir usuarios que operan una aplicación externa que afecta a páginas o listas de artículos relacionadas con la aplicación (por ejemplo, operar una aplicación de carga de imágenes separada que agrega imágenes a las páginas o a una lista de artículos almacenada en un sistema de gestión de contenido asociado con la aplicación).

Se apreciará que diferentes diseñadores y usuarios finales pueden tener permisos específicos para capacidades de edición específicas.

El sistema 100 puede ser basado en objetos, manteniendo una estructura de datos interna y un repositorio de objetos (por ejemplo, páginas, componentes, etc.), sus atributos y relaciones. La visualización real en los visualizadores 24 y 34 puede generarse dinámicamente (basada en los datos de objeto almacenados) usando HTML5, Adobe Flash, una aplicación cliente dedicada o cualquier otro medio. Se apreciará que los objetos pueden ser objetos visuales y objetos de información almacenados y que los objetos también pueden estar definidos por esquema o por sistema.

Se apreciará que el sistema 100 puede manejar dos niveles de entidades relacionadas con sitio web: entidades de nivel de gestión "superior", como sitios web completos, proyectos y bibliotecas de medios, y entidades de nivel de diseño "inferior", como páginas de sitios web, componentes de página y archivos de medios. Las entidades de nivel de diseño suelen estar contenidas dentro de las entidades de nivel de gestión.

El sistema 100 también puede admitir varios tipos de relaciones entre estas entidades (entidad de nivel de gestión -entidad de nivel de gestión, entidad de nivel de gestión - entidad de nivel de diseño y entidad de nivel de diseño -entidad de nivel de diseño) como se describe con más detalle a continuación.

Las entidades de nivel de gestión pueden incluir proyectos (por ejemplo, colecciones de sitios web y otros elementos relacionados), subproyectos, bibliotecas de medios (por ejemplo, colecciones de imágenes) y sitios web, incluidos (por ejemplo) completos/publicables, sitios web que se están editando o secciones de sitio web que se utilizarán para inclusión en otros sitios web. Estos también pueden incluir sitios web habituales, así como sitios web específicos para dispositivos móviles u otros. Las entidades de nivel de gestión también pueden incluir aplicaciones de terceros (tanto bibliotecas de aplicaciones de terceros como aplicaciones de terceros independientes proporcionadas por un proveedor de aplicaciones de terceros externo) y listas - artículos de datos y colecciones de tipos de datos (posiblemente incluidos artículos que se ajustan a varios tipos). Las entidades de nivel de gestión también pueden incluir aplicaciones de lista: colecciones de definiciones y vistas que describen cómo se debe manejar, modificar y mostrar una lista. Se apreciará que las propias vistas son esencialmente plantillas de página (como se describe a continuación en el presente documento) y, por tanto, son entidades de nivel de diseño en lugar de entidades de nivel de gestión. Aplicaciones de lista se describen en la publicación de patente de EE. UU. 2014/0282218 publicada el 18 de septiembre de 2014 y cedida al cesionario común de la presente invención.

El manejo de entidades a nivel de gestión generalmente incluye el manejo de usuarios, sus perfiles y sus permisos y privilegios. Las entidades de nivel de gestión normalmente contienen entidades de nivel de diseño, pero también pueden contener otras entidades de nivel de gestión (por ejemplo, un sistema que permite subproyectos y subsubproyectos).

El sistema 100 puede implementar cualquier subconjunto de los elementos de arquitectura como se describe en este documento anteriormente, y también puede implementar restricciones específicas sobre su estructura y relaciones. Por ejemplo, el sistema 100 puede permitir el uso de algunas entidades de nivel de gestión (como aplicaciones de terceros y bibliotecas de medios) solo dentro de la entidad de nivel de gestión de nivel superior que las incluye (por ejemplo, un subproyecto), o dentro del conjunto de proyectos completo, o puede requerir una estructura jerárquica específica.

Un ejemplo más de una implementación específica, el sistema de diseño de sitios web de Wix (disponible en www.wix.com), implementa una jerarquía de entidades de nivel de gestión de 3 niveles específicos que incluye un Nivel 1: una cuenta (la colección de meta-sitios / bibliotecas de medios para el propietario de un sitio específico), un Nivel 2: el meta-sitio (es decir, el proyecto) y las bibliotecas de medios (bibliotecas de imágenes, etc.) y el Nivel 3 (todo en el "meta-sitio" anterior): el sitio web, el sitio móvil y cualquier aplicación de terceros y aplicaciones de lista como se describe aquí arriba.

Se apreciará que bajo el sistema Wix, cada cuenta puede tener un solo usuario único (el propietario del sitio) que tiene privilegios completos de gestión y acceso para la cuenta. El modelo general permite múltiples de tales usuarios para cada cuenta con privilegios específicos para cada uno.

Las entidades de nivel de diseño incluyen los bloques de construcción visuales de sitios web que consisten en páginas que incluyen componentes. Las páginas pueden tener una estructura jerárquica, creada mediante el uso de componentes contenedores que pueden contener otros componentes (contenedores o atómicos). Los contenedores pueden ser contenedores de una o varias páginas. Los contenedores de varias páginas (también conocidos como galerías) muestran varias minipáginas, cada una de las cuales tiene su contenido independiente. Los componentes pueden incluir, por ejemplo: componentes de decoración (por ejemplo, una forma utilizada en el diseño de la página), componentes simples (por ejemplo, campo de texto, marco visual, etc.), componentes de objetos de medios (por ejemplo, imágenes, audio, vídeo), componentes complejos (por ejemplo, un navegador de mapas integrado) e instancias específicas de aplicaciones de terceros (definidas en la entidad de nivel de gestión anterior).

El sistema 100 también puede admitir plantillas: páginas completas, páginas parciales o componentes que se utilizan como base para la creación de instancias de la plantilla. Se dice que las instancias heredan de la plantilla. El sistema 100 puede admitir además herencia multinivel (A hereda de B, que hereda de C), herencia múltiple (A hereda de B y C) y herencia de diamante (A hereda de B y C, y B y C heredan de D).

Como se discutió anteriormente en el presente documento, el sistema 100 admite la noción de listas, que son colecciones de artículos, y cada artículo consta de campos de datos. La estructura de artículo (es decir, qué campos contiene) se define usando un tipo (también llamado tipo de artículo), y los diferentes artículos (incluso en la misma lista) pueden tener diferentes tipos. Los artículos se muestran a través de vistas que son plantillas que contienen marcadores de posición llenos de datos de los artículos. Una aplicación de lista puede incluir una definición de componente de enlace, una lista o listas asociadas y un conjunto de tipos y vistas de artículos relacionados. Las vistas se muestran dentro de componentes de enlace, que son esencialmente contenedores virtuales de varias páginas que muestran minipáginas virtuales generadas a partir de vistas y artículos correspondientes en una lista o listas dadas.

Un componente de enlace puede incluir criterios de filtro, que se utilizan para seleccionar qué artículos mostrar de una lista asociada con el componente de enlace dado. También pueden incluir criterios de ordenación utilizados para ordenar los artículos seleccionados. Se apreciará que los criterios de ordenación pueden incluir la ordenación de artículos por criterios tales como: valores de campo específicos, marca de tiempo de creación o actualización, ordenación manual y propietario (por ejemplo, los artículos del propietario del sitio siempre preceden a los artículos creados por otros usuarios).

El sistema 100 también puede admitir personalizaciones, como modificaciones específicas a las vistas que muestran artículos específicos. Por ejemplo, una aplicación de lista que muestra el menú de un restaurante puede requerir una personalización específica para resaltar un plato específico en el menú. Se apreciará que las listas y las aplicaciones de listas utilizadas para visualizarlas son entidades de nivel de gestión. La instancia de aplicación de lista real es una entidad de nivel de diseñador.

El sistema 100 puede clasificar listas de datos como una subentidad de sitio web, es decir, una lista dada "pertenece" a un sitio web dado y solo se puede utilizar dentro del sitio web dado. Alternativamente, el sistema puede clasificar listas como entidades de nivel de gestión genéricas, por lo que una lista dada podría reutilizarse en varios sitios web (pero posiblemente limitando el alcance de la lista a una entidad de nivel de gestión de proyecto dada, por ejemplo, en un conjunto de usuarios dado de sitios web).

Se apreciará que las bases de datos de listas pueden ser mucho más grandes (en volumen) y actualizarse con mucha más frecuencia que el resto de los elementos del sitio web. Por ejemplo, el sitio web de blog podría tener plantillas y páginas de navegación (que rara vez se actualizan), pero las entradas de blog reales y los comentarios como listas de datos. Un sitio web de publicación de álbumes podría almacenar los álbumes, las imágenes y los comentarios como listas de datos.

Como se discutió anteriormente en el presente documento, el sistema 100 puede soportar una variedad de posibles relaciones entre entidades de nivel de gestión y/o entidades de nivel de diseño. Los posibles tipos de relaciones (y ejemplos de su uso) pueden incluir relaciones de contención en las que los sitios web contienen las páginas y los componentes. Los proyectos pueden contener subproyectos que a su vez pueden contener subsubproyectos, etc., y las bibliotecas de medios pueden incluirse a nivel de sitio web, el nivel de proyecto o alguna combinación de niveles específicos.

Otro tipo de relación puede ser la herencia. Un sitio web podría basarse en (o heredarse de otro modo) de un segundo sitio web. En este escenario, el sistema 100 puede admitir la noción de un sitio web principal y versiones localizadas o personalizadas del sitio web que comparten la misma estructura mediante el uso de diferentes elementos textuales. El sistema 100 también puede admitir la herencia basada en plantillas, con un repositorio de plantillas a las que se hace referencia (heredadas) en diferentes sitios web.

Otro tipo de relación puede ser la instanciación. Un elemento (entidad de nivel de diseño) dentro de una entidad de nivel de gestión puede ser una instancia de una entidad de nivel de gestión o cualquier elemento de la misma. Por ejemplo, un sitio web puede contener una instancia de una aplicación de terceros (que es en sí misma una entidad de nivel de gestión).

Las entidades interconectadas (nivel de gestión y nivel de diseño) pueden formar un gráfico de conexión, que no debe contener círculos (es decir, mediante un gráfico acíclico dirigido - DAG, del inglés Directed Acyclic Graph), por lo que se puede realizar un análisis de dependencia entre estas entidades (p. ej., para determinar qué entidades deben ser publicadas sobre la base de una solicitud de publicación como se describe más adelante en el presente documento).

Se apreciará que los datos de objeto pueden mantenerse en una o más bases de datos. En particular, los datos visuales (es decir, páginas, componentes, vistas, tipos) se pueden mantener separados de los datos de lista (contenido real de artículo) como se describe con más detalle a continuación.

El sistema 100 se puede implementar en cualquier combinación de tecnologías de bases de datos subyacentes, como bases de datos estructuradas (por ejemplo, bases de datos SQL), bases de datos NoSQL, bases de datos orientadas a objetos, repositorios de estructura (por ejemplo, repositorios XML o JSON), etc. Además, el sistema 100 puede utilizar repositorios externos, como bases de datos o sistema(s) de gestión de contenido no gestionados directamente por el sistema. Por ejemplo, el sistema puede implementar una lista "virtual" que refleja los datos almacenados en repositorios externos, una base de datos externa o un sistema de gestión de contenido, y no es una base de datos separada por sí misma. El sistema 100 puede almacenar datos de medios (por ejemplo, campos de imagen) en un repositorio de imágenes externo y aplicaciones de terceros pueden almacenar algunos de los datos que gestionan en repositorios separados gestionados por el proveedor de aplicaciones de terceros. Dado que los datos de objeto se guardan en una o más bases de datos, el sistema 100 puede almacenar datos visuales (es decir, páginas, componentes, vistas, tipos) por separado de los datos de lista (contenido real de artículo).

Ahora se hace referencia a las Figuras 2A y 2B que ilustran los elementos del procesador de modificaciones 60 y su interacción con el servicio de datos de usuario 40 y el servicio de datos de diseñador 50. El procesador de modificación 60 comprende un coordinador de solicitudes de usuario 90, un coordinador de solicitudes de diseñador 95, un manejador de solicitudes de PDB (base de datos publicada) 105, un manejador de solicitudes de DDB 110 (base de datos de borradores), un subsistema auxiliar 120, una base de datos publicada 130, una base de datos de borradores 140 y una base de datos de archivo 150. La Figura 2A muestra una realización donde la lista y las aplicaciones de lista se almacenan en la base de datos publicada 130 y la base de datos de borradores 140 y la Figura 2B muestra una realización en la que se almacenan en una base de datos de lista separada 135 como se describe con más detalle a continuación. La base de datos de borradores 140 puede comprender además una base de datos de objetos eliminados asociada 145 que contiene los ID únicos de los objetos eliminados como se describe con más detalle a continuación.

Como se mencionó anteriormente, muchos sistemas de implementación y construcción de sitios web utilizan bases de datos o repositorios para almacenar detalles de sus sitios web. Se apreciará que todas las bases de datos pueden gestionar todos los elementos del sitio web, incluidas las páginas y componentes visuales, artículos de datos y tipos/esquemas de datos. La base de datos publicada 130 puede contener objetos publicados completos y representar el estado actual publicado del sitio web, es decir, el sitio web que ve un usuario. La base de datos de borradores 140 puede representar el estado del sitio web de desarrollo y puede contener borradores de cambios realizados en los objetos de sitio web por diseñadores que aún no se han publicado y la base de datos de archivo 150 puede contener un historial de versiones guardadas y publicadas de la base de datos como se describe con más detalle más adelante en este documento. Tanto la base de datos publicada 130 como la base de datos de borradores 140 pueden almacenar todas las entidades de nivel de diseñador y pueden almacenar algunas entidades de nivel de gestión. Los tipos de entidad pueden incluir, entre otros, plantillas, páginas del sitio web, componentes (componentes regulares y de lista), incluidos sus parámetros (tamaño, posición, etc.), personalizaciones: personalizaciones específicas (diseño, estilo, posición) para mostrar el campo de vista específico dentro de un componente de enlace, criterios de filtrado y clasificación, definiciones de vista: componentes, campos, tipos de artículos y artículos de datos reales. Se apreciará que aunque los artículos de datos reales están lógicamente en la misma base de datos, pueden almacenarse en una base de datos física separada (por ejemplo, debido a su tamaño y actualización rápida como se indicó anteriormente).

Se apreciará que todas las bases de datos (la base de datos de borradores 140, la base de datos publicada 130, la bases de datos de listas 135 y la base de datos de archivo 150) pueden implementarse utilizando la tecnología de base de datos actual más avanzada, utilizando uno o varios servidores de base de datos. Dichos servidores de bases de datos subyacentes manejan los detalles básicos de permitir que múltiples usuarios accedan a la misma base de datos o repositorio, evitando la corrupción física de la base de datos en múltiples actualizaciones y proporcionando capacidades de transacción. Todas las bases de datos (la base de datos de borradores 140, la base de datos publicada 130, la lista de base de datos 135 y la base de datos de archivo 150) también pueden estar en memoria, almacenadas localmente, almacenadas remotamente o almacenadas en la nube.

Por lo tanto, la operación de publicación (como se describe con más detalle a continuación) puede utilizar la capacidad de transacción de la base de datos subyacente para que la actualización real se realice como una unidad atómica y los usuarios no estén expuestos a un estado inconsistente del sitio web.

Se apreciará que algunas entidades de nivel de gestión están por encima del nivel de diseño de la base de datos publicada 130 y de la base de datos de borradores 140 (por ejemplo, la definición del usuario y lo que es público) y, por lo tanto, no serían almacenadas por ellas.

La base de datos publicada 130 también puede almacenar todos los cambios y solicitudes resultantes que no sean de editor al sitio web, incluidos los del contenido generado por usuario, los sistemas de gestión de contenido, las API y cualquier aplicación especial. Se apreciará que esto no es equivalente al almacenamiento de operaciones en cola que se puede encontrar en otros sistemas, es decir, la base de datos publicada 130 puede almacenar las entidades modificadas resultantes y no una serie de operadores de modificación. También se apreciará que el acceso de usuario (incluidas aplicaciones externas y clientes API) a la base de datos publicada 130 puede ser de solo lectura o solo agrega nuevas páginas o nuevos artículos de lista (como se describe en el presente documento anteriormente). El acceso de usuario no puede actualizar plantillas, atributos de componentes o tipos de artículos.

Se apreciará que tanto la base de datos publicada 130 como la base de datos de borradores 140 pueden configurarse como granjas de servidores independientes (es decir, agrupaciones de servidores diferentes). Las dos granjas de servidores pueden comunicarse "horizontalmente", por ejemplo, para realizar una lectura de base de datos de borradores 140 o una operación de publicación. En una realización alternativa, puede haber múltiples granjas y cada servidor puede ejecutar servicios de base de datos publicada 130 y servicios de base de datos de borradores 140 para un subconjunto dado de sitios web. Por ejemplo, pueden disponerse múltiples servidores de modo que cada servidor específico maneje los servicios de la base de datos publicada 130 y los servicios de la base de datos de borradores 140 para un subconjunto específico de los sitios manejados.

El coordinador de solicitudes del usuario 90 puede coordinar las solicitudes entrantes del cliente de usuario 20 y el coordinador de solicitudes de diseñador 95 puede coordinar cualquier solicitud entrante del cliente de diseñador 30.

También se puede apreciar que el sistema 100 puede utilizar adicionalmente información sobre los usuarios y el sitio web subyacente para determinar el manejo apropiado de los cambios del sitio web. El sistema 100 también puede soportar el enrutamiento dinámico de cambios para que puedan aplicarse directamente a la base de datos publicada 130 o almacenarse en la base de datos de borradores 140 como se describe con más detalle a continuación.

El sistema 100 también puede permitir a los diseñadores realizar modificaciones complejas en todo o parte del sitio web editado, y aún ver el contenido del sitio web, incluidos los cambios realizados simultáneamente por otros usuarios (en tiempo real o casi en tiempo real). También puede permitir que un diseñador cambie el esquema de objeto (es decir, el tipo de artículo) sin requerir ningún cambio en los artículos asociados con el esquema que se está modificando. Otros diseñadores y usuarios pueden seguir usando artículos existentes o creando nuevos artículos. La publicación del esquema modificado se puede realizar sin necesidad de conversión de artículos o tiempo de inactividad, y permite ver artículos creados con el esquema anterior a través del nuevo esquema.

El sistema 100 también puede rastrear los cambios realizados por un diseñador a través del cliente diseñador 30 y puede estar al tanto de los cambios específicos realizados en los objetos y esquemas. Puede admitir además la fusión inteligente, adaptada a la estructura del componente visual del sitio web y a la información de esquema específica para los artículos de datos asociados, como se describe con más detalle en el presente documento a continuación.

Ahora se hace referencia a la Figura 3 que ilustra los elementos del subsistema auxiliar 120. El subsistema auxiliar 120 puede recibir y procesar tipos de solicitudes adicionales recibidas del servicio de datos de diseñador 50 antes de enviar instrucciones a la base de datos publicada 130 y la base de datos de borradores 140 como se describe con más detalle a continuación El subsistema auxiliar 120 comprende un actualizador automático 121, un publicador 122, un archivador 123, un revertidor 124, una base de datos de historial de edición 125, un registrador de historial de edición 126, un analizador de historial de edición 127, un clonador 128 y un creador de bases de datos 129. El propósito del subsistema auxiliar 120 es proporcionar servicios adicionales relacionados con la base de datos publicada 130 y/o la base de datos de borradores 140. Estos servicios son adicionales al manejo de solicitudes de lectura y escritura que son manejadas por los manejadores de solicitudes 105 y 110. El actualizador automático 121 y el publicador 122 pueden comprender además un manejador de conflictos 113 y el actualizador automático 121 también puede comprender un distribuidor de línea de base 117. El solucionador de conflictos 113 puede ser necesario para resolver conflictos provocados por cambios entrantes de múltiples fuentes. Para el actualizador automático 121, estos pueden ser cambios realizados por otros diseñadores, que pueden estar completamente comprometidos e integrados en la base de datos de borradores 140, y distribuidos por el actualizador automático 121 a los diseñadores que aún están trabajando en sus cambios para fusionarlos con la versión específica editada por ellos (con conflictos manejados por el manejador de conflictos incluido 113). Para el publicador 122, estos pueden ser cambios realizados por diseñadores que trabajan en la base de datos de borradores 140 y fusionados con otros cambios realizados por los usuarios en la base de datos publicada 130.

El actualizador automático 121 puede manejar la notificación a un diseñador en cuanto a los cambios que se han realizado en un sitio que está editando y puede fusionar cualquier cambio realizado por los otros diseñadores o usuarios en el sitio web editado actualmente. Esto puede realizarse mediante un proceso de tipo push o mediante el servidor de sondeo 10 del cliente diseñador 30 para cambios. El publicador 122 puede publicar los cambios de diseño contenidos en la base de datos de borradores 140 en la base de datos publicada 130. El archivador 123 puede acceder a la base de datos de archivo 150 para leer y escribir versiones archivadas. El revertidor 124 puede ejecutar solicitudes de reversión. El registrador de historial de edición 126 puede registrar el historial de edición durante la edición en la base de datos de historial de edición 125. El analizador de historial de edición 127 puede analizar el historial de edición como un servicio general para varios elementos del sistema que utilizan información de historial de edición. El clonador 128 puede copiar tanto la base de datos publicada 130 como la base de datos de borradores 140 a un nuevo sitio y el creador de bases de datos 129 puede crear un conjunto de bases de datos por primera vez.

Se apreciará que los manejadores de solicitudes 105 y 110 pueden consistir en capacidades de lectura y escritura para permitir tanto a los usuarios como a los diseñadores ver y actualizar las bases de datos pertinentes según sea necesario. Se apreciará que una lectura de la base de datos publicada 130 puede ser directamente de la base de datos y puede incluir conversiones de artículos de lista a la última versión de esquema publicada, y también puede realizar la reescritura de consultas si es necesario como se describe con más detalle a continuación. Una escritura en la base de datos publicada 130 puede implicar la escritura de actualizaciones directamente en la base de datos publicada 130 y también puede implicar la detección y resolución de conflictos si se permiten ediciones complejas del usuario. Una lectura de la base de datos de borradores 140 puede incluir confirmar si un objeto ha sido eliminado, conversiones de artículos de lista a esquemas modificados guardados en la base de datos de borradores 140 y realizar la reescritura de la consulta si es necesario. La redacción puede incluir la fusión de cambios en la base de datos de borradores 140, la actualización de registros y la detección y resolución de conflictos cuando sea necesario.

Ahora se hace referencia a las Figuras 4A y 4B que ilustran los elementos de los manejadores de solicitudes 105 y 110, respectivamente. Los manejadores de solicitudes 105 y 110 pueden comprender un receptor de solicitudes 111, un adaptador de artículos 112, un solucionador de conflictos 113 y un reescritor de consultas 115. El manejador de solicitudes DDB 110 también puede comprender un manejador de cambios de tipo de artículo 114. El solucionador de conflictos 113 puede comprender además un comparador y un fusionador de componentes 116.

El receptor de solicitudes 111 puede recibir solicitudes del servicio de datos de usuario final 40 para acceso de lectura o escritura a la base de datos publicada 130 y el adaptador de artículos 112 puede adaptar artículos de lista a diferentes versiones de esquema. El solucionador de conflictos 113 puede resolver conflictos entre las versiones de una página u objeto en la memoria y la versión actual retenida al guardar el objeto o la página. El manejador de cambio de tipo de artículo 114 puede manejar la modificación de definición de tipo de objetos y el reescritor de consultas 115 puede optimizar consultas recibidas de un diseñador o usuario basándose en cambios de tipo de artículo. El comparador y fusionador de componentes 116 puede realizar una comparación y una fusión orientadas a los componentes para determinar las diferentes versiones de los componentes, resolver las diferencias y fusionar las versiones en una nueva versión actualizada para que la utilicen tanto los usuarios como los diseñadores.

Como se discutió anteriormente en el presente documento, todos los cambios realizados por el diseñador a través del visualizador y editor 34 se almacenan en la base de datos de borradores 140. Esto se aplica a los cambios de páginas, componentes, artículos de lista, tipos de artículos y vistas. Todos los demás cambios (incluidos los del cliente de usuario 20) pueden afectar la base de datos publicada 130, incluidos los cambios de los visualizadores de la aplicación (por ejemplo, agregar comentarios de blog, visualizadores con capacidades de edición limitadas), acceso externo al sistema de gestión de contenido, acceso externo a través de una API y acceso externo a través de clientes especiales, p. ej. una aplicación de iPhone para agregar imágenes.

Se apreciará que el sistema 100 puede almacenar registros de cambios en varios niveles de granularidad (por ejemplo, para optimizar el tiempo de almacenamiento y procesamiento) como el nivel de objeto completo (por ejemplo, la página/artículo/tipo modificado completo), nivel de subobjeto modificado específico (p. ej. componentes visuales modificados), nivel de cambio de atributo específico (p. ej. altura del componente A cambiada a Y) y cambios que involucran tipos/esquemas de artículos que requieren manipulación de artículos específicos y que se describen con más detalle a continuación. La jerarquía de posibles operaciones de lectura y modificación se resume en la Figura 5, a la que ahora se hace referencia.

Las solicitudes de lectura que provienen de una fuente de interfaz de usuario que no es del editor (como el visualizador 24, un sistema de gestión de contenido externo, etc.) pueden ser manejadas directamente por el manejador de solicitudes de PDB 105 que puede leer la solicitud directamente de la base de datos publicada 130. Solicitudes de lectura de datos de un diseñador a través del visualizador y editor 34 pueden ser manejadas por el manejador de solicitudes de DDB 110 que puede instruir a la base de datos de borradores 140 en consecuencia. La base de datos de borradores 140 puede acceder a la base de datos publicada 130 para recuperar una entidad relevante, y puede aplicar cualquier cambio (realizado por el diseñador solicitante) a ella para devolver la versión actualizada.

Se apreciará además que un diseñador puede cambiar un tipo de artículo (es decir, esquema) utilizado para definir la estructura de artículos de datos en las listas de datos. Los cambios pueden incluir agregar o eliminar un tipo completo, así como agregar, eliminar o modificar una definición de campo dentro de un tipo. Dicho cambio se puede realizar mientras otros usuarios agregan, eliminan o modifican artículos existentes utilizando el tipo de artículo que se está modificando. Por ejemplo, en una base de datos de bienes raíces (lista de datos), un diseñador puede agregar un nuevo campo "número de entrada de la casa" con un valor predeterminado de '1' que se mostrará para todos los artículos de la lista. Como otro ejemplo, una base de datos de bienes raíces de este tipo puede tener un campo con una lista de valores posibles (por ejemplo, nombres de ciudades), y el nombre de una ciudad dada debe corregirse debido a errores ortográficos.

El receptor de solicitudes 111 (dentro del manejador de solicitudes pertinentes 105, 110) puede recibir la solicitud del coordinador de solicitudes de usuario 90 o del coordinador de solicitudes de diseñador 95 en consecuencia. Para una solicitud para adaptar artículos a un esquema diferente únicamente, puede reenviar la solicitud al adaptador de artículos pertinente 112. Dado que la modificación real del tipo solo puede realizarse en la base de datos de borradores 140, puede enviarse una solicitud de un diseñador para modificar una definición de tipo (esquema) al manejador de cambio de tipo de artículo 114. Se apreciará que los usuarios aún pueden ingresar y ver los artículos en la base de datos publicada 130 después de que un diseñador haya modificado el tipo. Si se cambió un tipo en la base de datos de borradores 140 a través del manejador de cambios 114 pero el cambio aún no se publicó (como se describe con más detalle a continuación), es posible que el usuario no vea el cambio y solo vea el tipo de artículo antiguo. Una vez que se ha publicado el cambio, todos los accesos (a través del visualizador 24 y el visualizador y editor 34) pueden usar el nuevo tipo (excepto el acceso del diseñador después de una operación de reversión como se explica más adelante).

Se apreciará que la descripción siguiente se aplica a una realización completa del adaptador de artículos 112, destinado a "listas grandes": listas que incluyen un número sustancial de artículos o que reflejan el contenido de una base de datos o repositorio externo (que puede contener cualquier número de artículos). El sistema 100 también puede admitir "listas pequeñas" (almacenadas en sus bases de datos internas y con un número menor de artículos) a través de una realización simplificada del adaptador de artículos 112 como se describe con más detalle a continuación.

Por ejemplo, un tipo t1 es modificado por un diseñador y, como resultado, el manejador de cambio de tipo de artículo 114 puede guardar el tipo modificado t2 en la base de datos de borradores 140. El tipo modificado guardado t2 también puede incluir la secuencia de operaciones de modificación realizadas en el tipo t1 para derivar t2. El diseñador puede entonces modificar un artículo A creando en consecuencia un nuevo artículo A modificado de tipo t2 (incluyendo tal cambio posiblemente cambios adicionales y no solo conversión de tipo).El manejador de solicitudes de DDB 110 puede guardar el artículo A, tipo t2 en la base de datos de borradores 140 (incluyendo cualquier modificación posterior antes de la publicación). Se apreciará que el artículo A de tipo t1 en la base de datos publicada 130 y los artículos reales asociados con el tipo t1 no se modifican.

El acceso al artículo A (lectura/escritura/modificación) a través del servicio de datos de usuario final 40 puede devolver el artículo A de tipo t1, ya que el artículo A de tipo t2 aún no se ha publicado.

El acceso de lectura al artículo A del tipo t1 por parte de un diseñador a través del servicio de datos de diseñador 50 puede leer inicialmente el artículo A del tipo t1 de la base de datos publicada 130 (si el artículo existe). Si la base de datos de borradores 140 contiene un artículo A completamente nuevo (por ejemplo, debido a la granularidad delta que dicta el ahorro de artículos modificados completos en la base de datos de borradores 140), el manejador de solicitudes de DDB 110 puede devolver el nuevo artículo en su lugar. De lo contrario, si la base de datos de borradores 140 contiene cambios en el artículo A, y en particular una nueva versión t2 del tipo de artículo, el adaptador de artículos 112 puede adaptar el artículo al tipo modificado t2 y devolver el registro de artículo modificado a través del servicio de datos de diseñador 50.

Se apreciará que cuando el publicador 122 publique el cambio (como se discute con más detalle a continuación), el publicador 122 puede escribir el artículo A de tipo t2 en la base de datos publicada 130. Una vez que el publicador 122 haya publicado el artículo A adaptado al tipo t2, todas las solicitudes para leer el artículo A pueden devolver el artículo A con formato de tipo t2.

Se apreciará que para que el adaptador de artículos 112 adapte artículos a diferentes versiones de su tipo asociado, debe poder hacer coincidir los elementos de un artículo construido usando la versión t1 de un tipo dado con los mismos elementos en la versión t2 de un el tipo dado. Se apreciará además que el adaptador de artículos 112 puede realizar varias operaciones de cambio de esquema. También se apreciará que una implementación limitada del adaptador de artículos 112 puede que solo soporte algunas de las operaciones.

El adaptador de artículos 112 puede usar el manejo de tipos basado en ID para manejar este proceso. En este método, a todos los elementos de la definición del tipo de artículo se les asignan ID únicos persistentes en todo el sistema. Por lo general, estos incluyen los campos de tipo, pero también pueden incluir elementos adicionales como valores posibles de definiciones de campos que tienen una lista de valores posibles.

El adaptador de artículos 112 puede guardar las múltiples versiones del tipo (en la base de datos de borradores 140 y posteriormente en la base de datos publicada 130), o puede retener solo la versión más actualizada (excepto para guardar los cambios en la base de datos de archivo 150 como se describe con más detalle a continuación).

Si se guardan versiones de tipo más antiguas, el adaptador de artículos 112 puede realizar una coincidencia entre la versión de tipo anterior t1 y la versión de tipo más nueva t2, y los campos asociados con el artículo se adaptan según los cambios ubicados entre las versiones de tipo. Si las versiones de tipo más antiguas no se guardan, el adaptador de artículos 112 puede realizar una coincidencia directamente entre los campos asociados con el artículo y la definición de tipo más nueva t2.

El adaptador de artículos 112 también puede adaptar artículos a diferentes versiones de su tipo asociado usando el manejo de tipo basado en cambios. El registrador de historial de edición 126 puede rastrear los cambios a cualquier tipo dado a través del visualizador y editor 34 y registrar la secuencia de operaciones de cambio (la secuencia de cambio), incluyendo la eliminación de cambios que no se hicieron o se invirtieron de otra manera.

Se apreciará que el manejador de cambio de tipo de artículo 114 puede haber guardado las secuencias de cambio (en la base de datos de borradores 140 y posteriormente en la base de datos publicada 130) junto con el tipo de artículo modificado para su uso posterior por el adaptador de artículos 112. Como se discutió aquí anteriormente en relación con al adaptador de artículos 112, la discusión sobre el manejador de cambio de tipo 114 se aplica a una realización completa, dirigida a "listas grandes". Para el manejador de cambio de tipo 114, el sistema 100 también puede admitir "listas pequeñas" (almacenadas en sus bases de datos internas y con un número menor de artículos) a través de una realización simplificada del manejador de cambio de tipo 114.

Por tanto, la base de datos de borradores 140 puede contener el conjunto completo de versiones del tipo de artículo, junto con las secuencias de cambio entre ellas. Cada artículo puede incluir un identificador de versión junto con la indicación de tipo de artículo.

Se apreciará que el adaptador de artículos 112 todavía puede usar ID únicos de todo el sistema en este método, aunque también se pueden usar técnicas alternativas (tales como usar los nombres de campo o ID específicos de tipo). Se apreciará además que el método basado en cambios puede tener algunos beneficios en comparación con el método basado en ID; por ejemplo, puede admitir operaciones complejas (como la concatenación o división de campos) que no pueden ser compatibles con el método basado en ID. Sin embargo, requiere almacenamiento y procesamiento adicionales. Por tanto, la selección del método que se utilizará es una decisión de funcionalidad frente a procesamiento.

El adaptador de artículos 112 también puede combinar los dos métodos: realizar el manejo basado en ID más rápido cuando sea posible y recurrir al manejo basado en cambios para modificaciones más complejas.

Los posibles cambios en los tipos de artículos pueden incluir una combinación de cualquiera de las siguientes operaciones, como agregar un campo, eliminar un campo, cambiar el nombre de un campo, cambiar el tipo de campo, cambiar la lista de valores posibles de un campo (agregar, eliminar o modificar), unir campos y dividir campos. El adaptador de artículos 112 también puede admitir un subconjunto de estas operaciones.

Cuando se lee un registro de artículo y se adapta de su tipo actual a un nuevo tipo, el adaptador 112 puede manejar estos cambios de tipo de la siguiente manera:

Si el nuevo tipo de artículo agregó un campo, el adaptador 112 puede agregarlo al registro de artículo leído con el valor predeterminado.

Si el nuevo tipo de artículo eliminó un campo, el adaptador 112 puede eliminarlo del registro de artículo leído.

Si el nuevo tipo de artículo cambió el nombre de un campo, el adaptador 112 puede renombrar el campo en el registro.

Si el nuevo tipo de artículo cambió el tipo de un campo, el adaptador 112 puede convertir el valor de campo si es posible (por ejemplo, un número entero en una cadena); de lo contrario, devolverá una indicación de error en este campo.

Si un campo en el artículo utiliza un valor posible que se eliminó para este campo en el nuevo tipo, el adaptador 112 puede marcar el campo como error.

Si un campo en el artículo usa un valor posible que se modificó para este campo en el nuevo tipo, el adaptador 112 puede cambiar el valor a la versión modificada del valor.

Si el nuevo tipo de artículo une campos, el adaptador 112 puede unir los campos existentes si es posible (es decir, los dos campos existen en la versión anterior y su tipo de datos permite la unión).

Si el nuevo tipo de artículo divide un campo, el adaptador 112 puede dividir el campo de acuerdo con la metodología especificada si es posible (por ejemplo, en una posición dada en el campo).

Se apreciará que el registro adaptado es el que se devuelve a través del servicio de datos relevante 40 o 50.

En caso de fallo de conversión (por ejemplo, se agregó un nuevo campo sin un valor predeterminado y se lee un registro de artículo al que se debe agregar este campo), se puede solicitar al diseñador que corrija la definición de tipo. El adaptador 112 puede hacer esto en los siguientes casos:

Cuando el manejador de solicitudes de DDB 110 lee un artículo de la base de datos de borradores 140 para su visualización/uso por parte del editor y el visualizador 35, el adaptador de artículos 112 puede adaptarlo a la versión más reciente del tipo de base de datos de borradores 140 encontrada. El artículo puede ser un artículo no modificado (que es leído por la base de datos de borradores 140 de la base de datos publicada 130), o un artículo modificado (que incluye modificaciones o la versión actualizada guardada en la base de datos de borradores 140). Esta adaptación se puede realizar en el registro devuelto por el manejador de solicitudes de DDB 110 pero no se guarda en la base de datos de borradores 140 o en la base de datos publicada 130.

Cuando un artículo de este tipo se escribe desde el editor y visualizador 34 en la base de datos de borradores 140, la versión guardada ya está adaptada a la nueva versión de tipo.

Cuando el publicador 122 publica un artículo que se modificó en el editor y visualizador 34 (y, por lo tanto, se guarda en la base de datos de borradores 140), el publicador 122 puede escribir en la base de datos publicada 130 el artículo adaptado a la versión más reciente del tipo de artículo (incluidos los posibles cambios en este tipo de artículo que también se registra en la base de datos de borradores 140).

Cuando el manejador de solicitudes de PDB 105 lee un artículo de la base de datos publicada 130 para mostrarlo en el visualizador 24, el adaptador de artículos 112 puede adaptarlo a la versión publicada más reciente del tipo que se encuentra en la base de datos publicada 130. Esta adaptación puede realizarse en el registro devuelto por el manejador de solicitudes de PDB 105, pero no se guarda en la base de datos de borradores 140 ni en la base de datos publicada 130.

Si un artículo se modifica en el visualizador 24, es decir, una interfaz de usuario no de editor ya puede estar adaptado a la versión publicada más reciente del tipo de artículo (en lectura) y, por lo tanto, se guardaría en la base de datos publicada 130 adaptada a esta versión.

El sistema 100 puede implementar una realización alternativa del adaptador de artículos 112 y el adaptador de cambio de tipo de artículo 114 dirigido a "listas pequeñas" (como se indicó anteriormente). En tal realización, siempre que un diseñador cambia un tipo de artículo de t1 a t2 (y guarda el cambio), el adaptador de cambio de tipo de artículo 114 realiza inmediatamente una migración por lotes de todos los artículos de tipo t1 en la base de datos de borradores 140 y los adapta al tipo t2. Siempre que se publique un cambio de tipo de este tipo, el publicador 122 puede indicar al adaptador de cambio de tipo de artículo 114 que adapte todos los artículos del tipo t1 en la base de datos publicada 130 al tipo t2.

Se apreciará además que el sistema 100 puede soportar una disposición jerárquica de componentes que tienen atributos, o árboles de componentes. Cada nodo en un árbol de componentes puede representar un componente y puede tener múltiples subnodos (por ejemplo, para componentes dentro de un componente contenedor). Específicamente, cada nodo tiene atributos geométricos (como posición y tamaño) en relación con la entidad que lo contiene.

Es posible que se requiera que el solucionador de conflictos 113 compare (y luego fusione) dos árboles de componentes (por ejemplo, la versión de línea de base y una versión modificada) en un solo árbol de componentes. Dicha combinación puede ser automática, guiada por el usuario o ambas. El comparador y el fusionador de componentes 116 pueden utilizar una comparación y una fusión orientadas a componentes basándose en la descomposición jerárquica de los objetos que se fusionan. El comparador y el fusionador de componentes 116 pueden utilizar además un análisis de la geometría, los atributos y el contenido de los objetos y subobjetos comparados para ayudar en la comparación. Se apreciará que la funcionalidad del comparador y el fusionador de componentes 116 se analiza en la patente de EE. UU. 9.817.804 titulada " A System for Comparison and Merging of Versions in Edited Websites and Interactive Applications", presentada el 11 de febrero de 2015 y emitida el 14 de noviembre de 2017, cedida al cesionario común de la presente invención.

Se apreciará que la base de datos de listas 135 (según la realización mostrada en la Figura 2B) puede contener múltiples artículos basados en múltiples versiones del mismo tipo, y es posible que deban realizarse diferentes adaptaciones para cada versión de tipo. Se apreciará que en este escenario la base de datos de lista de escenarios 135 puede manejarse como la base de datos publicada 130 (cuando no se combina con la base de datos publicada 130 como se ilustra en la Figura 2A) y los usuarios tienen la capacidad de acceder y modificarla a través del manejador de solicitudes de PDB 105. Se apreciará además que la base de datos de listas 135 puede emplear un algoritmo de control de versiones de listas. Alternativamente, la base de datos de listas 135 puede implementar su propia disposición que puede incluir áreas internas publicadas y en borrador, similar a las principales bases de datos publicadas / de borradores utilizadas para la información del sitio web que no es de la lista. También debería apreciarse que incluso en esta realización, el sistema 100 puede clasificar algunas listas de modo que no se almacenen en la base de datos de listas 135 separada, sino que utilicen los mecanismos de la base de datos publicada 130 habitualmente y la base de datos de borradores 140. Esto suele ser relevante para listas pequeñas que no representan datos modificados dinámicamente, p. ej. una lista de departamentos de la empresa que está vinculada a la estructura del sitio web y no cambia con mucha frecuencia.

Se apreciará que una base de datos de lista separada puede gestionarse por separado, p. ej. tener un conjunto separado de ID de usuario. Los distintos ID pueden estar relacionados entre sí a través de la información del sitio. Esto puede ser necesario, por ejemplo, para admitir listas comunes a múltiples bases de datos y usuarios.

Se apreciará que los manejadores de solicitudes 105 y 110 también pueden eliminar un tipo de artículo que tiene artículos de datos asociados con él. La eliminación es en realidad una eliminación virtual. El tipo se marca como eliminado, pero se conserva en las bases de datos subyacentes 130 y 140. Por lo tanto, los artículos que utilizan este tipo (o cualquier generación del mismo) pueden seguir funcionando, pero el tipo no se mostrará siempre que se muestre una lista de tipos disponibles. Se apreciará además que el sistema 100 puede admitir la duplicación de artículos, en cuyo caso aún se pueden crear nuevos artículos basándose en un tipo eliminado duplicando artículos existentes. El tipo solo se eliminará realmente una vez que no haya artículos asociados con él.

Se apreciará además que siempre que el manejador de solicitudes DDB 110 elimina un objeto (artículo, página, lista, etc.), el manejador de solicitudes d Db 110 puede escribir su ID única en la base de datos de objetos eliminados 145. Se apreciará además que cuando el manejador de solicitudes DDB 110 lee un objeto de la base de datos de borradores 140, también puede consultar con la base de datos de objetos eliminados 145 para ver si hay una coincidencia entre el ID del artículo y los ID de los artículos eliminados. Si hay una coincidencia, puede notificar al visualizador y al editor 34 que el artículo ya no existe, aunque todavía esté presente en la base de datos publicada 130. También se apreciará que cuando el publicador 122 publique cambios en la base de datos publicada 130, puede eliminar objetos en la base de datos publicada 130 que tienen un ID que coincide con un ID eliminado en la base de datos de objetos eliminados 145. Se apreciará que, como resultado, el proceso es síncrono en lugar de asíncrono.

El reescritor de consultas 115 puede optimizar las consultas que se refieren a nuevos campos de artículos agregados en nuevas versiones del tipo de artículo. Por ejemplo, se ha agregado un nuevo campo numérico x en la versión 6 del tipo de artículo B y el valor predeterminado para el campo x es 10.

Si todos los artículos para los que se solicitan x <15, el reescritor de consultas 115 puede incluir automáticamente todos los artículos con una versión de tipo anterior a 6 (ya que el valor de campo predeterminado x = 10 satisface la condición x <15). Todos los artículos para los que se ha especificado un valor para x ya se habrían adaptado a la versión 6 del tipo de artículo. Esto podría proporcionar una optimización sustancial, ya que la versión de tipo de artículo a menudo podría ser indexada por la base de datos subyacente nativa, mientras que el campo x podría no estar indexado (y requerir pruebas registro por registro). Además de la optimización, el reescritor de consultas 115 puede proporcionar una solución para la recuperación usando índices sobre "campos faltantes" (agregados en una versión dada de un tipo). El reescritor de consultas 115 puede modificar una consulta que se refiera a un "campo faltante" para usar un índice sobre los campos que incluye solo los registros que contienen el campo agregado, al tiempo que se asegura que los registros en los que falta el campo (es decir, los registros definidos mediante versión anterior del tipo sin el campo) se incluyen o excluyen automáticamente según corresponda.

De manera similar, si se solicitan todos los artículos para los que x> 15, el reescritor de consultas 115 puede excluir automáticamente todos los artículos con una versión de tipo anterior a la 6.

Se apreciará que si se admiten varias reglas de conversión (que detallan métodos de conversión especializados entre diferentes versiones de tipos), es mucho más difícil usar índices nativos y la funcionalidad de base de datos subyacente, ya que los valores de campo podrían convertirse al leer de una fuente anterior, requiriendo así pruebas registro por registro de los valores de campo. Por ejemplo, si el campo x existe en la versión t1 de un tipo t, y se reemplaza por el campo y en la versión t2 del tipo t. Se utiliza una fórmula de conversión compleja y = func(x) al convertir x en y. En tal caso, es posible que el sistema de indexación de la base de datos subyacente no pueda indexar x e y juntos en el mismo índice y, por lo tanto, se le podría solicitar que realice comparaciones explícitas para cada registro recuperado, en lugar de realizar una consulta indexada. Esto se puede manejar en algunos casos (pero no siempre) mediante la reescritura de consulta que divide la consulta en la unión de una consulta "previa al cambio" y una consulta "posterior al cambio".

Los elementos típicos de los grandes sitios web son galerías que recuperan artículos según las etiquetas de los artículos. Por ejemplo, un único repositorio de listas puede contener todos los artículos disponibles en una tienda electrónica dada, pero diferentes páginas (por ejemplo, "departamentos" de la tienda electrónica) pueden contener componentes visuales de tipo galería que recuperan los artículos que se mostrarán según las etiquetas de los artículos (p. ej. libros, música, gadgets, etc.). Estas etiquetas también pueden estar disponibles para la búsqueda del usuario final en el repositorio.

Un diseñador puede querer modificar una etiqueta (en un criterio de filtro, así como en artículos filtrados) debido a un error de ortografía en la etiqueta, o algún otro cambio estructural. Se apreciará que el sistema 100 tiene que publicar cambios en las etiquetas de recuperación en artículos y cambios en los criterios de filtrado simultáneamente; de lo contrario, el sitio se interrumpiría durante algún tiempo. Un sitio web típico a gran escala está continuamente en línea y no se puede cerrar fácilmente para mantenimiento o cambios de bases de datos.

Por tanto, el diseñador puede cambiar las etiquetas, a través del editor y visualizador 34, que se utilizan para seleccionar artículos (por ejemplo, en las galerías del sitio web), y también puede cambiar las etiquetas asignadas a artículos específicos de la lista existente. Sin embargo, ambos tipos de cambios pueden mantenerse juntos en la base de datos de borradores 140 y comprometerse con la base de datos publicada 130 (cuando se publique). Mientras no se publiquen los cambios, los usuarios existentes que accedan al sitio web (mientras se crea el cambio) seguirían viendo etiquetas antiguas en los componentes visuales de la galería (que se utilizan para mostrar los artículos), así como los artículos, y el sitio web no se roto.

Una vez que un diseñador ha realizado los cambios pertinentes en la base de datos de borradores 140, el publicador 122 puede publicar los cambios del diseñador guardados en la base de datos de borradores 140 para un sitio web dado (u otra entidad de nivel de gestión como un proyecto que contiene varios sitios web).

El publicador 122 puede ampliar la solicitud de publicación para incluir modificaciones realizadas en otras entidades de nivel de gestión relacionadas en las que se basa la entidad de nivel de gestión publicada (trazando el gráfico de dependencia de las entidades de nivel de gestión). Por ejemplo, la publicación de un sitio web puede publicar cambios en plantillas relacionadas y aplicaciones de lista también. Dicho análisis de dependencia es posible ya que las entidades de nivel de gestión forman un DAG (como se señaló anteriormente), es decir, no hay dependencias circulares.

El publicador 122 puede aplicar todos los cambios en la base de datos de borradores 140 para el sitio web dado (u otras entidades de nivel de gestión) a la base de datos publicada 122 (es decir, todas las páginas, componentes, artículos, tipos y vistas). El publicador 122 puede entonces eliminar los registros de cambios de la base de datos de borradores 140 ya sea física o lógicamente (por ejemplo, usando un puntero de "último punto de actualización" o una consulta de marca de tiempo) como se discutió anteriormente en este documento.

El publicador 122 también puede guardar una instantánea del sitio web completo en la base de datos de archivo 150 (como se describe con más detalle en el presente documento a continuación), para que pueda usarse como punto de reversión en el futuro. La instantánea puede incluir todos los elementos del sitio web, excepto los artículos de datos de lista (para todas o algunas de las listas), que se analizan con más detalle a continuación.

Como se discutió anteriormente en el presente documento, la base de datos de archivo 150 puede mantener una lista de versiones guardadas o publicadas. La base de datos de archivo 150 puede contener indicaciones de apoyo tales como "publicado" e "importante", descripciones de la versión, etc. Estas pueden usarse para ayudar al diseñador cuando seleccione una versión previamente guardada para verla o para solicitar una reversión. El archivador 123 puede almacenar instantáneas de elementos completos o información de diferencias a nivel de atributo (como se describe aquí arriba para el manejo de solicitudes de modificación).

Se apreciará que la base de datos de archivo 150 puede incluir una instantánea de los elementos visuales del sitio (páginas, plantillas, contenedores, componentes, etc.), tipos de artículos y vistas de artículos. La base de datos de archivo 150 puede no incluir artículos de datos reales almacenados en algunas o todas las listas de datos y cualquier componente externo y aplicaciones de terceros a las que se hace referencia en el sitio web.

Un diseñador puede acceder (a través del editor y visualizador 34) a la lista de versiones del sitio web en la base de datos de archivo 150 y revertir a una versión dada (publicada o no). La versión revertida puede convertirse en el nuevo estado de "desarrollo reciente" del sitio web.

Se apreciará que el proceso de reversión es "revertir para visualización/edición" y solamente puede afectar la vista presentada al diseñador específico que realiza la operación de reversión. Es posible que la operación de reversión no afecte a otros visualizadores del sitio web hasta que se realice una solicitud de publicación. El diseñador puede revertir fácilmente a otra versión del sitio web (anterior, posterior o más reciente) antes de publicar los cambios.

El revertidor 124 puede borrar la base de datos de borradores 140 (dado que los cambios realizados hasta ahora son anulados por la versión revertida). A continuación, puede copiar la versión completa revertida de la base de datos de archivo 150 a la base de datos de borradores 140 (excluyendo los artículos de datos de lista como se indicó anteriormente). Incluso si la base de datos de archivo 150 almacena la versión en un formato basado en delta, se genera la versión completa.

Se apreciará que este proceso no afecta a la base de datos publicada 130. Por tanto, si el revertidor 124 revierte a una versión anterior a la última versión publicada, la base de datos publicada 130 aún puede contener una versión posterior a la versión revertida. Esta última versión se sobrescribirá cuando el publicador 122 publique la versión anterior que ahora se encuentra en la base de datos de borradores 140.

Ahora se hace referencia a las Figuras 6A, 6B, 6C y 6D que ilustran diferentes escenarios de "reversión".

La Figura 6A asume que la base de datos de archivo 150 contiene las versiones v1-v10 de la aplicación o sitio web creados. La versión publicada actual es v8, y las versiones v9-v10 se modifican y guardan posteriormente basadas en v8 (que no se publicaron).

En la Figura 6B, el diseñador vuelve a la v6, que es anterior a la v8 publicada. La base de datos de borradores 140 puede contener entonces la v6 completa (no solo las diferencias, sino también los artículos de datos de lista), mientras que la base de datos publicada 130 aún contendría la versión 8. Se apreciará que los cambios a v10 (por ejemplo, v10+) incluidos en la base de datos de borradores 140 antes de la operación de reversión se pierden.

En la Figura 6C, el diseñador modifica aún más v6, creando v6* a través de cambios en la base de datos de borradores 140. El diseñador guarda v6*, y se convierte en v11 en la base de datos de archivo 150.

En la Figura 6D, el diseñador publica (a través del publicador 122) v11 (==v6*). La base de datos publicada 130 se actualiza con v11, que se convierte en la versión actual disponible públicamente.

Se apreciará que el revertidor 124 no borra la base de datos de archivo 150 después de la reversión, por lo que un diseñador podría (como en el ejemplo anterior), revertir a v6, modificarla, guardar v6* como v11 y luego revertir nuevamente a v9 (o cualquier otra versión guardada en la base de datos de archivo 150) y continuar trabajando con una v9* modificada (que ahora se convertiría en v12).

Se apreciará que esto solo se aplica a los datos, vistas y tipos WYSIWYG y no a los artículos de lista.

Como se discutió anteriormente en el presente documento, el sistema 100 puede excluir algunos o todos los repositorios de artículos de lista de las versiones guardadas en la base de datos de archivo 150. Tales repositorios excluidos también pueden excluirse del proceso de reversión. Esto se debe a que los repositorios de artículos de lista pueden ser muy grandes y, por lo tanto, puede que no sea práctico mantener una instantánea completa de la base de datos de archivo 150.

Además, los usuarios pueden agregar continuamente datos de artículos de lista (por ejemplo, publicaciones de blog y comentarios) independientemente del diseño de sitio web, este contenido acumulado puede perderse al revertir. Por tanto, el revertidor 124 puede limitarse a manejar listas relacionadas con los elementos de diseño del sitio y no a listas relacionadas con el contenido acumulado.

Algunos repositorios de artículos de lista pueden representar información real del mundo real (como niveles de inventario de existencias) y elementos de diseño no de aplicaciones y demás. Por lo tanto, si (por ejemplo) un sitio se adaptó a la Navidad durante un período dado, después de Navidad, el diseño del sitio debe retrocederse a la versión anterior a la Navidad después del período navideño. En este escenario, aunque la apariencia del sitio puede cambiar, es deseable no retroceder los niveles de inventario a los anteriores a las ventas de Navidad.

El publicador 122, el archivador 123 y el revertidor 124 pueden, por tanto, excluir algunos o todos los repositorios de artículos de lista. Dicha exclusión puede determinarse en función de una combinación de criterios, como la especificación explícita del diseñador de aplicación, el tamaño de los repositorios (por ejemplo, excluir repositorios por encima de un tamaño dado), el patrón de uso del repositorio (por ejemplo, ¿se comporta como un repositorio de blogs acumulativo o no en términos de agregar/eliminar/modificar solicitudes realizadas en él / ¿representa datos del "mundo real"?), la frecuencia y el alcance de las actualizaciones a la lista dada, la clasificación de usuarios que acceden para modificaciones (por ejemplo, incluye contenido generado por usuario o no) o el método de almacenamiento del repositorio (por ejemplo, crear una instantánea de las listas de artículos almacenadas internamente pero no de las listas almacenadas en una base de datos externa).

Como se discutió anteriormente en el presente documento en relación con la Figura 2B, el sistema 100 también puede emplear el control de versiones de la base de datos de listas 135. Se apreciará que las listas de artículos pueden tener diferentes requisitos de versiones de las bases de datos "normales" y los repositorios de componentes. En particular, algunas listas deben excluirse del control de versiones/retroceso, ya que pueden incluir información de usuario acumulada (por ejemplo, la acumulación de contestaciones de blog o comentarios de vídeo) que no deben perderse y pueden representar datos físicos de palabras como niveles de inventario (que no deben ser revertido). Sin embargo, en muchos casos puede ser deseable una funcionalidad de reversión e historial de listas para al menos algunas de las listas sin almacenar información de lista en las bases de datos existentes 130, 140 y 150. Se apreciará que las listas pueden ser mucho más grandes que la cantidad de datos almacenados en bases de datos existentes 130, 140 y 150 y posiblemente se actualicen con mucha más frecuencia. Se apreciará además que en este escenario, el sistema 100 puede usar un algoritmo de control de versiones de lista (como el descrito en el Apéndice 1) para proporcionar la funcionalidad requerida. Un algoritmo de este tipo también puede admitir el control de versiones de artículos de lista con sobrecarga y costes de tiempo mínimos (sin almacenar los artículos de lista en la base de datos de archivo 150 y la base de datos de borradores 140).

Se apreciará que el revertidor 124 puede enfrentarse a un problema al revertir aplicaciones que contienen galerías que seleccionan artículos de lista según las etiquetas (que han sido modificadas), y no revertir los artículos de lista correspondiente.

Por ejemplo, un diseñador crea un sitio web (versión n.° 1) con un tipo de artículo "impresoras" que tiene un campo de etiqueta "fabricante" con los valores posibles 'Canon', 'h-p' y 'Xerox'. Los usuarios del sitio web pueden agregar artículos de datos x1 -x5, con algunos artículos etiquetados con 'h-p'. A continuación, el diseñador decide actualizar el sitio web modificando el tipo de artículo "impresoras" corrigiendo 'h-p' a 'HP'. El diseñador también puede modificar un criterio de filtro en una galería que muestra la lista para usar 'HP', así como también modificar los artículos de "impresoras" existentes etiquetados con 'h-p' para usar 'HP' (si es necesario). Finalmente, el diseñador guarda la versión modificada #2 y la publica usando el publicador 122.

Luego, un usuario puede agregar más artículos x6-x10, algunos de los cuales están etiquetados con 'HP'. Si el diseñador decide revertir de la versión n.° 2 del sitio web a la n.° 1, la galería puede revertir para usar 'hp' como criterio de filtro, mientras que los artículos x1 -x10 todavía usan "HP" (ya que el revertidor 124 no cambia estos artículos).

Se apreciará que una solución a este problema puede ser el uso de ID de etiqueta únicos. El sistema 100 puede usar una ID única que se crea siempre que se crea un valor de etiqueta de criterios de filtro (por ejemplo, el 'h-p' anterior) y puede retener este código incluso si cambia el texto de la etiqueta asociada. Si se importan los datos, el revertidor 124 puede generar una ID única basada en los valores importados y utilizar esta ID única para las consultas reales (en lugar del texto de la etiqueta). Se apreciará que esto resuelve los problemas provocados por el cambio de nombre o la corrección de etiquetas, pero no resuelve (por ejemplo) un problema creado por "división de etiquetas", los artículos clasificados bajo una etiqueta dada se reclasifican bajo una serie de etiquetas posibles (por ejemplo, cuando se divide un departamento virtual). Tampoco resolvería un problema similar de "unión de etiquetas".

Otra solución puede ser el seguimiento de cambios de editor. Como se discutió anteriormente en el presente documento, el registrador de historial de edición de 126 puede guardar ediciones en la base de datos de historial de edición 125.

El revertidor 124 puede usar la base de datos de historial de edición 125 (a través del analizador de historial de edición 127) y almacenar el historial de edición de modificación de etiqueta (por ejemplo, el "cambio h-p a HP" anterior). Esto puede incluir la eliminación de cambios que se deshicieron o que se revertieron de otro modo. El revertidor 124 puede entonces aplicar la cadena de tales cambios a los artículos cuando los carga para convertirlos a los valores de etiqueta actuales.

Se apreciará que esto es más similar a la forma en que los campos de artículos se convierten del tipo de datos antiguo al tipo de datos nuevo cuando se adaptan a las nuevas versiones del esquema de objeto.

El revertidor 124 también puede usar conversión por lotes, p. ej. puede realizar una conversión por lotes de artículos existentes tras la publicación de dicho cambio (cambiando h-p => HP), y una conversión por lotes hacia atrás al revertir. Sin embargo, tal arreglo puede requerir un bloqueo sustancial de la base de datos al publicar y revertir, lo que no es deseable en sitios web grandes.

Se apreciará que el sistema 100 puede admitir el uso de listas relacionadas. Estas son listas que están relacionadas con otras listas en una relación jerárquica, similar a la relación entre la lista de contestaciones de blog y la lista de entradas de blog (cuando las contestaciones de bloque están relacionadas con entradas de blog específicas).

Se apreciará además que puede surgir un problema potencial al realizar la retroceso/avance de artículos de lista en listas relacionadas. Por ejemplo, se pueden adjuntar contestaciones a un artículo de blog que se eliminó debido a una reversión o retroceso a una versión diferente. Estas contestaciones deberían reaparecer en el avance. El revertidor 124 puede determinar que los repositorios de blog y contestación deben excluirse de la base de datos de archivos 150 y, por lo tanto, la reversión no se aplica a ellos. Se apreciará que el revertidor 124 también puede usar un algoritmo de versiones de lista como se discutió anteriormente en este documento para resolver este problema, ya que el blog y el retroceso son parte de un conjunto de versiones que aparecen y desaparecen juntas, por lo que se asume que no lo son eliminados en un retroceso, la conexión entre las dos listas debe permanecer.

El revertidor 124 también puede admitir el manejo de cambios simultáneos. Como se discutió anteriormente, los objetos (por ejemplo, componentes visuales o artículos de lista) pueden ser modificados por un diseñador (a través del visualizador y editor 34) simultáneamente con los cambios realizados por otros diseñadores o por los usuarios a través del visualizador 24 o por un sistema de gestión de contenido, etc. El sistema 100 no bloquea objetos para evitar dicha edición simultánea, sino que intenta resolver los conflictos de edición al guardar un objeto modificado.

Como se discutió anteriormente en el presente documento, el solucionador de conflictos 113 puede resolver conflictos entre las versiones de una página u objeto en memoria y la versión actual que se mantiene al guardar el objeto en memoria. Es decir, el solucionador de conflictos 113 puede comprobar que el objeto guardado no haya sido modificado por otro usuario o diseñador desde la última vez que fue leído. Se apreciará que la resolución de conflictos puede involucrar solo una parte de una página u objetos específicos. El solucionador de conflictos 113 puede implementar múltiples métodos de detección de cambios tales como el sellado de tiempo o la adición de un valor hash y las operaciones de escritura pueden incluir todo tipo de tipos de cambio (agregar, eliminar y modificar).

El solucionador de conflictos 113 del manejador de solicitudes de PDB 105 también puede resolver casos en los que múltiples usuarios finales modifican el mismo objeto.

También se apreciará que tanto el actualizador automático 121 como el publicador 122 también pueden comprender el solucionador de conflictos 113. Dentro del publicador 122, el solucionador de conflictos 113 puede comprobar los cambios simultáneos dentro de la base de datos publicada 130. En este escenario, el solucionador de conflictos 113 puede permitir que el publicador 122 publique cambios de la base de datos de borradores 140 en la base de datos publicada 130.

El solucionador de conflictos 113 puede calcular una suma de comprobación X del objeto como se ha cargado. Al intentar guardarlo, puede calcular la suma de comprobación Y del valor actual del objeto en la base de datos pertinente (130 o 140). Si X t Y, el solucionador de conflictos 113 puede detectar un conflicto.

Una vez que el solucionador de conflictos 113 ha detectado un conflicto, puede activar una combinación, manual o automática, como se describe en la patente de EE. UU. 9.817.804 titulada "A System for Comparison and Merging of Versions in Edited Websites and Interactive Applications", presentada el 11 de febrero de 2015 y emitida el 14 de noviembre de 2017 y cedida al cesionario común de la presente invención. Se apreciará que el solucionador de conflictos 113 puede implementar sumas de comprobación en diferentes niveles de granularidad, como para todo el sitio, páginas específicas, componentes específicos, etc.

Como se discutió anteriormente en el presente documento, en los sistemas de control de versiones existentes, un desarrollador normalmente usa una versión congelada (un directorio de registro de salida o una rama) del sitio web que se está editando. Se apreciará que el actualizador 121 puede indicar que un diseñador ve a través del visualizador y editor 34, una versión continuamente actualizada de la aplicación o sitio web que se está editando. Esta actualización de la versión que se está editando puede ser total o parcial y puede tener un alcance limitado. La actualización puede resultar del acceso a bases de datos (por ejemplo, algunos artículos de lista) que se gestionan fuera de las bases de datos de sistema (es decir, la base de datos de borradores 140 o la base de datos publicada 130) o de actualizaciones de otros usuarios de sistema (por ejemplo, de visualizadores). Estas actualizaciones pueden fusionarse automáticamente en la versión modificada manejada por el diseñador durante el trabajo, antes de que esta versión (actualmente editada) se vuelva a fusionar con la base de datos de borradores (al guardar) y luego a la base de datos publicada (al publicar).

Se apreciará que la distribución de cambios en versiones editadas (es decir, la versión que el diseñador está editando actualmente) puede activarse en función de la configuración de tiempo/frecuencia, la solicitud de diseñador, la cantidad de cambios acumulados, la importancia de los cambios acumulados o la configuración previa del diseñador (p. ej., basado en cambios en un componente o clase de componente específico). El distribuidor de cambio de línea de base 117 puede monitorizar cambios desde la versión de línea de base definida basándose en ajuste de tiempo y frecuencia, solicitud de diseñador, cantidad de cambios acumulados, criticidad de cambios acumulados o preajuste de diseñador.

Ahora se hace referencia a la Figura 7, que ilustra un ejemplo de actualización automática de la distribución de cambios en diferentes versiones o ramas laterales que se están editando actualmente. La versión principal o de línea de base A contiene cambios que son importantes debido a uno de los criterios anteriores y, por lo tanto, estos cambios se propagan (y se fusionan con) las versiones de rama B y C. Se apreciará que aunque terminología como "línea de base" (que denota la versión principal) y "rama" (que denota una versión actual que está siendo editada por el diseñador pero que aún no se ha fusionado con la versión principal (base de datos de borradores)) se asocia típicamente con un sistema de control de versiones, como se discutió anteriormente en este documento, una realización típica del sistema 100 puede no contener un sistema de control de versiones.

Una vez que una versión de un sitio web está lista para ser publicada, el publicador 122 puede escribir en la base de datos publicada 130 la versión actual de la base de datos de borradores 140. Se apreciará que esto puede sobrescribir la versión actualmente almacenada. Se apreciará además que el publicador 122 puede activar el archivador 123 que puede escribir en la base de datos de archivo 150 una copia de la versión del sitio web que se va a publicar.

En una realización alternativa a la presente invención, como se ilustra en la Figura 8 a la que ahora se hace referencia, la base de datos de borradores 140 puede contener una copia completa y continuamente actualizada de la versión que se encuentra en la base de datos publicada 130. Cambios en la base de datos publicada 130 realizados por un usuario, también pueden escribirse automáticamente en la base de datos de borradores 140 (es decir, en paralelo). Por lo tanto, la base de datos de borradores 140 se actualiza continuamente con los cambios realizados en la base de datos publicada 130. Se apreciará que en este escenario, los cambios en la base de datos de borradores 140 no se actualizan automáticamente en la base de datos publicada 130. El publicador 122 puede marcar cualquier cambio entrante a través del manejador de solicitudes de PDB 105 como "ya publicado" y luego puede ignorarlas al publicar nuevas actualizaciones de la base de datos de borradores 140 a la base de datos publicada 130. También se apreciará que, en esta realización, dado que la base de datos de borradores 140 contiene la versión actual contenida en la base de datos publicada 130, todas las eliminaciones pueden realizarse directamente en la base de datos de borradores 140 sin la necesidad de eliminar la base de datos de objetos 145. El publicador 122 puede detectar las diferencias entre las dos versiones contenidas en las dos bases de datos y puede eliminar los objetos relevantes de la base de datos publicada 130. Alternativamente, la eliminación de objetos puede implementarse en esta realización de manera similar a las realizaciones anteriores, es decir, utilizando una base de datos de objetos eliminados 145 incrustados dentro de base de datos de borradores 140.

En otra realización más de la presente invención, como se ilustra en la Figura 9 a la que ahora se hace referencia, la base de datos publicada 130 y la base de datos de borradores 140 pueden combinarse en una base de datos fusionada 180. La base de datos fusionada 180 puede incluir múltiples instancias de un único registro de objeto, marcado con información de estado adicional que incluye un indicador del tipo de versión de la base de datos, es decir, si el registro de objeto está asociado con la base de datos publicada o en borrador. Se apreciará que un registro o artículo dados pueden tener dos versiones, una versión "publicada" y una versión "borrador" guardada pero aún no publicada. También se apreciará que, en este escenario, la base de datos fusionada 180 puede comprender la base de datos de objetos eliminados 145 para su uso como se describe aquí anteriormente.

Ambos manejadores de solicitudes 105 y 110 pueden escribir registros en la base de datos fusionada 180 marcando sus registros según corresponda. Se apreciará que el manejador de solicitudes de PDB 105 puede leer una versión publicada del registro y que el manejador de solicitudes de DDB 110 puede leer una versión preliminar del registro o la versión publicada si no existe una versión preliminar. El publicador 122 puede marcar cualquier registro de borrador cambiado como los publicados actuales y puede eliminar (tanto lógica como físicamente) los registros publicados previos en la base de datos fusionada 180.

En una realización adicional de la presente invención, como se ilustra en la Figura 10, a la que ahora se hace referencia, el sistema 100 se puede usar junto con un sistema de control de versiones subyacente. La Figura 10 ilustra un sistema 200 en el que los cambios se encaminan dinámicamente, posiblemente activando la funcionalidad de control de versiones sin requerir que el usuario opere explícitamente un sistema de control de versiones. El sistema 200 puede tener una funcionalidad similar al sistema 100, pero el procesador de modificaciones 260 también puede comprender un clasificador de solicitudes 210, un clasificador de usuarios 220, una base de datos de usuarios 230 y un sistema de control de versiones 240. El clasificador de solicitudes 210 puede comprender además un clasificador de solicitudes de escritura 217 y un clasificador de solicitudes de lectura 215. El sistema de control de versión 240 puede comprender además un solucionador de conflictos 213, un manejador de rama 250 y un manejador de solicitudes de DDB 110. Se apreciará que el sistema de control de versiones 240 puede diseñarse intencionalmente para trabajar junto con el sistema 100 con la capacidad para trabajar con objetos y proporcionar comparación y fusión basadas en componentes, aunque puede funcionar utilizando principios y metodologías típicos de sistema de control de versiones. Se apreciará además que para todas las realizaciones, el diseñador recibe una vista publicada del sitio web a través del editor y visualizador 34.

Se apreciará que, aunque la Figura 10 ilustra una disposición combinada de base de datos publicada 130 / base de datos de borradores 140, también puede usarse con la base de datos fusionada 180.

El clasificador de solicitudes 210 puede comprobar todas las solicitudes (tanto de diseñadores como de usuarios finales) y no solo solicitudes de modificación. Esto es necesario ya que las solicitudes de lectura (tanto de los diseñadores como de los usuarios finales) pueden ser redirigidas al sistema de control de versiones 240 en algunos casos, ya que pueden ser leídas desde una rama gestionada por el sistema de control de versiones 240. El clasificador de solicitudes 210 puede clasificar todas las solicitudes (tanto de lectura como de escritura) como directa (realizada directamente y contra la base de datos publicada 130) o indirecta (realizada a través del sistema de control de versiones 240, que consulta la base de datos de borradores 240 y posiblemente la base de datos publicada 130).

El clasificador 210 de solicitud también puede consultar el clasificador de usuarios 220, ya que algunas categorías de clasificación dependen de los parámetros relacionados con el usuario (por ejemplo, clasificar según el usuario que realiza la ejecución como se describe a continuación en este documento). El clasificador de solicitudes 210 también puede consultar con la base de datos publicada 130, ya que algunas categorías de clasificación pueden depender de la aplicación (por ejemplo, clasificar según la especificación del diseñador de la aplicación).

El clasificador de solicitudes 210 puede evaluar cambios solicitados al conjunto de datos gestionado y clasificarlos en cambios directos, que no pasan por el control de versiones 240 y modificar directamente la línea de base, cambios que invocan el control de versiones 240 y son completamente resueltos por el usuario modificador que trabaja con el control de versiones 240 y cambios que se resuelven de forma transparente en el contexto del usuario específico (o un conjunto de usuarios), pero requieren un procesamiento del control de versiones 240 para aplicarse a diferentes comunidades de usuarios (similar a un sistema de flujo de trabajo). Por ejemplo, los procesos de fusión que requieren la interacción del usuario podrían dirigirse automáticamente a un usuario diferente.

Se apreciará que el clasificador de solicitudes 210 puede aplicar cambios de manera diferente a diferentes subconjuntos de la comunidad de usuarios. Por lo tanto, al manejar un cambio específico, algunas vistas de usuario pueden incluir el cambio, algunas vistas de usuario pueden no incluir el cambio y algunas vistas de usuario pueden incluir el cambio solo cuando es confirmado e integrado en la versión de línea de base (por ejemplo, por una persona específica, o por una persona seleccionada de un subconjunto específico de la comunidad de usuarios). Se apreciará que esto puede aplicarse a cambios de objeto, así como a cambios de esquema de objeto.

Además, el clasificador de solicitudes 210 puede clasificar los cambios de acuerdo con el método/UI utilizado para realizar el cambio (es decir, los cambios provenientes del editor frente a los cambios del sistema de gestión de contenido), el usuario que realiza la ejecución, la entidad que se está cambiando, el tipo de cambio, el alcance del cambio (la cantidad de elementos cambiados, cambios en atributos específicos, cambios que tienen un cierto (nivel de) efecto visual, conformidad con reglas/pautas específicas (por ejemplo, cada cambio a un color que no sea azul)) o por especificación de la aplicación diseñador (por ejemplo, como un atributo de la entidad específica que se está modificando).

Como se discutió en el presente documento anteriormente, el clasificador de solicitudes 210 también puede operar en solicitudes de lectura para proporcionar vistas diferentes o alteradas a diferentes usuarios de lectura, sobre la base de los criterios relevantes de los especificados anteriormente. El clasificador de solicitudes 210 puede realizar dichos cambios directamente. Alternativamente, el clasificador de solicitudes 210 puede incluir los parámetros relevantes (específicos del usuario o de otro tipo) junto con los datos de solicitud de lectura enviados al manejador de solicitudes de PDB 105 o al sistema 240 de control de versiones, y hacer que realicen los cambios de vista requeridos.

El clasificador de solicitudes 210 puede encaminar los cambios al sistema de control de versiones 240 que puede determinar cómo manejar el cambio específico o el conjunto de cambios requerido por el usuario (que puede ser un diseñador o un usuario final). El sistema de control de versiones 240 puede entonces determinar si abrir una nueva rama, aplicar el cambio a una rama existente o cerrar la rama del sitio web actual. El sistema de control de versiones 240 puede mantener abiertas múltiples ramas para que diferentes usuarios puedan tener diferentes vistas de la base de datos de borradores 140. El sistema de control de versiones 240 puede activarse debido a las solicitudes del usuario o externamente (por ejemplo, para operar en modo de flujo de trabajo). También puede trabajar de forma interactiva con el usuario que realiza la solicitud y también con otros usuarios (no solicitantes).

El clasificador de usuarios 220 puede acceder a un perfil de usuario desde la base de datos 230 de usuario que puede considerarse el repositorio de perfiles de usuario del sistema 200. Esto puede usarse para determinar cómo manejar los cambios realizados por el usuario (aplicar directamente o mediante el sistema de control de versiones 240) o para determinar qué versión del sitio mostrar cuando hay varias versiones paralelas disponibles.

Por ejemplo, un usuario A1 realiza un cambio X en el sitio web. El cambio X hace que el sistema de control de versiones 240 abra automáticamente una rama Y (que se almacenará en la base de datos de borradores 140) que consiste en la versión modificada del sitio que incluye el cambio X.

Los usuarios de la comunidad de usuarios A (que incluye al usuario A1, así como a los usuarios A2, A3,..., A17) son todos dirigidos (al acceder al sitio) por el clasificador de solicitudes 210 al sistema de control de versiones 240 que les proporciona información de rama Y que contiene el cambio X.

El clasificador de solicitudes 210 dirige a otros usuarios (que no pertenecen a la comunidad de usuarios A) a la base de datos publicada 130 y accederían al sitio web sin el cambio X.

El gestor de solicitudes de DDB 110 puede intentar fusionar el cambio X en la línea de base, ya sea automáticamente basándose en criterios específicos (por ejemplo, un número dado de cambios acumulados) o basándose en la solicitud del usuario. Dicha fusión puede tener éxito (por ejemplo, no hubo conflicto entre el cambio X y la versión de línea de base) o requerir una intervención manual.

Alternativamente, al usuario senior A17 es dirigido (cuando ingresa al sistema) por el clasificador de solicitudes 210 para que confirme el cambio X, descarte el cambio X o maneje cualquier dificultad para fusionar el cambio X con la línea de base.

El manejador de rama 250 puede manejar operaciones de apertura/fusión/cierre de ramas.

Se apreciará que en esta realización, el solucionador de conflictos 213 (incluido dentro del manejador de solicitudes de PDB 105, el manejador de solicitudes de DDB 110, el actualizador automático 121 y el publicador 122) también puede comprender un solucionador de conjunto de cambios 290 como se ilustra en la Figura 11 a la que ahora se hace referencia. El solucionador de conjuntos de cambios 290 puede integrarse entre los conjuntos de cambios recibidos de los usuarios y diseñadores y el sistema de control de versiones 240. Generalmente, los conjuntos de cambios recibidos pueden no ser directamente compatibles con el funcionamiento de un sistema de control de versiones, por ejemplo, un único conjunto de cambios puede afectan a varios objetos, algunos de los cuales pueden estar en edición en varias ramas del sistema de control de versiones. Además, el sistema de control de versiones 240 puede ser un sistema proporcionado externamente que está integrado en el sistema 200 y puede requerir adaptación para una integración adecuada. Por ejemplo, el sistema de control de versiones 240 puede usar una representación de datos diferente, diferente granularidad de conjunto de cambios, etc. Esta adaptación también puede ser realizada por el solucionador de conjuntos de cambios 290.

Se apreciará que el solucionador de conjuntos de cambios 290 puede ser automático/semiautomático/no automático o puede requerir la interacción del usuario.

También se apreciará que los usuarios del sistema de control de versiones 240 normalmente son plenamente conscientes de sus sistemas de control de versiones de uso y solicitan explícitamente operaciones tales como registro de salida, registro de entrada y bloqueo.

El clasificador de usuarios 220 también puede realizar además la definición automática de comunidades de usuarios, que luego se utilizan para clasificar cambios. Esto se puede hacer utilizando cualquier método de clasificación de usuarios, como clase de usuario, tipo de usuario, criterios definidos por el diseñador, la ubicación física del usuario, el dispositivo o tipo de dispositivo a través del cual el usuario accede al sistema, el método por el cual el usuario accede el sistema y la ubicación geográfica del usuario.

Se apreciará que cada una de las realizaciones mencionadas anteriormente se puede usar simultáneamente, como cuando se alojan múltiples sitios web, de modo que una realización se puede usar para un sitio web particular y otra realización para otro conjunto de sitios.

Por lo tanto, diferentes tipos y niveles de usuarios y diseñadores pueden acceder y posiblemente modificar diferentes vistas de un sitio web simultáneamente con la sincronización requerida y sin requerir tiempo de inactividad del sitio web.

Aunque en el presente documento se han ilustrado y descrito ciertas características de la invención, ahora los expertos en la técnica se darán cuenta de muchas modificaciones, sustituciones y cambios. Por lo tanto, debe entenderse que las reivindicaciones adjuntas están destinadas a cubrir todas las modificaciones y cambios que caen dentro del alcance de las reivindicaciones.

A menos que se indique específicamente lo contrario, como se desprende de las discusiones anteriores, se aprecia que, a lo largo de la memoria descriptiva, las discusiones que utilizan términos como "procesamiento", "computación", "cálculo", "determinación" o similares, se refieren a la acción y/o procesos de una ordenador, sistema informático, sistema cliente/servidor o dispositivo informático electrónico similar que manipula y/o transforma datos representados como cantidades físicas, como electrónicas, dentro de los registros y/o memorias del sistema informático en otros datos representados de manera similar como cantidades físicas dentro de las memorias del sistema informático, registros u otros dispositivos de almacenamiento, transmisión o visualización de información.

Las realizaciones de la presente invención pueden incluir un aparato para realizar las operaciones de la presente. Este aparato puede construirse especialmente para los propósitos deseados, o puede comprender un ordenador de uso general activado selectivamente o reconfigurado por un programa de ordenador almacenado en el ordenador. El aparato resultante, cuando se instruye mediante software, puede convertir el ordenador de uso general en elementos inventivos como se describe en el presente documento. Las instrucciones pueden definir el dispositivo inventivo en funcionamiento con la plataforma informática para la que se desea. Dicho programa de ordenador puede almacenarse en un medio de almacenamiento legible por ordenador, como, entre otros, cualquier tipo de disco, incluidos disquetes flexibles, discos ópticos, discos magnéticos-ópticos, memorias de solo lectura (ROM), memorias de solo lectura en disco compacto (CD-ROM), memorias de acceso aleatorio (RAM), memorias de solo lectura programables eléctricamente (EPROM), memorias de solo lectura programables y borrables eléctricamente (EEPROM), tarjetas magnéticas u ópticas, memoria Flash, disco en clave o cualquier otro tipo de medio adecuado para almacenar instrucciones electrónicas y que pueda acoplarse a un bus de sistema informático.

Los procesos y pantallas que se presentan en este documento no están intrínsecamente relacionados con ninguna ordenador u otro aparato en particular. Se pueden usar varios sistemas de propósito general con programas de acuerdo con las enseñanzas de este documento, o puede resultar conveniente construir un aparato más especializado para realizar el método deseado. La estructura deseada para una variedad de estos sistemas aparecerá en la descripción siguiente. Además, las realizaciones de la presente invención no se describen con referencia a ningún lenguaje de programación particular. Se apreciará que se puede usar una variedad de lenguajes de programación para implementar las enseñanzas de la invención como se describe en este documento.

Apéndice 1

1) Para cada cliente de software (por ejemplo, editor) que accede a la lista, hay (en un momento dado) una versión efectiva. Téngase en cuenta que esto podría ser diferente entre diferentes usuarios que acceden a la misma base de datos, por lo que (por ejemplo), un usuario podría estar trabajando en la versión más reciente (id=5), mientras que un diseñador podría haber revertido a una versión diferente (por ejemplo, id=2).

2) En el algoritmo siguiente, se utiliza DDB (si es diseñador), PDB (si es usuario).

3) Lectura de registros (diseñador/usuario):

a) Téngase en cuenta que puede haber varias instancias de un único artículo de lista con diferentes ID de versión (pero solo uno por ID de versión). Sin embargo, en el caso típico (se acaba de agregar un registro y no se modifica más adelante), habría una sola instancia del registro, con el ID de versión bajo el que fue escrito.

b) Leer todas las instancias del artículo de lista para el list_id y el item_id dados.

c) Si no se encuentra, devolver "no se encontró ningún artículo de lista";

d) Ubicar para cada instancia el campo "activo" de la tabla VT para el ID de versión dado.

e) Ubicar la instancia con el version_id más alto para el cual active = verdadero.

f) El cliente puede realizar las dos etapas anteriores en la memoria o mediante una SQL Join como:

SELECT LI.*, VT.version_id, VT.active

From LI, VT

WHERE LI.list_id = $list_id

AND LI.item_id = $item_id

AND LI.version_id=VT. version_id

AND VT.active = true

ORDER BY VT. versionjd DESC

LIMIT 1

g) Si la instancia seleccionada tiene Eliminado = Verdadero, devuelve "no se encontró ningún artículo de lista".

Téngase en cuenta que se debe marcar Eliminado después de la selección de instancia, ya que un desarrollador podría haber eliminado el artículo en v4, revertido a v3 y creado v5 basado en v3 (reviviendo así el artículo).

h) De lo contrario, devolver la instancia de artículo de lista seleccionado.

) Creación de registros (diseñador/usuario):

a) Cuando se crean artículos de lista (por usuarios en la PDB o diseñadores en la DDB), se crean con el id_versión de la versión efectiva actual y un nuevo item_id único.

) Modificación de registro (diseñador/usuario):

a) Esto se aplica cuando se lee, modifica y guarda un artículo de lista existente.

b) Obtener la versión con la que se guardó el artículo.

c) Si la versión efectiva es idéntica a la versión original de los artículos, sobrescribir el registro de artículo. d) Si la versión efectiva es diferente a la versión original de los artículos, escribir como un nuevo registro con la versión efectiva como su versión.

) Eliminación de registros (diseñador/usuario):

a) Obtener la versión con la que se guardó el artículo.

b) Crear un registro de solo encabezado con el campo "Eliminado" establecido en Verdadero y la versión efectiva.

) Publicar (solo diseñador):

a) Esto es similar a lo que se hace para otros cambios en la DDB.

b)

c) Borrar la DDB.

) Cambiar/revertir a la versión dada (solo diseñador):

a) Suponiendo que se tiene una secuencia de versiones (v1 -v5) con v5 publicada, VT se vería así:

b) Revertir a una versión anterior, p. ej. id=2 - haría lo siguiente:

i) Establecer las versiones siguientes en Activo = Falso.

ii) Asignar un nuevo version_id efectivo después del último (6 en este caso). La asignación es potencial en el sentido de que se volvería permanente (creando un nuevo registro en VT) solamente cuando se realiza un cambio en cualquier artículo de lista y se guarda en la base de datos. De esta manera, si un diseñador cambia entre varias versiones solo para obtener una vista previa de su apariencia, no creará una serie de nuevas versiones innecesarias.

iii) La nueva tabla VT sería (una vez que la posible versión 6 se haga permanente):

c) Si se vuelve a revertir, por ejemplo a la versión 4:

i) La "rama" recién creada (id=6) está "abandonada" (con cualquier artículo de lista guardado en id=6 revertiría a la última versión anterior (si existe)).

ii) Las versiones 3 y 4 se vuelven a marcar como activas.

iii) Se crea una nueva versión (id=7) para cualquier artículo creado o modificado. Como se señaló anteriormente, la asignación es "potencial" y el registro adicional se crearía en VT solo cuando un artículo se modifica y guarda realmente.

iv) La nueva tabla VT sería (una vez que la posible versión 7 se haga permanente):

Claims

REIVINDICACIONES

1. Un sistema para modificar un sitio web o una aplicación interactiva, siendo el sistema implementable en un dispositivo informático, el sistema caracterizado por:

una base de datos publicada (130) accesible a través de un servicio de datos de usuario final para presentar al menos la versión más actualizada de los objetos de dicho sitio web, siendo dichos objetos al menos uno de definido por esquema y definido por sistema y visual, visible y editable por al menos un usuario;

una base de datos de borradores (140) accesible a través de un servicio de datos de diseñador y visible y editable por al menos un diseñador para almacenar al menos ediciones en dichos objetos de dicha base de datos publicada;

un manejador de solicitudes de bases de datos publicadas (105) para coordinar la visualización y actualización simultáneas de dichos objetos entre dicho servicio de datos de usuario final y dicha base de datos publicada (130) mientras se ejecuta dicho sitio web;

un manejador de solicitudes de base de datos de borradores (110) para coordinar la visualización, edición y actualización simultáneas de dichos objetos entre dicho servicio de datos de diseñador y dicha base de datos de borradores (140) y para fusionar al menos una de las ediciones y actualizaciones de dichos objetos de dicha base de datos publicada (130) y edita y actualiza dichos objetos en dicha base de datos de borradores (140) y para devolver la versión fusionada de dichos objetos a dicho al menos un diseñador a través de dicho servicio de datos de diseñadores sin modificar dicha base de datos publicada (130) mientras se ejecuta dicho sitio web;

un sistema auxiliar (120) para actualizar dicha base de datos publicada (130) sobre la base de dicha edición y actualización de dichos objetos en dicha base de datos de borradores a través de dicho servicio de datos de diseñador;

un solucionador de conflictos (113) para resolver conflictos provocados por dichas ediciones y actualizaciones entrantes de múltiples fuentes, comprendiendo dicho solucionador de conflictos (113) un comparador y un fusionador de componentes (116) para realizar una comparación y una fusión orientadas a objetos para determinar diferentes versiones de dichos objetos.

2. El sistema según la reivindicación 1 y que también comprende una base de datos de listas (135) para almacenar listas y aplicaciones de lista.

3. El sistema según la reivindicación 1 y que también comprende un sistema de control de versiones (240).

4. El sistema según la reivindicación 1 y en donde dicho manejador de solicitudes de bases de datos publicadas (105) y dicho manejador de solicitudes de borradores de bases de datos (110) comprenden al menos uno de:

un adaptador de artículos (112) para realizar la adaptación de los artículos de lista a diferentes versiones del esquema de acuerdo con dichas solicitudes usando al menos uno de manejo basado en ID y manejo basado en cambios y para devolver dichos artículos de lista adaptados a través de al menos uno de dichos datos de usuario final servicio y dicho servicio de datos de diseñador; y

un reescritor de consultas (115) para modificar las consultas de lectura realizadas a al menos una de dicha base de datos publicada (130) y dicha base de datos de borradores (140) para soportar la recuperación de dichos artículos de lista guardados bajo diferentes versiones de un esquema dado basado en el análisis de las condiciones de consulta contra al menos uno de los campos de valores predeterminados agregados y el campo de valores predeterminados eliminado en diferentes versiones del esquema.

5. El sistema según la reivindicación 1 y en donde dicho manejador de solicitudes de base de datos de borradores (110) comprende un manejador de cambios de tipo de artículo (114) para gestionar modificaciones de definición de tipo de dichos objetos de dicho sitio web de acuerdo con dichas solicitudes.

6. Sistema según la reivindicación 1 y en donde dicho sistema auxiliar (120) comprende al menos uno de:

un actualizador automático (121) para notificar a dicho al menos un diseñador a través de dicho servicio de datos de diseñador en cuanto a los cambios realizados en un sitio web editado actualmente por otro al menos un diseñador y para fusionar dichos cambios en dicho sitio web editado actualmente;

un publicador (122) para publicar al menos uno de los cambios totales y un subconjunto de cambios de dicha base de datos de borradores (140) a dicha base de datos publicada (130) y para borrar dichos cambios de dicha base de datos de borradores;

un archivador (123) para almacenar y recuperar al menos una de las versiones archivadas total o parcial de dichos objetos en una base de datos de archivo;

un registrador de historial de edición (126) para registrar el historial de edición durante la edición por dicho al menos un diseñador en una base de datos de historial de edición;

un analizador de historial de edición (127) para analizar dicho historial de edición en dicha base de datos de historial de edición;

un revertidor (124) para revertir dichos objetos contenidos en dicha base de datos de borradores a una versión de dicha base de datos archivada, siendo dicha versión al menos una anterior o posterior a dicha versión editada actualmente, y en donde dicha versión de dicha base de datos archivada se convierte en dicha versión actual versión editada y en donde dicha reversión está limitada a datos que no están en la lista e incluye soporte para etiquetar cambios de atributos mediante el seguimiento del historial de edición de etiquetas o la coincidencia de ID de etiqueta;

un clonador (128) para crear copias de dicha base de datos publicada (130) y dicha base de datos de borradores; y un creador de bases de datos (129) para crear dicha base de datos publicada (130) y dicha base de datos de borradores (140) la primera vez que se utilizan.

7. El sistema según la reivindicación 1 y en donde dicho solucionador de conflictos (113) comprende un solucionador de conjuntos de cambios (290) para cambiar la clasificación de conjuntos para integrar conjuntos de cambios recibidos de al menos dos de dicho servicio de datos de usuario final, dicho servicio de diseñador y dicho sistema de control de versiones.

8. El sistema según la reivindicación 6 y en donde dicho actualizador automático (121) comprende un distribuidor de línea de base (117) para monitorizar cambios desde una versión de línea de base definida de dichos objetos de dicho sitio web actualmente editado en dicha base de datos de borradores.

9. El sistema según la reivindicación 7 y que comprende además:

un clasificador de solicitudes (210) para realizar la clasificación de las solicitudes entrantes de dicho servicio de datos de usuario final y dicho servicio de datos de diseñador en al menos una comunidad; y

un clasificador de usuarios (220) para acceder a perfiles de usuario desde un repositorio de perfiles de usuario.

10. Un método para modificar un sitio web o una aplicación interactiva, el método caracterizado por:

presentar una versión actualizada de los objetos de una base de datos publicada de dicho sitio web, siendo dichos objetos al menos uno de entre el definido por esquema, el definido por sistema y visual, visible y editable por al menos un usuario;

ver y editar una base de datos de borradores de dicho sitio web en donde dicha base de datos de borradores almacena al menos ediciones de dichos objetos de dicha base de datos publicada;

coordinar la visualización y actualización simultáneas de dichos objetos entre dicho servicio de datos de usuario final y dicha base de datos publicada mientras se ejecuta dicho sitio web;

coordinar la visualización, edición y actualización simultáneas de dichos objetos entre dicho servicio de datos de diseñador y dicha base de datos de borradores y fusionar al menos una de las ediciones y actualizaciones de dichos objetos de dicha base de datos publicada y las ediciones y actualizaciones de dichos objetos en dicha base de datos de borradores y devolver la versión fusionada de dichos objetos a dicho al menos un diseñador a través de dicho servicio de datos de diseñadores sin modificar dicha base de datos publicada mientras se ejecuta dicho sitio web;

resolver conflictos provocados por dichas ediciones y actualizaciones entrantes de múltiples fuentes, comprendiendo dicha resolución de conflictos realizar una comparación orientada a objetos y fusionar para determinar diferentes versiones de dichos objetos; y actualizar dicha base de datos publicada sobre la base de dicha edición y actualización de dichos objetos en dicha base de datos de borradores a través de dicho servicio de datos de diseñador.

11. El método según la reivindicación 10 y que también comprende almacenar listas y aplicaciones de listas en una base de datos de listas.

12. El sistema según la reivindicación 2 y el método según la reivindicación 11 y en donde dichas listas comprenden artículos de lista definidos de acuerdo con un esquema, y en donde una única lista incluye al menos uno de los artículos construidos de acuerdo con una única versión de esquema, artículos construidos de acuerdo con múltiples versiones de un esquema dado y artículos construidos según múltiples esquemas.

13. El método según la reivindicación 10 y que también usa un sistema de control de versiones.

14. El sistema y el método según las reivindicaciones 1 y 10 y en donde dicha base de datos de borradores y dicha base de datos publicada se combinan en una única base de datos.

15. El método según la reivindicación 10 y en donde dicha coordinación de visualización y actualización simultáneas de dichos objetos entre dicho servicio de datos de usuario final y dicha base de datos publicada y dicha coordinación de visualización, edición y actualización simultáneas de dichos objetos entre dicho servicio de datos de diseñador y dicha base de datos de borradores y dicha fusión y dicha actualización comprenden al menos uno de:

realizar la adaptación de artículos de lista a diferentes versiones de esquema de acuerdo con dichas solicitudes usando al menos uno de manejo basado en ID y manejo basado en cambios; y devolver dichos artículos de lista adaptados a través de al menos uno de dicho servicio de datos de usuario final y dicho servicio de datos de diseñador; y

modificar las consultas de lectura realizadas a al menos una de dicha base de datos publicada y dicha base de datos de borradores para apoyar la recuperación de dichos artículos de lista guardados en diferentes versiones de un esquema dado sobre la base del análisis de las condiciones de consulta contra al menos uno del campo de valores predeterminados agregado y el campo de valores predeterminados eliminado en diferentes versiones de esquema.

16. El método según la reivindicación 10 y en donde dicha coordinación de visualización, edición y actualización simultáneas de dichos objetos entre dicho servicio de datos de diseñador y dicha base de datos de borradores y dicha fusión y dicha actualización comprenden manejar modificaciones de definición de tipo de dichos objetos de dicho sitio web de acuerdo con dichas solicitudes.

17. El método según la reivindicación 10 y en donde dicha actualización comprende al menos uno de:

notificar a dicho al menos un diseñador a través de dicho servicio de datos de diseñador en cuanto a los cambios realizados en un sitio web editado actualmente por otro al menos un diseñador y fusionar dichos cambios en dicho sitio web editado actualmente;

publicar al menos uno de los cambios totales y un subconjunto de cambios de dicha base de datos de borradores a dicha base de datos publicada y borrar dichos cambios de dicha base de datos de borradores; almacenar y recuperar al menos una de las versiones archivadas total o parcial de dichos objetos en una base de datos de archivo;

registrar el historial de edición durante la edición por dicho al menos un diseñador en una base de datos de historial de edición;

analizar dicho historial de edición en dicha base de datos de historial de edición;

revertir dichos objetos contenidos en dicha base de datos de borradores a una versión de dicha base de datos archivada, siendo dicha versión al menos una anterior o posterior a dicha versión editada actualmente, y en donde dicha versión de dicha base de datos archivada se convierte en dicha versión actualmente editada y en donde dicha reversión está limitada a datos que no están en la lista e incluye soporte para cambios de atributos de etiquetas mediante el seguimiento del historial de edición de etiquetas o la coincidencia de ID de etiquetas; crear copias de dicha base de datos publicada y dicha base de datos de borradores; y

crear dicha base de datos publicada y dicha base de datos de borradores la primera vez que se utilizan.

18. El método según la reivindicación 10 y en donde dicha resolución de conflictos comprende resolver la clasificación de conjuntos de cambios para integrar conjuntos de cambios recibidos de al menos dos de dicho servicio de datos de usuario final, dicho servicio de diseñador y dicho sistema de control de versiones.

19. El método según la reivindicación 15 y en donde dicha notificación y fusión comprenden monitorizar cambios desde una versión de línea de base definida de dichos objetos de dicho sitio web actualmente editado en dicha base de datos de borradores.

20. El método según la reivindicación 16 y que también comprende:

realizar la clasificación de las solicitudes entrantes de dicho servicio de datos de usuario final y dicho servicio de datos de diseñador en al menos una comunidad; y

acceder a perfiles de usuario desde un repositorio de perfiles de usuario.