ES2970458T3 - Edición de una base de datos durante la previsualización de una página web virtual - Google Patents

Edición de una base de datos durante la previsualización de una página web virtual Download PDF

Info

Publication number
ES2970458T3
ES2970458T3 ES18848030T ES18848030T ES2970458T3 ES 2970458 T3 ES2970458 T3 ES 2970458T3 ES 18848030 T ES18848030 T ES 18848030T ES 18848030 T ES18848030 T ES 18848030T ES 2970458 T3 ES2970458 T3 ES 2970458T3
Authority
ES
Spain
Prior art keywords
web
data
code
website
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES18848030T
Other languages
English (en)
Inventor
Uval Blumenfeld
Amit Kaufman
Shay Weiner
Yoav Abrahami
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wix com Ltd
Original Assignee
Wix com Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wix com Ltd filed Critical Wix com Ltd
Application granted granted Critical
Publication of ES2970458T3 publication Critical patent/ES2970458T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9558—Details of hyperlinks; Management of linked annotations
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/972—Access to data in other repository systems, e.g. legacy data or dynamic Web page generation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/128—Restricting unauthorised execution of programs involving web programs, i.e. using technology especially used in internet, generally interacting with a web browser, e.g. hypertext markup language [HTML], applets, java
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G06F3/0486—Drag-and-drop
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/103—Formatting, i.e. changing of presentation of documents
    • G06F40/106—Display of layout of documents; Previewing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting
    • G06F40/186—Templates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/33—Intelligent editors
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)
  • User Interface Of Digital Computer (AREA)
  • Processing Or Creating Images (AREA)

Abstract

Las realizaciones divulgadas se relacionan con la actualización de una base de datos de back-end que contiene conjuntos de datos que pueblan una pluralidad de páginas web de un sitio web. Las operaciones incluyen recibir, a través de una interfaz de usuario, una pluralidad de elementos de datos; almacenar grupos de al menos un elemento de datos en una base de datos; generar una pluralidad de páginas web virtuales, en donde cada página web virtual es una vista previa de una página web real correspondiente antes de que la página web real correspondiente entre en funcionamiento; mostrar cada grupo de al menos un elemento de datos en una página separada de la pluralidad de páginas web virtuales; mostrar una herramienta de edición para permitir a un usuario editar una página web virtual a partir de la pluralidad de páginas web virtuales; traducir las ediciones de la página web virtual en actualizaciones para la base de datos; almacenar las actualizaciones en la base de datos; y habilitar una visualización en la propia página web correspondiente con las actualizaciones. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Edición de una base de datos durante la previsualización de una página web virtual
REFERENCIA CRUZADA A SOLICITUDES RELACIONADAS
Esta solicitud está relacionada con el campo de la actualización del sistema de base de datos de la interfaz del sistema.
ANTECEDENTES
La presente divulgación se refiere a sistemas de creación de sitios web para crear sitios web indexables y aplicaciones web que integran funcionalidad de la interfaz del sistema personalizada que se ejecuta en un sistema totalmente gestionado por un tercero. Por ejemplo, las realizaciones incluyen el desarrollo de funcionalidad de la interfaz del sistema personalizada que puede ejecutarse en un entorno de servidor sin estado (tales como contenedores, código sin servidor o máquinas virtuales) cuando se activa un evento programable asociado con un componente de la interfaz de usuario o una actividad del sistema sin que el usuario del sistema tenga que involucrarse en la gestión de la interacción cliente-servidor.
Además, esta divulgación se refiere al alojamiento y gestión de la carga de un sitio web proporcionando instancias de ejecución bajo demanda del sitio web o de páginas web individuales de forma instantánea. En algunas realizaciones, las instancias pueden generarse como máquinas virtuales, contenedores o elementos de código sin servidor. Más concretamente, esta divulgación se refiere a sistemas y métodos para monitorizar la carga y la actividad de sitios web alojados con el fin de añadir y eliminar automáticamente instancias que sirvan sitios web alojados en el sistema sin retrasos significativos en la respuesta a una solicitud para servir un sitio web. Además, los sitios web alojados pueden estar compuestos por una combinación de código genérico y específico del sitio web.
Aún más, la divulgación se refiere a la visualización y prueba de sitios web con acceso en tiempo real a los datos generados en un entorno de producción para y por el usuario final del sitio web y los datos vinculados al sitio web. Más concretamente, esta divulgación se refiere a proporcionar acceso a los datos que normalmente ve un usuario final de un sitio web para probar la funcionalidad y la experiencia de un sitio web por parte de un desarrollador o diseñador del sitio web.
Además, esta divulgación se refiere a la edición de una base de datos durante la previsualización de una página web virtual. Por ejemplo, los usuarios pueden almacenar grupos de elementos de datos (por ejemplo, texto, gráficos, vídeos, etc.) en una base de datos, y se pueden generar una o más páginas web virtuales para mostrar una vista previa de las páginas web. Durante la visualización de las páginas web virtuales, puede permitirse a los usuarios editar la página web virtual, y sus ediciones pueden traducirse en actualizaciones para la base de datos. Además, durante la visualización en directo de una página web real correspondiente a la página web virtual, las actualizaciones de la base de datos pueden reflejarse en la visualización en directo.
Los sistemas de creación de sitios web, tal y como se describen en el presente documento, se utilizan para permitir que personas con experiencia limitada en el desarrollo de software y/o recursos limitados desarrollen y alojen un sitio web personalizado. Los sistemas convencionales de desarrollo de sitios web, por su parte, ofrecen una UI de interfaz de usuario sin control de interfaz del sistema o con control limitado mediante llamadas a servicios externos o fragmentos de código incrustados que llaman al código del lado del servidor, lo que limita el sistema a páginas web sin opciones o con opciones mínimas para la manipulación de datos u otras funcionalidades personalizadas. Otros sistemas esperan participar plenamente en la configuración de las interacciones cliente-servidor para acceder al control total del interfaz del sistema.
Los sistemas convencionales de desarrollo de sitios web carecen de la capacidad de crear diseños de páginas web que se rellenen con datos para crear múltiples páginas dinámicas que puedan indexarse. Además, los sistemas convencionales carecen de la capacidad de integrar enrutadores basados en software para páginas web, lo que puede permitir que las páginas web contengan contenidos diferentes o funcionen de forma distinta dependiendo de cómo un usuario haya llegado a las páginas web o interactúe con ellas. Los sistemas convencionales también carecen de la capacidad de supervisar la interacción de un usuario del sitio web y mostrar salidas resultantes basadas en la funcionalidad registrada previamente asociada a esas interacciones.
Los sistemas convencionales de alojamiento de sitios web gestionados se utilizan para servir solicitudes a un sitio web bien utilizando servidores dedicados, que cuestan mucho dinero y recursos mantener listos y operativos, o bien utilizando un arranque en frío de nuevas instancias cuando se solicita un nuevo sitio web o la carga de un sitio web concreto supera un determinado umbral de retraso en la respuesta a una solicitud. Este procedimiento de arranque en frío de nuevas instancias de un sitio o páginas web conlleva un retraso sustancial en el procesamiento y la consiguiente latencia en la experiencia del usuario.
Los sistemas convencionales de desarrollo de sitios web también están limitados en cuanto a su capacidad para permitir a los usuarios editar dinámicamente las vistas previas de las páginas. Estos sistemas tampoco pueden recibir ediciones de una página previsualizada y traducirlas en actualizaciones de una base de datos en la que se basan todas o parte de las páginas. Como resultado, el uso de estos sistemas convencionales implica más acciones por parte del usuario, más ancho de banda y operaciones más engorrosas.
Los sistemas de prueba de sitios web, tal y como se describen en el presente documento, pueden configurarse para crear una experiencia realista de uso del sitio web por parte de un usuario final sin interrumpir la experiencia del usuario final. Los sistemas convencionales de prueba de sitios web, sin embargo, ofrecen una interfaz de vista previa limitada para revisar el sitio de la forma en que un usuario final experimentaría el sitio web, pero no tienen una forma de proporcionar acceso en tiempo real a los datos generados en el sitio web que se está probando. Los sistemas convencionales también carecen de la capacidad de añadir nuevos datos y eliminar los generados para el sitio sin que ello repercuta en la experiencia del usuario final.
Los sistemas convencionales de alojamiento de sitios web también son vulnerables a los complementos de funciones (por ejemplo, software que puede integrarse en la interfaz de usuario o interfaz del sistema de un sitio web) que contienen código malicioso (por ejemplo, malware). Cuando dicho código es cargado por el propietario o usuario de un sitio web, puede propagarse a través del sistema de alojamiento de sitios web y afectar a los sitios web de otros propietarios o usuarios. Los sistemas convencionales de alojamiento de sitios web carecen de capacidad para aislar los complementos de funciones cargados y evitar que infecten otros sitios web alojados habitualmente en el sistema.
En consecuencia, existe una necesidad de soluciones tecnológicas para nuevos sistemas de desarrollo de sitios web para gestionar la funcionalidad de interfaz del sistema, para proporcionar la libertad de tener más personalización del sitio web, y sin involucrar a un usuario en la configuración del servidor, el aprovisionamiento, o las interacciones servidor-cliente. Además, es necesario proporcionar herramientas tecnológicas a los usuarios para crear sitios web personalizados, incluso con capacidades de codificación personalizadas, sin necesidad de que los usuarios tengan que codificar sitios web enteros desde cero.
Además, existe la necesidad de soluciones tecnológicas para un nuevo sistema bajo demanda que gestione las solicitudes a sitios web sin retrasos significativos. Estas soluciones tecnológicas deben utilizar recursos informáticos virtuales, tales como máquinas virtuales, contenedores, código sin servidor, etc. Además, dichas soluciones deberían permitir sitios web altamente personalizados, incluyendo tanto características comunes a muchas páginas o sitios, como características exclusivas de páginas o sitios concretos.
Aún más, también existe la necesidad de soluciones tecnológicas para un nuevo sistema de pruebas de sitios web con acceso a datos en tiempo real a lo que está disponible en producción.
Además, se necesitan soluciones tecnológicas para aislar los complementos de funciones cargados y evitar que infecten sitios web alojados conjuntamente. Dichas técnicas deben ser capaces de aislar tanto los complementos de funciones de la interfaz de usuario como los del interfaz del sistema, permitiendo al mismo tiempo que dichos complementos de funciones sean cargados y utilizados por los propietarios y usuarios del sitio web.
El documento WO 2014/141122 A1 se refiere a dispositivos, sistemas y métodos para la construcción de sitios web mediante la utilización de listas de datos y divulga un sistema de construcción de sitios web (WBS) que comprende: un conjunto de elementos de contenido que se mostrarán en un sitio web que se está construyendo; un conjunto de vistas que se pueden utilizar para mostrar dichos elementos, siendo cada vista una plantilla para una sección de una página web de dicho sitio web; un módulo de correspondencia y adaptación dinámica para proporcionar dinámicamente una vista adecuada para cada elemento de contenido para mostrar dicho elemento de contenido en dicho sitio web.
El documento US 2009/0031228 A1 se refiere a esquemas para modificar y ampliar la funcionalidad de sitios web y divulga un método de habilitación de aplicaciones virtuales de un sitio web que incluye: a) a través de un dispositivo de usuario final, conectarse a un sitio web destinado a la habilitación de aplicaciones; b) generar código compatible con el dispositivo de usuario final para la renderización de una página web en el dispositivo de usuario final; c) renderizar una página web en el dispositivo de usuario final; d) proporcionar ubicaciones en una página web renderizada designadas para la habilitación virtual de aplicaciones de un sitio web; e) asignar automáticamente las ubicaciones seleccionadas en el elemento d) a las ubicaciones correspondientes en el código fuente del usuario final o del sitio web; f) proporcionar código de habilitación de aplicaciones que se insertará en las ubicaciones identificadas en el elemento e) o en otras ubicaciones generales del código del sitio web; g) generar y gestionar un paquete de configuración de habilitación de aplicaciones virtuales adaptado para almacenar la información de habilitación de aplicaciones generada en los elementos d), e) y f); y h) virtualmente (es decir, justo a tiempo) generar el código de usuario final habilitado para la aplicación de acuerdo con la información y las instrucciones contenidas en el paquete de configuración habilitador de la aplicación.
EL documento US 2013/0262986 A1 se refiere a la generación y gestión de previsualizaciones editables de páginas web y divulga un método para gestionar una previsualización editable de una página web que incluye recibir una solicitud para generar una previsualización editable de una página web, a través de un servidor de previsualización, comprendiendo la página web activos dispuestos de acuerdo con un diseño, en respuesta a la solicitud; obtener, a través del servidor de previsualización, activos de un repositorio de contenidos; generar, a través del servidor de previsualización, una previsualización editable de la página web utilizando los activos obtenidos y el diseño; y proporcionar, a través del servidor de previsualización, la previsualización de la página web a un entorno de creación para su edición por parte de un editor de contenidos de tal forma que cuando el editor de contenidos edite al menos uno de los activos obtenidos, el al menos uno de los activos obtenidos se coloque en un formato bloqueado para impedir su edición por parte de editores de contenidos adicionales.
El documento US 2014/0245257 A1 se refiere a facilitar la creación de contenidos y el desarrollo de software y, más particularmente, a un mecanismo para permitir a un usuario cambiar entre un contexto de usuario y un contexto de creador o desarrollador.
SUMARIO
Ciertas realizaciones de la presente divulgación se refieren a un sistema para construir un sitio web. El alcance de la protección está definido por las reivindicaciones independientes. Las reivindicaciones dependientes definen realizaciones adicionales.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Los dibujos adjuntos, que se incorporan y forman parte de esta memoria descriptiva, ilustran varias realizaciones y, junto con la descripción, sirven para explicar los principios divulgados. En los dibujos:
La FIG. 1 representa un sistema ejemplar de creación de sitios web en línea que interactúa con otros sistemas y componentes, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 2 representa un sistema ejemplar de creación de sitios web en línea, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 3 ilustra una ruta de ejecución del código de interfaz del sistema asociado a un activador, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 4 representa una interfaz de editor en línea ejemplar para actualizar la funcionalidad de interfaz del sistema, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 5 es un diagrama de bloques que muestra una página web dinámica ejemplar en modo de desarrollo, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 6 es un diagrama de flujo que ilustra un método de desarrollo de funcionalidad de interfaz del sistema, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 7 es un diagrama de flujo que ilustra un método para activar la ejecución de código de interfaz del sistema, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 8 representa un diagrama de bloques de un sistema de instancia de ejecución de servidor web bajo demanda, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 9 representa un diagrama esquemático de la interacción entre diversos componentes del sistema de instancia de ejecución de servidor web bajo demanda, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 10 es un diagrama de flujo que ilustra un método para responder a una solicitud web enviada para un sitio web, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 11 es una ilustración de un sistema de instancia de ejecución de servidor web bajo demanda para determinar si un sitio web está alojado, y generar e instanciar instancias de ejecución de servidor web, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 12 representa la instanciación de elementos de instancia de ejecución de servidor web con un sitio web, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 13 representa la monitorización de carga de sitios web alojados y la gestión de instancias en uso, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 14 representa el número de instancias de ejecución de servidores web disponibles para el alojamiento, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 15 representa un sistema ejemplar de pruebas en tiempo real de un sitio web, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 16a representa un diagrama esquemático de un entorno de despliegue de acceso a elementos de datos, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 16b representa un diagrama esquemático del acceso del entorno de prueba a los elementos de datos, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 17 es una ilustración del acceso desde un sitio web a datos reales y de prueba en un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 18 representa la generación de datos de prueba utilizados en un entorno de prueba para probar sitios web, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 19 es un diagrama de flujo que ilustra un método para acceder a un sitio web en un entorno de despliegue, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 20 es un diagrama de flujo que ilustra un método para acceder a un sitio web en un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 21 es un diagrama de flujo que ilustra un método para gestionar solicitudes de datos en un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 22 es un diagrama de flujo que ilustra un método para gestionar solicitudes de lectura en un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 23a es un diagrama de flujo de un método para actualizar elementos de datos en un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 23b es un diagrama de flujo de un método para actualizar elementos de datos en un entorno de despliegue, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 23c es un diagrama de flujo de un método para añadir elementos de datos en un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 24 es un diagrama de flujo que ilustra un método para borrar elementos de datos de un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación
La FIG. 25 ilustra un procedimiento de superposición para generar los resultados de la consulta de datos de prueba, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 26 es un diagrama de flujo que muestra los pasos implicados en la edición de una base de datos durante la previsualización de un sitio web, de acuerdo con algunas realizaciones de la presente divulgación. La FIG. 27 es un sistema para el desarrollo y previsualización de páginas web, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 28 es un diagrama de bloques de una página web virtual, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 29 es una vista en despiece ordenado de un miembro de accionamiento de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 30 representa un diagrama de bloques de un sistema de vista previa dinámica, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 31 ilustra una vista previa de una página web virtual que está siendo editada, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 32 es un diagrama esquemático que representa una relación entre grupos de datos y sitios web, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 33 es un diagrama esquemático que muestra los componentes implicados en la generación de páginas web virtuales, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 34 es un diagrama de flujo que muestra los pasos implicados en una previsualización de páginas web virtuales, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 35 es un diagrama esquemático de usuarios interactuando con el sistema de alojamiento de sitios web, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 36 representa un acceso controlado a sitios web coalojados, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 37 muestra grupos de sitios web coalojados que comparten código de complemento de funciones bajo rutas comunes, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 38 representa entornos de ejecución aislados del código del complemento de funciones de interfaz del sistema, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 39 representa un acceso controlado y la ejecución del código del complemento de funciones de interfaz de usuario, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 40 representa la ejecución aislada del código del complemento de funciones en el lado del cliente, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 41 es un diagrama de flujo que muestra los pasos implicados en el acceso y ejecución del código del sitio web y del complemento de funciones, de acuerdo con algunas realizaciones de la presente divulgación. La FIG. 42 es un ejemplo de interfaz de usuario para editar una página web y crear una colección de bases de datos, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 43 es un ejemplo de interfaz de usuario para editar una página web y configurar permisos para una colección de bases de datos, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 44 es un ejemplo de interfaz de usuario para editar una página web y entradas en una colección de bases de datos, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 45 es un ejemplo de interfaz de usuario para editar una página web y mostrar resultados de una colección de bases de datos, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 46 es un ejemplo de interfaz de usuario para editar una página web y crear una función repetidora, de acuerdo con algunas realizaciones de la presente divulgación.
La FIG. 47 es un ejemplo de interfaz de usuario para editar una página web y mostrar el resultado de una función de presolicitud, de acuerdo con algunas realizaciones de la presente divulgación.
DESCRIPCIÓN DETALLADA
En la siguiente descripción detallada, se establecen numerosos detalles específicos para proporcionar una comprensión profunda de las realizaciones de ejemplo divulgadas. Sin embargo, se entenderá por los expertos en la técnica que los principios de las realizaciones de ejemplo pueden ser practicados sin cada detalle específico. No se han descrito en detalle métodos, procedimientos y componentes bien conocidos para no oscurecer los principios de las realizaciones de ejemplo. A menos que se indique explícitamente, los métodos y procedimientos de ejemplo descritos en el presente documento no están limitados a un orden o secuencia particular, ni a una configuración de sistema particular. Además, algunas de las realizaciones descritas o elementos de las mismas pueden ocurrir o realizarse simultáneamente, en el mismo momento, o concurrentemente. La referencia ahora se hará detalladamente a realizaciones divulgadas, los ejemplos de las cuales se ilustran en los dibujos adjuntos. A menos que se indique explícitamente, el envío y la recepción, tal y como se utilizan en el presente documento, se entienden en un sentido amplio, incluido el envío o la recepción en respuesta a una solicitud específica o sin dicha solicitud específica. Así pues, estos términos abarcan tanto las formas activas como las pasivas de envío y recepción.
Los sistemas y métodos consistentes con la presente divulgación están dirigidos a sistemas de construcción de sitios web, incluyendo funcionalidad interfaz de usuario e interfaz del sistema personalizada. En algunas realizaciones, los sistemas de creación de sitios web pueden incluir opciones para que el usuario configure las capacidades de desarrollo de la funcionalidad de interfaz del sistema.
La FIG. 1 representa un sistema ejemplar que interactúa con otros componentes y usuarios a través de una red, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 1, el sistema de creación de sitios web (WBS) 100 incluye el Editor 110 WBS, que puede ser una herramienta para crear y editar sitios web. El WBS 100 también puede incluir un sistema de gestión de contenidos WBS (CMS) 120, que puede ser un repositorio de widgets y otras herramientas utilizadas en la construcción de sitios web, bases de datos o estructuras similares de almacenamiento de datos, código o datos que representan sitios web construidos o en desarrollo, y los datos creados, actualizados y visualizados utilizando los sitios web construidos o en desarrollo (tal como, por ejemplo, el inventario de una tienda electrónica subyacente a un sitio web de comercio electrónico).
El Editor 110 WBS puede ser un editor para construir y editar páginas web. El editor puede permitir construir sitios y páginas web partiendo de un lienzo en blanco o basándose en sitios, secciones de sitios o páginas ya desarrollados (conocidos conjuntamente como plantillas) que pueden almacenarse en el WBS CMS 120. El editor 110 WBS puede definir el diseño visual y otros atributos de las páginas de un sitio web en construcción. Las plantillas pueden definir las páginas web pertenecientes al sitio web que se está construyendo y su contenido inicial. El editor 110 WBS también puede incluir una sección de interfaz de usuario para determinar la disposición del sitio definiendo la navegación entre varias páginas. El Editor 110 WBS define el diseño de una página permitiendo a los usuarios colocar componentes en las páginas web de la forma en que preferirían que aparecieran las páginas web reales.
En algunas realizaciones, como se analiza más adelante, el WBS 100 puede alojar sitios web y páginas individuales a través de máquinas virtuales, instancias de contenedor o código sin servidor. Estas técnicas pueden mejorar los tiempos de carga y reducir la latencia para el usuario. Por ejemplo, en una situación en la que un sitio web tiene código de interfaz del sistema o interfaz de usuario integrado que debe ejecutarse, o incluye componentes específicos del sitio, dicho código y componentes pueden cargarse en instancias de ejecución de servidor sin estado la primera vez que dichas instancias se asocian con una solicitud realizada por un navegador (por ejemplo, el Navegador 131 Web ) para un sitio determinado. Estas instancias de servidor sin estado podrían reutilizarse para otras solicitudes del navegador relacionadas con el mismo sitio. Además, ofrece la ventaja de permitir que WBS 100 utilice sus recursos de servidor con base en las solicitudes reales que se atiendan, lo que resulta mucho más eficiente que utilizar instancias de ejecución de servicios web dedicadas (tales como servidores, VMs o contenedores) e infraestructura.
Las Herramientas 121 de Construcción pueden incluir widgets, que son componentes dispuestos en las páginas que edita el Editor WBS. En algunas realizaciones, los widgets pueden incluir aplicaciones desarrolladas por el usuario que crea la página web, otros usuarios, el propio proveedor de WBS o proveedores de aplicaciones de terceros. Las aplicaciones pueden proceder de repositorios tal como el WIX APP MARKET. Entre los ejemplos de widgets se incluyen widgets sencillos (tales como campos de texto, formas, etc.) o complejos (tales como calendarios, generadores de formularios, edición de imágenes, edición de vídeo, recuento de visitas, incorporación de redes sociales, etc.)
El WBS CMS 120 puede almacenar tanto componentes para la construcción de sitios web como sitios web ya construidos. En algunas realizaciones, los componentes y los sitios web se mantienen en sistemas CMS separados. Como se muestra en la FIG. 1, las Herramientas 121 de Construcción almacenadas en WBS CMS 120, que incluyen widgets y otras herramientas que ayudan a construir fácilmente un sitio web.
Las Herramientas 121 de Construcción son los bloques de construcción de un sitio web que facilitan el procedimiento de construcción e inclusión de contenidos en un sitio web. Las Herramientas 121 de Construcción pueden incluir tanto herramientas de componentes o widgets, como se ha comentado anteriormente, tales como pestañas, barra de búsqueda, botones, galería, presentaciones de diapositivas, etc., así como herramientas operativas como herramientas de alineación. Las Herramientas 121 de Construcción pueden incluir tanto widgets simples (por ejemplo, botones, campos de texto, etc.) como widgets complejos (por ejemplo, galería, widgets de calendario, etc.) y están configuradas para realizar funciones avanzadas. Las Herramientas 121 de Construcción pueden representarse como una abstracción del código que representa los widgets y otras herramientas. Las Herramientas 121 de Construcción pueden incluir herramientas públicas por defecto ofrecidas a todos los usuarios del sistema y herramientas privadas ofrecidas exclusivamente a un sitio web o usuario específico. Las herramientas privadas pueden incluir herramientas públicas que se han personalizado para el usuario o el sitio web o herramientas nuevas. Las herramientas privadas pueden ser creadas por el usuario del sistema que construye el sitio web o por terceros proveedores. Las Herramientas 121 de Construcción pueden compartirse entre múltiples sitios web construidos por diferentes grupos de usuarios y propiedad de diferentes grupos de usuarios. Las Herramientas 121 de Construcción también pueden personalizarse editando el código de las Herramientas 121 de Construcción existentes (por ejemplo, actualizando una hoja de estilo de un botón para crear una nueva hoja de estilo para un nuevo botón). Las Herramientas de Construcción personalizadas pueden almacenarse junto con las Herramientas 121 de construcción originales en la Base 122 de Datos del Área del Sistema.
El editor 110 WBS proporciona acceso remoto a las Herramientas 121 de Construcción almacenadas en la Base 122 de Datos del Área del Sistema del WBS EDT 120. Se puede crear una instancia de un widget seleccionado de Herramientas 121 de Construcción cuando un usuario coloca un widget en las páginas que está editando el editor 110 WBS. Se puede crear una instancia de un widget seleccionado de Herramientas 121 de Construcción mediante una referencia al widget en la página. También se puede crear una instancia de un widget seleccionado de Herramientas 121 de Construcción copiando el código que representa el widget seleccionado en la página web del sitio web que se está construyendo.
El editor 110 WBS es un software que normalmente se aloja en un servidor, mientras que algunos o todos sus elementos pueden cargarse para su ejecución en el dispositivo 130 de visualización del sitio web del usuario (o su Navegador 131 Web). En algunas realizaciones, el editor 110 WBS puede compartir la Base 122 de Datos del Área del Sistema con las Herramientas 121 de Construcción, o puede compartir un servidor común. No obstante, en otras realizaciones, el editor 110 WBS y la Base 122 de Datos del Área del Sistema se alojan por separado.
La Base 124 de Datos del Área de Sitio almacena los sitios web construidos utilizando el editor 110 WBS. Como se muestra, el Sitio 123 Web es un sitio web que está siendo construido usando el editor 110 WBS y almacenado en la Base 124 de Datos del Área de Sitio. El Sitio 123 Web almacenado en la Base 124 de Datos del Área de Sitio puede incluir texto que representa código y datos a los que se puede acceder, actualizar y ver utilizando el Dispositivo 140 de Desarrollo del Sitio Web. El Sitio 123 Web puede incluir una o más páginas web, incluyendo la Página 125 Web Indexable. En algunas realizaciones, por ejemplo, una o más Páginas 125 Web Indexables comparten el mismo dominio común (por ejemplo, http://www.my-site.com), subdominio (por ejemplo, http://my-site.wix.com/) o prefijo URL (por ejemplo, http://www.wix.com/wixsites/my-site/). La Página 125 Web Indexable puede incluir la Interfaz 126 de Usuario y la Interfaz 127 del Sistema. La Página 125 Web Indexable puede incluir un archivo o código especial, incluyendo o haciendo referencia a Interfaz 126 de Usuario e Interfaz 127 del Sistema, o puede ser sólo un nombre para la colección Interfaz 126 de Usuario e Interfaz 127 del Sistema, como se indica con una línea discontinua. la Interfaz 126 de Usuario puede estar compuesto por widgets y otros elementos de UI, que pueden ser instancias de Herramientas 121 de Construcción, incluida información específica de la instancia (tal como posición, tamaño y valores de atributo); dicha información específica de la instancia también puede incluir información de contención (es decir, qué componentes están contenidos dentro de qué contenedores). La Interfaz 126 de Usuario también puede incluir elementos de código como segmentos de código que se ejecutarán en la Interfaz 126 de Usuario (posiblemente afectando a los widgets durante el tiempo de ejecución). La Interfaz 126 de Usuario puede estar compuesta además por otros elementos, tales como metadatos de página, títulos, etc.
La Interfaz 126 de Usuario incluye instancias de Herramientas 121 de Construcción colocadas en la Página 125 Web Indexable del Sitio 123 Web construido utilizando el Editor 110 WBS, tales como aquellas que son siempre visibles para un usuario, son visibles por defecto, o son visibles al menos parte del tiempo. La Interfaz 127 del Sistema representa la funcionalidad que puede activarse cuando un usuario interactúa con la Interfaz 126 de Usuario o a través de eventos que no son de interacción, tal como una comunicación entrante al Sitio 123 Web, un activador basado en el tiempo o un cambio en la base de datos conectada al Sitio 123 Web. La Interfaz 127 del Sistema puede ser vista sólo parte del tiempo o puede no ser vista nunca por el usuario del Dispositivo 140 de Desarrollo de Sitio Web y del Dispositivo 150 de Personal de Proveedor de WBS. La Interfaz 126 de Usuario y la Interfaz 127 del Sistema pueden almacenarse en la Base 124 de Datos del Área de Sitio como código o datos estructurados (por ejemplo, XML, JSON, JSON-LD, etc.). El código puede almacenarse en formato textual o en código objeto compilado. El código que representa la Interfaz 126 de Usuario y la Interfaz 127 del Sistema puede estar en el mismo lenguaje de programación o formato de datos estructurados. En algunas realizaciones, el código que representa la Interfaz 127 del Sistema y el código que forma parte del FE 126 se convierte a un lenguaje de programación diferente antes de guardarlo en la Base 124 de Datos del Área de Sitio.
En algunas realizaciones, el código y los datos del Sitio 123 Web pueden compartir una base de datos o pueden tener bases de datos separadas. En algunas realizaciones, el código que representa la Interfaz 126 de Usuario y la Interfaz 127 del Sistema puede almacenarse en la Base 124 de Datos del Área de Sitio como texto sin formato en una tabla de base de datos. En otras realizaciones, el código podría almacenarse como objetos de archivo y podría almacenar una ubicación del archivo en la Base 124 de Datos del Área de Sitio. En algunas realizaciones, el código se almacena en una única ubicación en una columna de la Base 124 de Datos del Área de Sitio o en un archivo. En algunos casos, el código puede dividirse en varios archivos.
En algunas realizaciones, la Página 125 Web Indexable puede ser una página web dinámica y la Interfaz 126 de Usuario puede ser una plantilla y no la página web real. Como se explica más adelante, una página web dinámica puede ser una página web configurada para cambiar su apariencia o contenido basándose en una funcionalidad de interfaz del sistema personalizada. Ejemplos de funcionalidades de interfaz del sistema personalizadas, como se explica más adelante, incluyen la actualización de los datos mostrados en la página web, el cambio de tamaño o la alteración de imágenes en la página web, la activación de la renderización de contenidos de vídeo en la página web, etc. En algunas realizaciones, la Interfaz 126 de Usuario de las páginas web dinámicas puede ser una plantilla vinculada directamente a los datos de una tabla de base de datos para actualizar el contenido y la apariencia de diversas páginas web dinámicas.
En algunas realizaciones, el WBS 100 puede incluir más o menos componentes de los mostrados en la FIG. 1. Por ejemplo, las bases 122 y 124 de datos pueden ser una única base de datos o bases de datos separadas. Las bases de datos pueden ser un conjunto distribuido de bases de datos. Ambas bases 122 y 124 de datos pueden ser bases de datos relacionales, bases de datos orientadas a objetos, repositorios de archivos de lenguajes de datos (para lenguajes como XML o JSON) o bases de datos No SQL. Además, las bases 122 y 124 de datos pueden mantenerse en una red local (por ejemplo, una red de área local con acceso a Internet), en una red basada en la nube (por ejemplo, una arquitectura de nube pública o privada) o en un híbrido de una red local y una red basada en la nube.
Como se muestra en la FIG. 1, se puede acceder al Sitio 123 Web almacenado en una Base 124 de Datos del Área de Sitio en el WBS CMS 120 mediante el Dispositivo 130 de Visualización del Sitio Web (por ejemplo, ordenador de sobremesa, tableta, ordenador portátil, teléfono inteligente, etc.) a través del Navegador 131 Web. Un usuario (no representado) del Dispositivo 130 de Visualización de Páginas Web puede solicitar acceso a la Sitio 123 Web a través de la Red 160 (por ejemplo, Internet, incluyendo redes intermediarias entre el Dispositivo 130 de Visualización de Páginas Web y el WBS 100). El Navegador 131 Web (por ejemplo, APPLE SAFARI, GOOGLE CHROME, MOZILLA FIREFOX, MICROSOFT EXPLORER, etc.) del Dispositivo 130 de Visualización Web puede utilizarse para ver el Sitio 123 Web y los datos creados y editados utilizando el Sitio 123 Web. El Dispositivo 140 de Desarrollo de Sitios Web puede utilizarse para construir el Sitio 123 Web utilizando el Editor 110 WBS. El Navegador 141 Web en el Dispositivo 140 de Desarrollo de Sitios Web puede utilizarse para realizar una solicitud de acceso al Editor 110 WBS para construir el Sitio 123 Web. El Dispositivo 150 del Personal de Proveedor de WBS puede utilizarse para proporcionar soporte al cliente para un usuario (no representado) del Dispositivo 140 de Desarrollo de Sitios Web cuando se construye y mantiene el Sitio 123 Web. El Dispositivo 150 del Personal de Proveedor de WBS también puede ser utilizado por terceros vendedores para crear y personalizar Herramientas 121 de Construcción. El Dispositivo 150 del Personal de Proveedor de WBS también puede utilizarse para configurar el propio WBS 100 - por ejemplo, para gestionar el diseñador del sitio y las cuentas de usuario, para gestionar las plantillas de sitio o de página descritas anteriormente (creando nuevas o editando las existentes) o para gestionar los diversos elementos que componen el WBS 100.
En algunas realizaciones, el Dispositivo 130 de Visualización del Sitio Web, el Dispositivo 140 de Desarrollo del Sitio Web y el Dispositivo 150 del Personal de Proveedor de WBS pueden ser dispositivos físicamente diferentes. En otros casos, pueden verse diferentes a las que se accede desde el mismo dispositivo utilizando credenciales diferentes y/o roles diferentes. En algunas realizaciones, los navegadores 131, 141 y 151 web pueden ser el mismo navegador o diferentes navegadores en el mismo o diferentes dispositivos o diferentes pestañas en el mismo navegador.
El Dispositivo 130 de Visualización del Sitio Web, el Dispositivo 140 de Desarrollo del Sitio Web y el Dispositivo 150 del Personal de Proveedor de WBS pueden acceder al Sitio 123 Web a través de la Red 160. En algunas realizaciones, el Dispositivo 130 de Visualización del Sitio Web, el Dispositivo 140 de Desarrollo del Sitio Web y el Dispositivo 150 del Personal de Proveedor de WBS pueden ser un dispositivo móvil, un ordenador portátil, un ordenador de sobremesa, una tableta, etc.
Como se muestra en la FIG. 1, el Motor 170 de Búsqueda (por ejemplo, GOOGLE, YAHOO, BING, etc.) puede acceder a la Página 125 Web Indexable del Sitio 123 Web almacenada en la Base 124 de Datos del Área de Sitio a través de la Red 160, con o sin interactuar también con el WBS 100. El Motor 170 de Búsqueda puede indexar la Página 125 Web Indexable del Sitio 123 Web para facilitar su descubrimiento y aumentar así el número de usuarios que utilizan el Dispositivo 130 de Visualización del Sitio Web para ver el Sitio 123 Web. En algunas realizaciones, las Herramientas 121 de Construcción permiten además a los usuarios optimizar el Sitio 123 Web para su indexación y búsqueda a través del Motor 170 de Búsqueda. Por ejemplo, las Herramientas 121 de Construcción pueden permitir a los usuarios elegir el texto que aparece en las cabeceras de una determinada Página 125 Web Indexable, en determinadas ubicaciones de la Página 125 Web Indexable, o que está asociado (por ejemplo, como metadatos) con la Página 125 Web Indexable.
La FIG. 2 representa una estructura ejemplar del WBS 100, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 2, el WBS 100 incluye la Base 124 de Datos del Área de Sitio, que incluye componentes tanto para la construcción como para el alojamiento de sitios web, tal y como se ha comentado anteriormente en relación con la FIG. 1.
En algunas realizaciones, la Página 125 Web Indexable puede ser una página web dinámica o virtual en la que los componentes de la Interfaz 126 de Usuario podrían estar poblados con datos del Grupo 210 de Datos. El Grupo 210 de Datos puede estar asociado a más de una página web. El Grupo 210 de Datos puede estar compuesto por Elementos de Datos incluyendo el Elemento 211 de Datos. El Elemento 211 de Datos puede estar asociado con uno o más componentes de las Herramientas 121 de Construcción utilizados en la Interfaz 126 de Usuario de la Página 125 Web Indexable. Por ejemplo, el Grupo 210 de Datos puede ser una base de datos de empleados en la que cada Elemento 211 de Datos es un registro de empleado que contiene múltiples campos de datos (tal como nombre, edad e información de departamento). Estos campos múltiples pueden utilizarse para rellenar múltiples componentes visibles (campos de visualización) en la Interfaz 126 de Usuario de la Página 125 Web Indexable. En algunas realizaciones, el Grupo 210 de Datos se almacena en la Base 124 de Datos de Área Local como parte de una tabla y el Elemento 211 de Datos es una fila de esa tabla. Una página web asociada al Grupo 210 de Datos puede ser, por ejemplo, una página web dinámica.
Los Elementos 210 de Datos pueden asociarse con la DB 220 de Asociaciones URL. Cuando un usuario accede a la Página 125 Web Indexable del Sitio 123 Web utilizando el Dispositivo 130 de Visualización Web escribiendo una URL, la URL (o un segmento de la misma) puede compararse con las URL o segmentos de URL almacenados en la DB 220 de Asociaciones URL para su referenciación. Los grupos de datos pueden asociarse a una URL o a un segmento de URL en la DB 220 de Asociaciones URL. Una URL o segmento de URL en la DB 220 de Asociaciones URL puede ayudar a determinar el grupo de datos que se utilizará para generar la página web virtual o dinámica utilizando la Página 125 Web Indexable asociada. En algunas realizaciones, la Página 125 Web Indexable es una plantilla de una página web dinámica o virtual y la página web real se genera utilizando los datos del Grupo 210 de Datos determinados utilizando una URL en la DB 200 de Asociaciones URL.
Los Elementos 210 de Datos pueden determinarse utilizando un enrutador basado en software, que analiza una URL (o segmentos de URL) tecleados por un usuario o proporcionados de otro modo para acceder a una Página 125 Web del Sitio 123 Web utilizando el Dispositivo 130 de Visualización Web. El análisis de la URL por parte del enrutador basado en software puede dar como resultado una clave para acceder al Elemento 211 de Datos del Grupo 210 de Datos. Por ejemplo, con la URL http://mysite.wix.com/users/20, un enrutador basado en software puede analizar la URL para determinar que el prefijo "usuarios" está asociado con el grupo de datos y el sufijo "20" es la clave que resulta en la búsqueda del elemento de datos en el grupo de datos asociado "usuarios" que se identifica por un valor clave "20" Como se describe en el prese documento, un enrutador basado en software puede estar configurado para analizar el sufijo de una URL o un parámetro dentro de una URL para determinar qué versión de una página web, o qué contenido en una página web, mostrar. Todo lo anterior puede aplicarse a las URL que no son tecleadas directamente por el usuario, sino que son recibidas de otro modo por el sistema (por ejemplo, URL generadas automáticamente por otra página o código asociado a la página en el sitio web). El sistema también puede admitir varios enrutadores de software definidos simultáneamente, y el sistema 100 de construcción de sitios web realiza un análisis inicial de una URL recibida para determinar cuál de los enrutadores de software definidos debe utilizar. Dicho análisis puede realizar su determinación basándose en la URL recibida, basándose en las definiciones incluidas en la DB 220 de Asociaciones URL o basándose en información o condiciones adicionales (tal como las condiciones del entorno del sistema).
Las Primeras Instrucciones 240 son un conjunto de instrucciones a las que accede el Navegador 141 Web y que pueden ser configurables a través del Procesador 260. Las Primeras Instrucciones 240 ayudan al Navegador 141 Web a acceder remotamente a una biblioteca almacenada de herramientas incluyendo las Herramientas 121 de Construcción. La Interfaz 243 del Editor En Línea puede ser la representación visual del software Editor 110 WBS en el Navegador 141 Web. La Interfaz 243 del Editor En Línea se utiliza para crear y editar la implementación del diseño de la Interfaz 126 de Usuario de la Página 125 Web Indexable con la ayuda de las Herramientas 121 de Construcción y el código asociado de la Interfaz 126 de Usuario y la Interfaz 127 del Sistema de la Página 125 Web Indexable. De forma similar a las Primeras Instrucciones 240, las instrucciones adicionales (por ejemplo, las Segundas Instrucciones 250 y las Terceras Instrucciones 260, entre otras instrucciones) también pueden ser accesibles para el Procesador 260 y el Navegador 141 Web.
El Navegador 141 Web se utiliza para construir el Sitio 123 Web mostrando la Interfaz 242 de Navegación para navegar entre las diferentes partes del Sitio 123 Web y la Interfaz 213 de Editor En Línea para editar la parte de la Sitio 123 Web a la que se ha accedido. El código que representa al editor 110 WBS en el WBS 100 puede transmitirse al Navegador 141 Web para mostrar la Interfaz 242 de Navegación y la Interfaz 243 de Editor En Línea.
La FIG. 3 ilustra una ruta de ejecución del código de interfaz del sistema asociado a un activador, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 3, un Activador 310 puede resultar en la ejecución de código asociado con la Interfaz 127 del Sistema. Un Activador 310 puede producirse, por ejemplo, cuando un usuario de un Dispositivo 130 de Visualización Web que interactúa con la Página 125 Web Indexable del Sitio 123 Web realiza una acción específica (por ejemplo, un clic con el ratón o el panel táctil, una selección, un desplazamiento del cursor, una solicitud de recarga, la introducción de texto, la carga de contenido multimedia, etc.). Un Activador 310 también puede ocurrir durante un evento de no-interacción. Por ejemplo, las acciones periódicas basadas en el tiempo o las actualizaciones de la base de datos podrían dar lugar a un desencadenante y a la ejecución del código del Interfaz 127 del Sistema y/o del Interfaz 127 de Usuario. El Activador 310 puede ser personalizable y adoptar muchas formas diferentes. Además, las interacciones que necesitan resultar en la ejecución de código relacionado con la Interfaz 127 del Sistema pueden realizarse a través de un Evento 320 Programable. El Evento 320 Programare pasa el control a la Interfaz 127 del Sistema para su ejecución a través de un gancho que une la Interfaz 126 de Usuario y la Interfaz 127 del Sistema. El tipo de gancho utilizado para pasar el control entre el Evento 320 Programable y la Interfaz 127 del Sistema puede ser configurable y también puede depender del tipo de interacción u otro tipo de evento que causó el Activador 310. El Evento 320 Programable utiliza uno o más del Gancho 330 de Datos, Gancho 340 de Web, o Gancho 350 para Enrutador de Enlace de Datos, entre otros posibles tipos de ganchos, para pasar el control a la Interfaz 127 del Sistema para ejecutar el código en él.
El Gancho 330 de Datos puede ser utilizado para pasar el control desde el Evento 320 Programable al Interfaz 127 del Sistema cuando cualquier actualización de datos es introducida por un usuario del Dispositivo 130 de Visualización Web en la Página 125 Web Indexable del Sitio 123 Web mostrado en el Navegador 131 Web. Por ejemplo, el envío de un formulario puede considerarse una actualización de datos y el Gancho 330 de Datos puede utilizarse para pasar el control al Interfaz 127 del Sistema, que en algunas realizaciones crea o actualiza una entrada de la base de datos. Del mismo modo, como otro ejemplo, la publicación de texto en un blog o interfaz de medios sociales puede ser una actualización de datos asociada con el Gancho 330 de Datos. El Datos 330 de Gancho también puede utilizarse para pasar el control a la Interfaz 127 del Sistema mediante programación a través de una llamada a la API. Por ejemplo, un Activador 310 de acción periódica basada en el tiempo puede hacer que las entradas de una base de datos más antiguas que un periodo sean borradas o marcadas como inactivas.
El Gancho 340 de Web puede utilizarse para pasar el control desde el Evento 320 Programable al Interfaz 127 del Sistema cuando una función del módulo web es importada y llamada en el código que forma parte de la Interfaz 126 de Usuario. En algunas realizaciones, por ejemplo, el código que forma parte de la Interfaz 126 de Usuario se denomina secuencia de comandos de interfaz de usuario y se ejecuta cuando un usuario del dispositivo de visualización web interactúa con los componentes de la Interfaz 126 de Usuario de la Página 125 Web Indexable del Sitio 123 Web que se muestra en el Navegador 123 Web. Por ejemplo, el Gancho 340 de Web puede basarse en que un usuario de la Página 125 Web Indexable utilice una aplicación, realice una compra, se suscriba a contenidos de la Página 125 Web Indexable, etc.
El Enrutador 350 de Enlace de Datos de Gancho puede ser utilizado para pasar el control desde el Evento 320 Programable al Interfaz 127 del Sistema cuando una página web dinámica específica es solicitada por un usuario del Dispositivo 130 de Visualización Web navegando a una determinada URL en el Navegador 131 Web. Se puede navegar, por ejemplo, introduciendo una URL en la barra de direcciones del Navegador 131 Web, haciendo clic en un hipervínculo de una Página 125 Web Indexable del Sitio 123 Web que se esté viendo en el Navegador 131 Web o realizando una operación que navegue automáticamente a una URL predefinida o generada mediante programación. El Gancho 350 para Enrutador de Enlace de Datos ayuda a determinar el Grupo 210 de Datos y la función en código de la Interfaz 127 del Sistema a ejecutar para aplicar el Elemento 211 de Datos del Grupo 210 de Datos determinado a la plantilla de una página web definida en la función en código de Interfaz 127 del Sistema.
En algunas realizaciones, el Enrutador 350 de Enlace de Datos de Gancho puede funcionar junto con un enrutador basado en software. Por ejemplo, si un usuario que accede a la Página 125 Web Indexable introduce una URL para la Página 125 Web Indexable, un enrutador basado en software puede determinar qué datos mostrar en la Página 125 Web Indexable o incluso qué página web específica mostrar. Un enrutador puede asociarse a un prefijo que puede ser la primera parte de una URL (o a otro segmento de la URL). Por ejemplo, en la URL http://www.wix.com/label, "label" puede ser el prefijo. Además, en la URL http://www.wix.com/label/sub-label, "sub-label" puede ser un sufijo. Basándose en el segmento particular (por ejemplo, prefijo, sufijo o valor de un parámetro) de la URL que se proporciona, el enrutador puede determinar que debe mostrarse el contenido asociado a cualquiera de los dos, o que debe mostrarse una página web particular asociada a cualquiera de los dos. Por ejemplo, el prefijo puede asociarse a un enrutador, mientras que el sufijo puede pasarse al enrutador seleccionado para determinar a qué página acceder o qué datos utilizar en la página. Los enrutadores también pueden utilizarse para generar páginas virtuales o dinámicas completas a partir de los datos seleccionados y una plantilla. De este modo, la Página 125 Web Indexable del Sitio 123 Web puede hacerse dinámica y personalizable en función de cómo interactúen los usuarios con ella.
El Enrutador 350 de Enlace de Datos de Gancho también puede funcionar para pasar control basado en eventos internos tras la interacción del usuario con el Sitio 123 Web en el Dispositivo 130 de Visualización del Sitio Web. Por ejemplo, el Gancho 350 para Enrutador de Enlace de Datos podría registrarse para ejecutar una función antes de determinar un enrutamiento a una página como se ha descrito anteriormente para verificar si un usuario tiene permiso para acceder a la página enrutada. Los Ganchos 330 de Datos pueden ejecutarse opcionalmente antes o después de los Ganchos 350 para Enrutador de Enlace de Datos para el mismo Activador 310. Por ejemplo, un Gancho 330 de Datos podría ejecutarse después de que se ejecute una consulta contra la base de datos conectada al Sitio 123 Web para filtrar las entradas que ya no están activas (por ejemplo, un sitio web de una tienda comercial podría filtrar los productos que ya no se venden de los resultados de búsqueda de la consulta de la base de datos). De este modo, el sistema puede admitir el funcionamiento de diversas combinaciones de ganchos y el encadenamiento de ganchos entre sí.
La FIG. 4 es un diagrama de bloques que muestra una Página 125 Web dinámica ejemplar en modo de desarrollo a la que se accede en un Dispositivo 140 de Desarrollo Web a través del Navegador 141 Web, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 4, la Interfaz 243 del Editor En Línea está compuesta por la Interfaz 410 Unificada y la Interfaz 420 de Vista Previa.
La Interfaz 410 Unificada puede utilizarse para desarrollar o construir la Página 125 Web Indexable de un Sitio 123 Web. La Interfaz 410 Unificada puede proporcionar acceso a las Herramientas 121 de Construcción, como se ha comentado anteriormente. Las Herramientas 121 de Construcción pueden incluir Herramientas 411 de Edición para ayudar a editar la Página 125 Web Indexable del Sitio 123 Web. En algunas realizaciones, la Interfaz 410 Unificada podría ser una sección separada visible en un Navegador 141 Web durante el desarrollo. En otras realizaciones, la Interfaz 410 Unificada podría ser un nombre colectivo para las distintas herramientas y secciones de la interfaz de usuario. En algunas realizaciones, la Interfaz 410 Unificada puede ser una sección separada de una página web mostrada o una ventana flotante o un marco. En algunas realizaciones, los componentes de la Interfaz 410 Unificada podrían flotar dentro de una sección del Navegador 141 Web.
La Interfaz 126 de Usuario y la Interfaz 127 del Sistema pueden mostrarse o representarse en un modo de edición juntos o en ventanas separadas. En algunos casos, sólo pueden mostrarse de uno en uno. Asimismo, la Interfaz 127 del Sistema puede no ser específica de la Página 125 Web o del Sitio 123 Web que se muestra, y parte o la totalidad del mismo puede compartirse entre sitios web y desarrolladores de diferentes sitios web. Cuando un desarrollador guarda el Sitio 123 Web, la Interfaz de usuario puede guardarse en forma de Interfaz 126 de Usuario.
La Interfaz 420 de Vista Previa ayuda a los usuarios a visualizar el Sitio 123 Web que se está construyendo, mostrando las Páginas 125 Web como en el mundo real, es decir, como se mostrarían en el Navegador 131 Web en el Dispositivo 130 de Visualización Web que muestra la Página 421 Web Virtual. Cada Página 421 Web Virtual puede estar asociada a un Identificador 422 único. En algunas realizaciones, el Identificador 422 único es una URL o segmento de URL almacenado en la Base 124 de Datos del Área de Sitio junto con otras URL 210. También son posibles otras formas de Identificador 422.
La FIG. 5 es un diagrama de bloques que muestra una página web dinámica o virtual ejemplar en modo de desarrollo, de acuerdo con algunas realizaciones de la presente divulgación. Por ejemplo, como se ha comentado anteriormente en relación con la FIG. 4, la página web dinámica o virtual puede ser la Página 421 Web Virtual.
Como se muestra en la FIG. 5, la Interfaz 410 Unificada muestra Herramientas 121 de Construcción y la Página 125 Web Indexable. En esta ilustración ejemplar, Interfaz 126 de Usuario se muestra utilizando un editor WYSIWYG para editar visualmente el contenido de la página (por ejemplo, texto, gráficos, widgets, etc.). En algunas realizaciones, la Interfaz 126 de Usuario puede editarse directamente como código. En algunas realizaciones, las Herramientas 121 de Construcción son una sección de la interfaz de usuario dentro de la Interfaz 410 Unificada. En otras realizaciones, se puede acceder a las Herramientas 121 de Construcción mediante elementos de menú en la Interfaz 243 de Editor En Línea. En algunas realizaciones, las herramientas de creación de sitios web seleccionadas en Herramientas 121 de Construcción se pueden arrastrar y soltar en la sección Interfaz 126 de Usuario de la Interfaz 410 Unificada. La Interfaz 126 de Usuario de la Página 125 Web Indexable muestra la disposición visual de las Herramientas 121 de Construcción.
En algunas realizaciones, la Interfaz 127 del Sistema se muestra como una ventana flotante dentro de la Interfaz 410 Unificada. En otras realizaciones, la Interfaz 127 del Sistema podría ser una sección separada similar a la Interfaz 126 de Usuario. El código que representa Interfaz 127 del Sistema puede estar oculto y no mostrarse a menos que se solicite. En algunas realizaciones, se muestra todo el código Interfaz 127 del Sistema todo el tiempo, y en otras realizaciones sólo se muestra el código Interfaz 127 del Sistema asociado a un único elemento de las Herramientas 121 de Construcción.
El WBS 100 puede configurarse para generar automáticamente código esqueleto al seleccionar un elemento de las Herramientas 121 de Construcción y colocar el elemento en la Interfaz 126 de Usuario. El código esqueleto generado que se muestra en Interfaz 127 del Sistema puede incluir, por ejemplo, Función 521 de Armazón y Código 522 de Armazón. La Función 521 de Armazón y el Código 522 de Armazón juntos representan un Evento 320 Programable en código ejecutado por un Activador 310. En algunas realizaciones, como se ilustra, la Función 521 de Armazón de buttonClick es código que representa el evento de pulsar un botón. La activación de un clic en un botón da lugar a un buttonClick de evento programable.
La FIG. 6 es un diagrama de flujo que ilustra el Método 600 de desarrollo de la funcionalidad 127 de la interfaz del sistema, de acuerdo con algunas realizaciones de la presente divulgación. En algunas realizaciones, el Método 600 puede ser ejecutado por componentes del WBS 100, como se ha comentado anteriormente.
Como se muestra en la FIG. 6, en el Paso 610, el WBS 100 recibe una solicitud de acceso a las Herramientas 121 de Construcción en la Base 124 de Datos del Área de Sitio de un usuario del Dispositivo 140 de Desarrollo Web cuando el usuario realiza una solicitud de desarrollo del Sitio 123 Web a través del Navegador 141 Web. Como se ha comentado anteriormente, algunos ejemplos de Herramientas 121 de Construcción incluyen widgets, gráficos y otros contenidos.
En el Paso 620, el WBS 100 transmite las Primeras Instrucciones 240 a solicitud del Dispositivo 140 de Desarrollo del Sitio Web a través del Navegador 141 Web. La solicitud es recibida por el WBS 100 a través de la Red 160. La solicitud se envía al sitio web CMS 120. El sitio web CMS 120 proporciona acceso a las Primeras Instrucciones 240 solicitadas por el Procesador 260 y son transmitidas al Navegador 141 del Sitio Web. Las Primeras Instrucciones 230 proporcionan acceso a las Herramientas 121 de Construcción almacenadas en la Base 124 de Datos del Área de Sitio y que permiten construir la Interfaz 126 de Usuario y la Interfaz 127 del Sistema de la Página 125 Web.
En el Paso 630, el WBS 100, al recibir una solicitud del Dispositivo 140 de Desarrollo de Sitios Web a través de una Red 160 para utilizar una herramienta dentro de las Herramientas 121 de Construcción, genera automáticamente el código esqueleto de una herramienta seleccionada en las Herramientas 121 de Construcción basándose en las reglas. Por ejemplo, como se ha comentado anteriormente en relación con la FIG. 5, el código del esqueleto puede estar asociado a un evento, tal como un clic del ratón, un hover, una selección de contenido, etc.
En el Paso 640, el WBS 100 puede transmitir el código esqueleto al Dispositivo 140 de Desarrollo de Sitios Web para que se muestre en el Navegador 141 Web.
En el Paso 650, el WBS 100 puede proporcionar acceso a la funcionalidad 127 personalizada de Interfaz del Sistema asociada con la Sitio 123 Web cuya Interfaz 126 de Usuario se está editando o creando. Como se ha comentado anteriormente, la funcionalidad 127 de Interfaz del Sistema puede adoptar diversas formas diferentes y puede configurarse para que se produzca en función de diversos eventos definidos.
En el Paso 660, el WBS 100 puede recibir especificaciones de un usuario del Dispositivo 140 de Desarrollo del Sitio Web a través del Navegador 141 Web para configurar el Evento 320 Programable para activar la funcionalidad 127 personalizada de la interfaz del sistema.
En el Paso 670, el WBS 100 puede recibir del usuario del Dispositivo 140 de Desarrollo de Sitios Web a través del Navegador 141 Web código editable por el usuario que implementa la funcionalidad 127 de Interfaz del Sistema. El usuario puede modificar el código, por ejemplo, cambiando su funcionalidad, actualizándolo, etc.
En el Paso 680, el WBS 100 puede almacenar el código editable por el usuario editado en la Base 124 de Datos del Área de Sitio tal como se recibió del Dispositivo 140 de Desarrollo del Sitio Web a través de la Red 160. El código editable por el usuario editado puede entonces estar listo para su despliegue para proporcionar funcionalidad personalizada Interfaz 127 del Sistema para la Página 125 Web Indexable.
La FIG. 7 es un diagrama de flujo que ilustra un Método 700 para activar la ejecución del código de la Interfaz 127 del Sistema, de acuerdo con algunas realizaciones de la presente divulgación. El método 700 puede realizarse junto con el método 600, como se ha comentado anteriormente. De acuerdo con la discusión anterior, el Método 700 puede realizarse en el sistema de WBS 100.
Como se muestra en la FIG. 7, un usuario de un Dispositivo 130 de Visualización de Páginas Web puede Activar 310 un Evento 320 Programable asociado con la Interfaz 127 del Sistema ya sea mediante una transición en una Página 125 Web Indexable como se muestra en el Paso 711, cuando un usuario del Dispositivo 130 de Visualización de Páginas Web interactúa con la Página 125 Web Indexable como se muestra en el Paso 712, o cuando el usuario introduce una actualización en una Página 125 Web Indexable y da como resultado la Activación 310 como se muestra en el Paso 713. Por ejemplo, el Paso 711 puede implicar que un usuario haga clic en un hipervínculo anidado en la Página 125 Web Indexable asociado con otra página web parte del mismo Sitio 123 Web. Del mismo modo, el Paso 711 puede implicar que un usuario haga clic en un hipervínculo "siguiente" o "continuar" en la Página 125 Web Indexable para ver una página relacionada posterior. El Paso 712 puede implicar, por ejemplo, que el usuario pase el cursor por encima de un gráfico o texto de la Página 125 Web Indexable, que haga una pausa durante un periodo de tiempo predefinido, que haga clic en una imagen o texto de la Página 125 Web Indexable, etc. El paso 713 puede implicar que el usuario actualice contenido textual en la Página 125 Web Indexable, cargue una imagen o un archivo de vídeo en la Página 125 Web Indexable, rellene un formulario en la Página 125 Web Indexable, un temporizador de periodo que dé lugar a determinadas acciones, una actualización de la base de datos, etc.
En el Paso 720, el WBS 100, tras recibir una notificación de un Evento 320 Programable, accede al Activador 310 en respuesta que está asociado con el Evento 320 Programable. Como se ha comentado anteriormente, el Evento 320 Programable puede basarse en diversos tipos de ganchos, tal como un Gancho 330 de Datos, un Gancho 340 de Web, un Gancho 350 de Enrutador de Enlace de Datos, u otros. Los ganchos asociados con el Evento 320 Programable pueden implicar el acceso a datos internos de un Sitio 123 Web (por ejemplo, WixData) almacenados en la Base 124 de Datos del Área de Sitio.
En el Paso 730, el WBS 100 puede opcionalmente obtener datos externos a la Base 124 de Datos del Área de Sitio en línea y al Navegador 141 Web remoto (por ejemplo, de una base de datos externa, de otro sitio web, de un servicio remoto, etc.). En algunas realizaciones, dichos datos pueden utilizarse como parte del Evento 320 Programable.
En el Paso 740, el WBS 100 puede solicitar al Procesador 260 que ejecute el código Interfaz 127 del Sistema editado y editable por el usuario. En consecuencia, tras el Evento 320 Programare, puede producirse una funcionalidad de interfaz del sistema personalizada en la Página 125 Web Indexable. Como se ha comentado anteriormente, esta funcionalidad de interfaz del sistema personalizada puede definirse en términos de su funcionalidad, fuente de datos y temporización mediante la entrada del usuario. El usuario puede tener un control guiado sobre la creación y edición de código (por ejemplo, no tener que codificar funciones enteras desde cero, sino que se le proporcionen plantillas o muestras de código) sobre cada uno de estos atributos de la funcionalidad de interfaz del sistema personalizada.
Los sistemas y métodos consistentes con la presente divulgación también están dirigidos a sistemas de alojamiento de sitios web bajo demanda, incluyendo funcionalidad para alojar sitios web, servir sitios web a clientes, monitorizar la carga del sitio web y responder a la dinámica de carga del sitio web. En algunas realizaciones, la instancia ejecutable bajo demanda puede monitorizar la actividad de uso del sitio web y automáticamente poner en marcha o eliminar algunas o todas las instancias de ejecución. Además, como se explica más adelante, las instancias de ejecución del servidor web creadas para servir sitios o páginas web pueden incluir combinaciones de código genérico del sitio web y código específico del sitio o de la página, lo que da como resultado un servicio receptivo y muy eficiente de sitios y páginas web altamente personalizados e individualizados.
En general, cuando los usuarios interactúan con sitios web, pueden hacer una variedad de solicitudes HTTP. Por ejemplo, se puede realizar una solicitud HTTP inicial para cargar una página web (que podría, en algunas situaciones, desencadenar solicitudes HTTP adicionales para cargar elementos adicionales de la página, tales como imágenes o secuencias de comandos). Además, un usuario puede realizar solicitudes HTTP en mitad de la sesión (por ejemplo, seleccionar un valor para un campo, hacer clic en una imagen hipervinculada, etc.). Además, un usuario puede realizar una solicitud HTTP relacionada con datos, tal como por ejemplo a través del envío de un formulario. Además, un usuario puede realizar una solicitud HTTP de interfaz del sistema, que podría activar la funcionalidad de interfaz del sistema (por ejemplo, a través de código de interfaz del sistema, como se describe en el presente documento).
Con el fin de acelerar el procedimiento de carga de páginas y el manejo de solicitudes HTTP, el sistema (por ejemplo, WBS 100) puede configurarse para utilizar el arranque rápido de contenedores Docker o código sin servidor que están configurados para un sitio web o página específica. En algunas realizaciones, como se discute en el presente documento, un conjunto de contenedores de espera u otros recursos informáticos virtuales pueden proporcionarse con todo el código relevante no específico del sitio, pero sin ningún código específico del usuario o del sitio. A continuación, el sistema puede escuchar en un puerto activo una solicitud a un servidor para un sitio web específico. Si existe un contenedor activo u otro recurso informático virtual asociado al sitio web específico, el sistema puede conectarse a él. De lo contrario, el sistema puede utilizar un contenedor en espera del grupo e inyectar allí el contenido específico del sitio solicitado, o indicarle que cargue dicho contenido. Una vez cargado el contenido específico de un sitio determinado, el contenedor se une a un grupo de contenedores asociados a dicho sitio. Como ya se ha comentado, el contenido inyectado a nivel de sitio puede o no incluir las páginas reales del sitio. Dicha información de la página del sitio puede ser, por ejemplo, material real de la página listo para el navegador (por ejemplo, una colección de código HTML, CSS y JavaScript), datos de definición del sitio subyacentes (por ejemplo, utilizando archivos XML o expresiones JSON) que se convierten en material listo para el navegador mediante código del lado del cliente o del lado del servidor (tal como un módulo visor de WBS), o código de interfaz de usuario o interfaz del sistema (por ejemplo, código JavaScript invocado por la página para ejecutarse en el cliente, en el servidor o en ambos).
La FIG. 8 representa un diagrama de bloques de un Sistema 800 de Instancia de Ejecución de Servidor Web Bajo Demanda, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 8, El Sistema 800 Bajo Demanda incluye un Procesador 260, Memoria 820 para almacenar los sitios web servidos actual o recientemente, y Almacenamiento 830 Persistente para almacenar todos los sitios web disponibles para servirse. En algunas realizaciones, el Sistema 800 Bajo Demanda también puede incluir o estar asociado con un Servidor 840 Proxy para ayudar a determinar si se necesita una nueva instancia de ejecución de servidor web para servir una solicitud de sitio web.
El Sistema WBS 100 y el Sistema 800 Bajo Demanda almacenan y acceden al código para la edición del sitio web y el servicio de solicitudes web, respectivamente. El Editor 110 WBS se utiliza para presentar páginas web de sitios web para solicitudes de edición, recibidas desde el Dispositivo 140 de Desarrollo Web. Las instancias de ejecución del Servidor Web se instancian con definiciones de código y página creadas y editadas utilizando el Editor 110 WBS y almacenadas en la Base 124 de Datos del Área de Sitio para poder ver la Página 125 Web Indexable durante la edición del Sitio 123 Web, así como en tiempo de ejecución. En algunas realizaciones, el Sistema 800 Bajo Demanda puede ser un subsistema dentro del WBS 100. En algunas otras realizaciones, el WBS 100 y el Sistema 800 Bajo Demanda pueden compartir el acceso a la Interfaz 126 de Usuario y a la Interfaz 127 del Sistema de la Página 125 Web Indexable del Sitio 123 Web. En algunas realizaciones, el Almacenamiento 830 Persistente puede ser una base de datos similar a la Base 124 de Datos del Área de Sitio en WBS 100. Mientras que el WBS 100 puede almacenar la Interfaz 126 de Usuario en formato de datos estructurados, el Sistema 800 Bajo Demanda puede transformar la Interfaz 126 de Usuario en un formato de código comprendido por el Navegador 131 Web del Dispositivo 130 de Visualización Web. A diferencia del WBS 800, el Sistema 800 Bajo Demanda suele tener un acceso de sólo lectura a la Interfaz 126 de Usuario y la Interfaz 127 del Sistema almacenados de una Página 125 Web Indexable (cuando se utiliza para servir sitios web en tiempo de ejecución). Pero, cuando se utiliza junto con el Editor 110 WBS, el Sistema 800 Bajo Demanda puede modificar la Interfaz 126 de Usuario y/o la Interfaz 127 del Sistema del Sitio 125 Web y otros componentes del Sitio 125 Web. Debe aclararse que el editor WBS 100 puede trabajar conjuntamente con el Sistema 800 Bajo Demanda (siendo el código del editor parte del Código 824 del Servidor de Sitio Web Genérico), pero el editor en sí mismo puede funcionar como una capa por encima del Sistema 800 Bajo Demanda, y puede no afectar directamente a su funcionalidad y decisiones (por ejemplo, la asignación de instancias de ejecución para atender las solicitudes entrantes).
El procesador 260 puede estar asociado con uno o más servidores que alojan elementos del Sistema 800 Bajo Demanda. Por ejemplo, el Procesador 260 puede estar asociado a un único servidor o a un conjunto coordinado (por ejemplo, una granja) de servidores. Además, en algunas realizaciones cada uno de los elementos (por ejemplo, cada elemento dentro de la Memoria 820, cada elemento dentro del Almacenamiento 830 Persistente, el Servidor 840 Proxy, etc.) puede tener su propio Procesador 260 (por ejemplo, como parte de un servidor dedicado). Independientemente del número o tipo de Procesadores 260, cada uno de los elementos mostrados en el Sistema 800 Bajo Demanda es capaz de funcionar tanto de forma independiente como coordinada.
La Memoria 820 puede tener una o más instancias de ejecución de servidor web para servir sitios web o páginas a clientes. Las Instancias 821 en Uso pueden ser instancias de ejecución de servidores web que están actual o activamente sirviendo sitios web. Las Instancias 822 Disponibles, por otro lado, pueden ser un conjunto de instancias de servidor web disponibles en la Memoria 820 que actualmente no alojan ningún sitio web específico pero que están disponibles para hacerlo. En algunas realizaciones, el número de instancias de ejecución del servidor web en Instancias 822 Disponibles puede ser un número constante. En algunas otras realizaciones, el número de instancias de ejecución de servidor web en Instancias 822 Disponibles puede variar y depender del número de instancias de ejecución de servidor web en Instancias 821 en Uso. Por ejemplo, si hay un total de 10.000 instancias de ejecución, un aumento de las Instancias 821 en Uso puede significar una disminución de las Instancias 822 Disponibles, y viceversa. El número de instancias de ejecución de servidor web en Instancias 822 Disponibles también puede ser un porcentaje del número de instancias de ejecución de servidor web en Instancias 821 en Uso. Las Instancias 821 en Uso pueden, en algunas realizaciones, estar representadas por una estructura de datos que contiene un identificador único que identifica la Instancia 823 de Ejecución del servidor web y otras instancias que actualmente sirven sitios web. En algunas realizaciones, una estructura de datos similar puede ser mantenida por cada sitio web alojado por el Sistema 800 Bajo Demanda y todas estas estructuras de datos representan colectivamente las Instancias 821 en Uso.
Una Instancia 823 de Ejecución de Servidor Web puede ser una de las Instancias 821 en Uso que sirve solicitudes a un sitio web con la ayuda de un servidor web. La Instancia 823 de Ejecución de Servidor Web puede incluir el Código 824 del Servidor de Sitio Web Genérico y el Código 833 Específico del N del Sitio Web. El Código 824 del Servidor de Sitio Web Genérico puede, por ejemplo, ser un código común incluido en todas las instancias de ejecución del servidor web. Por ejemplo, dicho código común puede incluir elementos subyacentes del sistema de instancia de ejecución del servidor web (sistemas operativos, servidores web (por ejemplo, Apache), servidores de bases de datos, etc.) En algunas realizaciones, también puede incluir un editor o entorno de ejecución de WBS 100 junto con servicios externos y complementos de funciones comunes. Además, en algunas realizaciones, el código común puede incluir elementos comunes del lado del servidor a nivel de la aplicación del sitio web, tal como las bibliotecas y el código relacionados con los principales elementos comunes, tal como las aplicaciones verticales WBS 100, etc. El código común también puede incluir elementos de componentes comunes (por ejemplo, galerías), especialmente para los sitios web coalojados que se tratan más adelante. Para todo lo anterior, el código genérico puede incluir elementos reales del lado del servidor (que pueden almacenarse y ejecutarse en el servidor), así como elementos del lado del cliente (almacenados en el servidor y cargados en solicitudes de páginas web al cliente en tiempo de ejecución WBS 100 en ejecución). En algunas realizaciones, diferentes grupos de sitios web pueden incluir diferentes Código 824 de Servidor de Sitios Web Genérico. Así, por ejemplo, un grupo de sitios web de propiedad común puede tener un Código 824 de Servidor de Sitios Web Genérico común. Esto también puede aplicarse, por ejemplo, a varios sitios basados en el mismo marco de aplicación de mercado vertical (por ejemplo, restaurantes u hoteles). Alternativamente, diferentes sitios web pueden tener su propio Código 824 de Servidor de Sitios Web Genérico, que puede pertenecer a todas las páginas web dentro de cada sitio web.
El Código 834 Específico del Sitio Web N puede incluir el código específico del sitio web o página que está siendo servida por la Instancia 823 de Ejecución de Servidor Web (tal como el código Interfaz 126 de Usuario o Interfaz 127 del Sistema creado por el Desarrollador126 /Diseñador 1540 del sitio web para el sitio específico). La Instancia 823 de Ejecución de Servidor Web puede servir un sitio o página web que incluya el Código 834 Específico del Sitio Web N utilizando un servidor web (por ejemplo, Apache, Tomcat, Nginx, etc.) o un servidor específico de WBS. El Código 834 Específico del Sitio Web N puede incluir, por ejemplo, código para realizar funcionalidades exclusivas del sitio web o página específicos, tal como funcionalidad de carrito de la compra, procesamiento de pagos, acceso a bases de datos, integración o ejecución de aplicaciones, funciones de enrutador basadas en software, etc. La discusión anterior y aquí presente se refiere al Código 834 Específico del Sitio Web relacionado con un sitio web o página dados, y correspondientemente a la Instancia 823 de Ejecución de Servidor Web que puede servir solicitudes provenientes de clientes que utilizan el sitio web o página dados. Sin embargo, el Sistema 800 Bajo Demanda puede implementarse a diferentes niveles de granularidad de código específico. El nivel de granularidad típico puede ser a nivel de sitio, es decir, donde el Código 834 Específico del Sitio Web cubre un sitio entero - que es un nivel típicamente óptimo para la reutilización de la Instancia 823 de Ejecución de Servidor Web. No obstante, el sistema puede aplicarse con un nivel de granularidad de un grupo de sitios (para un grupo de sitios muy similares), un sitio entero, una sección de sitio (es decir, un conjunto de páginas) y una sola página. Para grupos de sitios, las partes comunes para numerosos sitios también pueden incluirse en el Código 824 de Servidor del Sitio Web Genérico como se indicó anteriormente.
La Instancia 826 de Ejecución de Servidor Web de las Instancias 822 Disponibles puede utilizarse para servir el mismo sitio web servido por la Instancia 823 de Ejecución de Servidor Web de las Instancias 821 en Uso inyectando el Código 833 Específico del Sitio Web N en la Instancia 826 de Ejecución de Servidor Web. De este modo, la Instancia 823 de Ejecución de Servidor Web puede generar (y servir) sitios y páginas web individualizados basándose en el Código 834 Específico del Sitio Web N único asociado a cada sitio o página web.
El Almacenamiento 830 Persistente puede incluir código genérico y específico para todos los sitios web alojados por el Sistema 800 Bajo Demanda en la Primera Ubicación 831 de Memoria y la Segunda Ubicación 832 de Memoria, respectivamente. El Código 824 de Servidor de Sitios Web Genérico puede ser almacenado, por ejemplo, en el Almacenamiento 830 Persistente en la Primera Ubicación 831 de Memoria. Los Códigos 833 y 834 Específicos de Sitio Web pueden almacenarse en la Segunda Ubicación 832 de Memoria, y pueden ser códigos específicos de los sitios web 1 y N respectivamente. El Almacenamiento 830 Persistente puede, en diversas realizaciones, ser un sistema de archivos distribuido, una base de datos u otro sistema de almacenamiento, y puede estar basado en la nube (por ejemplo, almacenamiento como servicio). La Primera Ubicación 831 de Memoria y la Segunda Ubicación 832 de Memoria pueden estar en diferentes ubicaciones del mismo sistema de almacenamiento o en diferentes sistemas de almacenamiento que juntos forman el Almacenamiento 830 Persistente. En algunas realizaciones, los Códigos 833 y 834 Específico de Sitio Web pueden estar en diferentes ubicaciones de memoria secundaria o en la misma ubicación, pero etiquetados por separado.
El Código 824 de Servidor del Sitio Web Genérico que reside en la Primera Ubicación 831 de Memoria del Almacenamiento 830 Persistente puede copiarse a una instancia de ejecución de servidor web similar a la Instancia 823 de Ejecución de Servidor Web después de poner en marcha la instancia. De este modo, el Código 824 de Servidor del Sitio Web Genérico, así como cualquier Código 833-834 Específico del Sitio Web, pueden integrarse para servir sitios o páginas web que incluyan sistemas comunes, marcos web, bibliotecas, componentes y complementos de funciones y elementos individualizados.
En diversas realizaciones, cada uno de los componentes de la Memoria 820, el Almacenamiento 830 Persistente y el Servidor 840 Proxy pueden implementarse a través de una red informática local, una red informática en la nube o una red híbrida que comprenda ambas arquitecturas. Algunos ejemplos de entornos de alojamiento en la nube pueden ser AMAZON W e b SERVICES, MICROSOFT AZURE, IBM CLOUD y otros, así como redes en la nube propias mantenidas por empresas de alojamiento de sitios web.
El Servidor 840 Proxy ayuda a determinar si un conjunto de Instancias 821 En Uso incluye una instancia de ejecución de servidor web disponible para servir una solicitud de un sitio web generada desde un Navegador 131 Web del Dispositivo 130 de Visualización Web. El Servidor 840 Proxy determina, por ejemplo, la disponibilidad de una instancia de ejecución de un servidor web interactuando con la Memoria 820. Por ejemplo, la Memoria 820 puede mantener una lista de Instancias 822 Disponibles e Instancias 821 en Uso, puede sondear las Instancias 823 y 826 de Ejecución de Servidor Web para determinar su estado actual, o puede recibir otra información de reporte relativa a la disponibilidad de una instancia de ejecución de servidor web. En algunas realizaciones, el Servidor 840 Proxy puede gestionar solicitudes HTTP (por ejemplo, de clientes) para acceder a un sitio o página web específicos, y determinar si el sitio o página web específicos ya están alojados en una Instancia 823 de Ejecución de Servidor Web. Además, en algunas realizaciones, el Servidor 840 Proxy puede mantener una Tabla 941 de Estado para su uso en la determinación del estado de las Instancias 822 Disponibles y las Instancias 821 en Uso. Dicha tabla de estado puede identificar tales recursos y los sitios o páginas web que ya albergan.
La FIG. 9 representa un diagrama esquemático de la interacción entre los componentes del Sistema 800 Bajo Demanda, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 2, el Gestor 950 de Instancias de Ejecución de Servidor Web del Sistema 800 Bajo Demanda gestiona instancias de ejecución de servidor web comunicándose con las Instancias 823 y 826 de Ejecución de Servidor Web y el Servidor 840 Proxy. En algunas realizaciones, el Gestor 950 de Instancias de Ejecución de Servidor Web puede determinar si es necesario añadir nuevas instancias de ejecución de servidores web a las Instancias 822 Disponibles. Esto puede ocurrir, por ejemplo, si se produce un aumento del tráfico asociado a un determinado sitio o página web que se aloja. En algunas realizaciones, el aumento de la carga de tráfico puede predecirse basándose en el conocimiento previo inferido de la información de tráfico periódica recopilada para el sitio en el pasado. La información de tráfico anterior puede incluir datos de tráfico mensuales, semanales, diarios y por hora, recopilados para comprender las tendencias estacionales y otros momentos de mayor uso del sitio, y añadir automáticamente más instancias de ejecución de servidores web que sirvan a un sitio web concreto. En algunas otras realizaciones, el Gestor 950 de Instancias de Ejecución de Servidor Web puede determinar si una instancia de las Instancias 821 en Uso está inactiva. En esta situación, se pueden desperdiciar recursos, ya que las Instancias 821 en Uso están operativas o en funcionamiento, a pesar de no tener ninguna solicitud de clientes a la que responder con sitios o páginas web. Por lo tanto, como se discute más adelante, cualquier Instancia 821 en Uso inactiva puede desactivarse o cerrada. De forma similar al procedimiento de añadir nuevas instancias de ejecución de servidores web para un sitio web, las predicciones, como se ha comentado anteriormente, basadas en información de uso previo, pueden utilizarse para cerrar instancias cuando haya menos tráfico previsto. El Gestor 950 de Instancias de Ejecución de Servidor Web puede tomar la determinación de añadir más instancias al conjunto de Instancias 822 Disponibles y/o marcar una Instancia en Instancias 821 en Uso como inactiva delegando la determinación al Servidor 840 Proxy. El Servidor 840 Proxy, como se ha indicado anteriormente, puede incluir la Tabla 941 de Estado para ayudar a determinar si añadir o eliminar instancias de ejecución de servidor web de las Instancias 821 en Uso e Instancias 822 Disponibles. La Tabla 941 de Estado puede mantener información asociando Instancias 821 En Uso e Instancias 822 Disponibles particulares con su estado actual, estado histórico, o estado futuro proyectado. Dicha información de estado puede identificar sitios web o páginas específicas que estén alojando, puedan alojar en el futuro o hayan alojado en el pasado. Además, la Tabla 841 de Estado puede incluir más información (por ejemplo, cuánto tiempo las Instancias 821 en Uso y las Instancias 822 Disponibles han estado alojando sitios web o páginas, cuánto tiempo las Instancias 821 en Uso y las Instancias 822 Disponibles han estado inactivas, etc.).
La FIG. 10 es un diagrama de flujo que ilustra un Método 1000 para responder a una solicitud web enviada para un sitio web, de acuerdo con algunas realizaciones de la presente divulgación. El Método 1000 de la FIG. 10 identifica dos caminos para servir solicitudes web entrantes recibidas por el Sistema 800 Bajo Demanda desde un Navegador 131 Web del Dispositivo 130 de Visualización Web. Cualquier requisito de configuración para servir la solicitud podría resultar en la copia del código específico del sitio web solicitado a una instancia de ejecución del servidor web que sirve la solicitud para acceder a un sitio web específico.
Como se muestra en la FIG. 10, en el Paso 1010, el Sistema 800 Bajo Demanda almacena el Código 824 de Servidor de Sitios Web Genérico en la Primera Ubicación 831 de Memoria del Almacenamiento 830 Persistente. Como se ha comentado anteriormente, esto puede implicar el almacenamiento de código común a un grupo de sitios web (por ejemplo, todos los que pertenezcan a un propietario común o se basen en un marco de sitio vertical común) o común a un grupo de páginas dentro de un sitio web. Además, el Código 824 de Servidor de Sitios Web Genérico puede estar asociado con una agrupación definida y arbitraria de sitios o páginas web. Como se ha comentado anteriormente, el Código 824 del Servidor de Sitio Web Genérico puede incluir código que especifique piezas comunes de software de diferentes capas, incluyendo sistemas operativos, marcos web, bibliotecas de software y componentes y complementos de funciones del sitio web, así como el propio código del editor y visor del WBS 100.
En el Paso 1020, el Sistema 800 Bajo Demanda puede almacenar el Código 834 Específico del Sitio Web N en la Segunda Ubicación 832 de Memoria del Almacenamiento 830 Persistente. Como se ha comentado anteriormente, el Código 834 Específico del Sitio Web N puede ser específico de un sitio o página web en particular. El Código 834 Específico del Sitio Web N puede incluir, por ejemplo, un widget, una aplicación o una funcionalidad personalizada de interfaz del sistema o interfaz de usuario. Además, el Código 833 Específico del Sitio Web N puede funcionar como un enrutador para un sitio o página web en particular, como se discutió anteriormente, donde uno o más segmentos de una URL ingresada por un usuario, o proporcionada de otra manera, determina cómo el sitio o página web debe ensamblar su contenido (por ejemplo, imágenes personalizadas, texto, hipervínculos, formularios, características de comercio electrónico, contenido personalizado, etc.).
En el Paso 1030, el Sistema 800 Bajo Demanda puede recibir una solicitud para acceder a un sitio web recibida desde un Navegador 131 Web en un Dispositivo 130 de Visualización Web. El Sistema 800 Bajo Demanda gestiona la solicitud verificando si el sitio web o la página solicitada está siendo servida actualmente por una o más instancias de ejecución de servidor web en las Instancias 821 en Uso. Como se ha comentado anteriormente, esto puede implicar consultar las propias Instancias 821 en Uso, consultar el Servidor 840 Proxy u obtener un informe de otro servicio que monitorice las Instancias 821 en Uso. Haciendo referencia a una tabla de consulta o tabla de estado, se puede confirmar el funcionamiento actual (o la ausencia del mismo) de las Instancias 821 en Uso. En algunas realizaciones, un único servidor puede servir a múltiples sitios web o múltiples clientes del mismo sitio, y la carga de tráfico y la actividad en un servidor en particular puede ser rastreada y tenida en cuenta a la hora de determinar qué servidor utilizar para responder a solicitudes adicionales.
En el Paso 1040, el Sistema 800 Bajo Demanda verifica si la Instancia 823 de Ejecución de Servidor Web u otras instancias de ejecución de servidor web en Instancias 821 en Uso sirven el sitio web solicitado. En caso afirmativo, el procedimiento 1000 puede en algunas realizaciones saltar al Paso 1070, que se discute más adelante.
Si la respuesta en el Paso 1040 es no, el procedimiento 1000 puede proceder al Paso 1050. Si ninguna de las instancias de ejecución de servidor web en Instancias 821 en Uso sirve el sitio web solicitado, entonces la solicitud puede reenviarse a una instancia de ejecución de servidor web disponible en Instancias 822 Disponibles. En algunas realizaciones, una de las instancias de ejecución del servidor web en Instancias 822 Disponibles puede seleccionarse para servir el sitio web solicitado. En otras realizaciones, como se muestra en la FIG. 10, la Instancia 826 de Ejecución del Servidor Web en Instancias 822 Disponibles recibe la solicitud para servir.
En el Paso 1060, se puede enviar una solicitud para buscar el Código 833 Específico de Sitio Web en la Ubicación 832 de Memoria Secundaria que coincida con el sitio web solicitado. Por ejemplo, como se ilustra, el Código 833 Específico del Sitio 123 Web es el código coincidente si la solicitud se recibió para el Sitio 1 Web. En algunas realizaciones, el Código 833 Específico de Sitio Web que coincide con el sitio web solicitado es identificado y copiado a la Instancia 826 de Ejecución de Servidor Web. La Instancia 826 de Ejecución de Servidor Web se añade a la lista de Instancias 821 en Uso (por ejemplo, en una tabla de estado, o en el Servidor 840 Proxy), y se elimina de la lista de Instancias 822 Disponibles. La solicitud es respondida (por ejemplo, al cliente) por la Instancia 826 de Ejecución de Servidor Web. El procedimiento 1000 puede entonces repetirse (por ejemplo, repetirse al Paso 1010, 1020, o 1030). Además, en el Paso 1060, el Código 833 Específico de Sitio Web puede ser inyectado en la Instancia 826 de Ejecución de Servidor Web, como se discutió anteriormente, para su integración en la construcción de un sitio web específico o página solicitada por el usuario.
La FIG. 11 es una ilustración del Sistema 800 Bajo Demanda configurado para determinar si un sitio web está alojado, y generar o instanciar instancias de ejecución, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 11, el Servidor 840 Proxy se utiliza para determinar los Pasos para gestionar una solicitud de acceso al Sitio 123 Web recibida a través de la Red 160 desde el Navegador 131 Web del Dispositivo 130 de Visualización Web. Tal determinación puede resultar en el manejo inmediato de la solicitud por el Gestor 950 de Instancia de Ejecución de Servidor Web o la instanciación de una instancia de ejecución de servidor web en Instancias 822 Disponibles usando código específico del sitio web solicitado antes de manejar la solicitud.
Como se muestra en la FIG. 11, en el Paso 1110, el Sistema 800 Bajo Demanda puede recibir una solicitud para el Sitio 123 Web a través de una Red 160. La solicitud puede proceder de un ordenador cliente o de una aplicación, como se ha comentado anteriormente. La solicitud puede ser una solicitud HTTP, HTTPS u otro tipo de solicitud de red.
En el Paso 1120, el Sistema 800 Bajo Demanda determina la mejor manera de servir el Sitio 123 Web solicitado. Como se discutió anteriormente, la determinación puede incluir la identificación de si una solicitud puede ser manejada por un conjunto actual de Instancias 821 en Uso o si se requiere una instancia de ejecución de servidor web adicional. Por ejemplo, el Sistema 800 Bajo Demanda puede determinar que la carga actual en las Instancias 821 en Uso ha superado un umbral de uso (por ejemplo, umbral de número de instancias, cantidad de ancho de banda utilizado, porcentaje de ancho de banda utilizado, nivel de uso de recursos del servidor tal como memoria o potencia del procesador, etc.). En ese caso, se puede determinar que una o más Instancias 822 Disponibles deben ponerse en marcha o utilizadas para satisfacer la demanda del sitio web o página en particular. Además, como se ha comentado anteriormente, el Sistema 800 Bajo Demanda puede intentar predecir un estado de carga futuro de las Instancias 821 en Uso. Esta predicción puede basarse, por ejemplo, en los niveles de carga anteriores. Basándose en el nivel de carga previsto para las Instancias 821 en Uso, el Sistema 800 Bajo Demanda puede igualmente determinar que una o más Instancias 822 Disponibles deben ponerse en marcha o utilizadas para satisfacer la demanda prevista para el grupo de sitios web, sitio web, conjunto de páginas o página en particular. El Sistema 800 Bajo Demanda también puede dirigir dicha solicitud entrante a una de las Instancias 821 en Uso (para proporcionar el mejor tiempo de respuesta), y paralelamente decidir poner en marcha una o más Instancias 822 Disponibles para que estén disponibles para futuras solicitudes relacionadas con el sitio web o página en cuestión.
En el Paso 1121, como parte del procedimiento de determinación, el Sistema 800 Bajo Demanda puede pasar el control al Gestor 950 de Instancias de Ejecución de Servidor Web junto con la solicitud del Sitio 123 Web (por ejemplo, una copia de la solicitud, o información sobre la solicitud). La solicitud puede ser una solicitud de acceso a una página web indexable del Sitio 123 Web, el envío de un formulario u otros tipos de solicitudes.
En el Paso 1122, el Gestor 950 de Instancia de Ejecución de Servidor Web puede delegar la determinación al Servidor 840 Proxy para ayudar a determinar cómo manejar la solicitud para servir al Sitio 123 Web. Esto puede implicar los tipos de toma de decisiones comentados anteriormente, incluyendo una determinación del estado de carga actual asociado con el Sitio 123 Web, proyecciones de carga futura para el sitio web, etc.
En el Paso 1123, el Servidor 840 Proxy puede referenciar la Tabla 941 de Estado en el Servidor 840 Proxy para las instancias en Instancias 821 en Uso que pueden servir el sitio web solicitado. En algunas realizaciones, la búsqueda en la Tabla 941 de Estados puede implicar buscar en una columna denominada "Sitio Web" 1143 en la tabla una URL de sitio web coincidente. También son posibles otros identificadores (por ejemplo, URL, nombre de cuenta, nombre arbitrario, etc.). En algunas realizaciones, el Paso 1122 ocurre periódicamente incluso cuando el Sistema 800 Bajo Demanda no ha recibido una solicitud para servir un sitio web - ya que el Sistema 800 Bajo Demanda puede monitorizar periódicamente los niveles de carga basándose en las tendencias históricas de tráfico del sitio web y puede activar o desactivar automáticamente las instancias de ejecución del servidor web excepto cuando la tendencia actual del tráfico sugiera lo contrario. En algunas realizaciones, el Gestor 950 de Instancia de Ejecución de Servidor Web recibe la solicitud para el Sitio 123 Web tras un fallo en la gestión de la solicitud, indicando la no disponibilidad de una instancia de ejecución de servidor web para servir la solicitud para el Sitio 123 Web.
En el Paso 1123, el Servidor 840 Proxy puede enviar una solicitud a una instancia de ejecución de servidor web en las Instancias 822 Disponibles para elegir la primera Instancia 826 de Ejecución de Servidor Web disponible para marcarse para servir solicitudes para el Sitio 123 Web. En otras realizaciones, la Instancia 826 de Ejecución de Servidor Web puede elegirse basándose en una política que tenga en cuenta las diferencias entre las Instancias 826 de Ejecución del Servidor Web que las hace adecuadas o más óptimas para gestionar la solicitud (por ejemplo, ubicación geográfica, aplicaciones en ejecución, memoria disponible, potencia de procesamiento, nivel de fragmentación de disco/memoria, etc.).
En el Paso 1124, el Sistema 800 Bajo Demanda selecciona una instancia de ejecución de servidor web en las Instancias 822 Disponibles para servir la solicitud del Sitio 123 Web. En algunas realizaciones, se selecciona la Instancia 826 de Ejecución de Servidor Web para servir la solicitud del Sitio 123 Web.
En el Paso 1125, la Instancia 826 de Ejecución de Servidor Web puede añadirse al conjunto de Instancias 121 En Uso inyectando el Código 833 Específico de Sitio 123 Web en la Instancia 826 de Ejecución de Servidor Web. En algunas realizaciones, el Sistema 800 Bajo Demanda puede solicitar al Servidor 840 Proxy que actualice la Tabla 941 de Estados con la entrada para la Instancia 826 de Ejecución de Servidor Web. La Tabla 841 de Estado puede así cambiar, incluyendo la adición de una fila con identificadores de Instancia 1142 y Sitio 1143 Web en la Tabla de Estado. En algunas realizaciones, la primera instancia disponible, por ejemplo, la Instancia 826 de Ejecución de Servidor Web, puede seleccionarse para inyectarse con el Código 833 Específico de Sitio. Tras esta inyección, la Instancia 826 de Ejecución de Servidor Web sería eliminada del conjunto de Instancias 822 Disponibles.
En otras realizaciones, la selección puede basarse en la proximidad geográfica a la ubicación de la solicitud del Sitio 123 Web o en el número de solicitudes web potenciales que podrían originarse desde una determinada ubicación geográfica. En algunas realizaciones, múltiples instancias de ejecución del servidor web pueden inyectarse con el Código 833 Específico del Sitio 123 Web y añadidas al conjunto de Instancias 821 en Uso.
La Determinación 1120 de gestionar el Sitio 123 Web solicitado puede tener además un umbral de tiempo de espera (por ejemplo, 10 o 100 milisegundos). El periodo de tiempo de espera puede coincidir con el estándar web general para servir solicitudes de páginas web. Las instancias de ejecución del servidor web que forman parte de las Instancias 822 Disponibles ayudan a reducir el tiempo de spin-up de las instancias cuando se realiza una nueva solicitud de sitio web. De este modo, se reducen los problemas de arranque en frío de los sistemas de construcción de sitios web convencionales anteriores.
En el Paso 1130, la Instancia 826 de Ejecución de Servidor Web puede servir la solicitud para el Sitio 123 Web utilizando el Código 833 Específico de Sitio 123 Web. Como se ha comentado anteriormente, al servir un sitio web o una página generada utilizando el Código 833 Específico del Sitio 123 Web, el contenido del sitio web puede adaptarse al usuario o a la forma en que el usuario llegó al sitio (por ejemplo, utilizando un enrutador basado en software). En algunas realizaciones, el propio paso de inyección puede modificar el material inyectado, por ejemplo, adaptándolo al usuario / plataforma / dispositivo específico que realiza la solicitud o a otras condiciones "ambientales" (país, idioma, base de datos a la que se accede, historial de acceso del usuario, etc.). El código cliente que inicia la solicitud de red puede añadir parámetros o información adicionales a la solicitud de red para que el módulo de inyección pueda realizar dicha adaptación. La información adicional puede añadirse directamente (por ejemplo, como URL añadida u otros parámetros de solicitud) o indirectamente (por ejemplo, estando disponible a través de una solicitud adicional, almacenamiento previo en una base de datos u otro método).
La FIG. 12 representa una instanciación de elementos de infraestructura de servidor con un sitio web, de acuerdo con algunas realizaciones de la presente divulgación. Las técnicas de la FIG. 12 pueden practicarse en los sistemas descritos anteriormente y descritos a lo largo de esta divulgación.
Como se muestra en la FIG. 12, el Sitio 123 Web puede servirse a través de una instancia de ejecución de servidor web copiando el Código 833 Específico del Sitio 123 Web al Contenedor 1221 o a la Máquina 1222 Virtual. En algunas realizaciones, el Sitio 123 Web puede ser servido por un Procedimiento 1223 separado del sistema operativo (por ejemplo, a través de código sin servidor). El Código 833 Específico del Sitio 123 Web puede incluir la Interfaz 126 de Usuario, la Interfaz 127 del Sistema y el Código 1226 de Referencia de Complemento de Funciones, tal y como se ha comentado anteriormente en relación con la funcionalidad de interfaz del sistema personalizada que puede proporcionarse en los sitios web. En algunas realizaciones, Interfaz 126 de Usuario, Interfaz 127 del Sistema, y Código 1226 de Referencia de Complemento de Funciones pueden copiarse individualmente al Contenedor 1221, Máquina 1222 virtual, o Procedimiento 1223. En algunas realizaciones, el Código 824 Genérico del Servidor Web puede copiarse al Contenedor 1221 o a la Máquina 1222 Virtual (que posteriormente incluiría el Código 833 Específico del Sitio 123 Web) como parte de la instanciación de la Instancia 826 de Ejecución de Servidor Web.
En algunas realizaciones, el uso del Sistema 800 Bajo Demanda, tal como a través de una implementación de código sin servidor, puede mejorar los tiempos de procesamiento y la utilización del servidor, al tiempo que reduce la latencia para los usuarios. En las realizaciones de código sin servidor, no hay servidores dedicados que gestionar. En su lugar, el código (por ejemplo, Interfaz 126 de Usuario, Interfaz 126 de sistema y Código 1226 de Referencia de Complemento de Funciones) puede proporcionarse como código y ejecutarse bajo demanda en la nube. En la medida en que se cobre a los usuarios por la ejecución del código, se les puede cobrar proporcionalmente a la ejecución real del código (en lugar de basarse en los costes de infraestructura dedicada o en los servidores que deben permanecer asignados a un sitio determinado mientras esperan las solicitudes entrantes). Alternativamente, esto puede reducir sustancialmente los costes de un proveedor de WBS en línea, al tiempo que le permite ofrecer un mejor servicio a sus usuarios. En algunas realizaciones, el Sistema 800 Bajo Demanda puede definir un conjunto de lenguajes de programación o marcos web compatibles para procesar código sin servidor. El Sistema 800 Bajo Demanda también puede soportar WebSockets, transmisión o comunicaciones en trozos, protocolos adicionales (por ejemplo, TCP y UDP, etc.), memoria como funcionalidad de servicio (por ejemplo, para funciones de código sin estado y sin efectos secundarios) y opciones nativas sin servidor (por ejemplo, Go, Rust, C, etc.). Al poder procesar código sin servidor bajo demanda, se pueden reducir los problemas de los sistemas convencionales de alojamiento de sitios web (por ejemplo, experimentar un "arranque en frío" para cargar instancias de máquinas o sitios web). El tiempo de inicio de los sitios o páginas web (incluyendo cualquier código en ejecución) puede ser inferior a 100 ms, lo que reduce la latencia y mejora la experiencia del usuario. Por el contrario, algunos sistemas convencionales experimentan un tiempo de inicio de sitios web o páginas de aproximadamente 600 ms a 2 segundos, incluyendo las funciones de sobrecarga de programación, inicio de una instancia, inicio de un procedimiento (por ejemplo, ejecución de código) y funcionamiento del gestor de solicitudes.
La Instancia 826 de Ejecución del Sitio Web puede servir múltiples sitios web a través del Contenedor 1221, Máquina 1222 Virtual, o Procedimiento 1223. En algunas realizaciones, la Instancia 826 de Ejecución de Servidor Web puede tener un conjunto de recursos de Contenedor 1221, Máquina 1222 Virtual y Procedimiento 1223 dedicados a ella o disponibles para ella. Múltiples Contenedores 1221, Máquinas 1222 Virtuales, y Procedimientos 1223 pueden servir a múltiples sitios web. En algunas realizaciones, las variantes de la Instancia 826 de Ejecución del Sitio Web que pueden servir a múltiples sitios web pueden incluir un único Contenedor 1221, Máquina 1222 Virtual, o Procedimiento 1223 que sirve a múltiples sitios web. El Contenedor 1221, la Máquina 1222 Virtual, y el Procedimiento 1223 que sirven a múltiples sitios web pueden necesitar que el código específico de múltiples sitios web sea copiado para servir diversas solicitudes de sitios web.
Las FIG. 13 representa técnicas de monitorización de carga de sitios web alojados y gestión de Instancias 821 en Uso, de acuerdo con algunas realizaciones de la presente divulgación. Estas técnicas pueden practicarse en los sistemas descritos anteriormente.
Como se muestra en la FIG. 13, el Gestor 950 de Instancia de Ejecución del Servidor Web (como se ha comentado anteriormente en relación con la FIG. 11) supervisa o se comunica con el Monitor 1310 de Carga para determinar si alguno de los sitios web atendidos por el Sistema 800 Bajo Demanda tiene una carga superior a la deseada o presupuestada. Como se ha comentado anteriormente, esto puede determinarse en función de las características actuales, anteriores o futuras de la carga. En algunas realizaciones, la carga futura puede predecirse basándose en el conocimiento previo basado en la carga periódica recopilada del sitio web/servidor web que aloja múltiples sitios web en el pasado. La carga pasada puede incluir datos mensuales, semanales, diarios y horarios para comprender las tendencias estacionales y otros momentos de uso más activo del sitio y añadir automáticamente más instancias de ejecución de servidores web que sirvan a un sitio web concreto o a un grupo de sitios web servidos por un servidor web.
Cuando los sitios web tienen una carga relativamente menor, algunas instancias son eliminadas del conjunto de Instancias 821 En Uso para un sitio web en particular y movidas de nuevo a Instancias 822 Disponibles. En algunas realizaciones, el Monitor 1310 de Carga enumera todos los Sitios 1311 Web alojados por el Sistema 800 Bajo Demanda y su Carga 1312 en forma tabular. En algunas realizaciones, la tabla del Monitor 1310 de Carga que enumera la carga del sitio web puede formar parte de la Tabla 941 de Estado gestionada por el Servidor 840 Proxy o accesible a él. En algunas otras realizaciones, el Monitor 1310 de Carga puede ser una tabla separada en el Servidor 840 Proxy. En otras realizaciones, el Monitor 1310 de Carga puede estar en la Memoria 820 del Sistema 800 Bajo Demanda.
En algunas realizaciones, las Instancias 821 en Uso pueden ser una colección de conjuntos separados de instancias que alojan algunos o todos los sitios web del Sistema 800 Bajo Demanda. En algunas realizaciones, los Sitios 123 y 2 Web, como se ilustra, son los sitios web alojados por el Sistema 800 Bajo Demanda. En diversas realizaciones, las Instancias 1320 Asignadas del Sitio 123 Web y las Instancias Asignadas del Sitio 2 Web son 1330, son el conjunto de instancias de ejecución del servidor web del Sitio 123 Web y del Sitio 2 Web. En algunas realizaciones, las Instancias 1320 Asignadas del Sitio 123 Web y las Instancias Asignadas 1330 del Sitio 2 Web se consideran conjuntamente Instancias 822 En Uso.
La tabla de carga del Monitor 1310 de Carga puede ser actualizada por el Gestor 950 de Instancias de Ejecución de Servidor Web directamente o puede solicitar al Servidor 840 Proxy que la actualice. En algunas realizaciones, la tabla de carga del Monitor 1310 de Carga es actualizada periódicamente por el Servidor 840 Proxy basándose en el número de solicitudes de acceso a los Sitios 1311 Web alojados por el Sistema 800 Bajo Demanda. La tabla de carga del Monitor 1310 de Carga puede actualizarse basándose en otras estadísticas de uso del sitio web. Por ejemplo, en el caso de un sitio web con gran contenido multimedia, las estadísticas de uso podrían incluir el uso de memoria y ciclos de procesador para atender las solicitudes del sitio web que impliquen la conversión de vídeo y audio a diferentes formatos en función del entorno del dispositivo utilizado por el usuario. Las instancias de ejecución del servidor web de las Instancias 821 en Uso se mueven a las Instancias 822 Disponibles cuando el sitio web que alojan tiene una carga menor. Del mismo modo, cuando un sitio web tiene una carga mayor, las instancias de ejecución del servidor web de las Instancias 822 Disponibles se marcan como Instancias 821 en Uso y el código específico del sitio web con mayor carga se inyecta en estas instancias de ejecución del servidor web.
En algunas realizaciones, basándose en que el Servidor 840 Proxy observa que el Sitio 123 Web tiene una carga más ligera, el Sistema 800 Bajo Demanda puede hacer que la Instancia 826 de Ejecución de Servidor Web se mueva del conjunto de Instancias 1320 Asignadas del Sitio 123 Web al conjunto de Instancias 822 Disponibles. En algunas realizaciones, la Instancia 1323 de Ejecución del Servidor Web se mueve a las Instancias 822 Disponibles. En algunas realizaciones, múltiples instancias de ejecución del servidor web se mueven a Instancias 822 Disponibles al mismo tiempo. El Servidor 840 Proxy, al observar que el Sitio 2 Web tiene una carga más pesada en el Monitor 1310 de Carga, puede mover la Instancia 1127 de Ejecución del Servidor Web del conjunto de Instancias 822 Disponibles al conjunto de Instancias 1330 Asignadas del Sitio 2 Web. Como parte del Paso 1342, el Sitio 2 Web puede tener código específico del sitio o de la página que se inyecta en la Instancia de Ejecución del Servidor Web M 1127 antes de moverlo a las Instancias 1330 Asignadas del Sitio 2 Web. Por supuesto, el Paso 1341 y el Paso 642 son independientes y no tienen que ocurrir juntos o en un orden específico.
La FIG. 14 representa la monitorización de instancias de ejecución de servidores web disponibles para alojamiento, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 14, el Gestor 950 de Instancias de Ejecución de Servidor Web monitoriza el número de Instancias 822 Disponibles. El Gestor 950 de Instancias de Ejecución de Servidor Web puede hacer girar nuevas instancias y añadirlas al conjunto de Instancias 822 Disponibles cuando el número de instancias de ejecución de servidor web en el conjunto de Instancias 822 Disponibles sea inferior a un umbral, como se ha comentado anteriormente. A la inversa, el Gestor 950 de Instancias de Ejecución de Servidor Web puede apagar instancias en el conjunto de Instancias 822 Disponibles cuando el número de instancias de ejecución de servidor web es superior a un umbral. Estas técnicas de activación y desactivación de instancias de ejecución pueden tener en cuenta la demanda actual, anterior o futura prevista de determinados sitios web o páginas, tal y como se ha comentado anteriormente.
En algunas realizaciones, el Gestor 950 de Instancias de Ejecución de Servidor Web puede esperar una cierta cantidad de tiempo antes de poner en marcha nuevas instancias para asegurarse de que las instancias inactivas identificadas a través de la Tabla 841 de Estado no son añadidas de nuevo al grupo. De forma similar, en algunas realizaciones, el Gestor 950 de Instancias de Ejecución de Servidor Web puede esperar un cierto tiempo antes de apagar las instancias disponibles para asegurarse de que una instancia no necesita inyectarse con código específico del sitio web para gestionar una nueva solicitud de sitio web. El apagado y encendido de instancias puede ser un procedimiento que requiera mucho tiempo y el Gestor 150 de Instancias de Ejecución del Sitio Web evita hacerlo frecuentemente esperando después de descubrir que un número de instancias disponibles se desvía de un número umbral.
En algunas realizaciones, el Gestor 950 de Instancias de Ejecución de Servidor Web gira y cierra instancias de ejecución de servidor web cuando el número actual de instancias en el conjunto de Instancias 822 Disponibles difiere del umbral en un número o porcentaje especificado. Esto permite un rango de valores para el número de Instancias 822 Disponibles a estar presentes en cualquier punto del tiempo. En otras realizaciones, el Gestor 850 de Instancias de Ejecución del Servidor Web puede reaccionar inmediatamente a la desviación de un umbral para poner en marcha y apagar instancias.
La FIG. 15 representa un sistema ejemplar de pruebas en tiempo real de un sitio web, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 15, El Sistema 1500 de Pruebas en Tiempo Real de Sitios Web incluye Procesador 260, Memoria 820, Base 124 de Datos del Área de Sitio para almacenar datos utilizados por sitios web, proporcionando Entorno 1510 de Despliegue que acceso a datos relacionados con un sitio web al que se está accediendo. En algunas realizaciones, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web también puede incluir el Entorno 1520 de Pruebas que proporciona acceso a datos relacionados con un sitio web al que se accede con fines de prueba. Se pueden utilizar términos alternativos para prueba/despliegue, como desarrollo/tiempo de ejecución, puesta en escena/producción y pruebas/en vivo.
En algunas realizaciones, el Sistema 800 Bajo Demanda puede ser un subsistema incluido en su totalidad en el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web. En algunas realizaciones, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web puede estar compuesto parcialmente por, o puede incluir, el Sistema 800 Bajo Demanda.
El Entorno 1510 de Despliegue puede ser un conjunto de componentes de software que se ejecutan en una instancia de ejecución de servidor web en un Sistema 800 Bajo Demanda.
El Entorno 1520 de Pruebas puede ser un conjunto de componentes de software ejecutándose en una instancia de ejecución de servidor web en el Sistema 800 Bajo Demanda. En algunas realizaciones, se genera un Entorno 1520 de Pruebas basado en el tipo de dispositivo utilizado para acceder a un sitio web. Por ejemplo, el acceso al Sitio 123 Web a través del Navegador 141 Web en el Dispositivo 140 de Visualización Web puede dar lugar a la creación del Entorno 1520 de Pruebas, que puede ser diferente en apariencia y diseño si el Dispositivo 140 de Visualización Web es un ordenador de sobremesa o un teléfono móvil. En otras realizaciones, se puede generar un Entorno 1520 de Pruebas en función del usuario que acceda al sitio web. Por ejemplo, un Desarrollador/Diseñador 1540 que solicita acceso al Sitio 123 Web puede dar lugar a la creación del Entorno 1520 de Pruebas. En algunas realizaciones, un Entorno 1520 de Pruebas puede ser compartido por varios usuarios. El Entorno 1520 de Pruebas puede ser diferente para distintos usuarios. En algunas realizaciones, el Entorno 1520 de Pruebas puede compartirse a través de múltiples sitios web almacenados en la Base 124 de Datos del Área de Sitio. En algunas realizaciones, una instancia del Entorno 1520 de Pruebas puede estar siempre disponible, y el Programador/Diseñador 1540 puede seleccionar entre acceder a un sitio web determinado a través del Entorno 1520 de Pruebas o del Entorno 1510 de Despliegue.
El Usuario 1530 Final puede acceder a un sitio web y a sus datos en un Entorno 1510 de Despliegue a través de la Red 160. En algunas realizaciones, el Usuario 1530 Final puede acceder al Sitio 123 Web a través del Navegador 131 Web en el Dispositivo 130 de Visualización del Sitio Web, de acuerdo con las realizaciones anteriores.
El Desarrollador/Diseñador 1540 puede acceder a un sitio web y a sus datos en un Entorno 1520 de Pruebas a través de la Red 160. El Desarrollador/Diseñador 1540 puede acceder al Sitio 123 Web a través del Navegador 141 Web en el Dispositivo 140 de Desarrollo de Sitios Web. En algunas realizaciones, el Programador/Diseñador 1540 puede acceder al Sitio 123 Web en el Entorno 1510 de Despliegue utilizando el Navegador 131 Web en el Dispositivo 130 de Visualización Web. Debe tenerse en cuenta que el Dispositivo 130 de Visualización Web y el Dispositivo 140 de Desarrollo pueden ser el mismo dispositivo.
El Usuario 1530 Final y el Desarrollador/Diseñador 1540 pueden ser diferentes roles de un mismo usuario que accede al Sitio 123 Web. En algunas realizaciones, un usuario puede cambiar de rol accediendo al Sitio 123 Web utilizando diferentes dispositivos. Por ejemplo, un usuario que accede al Sitio 123 Web utilizando el Dispositivo 150 de Personal de Vendedor de WBS o el Dispositivo 140 de Desarrollo de Sitios Web puede considerarse como Desarrollador/Diseñador 1540. Un usuario que accede al Sitio 123 Web utilizando el Dispositivo 130 de Visualización del Sitio Web puede considerarse Usuario 1530 Final. Se puede acceder a un sitio web utilizando el Entorno 1510 de Despliegue o el Entorno 1520 de Pruebas en función de si el usuario es el Usuario 1530 Final o el Desarrollador/Diseñador 1540 respectivamente. Además, se puede acceder a un sitio web utilizando el Entorno 1510 de Despliegue o el Entorno 1520 de Pruebas en función de si la solicitud se originó en el Dispositivo 130 de Visualización del Sitio Web o en el Dispositivo 140 de Desarrollo del Sitio Web. En algunas realizaciones, se puede acceder a un sitio web utilizando el Entorno 1510 de Despliegue o el Entorno 1520 de Pruebas en función de una combinación de usuario y tipo de dispositivo.
La FIG. 16a representa un diagrama esquemático de un Entorno 1510 de Desarrollo para acceder a elementos de datos, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 16a, el Entorno 1510 de Despliegue puede solicitar al Procesador 260 que ayude a acceder a los Datos 1610 en Vivo. El Entorno 1510 de Despliegue puede no acceder a los Datos 1620 de Prueba, representados por una línea discontinua. La FIG. 16b representa un diagrama esquemático de un Entorno 1520 de Pruebas para acceder a elementos de datos, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 16b, el Entorno 1520 de Pruebas puede solicitar al Procesador 260 que ayude a acceder a los Datos 1610 en Vivo y a los Datos 1620 de Prueba. El Desarrollador/Diseñador 1540 que accede a un Sitio 123 Web utilizando el Entorno 1520 de Pruebas puede solicitar elementos de datos asociados a la Página 125 Web Indexable del Sitio 123 Web. El Entorno 1520 de Pruebas puede estar configurado para recibir solicitudes de elementos de datos de un usuario, y puede reenviar las solicitudes a los Datos 1620 de Prueba. En algunas realizaciones, los Datos 1620 de Prueba pueden determinar si el elemento de datos solicitado está presente en los Datos 1620 de Prueba o reenviar la solicitud a los Datos 1610 en Vivo. En algunas realizaciones, el Entorno 1520 de Pruebas puede determinar por sí mismo si solicitar Datos 1610 en Vivo o Datos 1620 de Pruebas para un determinado elemento de datos. En algunas realizaciones, el Entorno 1520 de Pruebas puede acceder a los Datos 1610 en Vivo y a los Datos 1620 de Prueba después de copiarlos en la Memoria 820.
La FIG. 17 es una ilustración del acceso desde un sitio web a datos en vivo y de prueba en el Entorno 1520 de Pruebas, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 17, se está accediendo a la Página 125 Web Indexable del Sitio 123 Web utilizando el Navegador 141 Web en el Dispositivo 140 de Desarrollo Web. La Página 125 Web Indexable y los elementos de datos asociados están siendo accedidos a través del Entorno 1520 de Pruebas.
La Página 123 Web Indexable puede acceder tanto a los Datos 1610 en Vivo como a los Datos 1620 de Prueba como parte del acceso a los elementos de datos asociados con la Página 125 Web Indexable. En algunas realizaciones, todas las solicitudes de acceso a elementos de datos pueden enviarse primero a Datos 1620 de Prueba. Los Datos 1620 de Prueba pueden filtrar las solicitudes de acceso a elementos de datos que pueden ser manejados por los propios Datos 1620 de Prueba antes de reenviar las solicitudes a los Datos 1610 en Vivo.
La FIG. 18 representa la generación de datos de prueba utilizados en el Entorno 1520 de Pruebas para probar sitios web, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 18, los Datos 1610 en Vivo forman parte de los Datos 1620 de Prueba. En algunas realizaciones, el orden de adición de los Datos 1730 Marcados como Insertados y los Datos 1740 Marcados Como Eliminados puede ser diferente. Los Datos 1730 Marcados como Insertados y los Datos 1740 Marcados Como Eliminados pueden recorrerse concurrentemente para evitar agregar algo a los Datos 1620 de Prueba y luego borrar lo mismo marcado en los Datos 1740 Marcados Como Eliminados.
Los Datos 1730 Marcados como Insertados y los Datos 1740 Marcados Como Eliminados pueden persistir en la Base 124 de Datos del Área de Sitio. En algunas realizaciones, los Datos 1730 Marcados como Insertados y los Datos 1740 Marcados Como Eliminados pueden residir en la Memoria 920 hasta que la sesión para acceder al Sitio 123 Web en el Entorno 1520 de Pruebas esté activa. Los Datos 1730 Marcados como Insertados y los Datos 1740 Marcados Como Eliminados pueden persistir en la Base 124 de Datos del Área de Sitio cuando una sesión se vuelve inactiva. Por ejemplo, el Programador/Diseñador 1540 puede solicitar explícitamente que los Datos 1730 Marcados como Insertados y los Datos 1740 Marcados Como Eliminados persistan en la Base 124 de Datos del Área de Sitio. En algunas realizaciones, los Datos 1730 Marcados como Insertados y los Datos 1740 Marcados Como Eliminados pueden compartir la misma ubicación en la Base 124 de Datos del Área de Sitio. Los Datos 1730 Marcados como Insertados y los Datos 1740 Marcados Como Eliminados pueden persistir en función del número de solicitudes de lectura. Los elementos de datos dentro de los Datos 1730 Marcados como Insertados pueden persistir selectivamente en la Base 124 de Datos del Área de Sitio. Los elementos de datos pueden persistir selectivamente en función de criterios adicionales, tal como el número de veces que se solicita la lectura de un elemento de datos o el tiempo durante el cual un elemento de datos en ellos no ha cambiado o el número de sesiones en que se ha accedido a los datos.
Las FIG. 19 es un diagrama de flujo que ilustra un Método 1900 para acceder a un sitio web en un entorno de despliegue, de acuerdo con algunas realizaciones de la presente divulgación.
Como se muestra en el Paso 1910. Los elementos de datos que se actualizan y añaden al acceder a un sitio web en el Entorno 1510 de Despliegue se almacenan en los Datos 1610 en Vivo de la Base 124 de Datos del Área de Sitio.
En el Paso 1920, los Datos 1610 en Vivo almacenados en la Base 124 de Datos del Área de Sitio asociados con una página web indexable de un sitio web accedido en el Entorno 1510 de Despliegue son accedidos por el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web como parte del servicio de páginas web solicitadas por un usuario.
En el Paso 1930, los elementos de datos accedidos en el Paso 1920 se aplican a la página web indexable a la que están asociados para renderizar la página web en el Navegador 131 Web del Dispositivo 130 de Visualización Web utilizado por el Usuario 1530 Final.
La FIG. 20 es un diagrama de flujo que ilustra un Método 2000 para acceder a un sitio web en un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación.
En el Paso 2010, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web puede recibir una solicitud para realizar pruebas en el sitio web (por ejemplo, Sitio 123 Web) almacenado en la base de datos común (por ejemplo, Base 124 de Datos del Área de Sitio). En el Paso 2020, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web gestiona la solicitud de datos realizada como parte del procedimiento de prueba de un sitio web utilizando el Entorno 1520 de Pruebas. Por ejemplo, el Sitio 123 Web puede ser probado por el Programador/Diseñador 1540 accediendo al Sitio 123 Web mediante el Navegador 141 Web del Dispositivo 140 de Desarrollo de Sitios Web. Por ejemplo, el Programador/Diseñador 1540 puede solicitar la Página 125 Web Indexable del Sitio 123 Web escribiendo la URL. Además, en algunas realizaciones, la URL puede ser especificada por una aplicación. La solicitud incluye tanto la solicitud al Interfaz 126 de Usuario como los elementos de datos del Grupo 210 de Datos asociados a la Página 125 Web Indexable del Sitio 123 Web. Una solicitud de lectura de los datos puede realizarse como parte del procedimiento de acceso a una página web.
Como se muestra en la FIG. 20, en el Paso 2030, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web verifica si la prueba se ha completado. En algunas realizaciones, la prueba de un sitio web se considera completada si se accede al sitio web a través del Entorno 1520 de Pruebas durante un cierto periodo de tiempo. Las pruebas pueden considerarse concluidas tras un determinado número de solicitudes de datos. La prueba también puede considerarse finalizada cuando el Programador/Diseñador 1540 que accede a un sitio web a través del Navegador 141 Web del Dispositivo 140 de Desarrollo de Sitios Web cierra la pestaña o ventana del navegador utilizada para acceder al sitio web. Las pruebas también pueden considerarse finalizadas cuando el Programador/Diseñador 1540 lo solicite explícitamente al Sistema 1500 de Pruebas en Tiempo Real de Sitios Web. Si la respuesta al Paso 2030 es negativa, el Método 2000 puede volver al Paso 2010 y estar listo para recibir la siguiente solicitud de datos. Si la respuesta al Paso 2030 es afirmativa, el Método 2000 puede proceder al Paso 2040. En el Paso 2040, el Método 2000 puede aplicar los cambios realizados a los elementos de datos y guardados en los Datos 1620 de Prueba a los elementos de datos correspondientes en los Datos 1610 en Vivo. El Paso 2040 puede ser opcional, ya que el Desarrollador/Diseñador 1540 puede solicitar, por ejemplo, que se abandonen los cambios de datos incorporados en los Datos 1620 de Prueba.
En el Paso 2050, pueden borrarse todos los marcadores asociados con las actualizaciones de los elementos de datos realizadas durante la prueba del Sitio 123 Web en el Entorno 1520 de Pruebas.
La FIG. 21 es un diagrama de flujo que ilustra el Método 2100 para gestionar solicitudes de datos en el Entorno 1520 de Pruebas, de acuerdo con algunas realizaciones de la presente divulgación. El Método 2100 de la FIG. 21 identifica uno de cinco caminos ejemplares para manejar la solicitud entrante de elementos de datos asociados con un sitio web al que está accediendo un Desarrollador/Diseñador 1540.
Como se muestra en la FIG. 21, en el Paso 2110, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web recibe una solicitud de datos en el Entorno 1520 de Pruebas. La solicitud de datos forma parte del acceso a un sitio web para realizar pruebas en el Entorno 1520 de Pruebas. Por ejemplo, un Desarrollador/Diseñador 1540 que accede a un Sitio 123 Web a través del Dispositivo 140 de Desarrollo de Sitios Web puede provocar una solicitud del Elemento 211 de Datos del Grupo 210 de Datos asociado con el Sitio 123 Web.
En el Paso 2120, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web determina el tipo de la solicitud de acceso a elementos de datos asociados con un sitio web que está siendo probado. La determinación da lugar a que se tramiten distintos tipos de solicitudes. La solicitud de datos puede ser una solicitud de lectura para acceder a elementos de datos asociados con una página web que está siendo probada por el Desarrollador/Diseñador 1540 cuando solicitan una página web indexable escribiendo una URL. En algunas realizaciones, la solicitud de datos puede ser una solicitud de escritura para añadir un elemento de datos. Por ejemplo, el Desarrollador/Diseñador 1540 que prueba el Sitio 123 Web puede enviar un formulario en la Página 125 Web Indexable solicitando la creación de un nuevo elemento de datos que se añadirá al Grupo 210 de Datos. La solicitud de datos puede ser una solicitud de actualización para alterar el contenido de un elemento de datos asociado con el sitio web que está siendo probado por el Desarrollador/Diseñador 1540. La solicitud de datos puede ser una solicitud de eliminación para eliminar un elemento de datos asociado con un sitio web que está siendo probado por el Desarrollador/Diseñador 1540.
En el Paso 2121, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web ha determinado en el Paso 2120 que la solicitud de datos es para buscar elementos de datos asociados con el sitio web que está siendo probado por el Desarrollador/Diseñador 1540, o para navegar por el resultado de dicha operación de búsqueda.
En el Paso 2122, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web ha determinado en el Paso 2120 que la solicitud de datos es para leer elementos de datos asociados con el sitio web que está siendo probado por el Desarrollador/Diseñador 1540.
En el Paso 2123, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web ha determinado en el Paso 2120 que la solicitud de datos es para agregar elementos de datos asociados con el sitio web que está siendo probado por el Desarrollador/Diseñador 1540.
En el Paso 2124, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web ha determinado en el Paso 2120 que la solicitud de datos es para actualizar elementos de datos asociados con el sitio web que está siendo probado por el Desarrollador/Diseñador 1540.
En el Paso 2125, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web ha determinado en el paso 2120 que la solicitud de datos es para borrar elementos de datos asociados con el sitio web que está siendo probado por el Desarrollador/Diseñador 1540.
La FIG. 22 es un diagrama de flujo que ilustra un Método 2200 para gestionar solicitudes de lectura en un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación. El Método 2200 de la FIG. 22 identifica tres caminos para determinar si es necesario responder a una solicitud de datos y, en caso afirmativo, si se deben utilizar elementos de datos de los Datos 1620 de Prueba o de los Datos 1610 en Vivo.
Como se muestra en la FIG. 22, en el Paso 2122, se ha determinado en el Método 2100 que una solicitud de datos recibida es una solicitud de lectura de elementos de datos en la Base 124 de Datos del Área de Sitio y la Memoria 820.
En el Paso 2210, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web busca el elemento de datos solicitado en los Datos 1620 de Prueba y cuando encuentra una coincidencia verifica si está marcado como borrado. Si la respuesta en el Paso 2210 es afirmativa, el Método 2200 puede proceder al Paso 2120 y considera que el Método 2200 está completo. En el Paso 2 se devuelve el mensaje de no se ha encontrado ningún elemento de datos. Por ejemplo, el Desarrollador/Diseñador 1540 que accede a la Página 125 Web Indexable del Sitio 123 Web puede enviar una solicitud para el Elemento 1741 de Datos en los Datos 1740 Marcados Como Eliminados de los Datos 1620 de Prueba dando como resultado un mensaje de "no se ha encontrado ningún elemento de datos".
Si la respuesta en el Paso 2210 es no, el Método 2100 puede proceder al paso 2130. Como se muestra en la FIG. 22, en el Paso 2230, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web busca el elemento de datos solicitado en Datos 1730 Marcados Como Insertados de Datos 1620 de Pruebas.
Si la respuesta en el Paso 2230 es afirmativa, el Método 2200 puede proceder al Paso 2240. En el Paso 2240, el elemento de datos solicitado se encuentra en los Datos 1620 de Prueba y es devuelto. El elemento de datos solicitado puede estar en Datos 1730 Marcados Como Insertados de Datos 1620 de Pruebas ya que se añadió como un nuevo elemento de datos previamente. Además, el elemento de datos solicitado puede estar en Datos 1730 Marcados Como Insertados ya que se actualizó mientras se probaba un sitio web previamente. Por ejemplo, la solicitud del Desarrollador/Diseñador 1540 para acceder al elemento de datos del Contacto Dos 1760 en el Entorno 1520 de Pruebas resultará en que el Elemento 1732 de Datos en los Datos 1730 Marcados como Insertados de los Datos 1620 de Prueba sea devuelto después de que el Método 2200 ejecute el Paso 2240. El mismo elemento de datos cuando se solicita en el Entorno 1510 de Despliegue puede dar lugar a que se devuelva el Elemento 1752 de Datos.
Si la respuesta en el Paso 2230 es no, el Método 2200 puede proceder al Paso 2250. En el Paso 2250, el elemento de datos solicitado es devuelto desde Datos 1610 en Vivo.
Las FIG. 23a es un diagrama de flujo que ilustra un Método 2300 para actualizar elementos de datos en un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación. El Método 2300 de la FIG. 23a define una ubicación para almacenar el elemento de datos actualizado solicitado mientras se prueba un sitio web.
Como se muestra en la FIG. 23a, en el Paso 2124 se ha determinado en el Método 2100 que una solicitud de datos recibida es una solicitud para actualizar un elemento de datos presente en los Datos 1610 en Vivo o en los Datos 1730 Marcados como Insertados de los Datos 1620 de Prueba mientras se prueba un sitio web.
En el Paso 2310, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web determina la ubicación del elemento de datos que se solicita sea actualizado, primero verificando en Datos 1730 Marcados Como Insertados de Datos 1620 de Pruebas.
Si la respuesta al Paso 2310 es afirmativa, entonces el Método 2200 procede al Paso 2320. En el Paso 2320, se actualiza un elemento de datos correspondiente al que se solicita actualizar.
Si la respuesta al Paso 2310 es no, entonces el Método 2200 procede al Paso 2330 indicando que el elemento de datos solicitado que va a actualizarse no se actualizó en el pasado y está presente sólo en los Datos 1610 en Vivo. El elemento de datos en Datos 1610 en Vivo se copia en Datos 1740 Marcados Como Eliminados para evitar cualquier acceso futuro a los datos en Entorno 1520 de Pruebas.
En el Paso 2340, el Sistema 1500 de Pruebas en Tiempo Real del Sitio Web inserta el elemento de datos actualizado en los Datos 1620 de Prueba. En algunas realizaciones, añadir un elemento de datos implica añadir una entrada en la base de datos y marcar en una columna adicional que se ha añadido a través del Entorno de Pruebas. No se puede acceder al elemento de datos insertado en Datos 1730 Marcados Como Insertados de Datos 1620 de Pruebas desde Entorno 1620 de Pruebas mediante solicitudes en Entorno 1610 de Despliegue. Por ejemplo, la solicitud del Programador/Diseñador 1540 de actualizar el Elemento 1752 de Datos a través de la Sitio 123 Web da como resultado que el Elemento 1732 de Datos se inserte en los Datos 1730 Marcados como Insertados de los Datos 1620 de Prueba.
La FIG. 23b es un diagrama de flujo que ilustra otro Método 2300 para actualizar elementos de datos en el Entorno 1510 de Despliegue, de acuerdo con algunas realizaciones de la presente divulgación. El método asegura que los Datos 1610 en Vivo estén disponibles en tiempo real para el Desarrollador/Diseñador 1540 que prueba un sitio web utilizando el Entorno 1520 de Pruebas.
En el Paso 2350, se recibe una solicitud para actualizar un elemento de datos en el Entorno 1510 de Despliegue.
En el Paso 2360, un elemento de datos en los Datos 1610 en Vivo es actualizado de acuerdo con la solicitud.
En el Paso 2370, se realiza una solicitud de búsqueda para identificar el elemento de datos actualizado en los Datos 1610 en Vivo en el Paso 2360 contra los Datos 1740 Marcados Como Eliminados. Un elemento de datos correspondiente encontrado en Datos 1740 Marcados Como Eliminados se actualizó o borrado en Entorno 1520 de Pruebas.
Si la respuesta en el Paso 2370 es no, el Método 2300 procede al paso 2380 donde la tarea se considera completada y el Método 2300 sale.
Si la respuesta en el Paso 2370 es afirmativa, entonces el Método 2300 procede al Paso 2390. En el Paso 2390, el elemento de datos cuya actualización se ha solicitado a través del Entorno 1510 de Despliegue se actualiza en Datos 1740 Marcados Como Eliminados. Esto resulta en que el elemento de datos que se actualiza en los Datos 1610 en Vivo no se incluye en los resultados de la consulta como se discute en el Procedimiento 2500 más adelante.
La FIG. 23c es un diagrama de flujo que ilustra otro Método 2300 para añadir elementos de datos en un entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación. El Método 2300 de la FIG. 23c define una ubicación para almacenar los nuevos datos que se soliciten añadir mientras se prueba un sitio web.
Como se muestra en la FIG. 23c, en el Paso 2123 se ha determinado en el Método 2100 que una solicitud de datos recibida es una solicitud para agregar un nuevo elemento de datos no presente en los Datos 1610 en Vivo a los Datos 1620 de Prueba mientras se prueba un sitio web.
En el Paso 2392, el Sistema 1500 de Pruebas en Tiempo Real del Sitio Web inserta el elemento de datos en los Datos 1620 de Prueba. En algunas realizaciones, añadir un dato implica añadir una entrada en la base de datos y marcar en una columna adicional que se ha añadido a través de Entorno de Pruebas. No se puede acceder al elemento de datos insertado en Datos 1730 Marcados Como Insertados de Datos 1620 de Pruebas desde Entorno 1620 de Pruebas mediante solicitudes en Entorno 1610 de Despliegue. Por ejemplo, el Programador/Diseñador 1540 puede solicitar que se añada el Elemento 1731 de Datos a través del Sitio 123 Web, lo que da lugar a que el Elemento 1731 de Datos se inserte en los Datos 1730 Marcados como Insertados de los Datos 1620 de Prueba.
La FIG. 24 es un diagrama de flujo que ilustra un Método 2400 para borrar elementos de datos del entorno de prueba, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 24, el elemento de datos que se solicita eliminar puede presentarse en los Datos 1610 en Vivo o puede haber sido añadido previamente a través del Entorno de Pruebas y estar presente en los Datos 1730 Marcados como Insertados.
Como se muestra en la FIG. 24, en el Paso 2125, se ha determinado en el Método 2100 que una solicitud de datos recibida es una solicitud de eliminación de un elemento de datos en la Base 124 de Datos del Área de Sitio o en la Memoria 820.
En el Paso 2410, el Sistema 1500 de Pruebas en Tiempo Real de Sitios Web puede insertar el elemento de datos solicitado para borrarse a los Datos 1740 Marcados Como Eliminados de los Datos 1620 de Prueba. Cualquier elemento de datos, tanto si se ha añadido como si se ha actualizado en el Entorno de Pruebas, puede añadirse a los Datos 1740 Marcados Como Eliminados, ya que todos los elementos de datos de los Datos 1740 Marcados Como Eliminados pueden omitirse cuando se solicitan elementos de datos asociados a un sitio web que se está probando.
En el Paso 2420, se busca el elemento de datos que se solicita eliminar en los Datos 1730 Marcados como Insertados de los Datos 1620 de Prueba. El Procedimiento 2300 se considera completado si no se encuentra tal elemento de datos en los Datos 1620 de Prueba. Por ejemplo, el Desarrollador/Diseñador 1540 que prueba el Sitio 123 Web en el Navegador 141 Web hace una solicitud para borrar el Elemento 1741 de Datos da como resultado que el Elemento 1741 de Datos se inserta en los Datos 1740 Marcados Como Eliminados. El Elemento 1741 de Datos no está presente en los Datos 1730 Marcados como Insertados indica que no es necesario eliminar ningún dato y el Procedimiento 2400 se considera finalizado. Si la respuesta en el Paso 2420 es no, entonces el Método 2400 no ha encontrado un Dato 1730 Marcado Como Insertado un elemento de dato solicitado para ser borrado y el Método 2400 procede al Paso 2430 donde la tarea está completa y el Método 2400 sale.
Si la respuesta en el Paso 2420 es sí, entonces el Método 2400 encontró en Datos 1730 Marcados Como Insertados un elemento de datos solicitado para borrarse. En el Paso 2440, el elemento de datos de los Datos 1620 de Prueba se elimina de los Datos 1730 Marcados como Insertados.
La FIG. 25 ilustra un procedimiento de superposición para generar los resultados de la consulta de datos de prueba, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 25, el Método 2500 es un procedimiento de cuatro pasos que accede concurrentemente a los Datos 1610 en Vivo, a los Datos 1730 Marcados como Insertados, y a los Datos 1740 Marcados Como Eliminados de los Datos 1620 de Prueba.
Como se muestra en la FIG. 25, en el Paso 1, se accede a los elementos de datos que coinciden con la consulta desde Datos 1610 en Vivo, Datos 1730 Marcados como Insertados y Datos 1740 Marcados Como Eliminados. En algunas realizaciones, los elementos de datos son accedidos ejecutando una consulta en la Base 124 de Datos del Área de Sitio contra los Datos 1610 en Vivo, y los Datos 1730 Marcados como Insertados y los Datos 1740 Marcados Como Eliminados de los Datos 1620 de Prueba. En algunas realizaciones, los resultados de las consultas pueden disponerse como una Tabla 2510 Fusionada.
Los elementos de datos se ordenan de acuerdo con lo solicitado en la consulta. En algunas realizaciones, los elementos de datos se ordenan por la columna "B" en el 2510 en orden descendente. En algunas realizaciones, el orden puede incluir más de una columna. En algunas realizaciones, cuando no hay un orden solicitado se elige una columna al azar y se ordena en orden ascendente o descendente. En algunas realizaciones se añade una clave primaria a las columnas utilizadas en la clasificación.
En el Paso 2, el sistema recorre los elementos de datos en los Datos 1610 en Vivo, Datos 1730 Marcados como Insertados, y Datos 1740 Marcados Como Eliminados simultáneamente para seleccionar los elementos de datos que van a incluirse en los Datos 1620 de Prueba.
Para determinar los elementos de datos que se incluirán en la Prueba 1720, se establece un puntero en el primer elemento de Datos 1610 en Vivo, Datos 1730 Marcados como Insertados, y Datos 1740 Marcados Como Eliminados. En algunas realizaciones, el puntero se coloca en el elemento de datos más bajo basado en la columna "B". Se compara el registro más bajo actual en Datos 1610 en Vivo, Datos 1730 Marcados como Insertados, y Datos 1740 Marcados Como Eliminados para identificar el elemento de datos más bajo. El más bajo puede estar presente en varios lugares. Por ejemplo, los Elementos 2520 y 2530 de Datos son los elementos de datos más bajos de los Datos 1610 en Vivo y los Datos 1740 Marcados Como Eliminados y tienen el mismo contenido.
Una vez identificado el elemento de datos más bajo se determina si un elemento de datos debe incluirse en los Datos 1620 de Prueba basándose en las siguientes reglas. Si el elemento de datos existe tanto en los Datos 1610 en Vivo como en los Datos 1740 Marcados Como Eliminados, se omitirá su inclusión en los Datos 1620 de Prueba. Por ejemplo, los Elementos 2520 y 2530 de Datos tienen el mismo contenido y existen en los Datos 1610 en Vivo y en los Datos 1740 Marcados Como Eliminados, lo que indica que se solicitó anteriormente la eliminación del elemento de datos en el Entorno 1520 de Pruebas mientras se probaba un sitio web. También podría haberse actualizado y que el Elemento 2560 de Datos fuera el elemento actualizado resultante.
Si el elemento de datos sólo existe en los Datos 1610 en Vivo entonces se incluye en los Datos 1620 de Prueba. Por ejemplo, el Elemento 2540 de Datos sólo está presente en los Datos 1610 en Vivo indicando que no se alteró o borrado en el Entorno de Pruebas cuando se prueba un sitio web que está asociado con el Elemento 2540 de Datos.
Si el elemento de datos sólo existe en los Datos 1730 Marcados como Insertados, entonces se incluye en los Datos 1620 de Prueba. Por ejemplo, el Elemento 2540 de Datos sólo está presente en los Datos 1740 Marcados Como Eliminados, lo que indica que se insertó como un nuevo elemento de datos o se insertó como parte de la actualización del Elemento 2520 de Datos mientras se probaba un sitio web.
Una vez que un elemento de datos es incluido u omitido sólo aquellas fuentes de elemento de datos que tenían el elemento de datos más bajo tienen sus punteros para moverse al siguiente elemento de datos. En algunas realizaciones, los punteros para los Datos 1610 en Vivo y los Datos 1740 Marcados Como Eliminados se mueven al siguiente registro después de la primera iteración del recorrido.
Al alcanzar el último elemento de datos en las tres fuentes de elementos de datos, el Método 2500 termina y se obtienen los Datos 1620 de Prueba. La Tabla 2560 Fusionada indica los elementos de datos más bajos identificados en cada iteración del Paso 2 discutido anteriormente. Sólo se muestran rellenadas las fuentes que tenían el elemento de datos más bajo y el resto se dejan vacías. Por ejemplo, en la primera iteración del Paso 2, los Elementos 2520 y 2530 de Datos más bajos que tienen el mismo contenido se muestran como parte de sus respectivas fuentes Datos 1610 en Vivo, y Datos 1740 Marcados Como Eliminados y Datos 1740 Marcados Como Eliminados se dejan vacíos indicando que no tenía el elemento de datos más bajo. De forma similar, en la última iteración sólo los Datos 1730 Marcados como Insertados tienen el elemento 2550 de datos más bajo indicado en la última fila de la Tabla 2560 Fusionada.
La FIG. 26 representa un diagrama de flujo que muestra los pasos de un Método 2600 para editar una base de datos durante la previsualización de un sitio web, de acuerdo con algunas realizaciones de la presente divulgación. El Método 2600 puede practicarse en los entornos de sistema descritos a lo largo de esta divulgación, como los de las FIGS. 1, 2, 15 y otros.
Como se muestra en la FIG. 26, El Paso 2602 puede implicar la recepción de uno o más grupos de elementos de datos (por ejemplo, de un usuario de un sistema de construcción de sitios web). Los elementos de datos, como se ha comentado anteriormente, pueden incluir una variedad de diferentes tipos de contenido, o registros de contenido, que pueden integrarse en un sitio web, tal como texto, imágenes, vídeos, anuncios, visualizaciones de salida de base de datos, etc. En algunas realizaciones, los elementos de datos pueden incluir además un conjunto de objetos de datos (por ejemplo, dos instancias de texto y una imagen). Cada grupo puede tener uno o más elementos de datos. Así pues, un grupo puede definir un conjunto afín de uno o varios elementos. Por ejemplo, un primer sitio o página web (por ejemplo, un identificador de la página web) puede asociarse a un grupo que comprenda sólo texto, un segundo sitio o página web puede asociarse a un grupo que comprenda elementos de datos (cada uno de los cuales comprenda un texto y tres imágenes), un tercer sitio o página web puede asociarse a un grupo que comprenda elementos de datos que comprendan texto y vídeo, etc. A través de una interfaz de edición de sitios web, como se ha comentado anteriormente, el usuario puede identificar qué grupos de elementos de datos deben aparecer o estar asociados con páginas web individuales de un sitio web, o con determinadas plantillas de páginas virtuales.
Los grupos de datos pueden, en algunas realizaciones, ser entidades a nivel de sitio que pueden ser usadas y reutilizadas en múltiples páginas de un sitio web, o pueden ser entidades a nivel de propietario que pueden ser usadas y reutilizadas por un propietario de sitio web en particular. Además, los grupos de datos también pueden ser entidades a nivel de sistema (por ejemplo, una base de datos de códigos postales, descripciones de áreas geográficas, etc.) o entidades a nivel de página.
El Método 2600 también puede incluir un Paso 2604 de almacenamiento de los grupos de uno o más elementos de datos en una Base 124 de Datos del Área de Sitio, consistente con las realizaciones anteriores. Ejemplos de este tipo de bases de datos se han descrito anteriormente (por ejemplo, en relación con las FIGS. 1, 2, 15, y otras). Las bases de datos pueden estar configuradas para mantener cada grupo, mantener asociaciones entre los grupos y sitios web o páginas, o plantillas de páginas virtuales, y almacenar otros contenidos e información. Como se explica más adelante, cuando un usuario realiza modificaciones en una página web virtual durante un modo de vista previa, dichas modificaciones pueden traducirse en modificaciones de la base de datos en tiempo real, manteniendo así una base de datos actualizada para cada página web.
Además, el Método 2600 puede incluir un Paso 2606 de generación de una o más páginas web virtuales. Cada una de las páginas web virtuales puede representar elementos de datos (consistentes en uno o más objetos) que pueden mostrarse en modo de vista previa (durante el desarrollo) antes de que el sitio web real o sus partes actualizadas se pongan en marcha (es decir, se vuelvan visibles a través de Internet para otros usuarios). Para publicar posteriormente una colección de páginas web virtuales en modo directo, un usuario puede seleccionar una opción titulada "Publicar", "Publicación" o similar, que hará que la página web sea visible a través de Internet (ya que la publicación se realiza normalmente a nivel de sitio y no para una sola página). Una vez publicadas, las páginas virtuales (es decir, las instancias derivadas de la Plantilla 2704 de Página Web) pueden comportarse de forma similar a las páginas ordinarias (reales), aunque se generan dinámicamente. En algunas realizaciones, cada una de las páginas web reales no está diseñada con funcionalidad para actualizar la base de datos, mientras que las páginas web virtuales pueden estar diseñadas con esa funcionalidad. A modo de ejemplo, un sitio web de alquiler de hoteles puede mantener cinco plantillas de páginas virtuales diferentes para cinco tipos distintos de habitaciones disponibles en un hotel concreto (tal como cama individual, cama doble, etc.). Cada una de las plantillas de páginas virtuales puede estar asociada a su propio grupo de elementos de datos (es decir, registros para habitaciones del tipo dado), y cada habitación tendría así una página web virtual que podría ser visualizable y editable durante un modo de vista previa como página web virtual.
Además, el Método 2600 puede incluir un Paso 2608 de mostrar cada grupo de al menos un elemento de datos en uno separado de los conjuntos de páginas web virtuales. Por ejemplo, en el caso hipotético anterior de un sitio web de hotel, durante el modo de vista previa cada una de las cinco plantillas de páginas web virtuales correspondientes a diferentes tipos de habitaciones de hotel puede tener sus grupos asociados de elementos de datos (por ejemplo, diferentes textos que describan las habitaciones, imágenes de las habitaciones, vídeos de las habitaciones, etc.). Los conjuntos de páginas web virtuales generados (es decir, las instancias) pueden mostrarse al usuario a través de un navegador u otro cliente, como se ha comentado anteriormente en relación con otras técnicas.
El Método 2600 también puede incluir un Paso 2610, que implica desplegar una herramienta de edición para permitir a un usuario editar una o más de las plantillas e instancias de página web virtual. Las plantillas pueden editarse como si fueran páginas normales. Las instancias pueden editarse sólo en modo de vista previa, ya que no son visibles como parte del procedimiento normal de navegación y edición de páginas del editor. En una realización alternativa, el sistema puede permitir la edición de instancias como parte del procedimiento regular de edición del sitio. Pueden utilizarse diversas herramientas de edición, como reglas y cuadrículas (por ejemplo, para alinear elementos de datos), selectores de arrastrar y soltar (por ejemplo, para mover elementos de datos con un cursor), inserción y edición de hipervínculos, integración de widgets o aplicaciones (por ejemplo, de una tienda de aplicaciones), inserción y edición de botones, creación y edición de textos, inserción y edición de imágenes, inserción y edición de vídeos, creación y edición de presentaciones de diapositivas, funcionalidad de desplazamiento del cursor, estilos de fondo, repetidores (por ejemplo, que crean múltiples versiones de un elemento o grupo de datos concreto), enrutadores basados en software (por ejemplo, que crean una versión diferente de una página web en función de un elemento de la URL utilizada para acceder a ella), etc. El sistema puede mostrar (y operar) diferentes subconjuntos de las herramientas de edición disponibles para plantillas e instancias, y también puede personalizar el subconjunto de herramientas de edición mostrado dependiendo del usuario, plantilla de página virtual, instancia específica, grupo de datos o elemento conectado subyacente, etc. Como se discute más adelante, un usuario puede hacer ediciones a las plantillas e instancias de la página web virtual a través de las herramientas de edición, y las ediciones pueden traducirse en ediciones a la base de datos que mantiene la información de los componentes y/o el contenido de las páginas web.
El Método 2600 también puede incluir un Paso 2612 de asociar una URL única a cada página web virtual. Por ejemplo, un sitio web puede tener un nombre de dominio (por ejemplo, wix.com) y cada página dentro del sitio web puede tener un sufijo diferente (por ejemplo, wix.com/page1, wix.com/page2, wix.com/page3, etc.). Además, en algunos casos, las URL asociadas a páginas web virtuales pueden tener diferentes rutas (referidas a archivos o directorios) o valores de parámetros. En algunas realizaciones, se puede configurar un enrutador basado en software para el sitio web o para páginas web individuales. El enrutador basado en software puede ser configurable, por ejemplo, para asociar determinados prefijos de URL, rutas, segmentos o parámetros con determinadas páginas web. Cada una de las páginas web puede estar configurada para extraer datos diferentes de la base de datos que almacena los elementos de datos. En una implementación de JavaScript, por ejemplo, una solicitud entrante de una página web puede asociarse a un objeto que incluye información sobre la solicitud (por ejemplo, la URL, de dónde procede, de quién procede, etc.). El enrutador basado en software puede procesar esta información y decidir qué página web (posiblemente virtual) mostrar y qué elementos de datos incluir en ella.
Además, el Método 2600 puede incluir un Paso 2614 de mostrar una característica seleccionable por el usuario (por ejemplo, botones, barras de desplazamiento, enlaces, etc.) permitiendo al usuario navegar a través de las páginas web virtuales para mostrar individual y dinámicamente cada una de las páginas web virtuales. Por lo tanto, en el ejemplo anterior, la función seleccionable por el usuario puede permitirle ver cada uno de los cinco conjuntos de páginas web correspondientes a diferentes tipos de habitaciones de hotel. Cada página puede seleccionarse dinámicamente y visualizarse como una página web virtual.
El Método 2600 puede incluir además un Paso 2616 de recibir ediciones a uno o más atributos de página web virtual de un usuario. Por ejemplo, utilizando la herramienta de edición descrita anteriormente, un usuario puede cambiar el fondo de una página, el diseño o la plantilla de una página, las aplicaciones o widgets integrados en una página, los prefijos o sufijos de URL asociados a una página, la funcionalidad de resolicitud dentro de una página, la funcionalidad de enrutador basado en software para una página, o realizar otros tipos de ediciones. Los cambios realizados en la Plantilla 2704 de Página Web pueden escribirse directamente en la definición de página de la plantilla en la Base 124 de Datos del Área de Sitio. Los cambios realizados en las instancias de páginas virtuales podrán almacenarse en una base de datos independiente, que contendrá las adaptaciones a las instancias de páginas virtuales. De acuerdo con este esquema, las adaptaciones se indexarán con un índice único de la instancia de página virtual específica (por ejemplo, en nuestro ejemplo del hotel, "Habitación individual #1234"). La adaptación se recuperaría y volvería a aplicarse cada vez que se generara esta instancia de página virtual para su visualización (por ejemplo, durante la vista previa o durante la visualización en directo).
En algunas realizaciones, a los usuarios se les permite editar instancias de páginas virtuales, pero sólo en términos de su información de campo (por ejemplo, texto, gráficos, videos, etc.). Por ejemplo, en tales realizaciones, se puede prohibir a los usuarios la edición de otros elementos (es decir, distintos del contenido) de una instancia de página virtual, incluidos el diseño, los atributos, etc.
El Método 2600 también puede incluir un Paso 2618 de recepción de ediciones de los propios elementos de datos. Dichas ediciones pueden realizarse directamente en una visualización del grupo de datos (es decir, una visualización de los elementos de la interfaz de usuario que permiten navegar y editar los grupos de datos y elementos subyacentes). Alternativamente, dicha edición puede realizarse a través de la edición del contenido del campo en las instancias de página virtual generadas relacionadas con los elementos. El sistema puede permitir dicha edición añadiendo (en modo de vista previa) controles de edición adicionales a las instancias de página virtual mostradas (tal como un botón "seleccionar imagen alternativa" añadido a cada imagen mostrada originada a partir de un grupo de datos). Como ya se ha dicho, los datos pueden almacenarse en una base de datos. Las ediciones pueden incluir la edición de texto, la sustitución o modificación de imágenes, la sustitución o modificación de vídeos, la alteración de la funcionalidad de pasar el cursor por encima de un elemento y otros tipos de ediciones.
Además, el Método 2600 puede incluir un Paso 2620 de recibir ediciones al código asociado con una o más páginas web virtuales. Ejemplos del código pueden ser el código de interfaz de usuario y el código de interfaz del sistema descritos anteriormente en relación con las FIGs. 1-7. Por ejemplo, el código puede estar relacionado con la recopilación y el almacenamiento de datos y contenidos en una base de datos, la creación de páginas dinámicas, la implementación de widgets y aplicaciones orientadas al usuario, la resolicitud de diseños de elementos de datos, la configuración de enrutadores basados en software, etc. En algunas realizaciones, en el Paso 2622, se pueden generar segmentos de código esqueleto para facilitar al usuario la edición del código asociado a las páginas web. Por ejemplo, el código esqueleto puede ser abstracciones de alto nivel de funciones asociadas con código fuente más granular, que puede implementar los diversos tipos de funcionalidad interfaz de usuario e interfaz del sistema descritos anteriormente para páginas web. El código esqueleto puede mostrarse a los usuarios a través de la interfaz de edición y éstos pueden modificarlo. Las modificaciones de los usuarios en el código esqueleto pueden traducirse en modificaciones en el código real más granular asociado a las páginas web individuales. En cuanto a las ediciones de atributos de página y contenido de datos/campos de página mencionados anteriormente, el sistema puede admitir ediciones de la Plantilla 2704 de Página Web (que se almacenan en la Base 124 de Datos del Área de Sitio, posiblemente sujetas a Sandboxing de cambios de desarrollo antes de la publicación) o de instancias de páginas virtuales (que pueden almacenarse en la base de datos de adaptaciones de instancias de páginas virtuales). Esto se detalla más adelante en la descripción de los pasos 2630 y 2634.
En el Método 2600, un Paso 2624 puede permitir a un usuario seleccionar páginas web virtuales particulares y un Paso 2626 puede permitir a un usuario navegar a través de páginas web virtuales. Por ejemplo, los usuarios pueden seleccionar páginas individualmente haciendo clic en hipervínculos u otros enlaces asociados con imágenes o representaciones visuales de las páginas, o pueden navegar por las páginas visualmente (por ejemplo, mediante un botón de alternancia izquierda/derecha o arriba/abajo, o mediante otras visualizaciones de selección).
De acuerdo con el Método 2600, cualquier edición a páginas web virtuales (por ejemplo, edición de instancias a través de los Pasos 2616 o 2618) puede traducirse en actualizaciones a la base de datos que mantiene los elementos de datos para las páginas web en un Paso 2828. Por ejemplo, si un usuario sustituye una imagen de una página web virtual por otra imagen (por ejemplo, una imagen cargada por el usuario, etc.), la nueva imagen puede almacenarse en la base de datos. Además, si el usuario sustituye el texto de la página web virtual (por ejemplo, la descripción de una habitación de hotel específica), el texto actualizado también puede almacenarse en la base de datos. En algunas realizaciones, las actualizaciones de la base de datos pueden realizarse automáticamente en función de las ediciones del usuario en la página web virtual. Dado que la base de datos se utiliza para crear las páginas virtuales y está asociada a los contenidos de éstas, las modificaciones que se realicen en las páginas virtuales pueden asociarse a la base de datos utilizada para crearlas. En algunas realizaciones, se almacenan varias versiones de la base de datos, al menos temporalmente, para que los usuarios puedan realizar operaciones de deshacer o revertir si desean anular un cambio que hayan realizado en una página web virtual y volver a una versión anterior. Por ejemplo, los usuarios pueden seleccionar una opción de deshacer o revertir, o se les pueden presentar marcas de tiempo o identificadores de versión asociados a versiones anteriores de una página web virtual a las que pueden volver y reanudar su edición. Dicho sistema de versionado también puede soportar la realización de cambios en la versión de la base de datos de desarrollo que no formen parte de la versión publicada hasta que se realice una operación de publicación. Esto también se conoce como "Sandboxing" de la base de datos de desarrollo.
El Método 2600 también puede incluir un Paso 2630, en el que se recibe cualquier edición del código esqueleto realizada por el usuario. Además, en el Paso 2634, cualquier edición al código real (por ejemplo, a través del Paso 2620) o al código esqueleto (por ejemplo, a través del Paso 2630) puede traducirse en ediciones al código real para la página web. Como se ha descrito anteriormente, por ejemplo, los usuarios pueden editar el código real o esqueleto asociado con diversas funcionalidades interfaz del sistema o interfaz de usuario de las páginas web virtuales. Dichas ediciones del código pueden almacenarse en la misma base de datos que aloja los elementos de datos de una página web virtual o en una base de datos de códigos independiente.
Además, en un Paso 2632, el Método 2600 puede incluir habilitar, durante una vista en vivo de una página web real asociada con una página web virtual, una visualización de las páginas web con las actualizaciones hechas a la página web virtual durante el modo de vista previa - incluyendo tanto páginas web regulares como instancias de páginas web virtuales. Como se ha comentado anteriormente, por ejemplo, los usuarios pueden editar numerosas características de una página web virtual durante el modo de vista previa (por ejemplo, estructura de la página, elementos de datos, código de interfaz de usuario, código de interfaz del sistema, etc.) tanto para plantillas como para instancias. Tales ediciones pueden traducirse en las correspondientes actualizaciones de las definiciones de página o cambios en los elementos de datos, que pueden almacenarse en la Base 124 de Datos del Área de Sitio y/o en bases de datos separadas (por ejemplo, una base de datos de elementos de datos, una base de datos de adaptación de instancias, y/o una base de datos de código separada en la que se basa la página web virtual). Tales bases de datos separadas también pueden ser alojadas por el WBS 100, por ejemplo, como parte de la Memoria 820 o del Almacenamiento 830 Persistente. Además, estas modificaciones pueden traducirse en las correspondientes actualizaciones de la página web real. En diversas realizaciones, las páginas web virtuales y las páginas web reales pueden basarse en la misma base de datos o en bases de datos diferentes (por ejemplo, vinculadas). Debe tenerse en cuenta que estas bases de datos (por ejemplo, la Base 124 de Datos del Área de Sitio y otras bases de datos, tal como una base de datos de elementos de datos, una base de datos de adaptación de instancias o una base de datos de código de interfaz de usuario/interfaz del sistema separada) pueden implementarse como una única base de datos, un conjunto de bases de datos o una combinación de bases de datos (cada una de las cuales puede soportar un subconjunto de las funciones requeridas).
La FIG. 27 es un sistema 2700 para el desarrollo y previsualización de páginas web, de acuerdo con algunas realizaciones de la presente divulgación. Como se discutió anteriormente, el sistema 2700 puede ser similar a, u operar dentro de, los sistemas discutidos en conexión con las FIGS. 1, 2, 15 y otros. En algunas realizaciones, el sistema 2700 puede incluir una Base 124 de Datos del Área de Sitio, que almacena elementos de datos y/o código para una o más páginas 2704 web. Como se muestra, se pueden mantener numerosas páginas 2704 web, cada una de las cuales puede tener sus propios elementos de datos correspondientes. Como se ha comentado anteriormente, los elementos de datos pueden organizarse en el Grupo 210 de Datos de uno o más elementos de datos. Como se ha indicado anteriormente, dicho grupo 2710 de datos puede ser de todo el sistema, específico de un grupo de sitios, específico de un sitio o específico de una página (típicamente para una determinada Plantilla 2704 de Página Web).
Como se muestra en la FIG. 27, la Base 124 de Datos de Área Local puede comunicarse a través de una red con un Navegador 131 Web u otra aplicación cliente, que puede ser operada por un usuario. El Navegador 131 Web puede mostrar una Página 2712 Web Virtual correspondiente a cada Plantilla 2704 de Página Web en la Base 124 de Datos del Área de Sitio utilizando elementos de datos en el Grupo 210 de Datos. Además, cada Página 2712 Web Virtual puede estar asociada a un Elemento 211 de Datos. Además, los usuarios pueden visualizar los elementos de datos individualmente (por ejemplo, el Elemento 1211 de Datos y el elemento 22718 de datos) como parte del grupo de elementos 2714 de datos. Como se discutió anteriormente, los usuarios pueden interactuar con la Página 2712 Web Virtual mostrada, incluyendo sus elementos 2710, 2714, 211, 2718, para editar las diversas características de la Página 2712 Web Virtual. Las ediciones pueden implicar elementos de datos específicos, características de la estructura de la página, código de interfaz de usuario, código de interfaz del sistema, y más. Como se discutió anteriormente, tales ediciones pueden ser recibidas por la Base 124 de Datos del Área de Sitio y/u otras bases de datos.
La FIG. 28 es un diagrama 2800 de bloques de una página web virtual, de acuerdo con algunas realizaciones de la presente divulgación. De acuerdo con los ejemplos anteriores, la Página 2712 Web Virtual puede incluir diversas Características 2802 Seleccionables por el Usuario, incluyendo una característica 2804 de visualización, elemento 2806 de búsqueda, marcadores 2810, característica 2810 de desplazamiento, y otras características. La Página 2712 Web Virtual puede incluir además elementos 2714 de datos y código 2812 de interfaz de usuario, como se ha comentado anteriormente. Además, la Página 2712 Web Virtual puede estar asociada con código interfaz del sistema (no mostrado), tal como código de página web dinámica. Los usuarios pueden ver, interactuar y editar la Página 2712 Web Virtual como se ha comentado anteriormente. Dichas ediciones pueden ser recibidas por uno o más componentes del sistema de creación de sitios web, tal como la Base 124 de Datos del Área de Sitio. A través de la visualización de la Página 2712 Web Virtual, los usuarios pueden visualizar las ediciones que están haciendo antes de que la página web correspondiente salga al aire. Para publicar la Página 2712 Web Virtual en un modo en vivo, un usuario puede seleccionar un enlace "publicar" o "renderizar", como se discutió anteriormente.
La FIG. 29 es una visualización 2900 de línea de tiempo de actualización dinámica de páginas web, de acuerdo con algunas realizaciones de la presente divulgación. En particular, a medida que un usuario realiza ediciones en una Página 2712 Web Virtual, las ediciones pueden actualizarse en la Base 124 de Datos del Área de Sitio y, por lo tanto, también en el navegador del usuario. Como se muestra en la FIG. 29, el grupo 2710 de datos puede incluir el Elemento 1 211 de Datos y el Elemento 22718 de Datos, entre otros elementos de datos. Dentro del Elemento 1211 de Datos, puede mostrarse una Pestaña 12902 y dentro del Elemento 22718 de datos, puede mostrarse una pestaña 22904 de prueba. La pestaña 12902 y la Pestaña 22904 de Prueba pueden mostrarse en la Página 2712 Web Virtual, como se muestra, junto con otros elementos (por ejemplo, una barra de búsqueda, un menú desplegable, etc.).
A medida que avanza el tiempo en la visualización 2900 de la línea de tiempo, el usuario puede realizar ediciones en la Página 2712 Web Virtual. Por ejemplo, como se muestra, el usuario puede hacer ediciones a la Pestaña 22904 de Prueba, resultando en la Pestaña 2 Editada. Además, puede añadirse un nuevo Elemento 32906 de Datos a la Página 2712 Web Virtual, como parte del grupo 2710 de datos. A medida que se realizan las ediciones en la Página 2712 Web Virtual, se pueden realizar las ediciones correspondientes en un Entorno 2908 en Vivo. Por ejemplo, cuando el usuario selecciona una función "publicar" o "renderizar", el Entorno 2908 en Vivo puede actualizarse para mostrar las actualizaciones del grupo 2710 de datos y otros aspectos de la Página 2712 Web Virtual. Por ejemplo, una primera versión de la página 2910 web real puede no incluir la Pestaña 2 Editada o la Pestaña 3, mientras que la versión posterior de la página 2912 web real puede incluir dichas actualizaciones. En diversas realizaciones, las actualizaciones de la Página 2712 Web Virtual pueden hacerse automáticamente o cuando el usuario selecciona una función de actualización. Además, las actualizaciones de la página 2910 y 2912 web real en el Entorno 2908 en Vivo pueden realizarse cuando el usuario confirma una transición al Entorno 2908 en Vivo (por ejemplo, seleccionando un enlace "publicar" o "renderizar").
La FIG. 30 representa un diagrama de bloques de un Sistema 3000 de Vista Previa Dinámica, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 30, el Sistema 3000 de Vista Previa Dinámica ayuda a mostrar las páginas web tal y como aparecerían, por ejemplo, en el Entorno 1510 de Despliegue. La Interfaz 3010 de Vista Previa puede ser un marco u otra interfaz gráfica dentro de la Interfaz 243 de Editor En Línea que muestra una página web. En algunas realizaciones, la Interfaz 3010 de Vista Previa puede ser una pestaña separada abierta en el navegador web que se está utilizando para mostrar la Interfaz 243 de Editor En Línea.
La Interfaz 3010 de Vista Previa puede utilizarse para mostrar tanto páginas web estáticas como páginas web virtuales (es decir, instancias de una determinada Plantilla 2704 de Página Web). Las páginas web virtuales generadas para su visualización en la Interfaz 3010 de Vista Previa pueden ir acompañadas de una Interfaz 242 de Navegación. La Interfaz 3010 de Vista Previa puede permitir que la Interfaz 242 de Navegación incluya características de desplazamiento para permitir a los usuarios desplazarse a través de múltiples páginas web virtuales generadas para su visualización en la Interfaz 3010 de Vista Previa. La Interfaz 242 de Navegación puede permitir tanto la navegación secuencial como el acceso directo a páginas web virtuales específicas, así como la navegación entre páginas virtuales a través de la búsqueda (por ejemplo, utilizando valores del elemento de datos clave utilizado para identificar páginas virtuales específicas). La Interfaz 242 de Navegación puede tener acceso directo a páginas web virtuales específicas y puede soportar páginas web virtuales marcadas para navegar selectivamente. Por ejemplo, las páginas web virtuales que se muestran en la Interfaz 3010 de Vista Previa pueden ir acompañadas de un enlace a la primera, última, anterior o siguiente página web virtual. La WBS 100 también puede admitir otras disposiciones de las páginas virtuales, no sólo una lineal. Por ejemplo, el WBS 100 puede soportar una disposición jerárquica de páginas virtuales, por las que se puede navegar utilizando opciones adicionales tal como "ir a un nivel superior del árbol" o "expandir el nivel por debajo de la página actual".
La FIG. 31 ilustra una vista previa de una Página 3110 Web Virtual que está siendo editada, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 31, la Interfaz 126 de Usuario está asociada con el Grupo 210 de Datos. Las Herramientas 121 de Construcción incluidas en la Interfaz 126 de Usuario pueden estar asociadas a elementos de datos específicos del Grupo 210 de Datos. La Página 3110 Web Virtual puede mostrar la Página 125 Web Indexable, incluyendo la Interfaz 126 de Usuario, y puede visualizarse previamente en la Interfaz 3010 de Vista Previa. En algunas realizaciones, la Interfaz 3010 de Vista Previa puede ser un marco u otra representación gráfica dentro de la Interfaz 243 de Editor En Línea. La Interfaz 3010 de Vista Previa puede permitir previsualizar la Página 3110 Web Virtual tal y como aparecería en diferentes dispositivos móviles y de escritorio, utilizando diferentes idiomas, adaptada a los requisitos de accesibilidad o modificada de otro modo para audiencias específicas.
La FIG. 32 es un diagrama esquemático que muestra las relaciones entre los grupos de datos y los sitios web, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 32, un grupo de Páginas 3220 Web Virtuales de un sitio web puede estar asociado a un mismo Grupo 210 de Datos. En algunas realizaciones, el grupo de Páginas 3220 Web Virtuales puede estar asociado con un conjunto de Grupos 3230 de Datos. En algunas realizaciones, un grupo de Páginas 3240 Web puede compartir el mismo conjunto de Grupos 3230 de Datos. Un grupo de Páginas 3240 Web que comparte un conjunto de Grupos 3230 de Datos puede tener un mismo propietario u operador, o se le pueden haber concedido permisos apropiados (a través de un mecanismo de control de acceso) para acceder a Grupos 210 de Datos específicos. En algunas realizaciones, un grupo de Páginas 3240 Web que comparten un conjunto de Grupos 3230 de Datos pueden haber sido construidos por el mismo Desarrollador/Diseñador 1540, como se ha comentado anteriormente.
Como se ilustra en la FIG. 32, un Repetidor 3213 es una herramienta de construcción visible en la Interfaz de Usuario de una página web que muestra diferentes elementos de contenido o agrupaciones en diferentes secciones con un diseño o disposición repetida. En algunas realizaciones, el Repetidor 3213 puede formar parte de una Página 3111 Web Virtual generada mediante un enrutador basado en software, como se explica más adelante, o formar parte de una Página 125 Web Indexable normal (estática). El Repetidor 3213 muestra un contenido diferente basado en el Elemento 1211 de Datos y el Elemento de Datos M 3212 del Grupo 210 de Datos. El repetidor puede estar asociado directamente con un subconjunto 3213 de Grupo de Datos del Grupo 210 de Datos. Por ejemplo, se puede utilizar un repetidor para crear cinco agrupaciones diferentes de texto e imágenes. Cada agrupación puede colocar automáticamente el texto y las imágenes con las mismas proporciones y disposición. No obstante, en algunas realizaciones, el contenido real del texto y las imágenes puede ser diferente en cada agrupación.
La FIG. 33 es un diagrama esquemático que muestra los componentes implicados en la generación de páginas web virtuales, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 33, la Plantilla 2704 de Página Web, similar a las páginas web indexables, puede estar asociada con el Grupo 210 de Datos y otros grupos de datos. Como se ha comentado anteriormente, el Enrutador 3310 Basado en Software puede utilizarse para enlazar elementos de datos en un Grupo 210 de Datos y puede aplicarse a la Plantilla 2704 de Página Web para generar Páginas 3111, 3313 y 3312 Web Virtuales. El Enrutador 3310 Basado en Software puede seleccionar/filtrar/ordenar elementos de datos en el Grupo 210 de Datos para aplicarlos a la Plantilla 2704 de Página Web y a los grupos de páginas web virtuales basándose en la URL enviada por un usuario. El Enrutador 3310 Basado en Software identifica la Plantilla 2704 de Página Web basándose en un prefijo URL. El Enrutador 3310 Basado en Software puede identificar elementos de datos en el Grupo 210 de Datos para ser aplicados a la Plantilla 2704 de Página Web para generar páginas web virtuales basadas en elementos URL (por ejemplo, componentes de sufijo, segmentos de texto o valores de parámetros) siguiendo el prefijo URL. En algunas realizaciones, el prefijo URL "prefix1" identifica el Enrutador 3310 Basado en Software para la Plantilla 2704 de Página Web. El Enrutador 3310 Basado en Software puede generar las Páginas 3111 y 3312 Web Virtuales basándose en el valor del sufijo "label1" y "label2" respectivamente. El Enrutador 3310 Basado en Software puede generar un mapa del sitio Prefijo 1 Mapa 3313 del Sitio que enumera las posibles URL de todas las páginas web virtuales que pueden generarse utilizando la Plantilla 2704 de Página Web y el Grupo 210 de Datos asociado, así como otros grupos de datos. El Prefijo 1 Mapa 3313 del Sitio puede ayudar en la indexación de las Páginas Web Virtuales 3111 y 3312 por parte del Motor 170 de Búsqueda.
La FIG. 34 es el diagrama 3400 de flujo que muestra los pasos implicados en la generación y visualización previa de páginas web virtuales, de acuerdo con algunas realizaciones de la presente divulgación. El diagrama 3400 de flujo representa los pasos que pueden realizarse en las realizaciones del sistema descritas anteriormente.
Como se muestra en la FIG. 34, en el Paso 3410, un Sistema 3000 de Vista Previa Dinámica puede almacenar elementos de datos en la Base 124 de Datos del Área de Sitio. Como ya se ha comentado, los elementos de datos pueden adoptar formas muy diversas, tales como texto, imágenes, vídeos, fondos, así como registros consistentes en una combinación de cualquiera de estos tipos de objetos.
En el Paso 3420, el Sistema 3000 de Vista Previa Dinámica puede almacenar instrucciones que permitan la organización de los elementos de datos almacenados en grupos de datos. Por ejemplo, los grupos pueden definirse en bases de datos. Además, los grupos pueden definirse por las relaciones entre los elementos del grupo, o por los campos de los elementos de datos cuyos valores dependen de otros campos. De acuerdo con las realizaciones anteriores, los grupos de datos pueden definirse antes de que se definan los elementos visuales, los campos o las páginas web específicas.
En el Paso 3430, el Sistema 3000 de Vista Previa Dinámica puede proporcionar instrucciones adicionales al navegador web que muestra la Interfaz 243 de Editor En Línea para permitir la adición de elementos de datos adicionales a grupos de datos previamente creados en la Base 124 de Datos del Área de Sitio. De este modo, los grupos existentes pueden completarse o editarse para contener elementos diferentes o adicionales. Un usuario puede repetir el Paso 3420 y puede volver en cualquier momento para añadir más elementos de datos. Del mismo modo, este paso puede incluir instrucciones para realizar operaciones adicionales en los elementos de datos, tal como la eliminación y la actualización. Por ejemplo, un usuario puede alternar entre los Pasos 3410, 3420 y 3430, o proceder al Paso 3430.
En el Paso 3440, el Sistema 3000 de Vista Previa Dinámica puede ejecutar instrucciones para ayudar a asociar elementos de datos previamente insertados de grupos de datos almacenados en la Base 124 de Datos del Área de Sitio a la página web que está siendo editada en la Interfaz 243 de Editor En Línea. Un usuario puede repetir el Paso 3420 y puede volver en cualquier momento para crear más asociaciones entre las páginas web del sitio web que se está construyendo y los elementos de datos organizados como grupos de datos almacenados en la Base 124 de Datos del Área de Sitio.
En el Paso 3450, el Sistema 3000 de Vista Previa Dinámica proporciona instrucciones para ayudar a asociar grupos de elementos de datos con las páginas web de un sitio web. Esto puede implicar, como se ha comentado anteriormente, vincular los campos de un formulario entre sí tanto para activar/desactivar como para filtrar los valores potenciales permitidos para un campo (por ejemplo, un formulario para rellenar la dirección puede listar en el campo de la ciudad valores que dependen de la selección en el campo del estado).
En el Paso 3460, el Sistema 3000 de Previsualización Dinámica proporciona instrucciones a la Interfaz 3000 de Editor En Línea para permitir la visualización previa de páginas web de un sitio web que se está construyendo en la Interfaz 243 de Editor En Línea. Las vistas previas pueden permitir la edición del usuario en tiempo real, como se ha comentado anteriormente.
Un usuario puede repetir los Pasos 3430, 3440, 3450, 3460 cualquier número de veces y repetirlos en cualquier orden.
La FIG. 35 es un diagrama esquemático de usuarios interactuando con un Sistema 3500 de Alojamiento de Sitios Web, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 35, el Sistema 3500 de Alojamiento de Sitios Web incluye el Servidor 3510 de Alojamiento, que incluye uno o más sistemas para construir y visualizar sitios web, el Servidor 3520 de Complemento de Funciones que ejecuta el código de los complementos de funciones, el Procesador 260, la Memoria 820 que almacena los componentes y el código de los complementos de funciones, una Interfaz 3570 para desarrollar y cargar el código de los complementos de funciones y otros componentes.
El Servidor 3510 de Alojamiento puede ser uno o más servidores que alojen sitios 3511, 3512 y 3513 web coalojados. El Servidor 3510 de Alojamiento puede ser una instancia de ejecución de un servidor web en el Sistema 800 Bajo Demanda, por ejemplo, o en otro tipo de sistema de alojamiento de sitios web. En algunas realizaciones, el Servidor 3510 de Alojamiento puede ser múltiples instancias de ejecución del servidor web en el Sistema 800 Bajo Demanda. El Servidor 3510 de Alojamiento también puede ser el WBS 100 que almacena los sitios web editados y a los que acceden el Desarrollador/Diseñador 1540 y el Usuario 1530 Final, como se ha comentado anteriormente.
Las Herramientas 411 de Edición, como se discutió anteriormente, son herramientas comunes para editar un sitio web compartido por sitios web alojados por el Servidor 3510 de Alojamiento. En algunas realizaciones, las Herramientas 411 de Edición pueden compartirse a través de múltiples Servidores 3510 de Alojamiento que alojen Sitios 3511-3513 Web coalojados.
El Servidor 3520 de Complemento de Funciones puede ser uno o más servidores ejecutando código de complemento de funciones en un Entorno 3521 de Aislamiento. En algunas realizaciones, el Servidor 3520 de Complementos de Funciones utiliza la misma infraestructura que el Servidor 3510 de Alojamiento (que pueden ser servidores físicos o instancias de ejecución de servidores web, como se ha indicado anteriormente). El Complemento 3530 de Funciones está presente en la memoria 820 y es visible o accesible a través de una Interfaz 3531 de Usuario, Código 3532 de Complemento de Funciones de Interfaz de Usuario, y Código 3533 de Complemento de Funciones de Interfaz del Sistema.
Los Usuarios 3540-3560 pueden acceder a las Herramientas 411 de Edición desde el Servidor 3510 de Alojamiento para editar las Páginas 3511-3513 Web respectivamente. En algunas realizaciones, por ejemplo, el Sitio 3511 Web que está siendo editado por el Usuario 3540 puede incluir un Complemento 3530 de Funciones. Por ejemplo, el Sitio 3511 Web puede reproducir vídeo a través de un Complemento 3530 de Funciones de reproductor de vídeo cuando se accede al Sitio 3511 Web utilizando el Navegador 131 Web en el Dispositivo 130 de Visualización Web. El Usuario 3540 puede modificar el Sitio 3511 Web editando y cargando el código del complemento de funciones a través de la Interfaz 3570. En algunas realizaciones, la Interfaz 3570 puede ser parte de las Herramientas 411 de Edición.
Los Usuarios 3540-3560 interactúan con los Sitios 3511-13 Web en el Servidor 3510 de Alojamiento a través de la Plataforma 3580 Compartida. La Plataforma 3580 Compartida permite a grupos de usuarios editar grupos de sitios web. La Plataforma 3580 Compartida puede estar configurada mediante software para determinar qué grupos de Usuarios 3540-3560 tienen acceso a editar qué Sitios 3511-13 Web. En algunas realizaciones, el Servidor 3510 de Alojamiento que aloja múltiples Sitios 3511-13 Web puede actuar como Plataforma 3580 Compartida.
El Usuario 1530 Final que visualiza el Sitio 3511 Web utilizando el Navegador 131 Web en el Dispositivo 130 de Visualización Web puede incluir la Interfaz 3531 de Usuario del Complemento 3530 de Funciones. Por ejemplo, el Complemento 3530 de Funciones puede ser un reproductor de vídeo y la Interfaz 3531 de Usuario puede incluir botones de control de reproducción estilizados para el Complemento 3530 de Funciones de reproductor de vídeo. El Código 3532 de Complemento de Funciones de Interfaz de Usuario también puede transmitirse a través de la Interfaz 3531 de Usuario cuando el Usuario 3540 Final accede a un sitio web. El Usuario 1530 Final interactuando con la Interfaz 3531 de Usuario del Complemento 3530 de Funciones puede resultar en que el Código 3532 de Complementos de Funciones de Interfaz de Usuario del Complemento 3530 de Funciones se ejecute en el Navegador 131 Web. En algunas realizaciones, la interacción del Usuario 1530 Final con el Sitio 3511 Web también puede resultar en la ejecución del Código 3533 de Complemento de Funciones de Interfaz del Sistema en el Servidor 3520 de Complemento de Funciones. Por ejemplo, si el Usuario 3540 Final hace clic en los controles de reproducción de un complemento de reproductor de vídeo, el Código 3532 de Complemento de Funciones de Interfaz de Usuario se ejecuta y realiza una solicitud para transmitir el vídeo, y el Código 3533 de Complemento de Funciones de Interfaz del Sistema puede comprimir el vídeo en función de la disponibilidad de ancho de banda de la red.
La FIG. 36 representa una técnica de acceso controlado a sitios web coalojados, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 36, los usuarios 3540, 3550 se agrupan y se les permite el acceso a los Sitios 3511 y 3512 Web Coalojados 1. Los usuarios 3621 y 3622 pueden tener acceso a los Sitios 3611 y 3612 Web Coalojados 2. Los usuarios pueden acceder a uno o más sitios web coalojados, pero no pueden acceder a sitios web que no formen parte del grupo permitido. Los usuarios pueden tener sus derechos de acceso definidos, por ejemplo, en función de si son propietarios de determinadas páginas web, si son usuarios registrados, si se han autentificado, etc.
La FIG. 37 muestra grupos de sitios web coalojados que comparten código de complemento de funciones bajo rutas comunes, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 37, el Sistema 3500 de Alojamiento Web tiene dos conjuntos de sitios web coalojados, difiriendo cada conjunto del otro por una ruta URL. Por ejemplo, los Sitios 3711 Web Coalojados de la Ruta Común 1 pueden compartir el dominio www.a.com y los Sitios 3731 Web Coalojados de la Ruta Común 2 pueden compartir el dominio www.b.com. Alternativamente, los Sitios 3711 Web Coalojados de Ruta Común 1 pueden tener un subdominio común a.wixsite.com y los Sitios 3731 Web Coalojados de la Ruta Común 2 pueden tener un subdominio común b.wixsite.com. Los sitios web con rutas comunes pueden alojarse conjuntamente en un servidor o entorno de alojamiento para crear un entorno de aislamiento y eliminar la interacción con otros conjuntos de sitios web alojados conjuntamente. Los sitios web coalojados también pueden tener diferentes servidores de complementos de funciones para crear entornos aislados para la ejecución del código del complemento de funciones. Los Sitios 3711 Web Coalojados de Ruta Común 1 y los Sitios 3731 Web Coalojados de la Ruta Común 2 pueden seguir compartiendo el mismo Procesador 260 y Memoria 820 o tener procesadores y memoria diferentes. La FIG. 38 muestra entornos de ejecución aislados del Código 3533 de Complemento de Funciones de Interfaz del Sistema, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 38, el Código 3533 de Complemento de Funciones de Interfaz del Usuario del Entorno de Aislamiento del Complemento 3530 de Funciones puede basarse en un Contenedor (por ejemplo, Docker) 3810 o una Máquina 3820 Virtual o un Procedimiento 3830 de Sistema Operativo. En algunas realizaciones, el Entorno 3521 de Aislamiento puede incluir uno o más de Contenedor 3810, Máquina 3820 Virtual, y Procedimiento 3830 de Sistema Operativo (por ejemplo, código sin servidor), cada uno ejecutando el Código 3533 de Interfaz del Sistema de Complemento de Funciones separado. En algunas realizaciones, un servidor de complementos de funciones que aloja el Complemento 3530 de Funciones puede incluir múltiples entornos de aislamiento.
La FIG. 39 representa un acceso controlado y ejecución del Código 3532 de Complemento de Funciones de Interfaz de Usuario, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 39, el acceso al Sitio 3511 Web puede dar lugar al acceso al Código 3532 de Complemento 1 de Funciones de Interfaz de Usuario del Complemento 3530 de Funciones y al Código 3931 de Complemento 2 de Funciones de Interfaz de Usuario de otro complemento de funciones. El Sitio 3511 Web puede asegurarse de ejecutar cada uno de los complementos de funciones en SubRegiones 3910 y 3930 separadas respectivamente. El Sistema 3500 de Alojamiento de Sitios Web también puede crear un canal de comunicación seguro (por ejemplo, SSL, túnel seguro, etc.) para permitir que sólo se pueda acceder a ciertas otras subregiones del sitio web. El canal de comunicación seguro puede restringir el acceso de un complemento de funciones de interfaz de usuario a otras subregiones del sitio web. Por ejemplo, el Código 3532 de Complemento 1 de Funciones de Interfaz de Usuario ejecutándose en la SubRegión 3910 puede comunicarse con otra SubRegión 3920 pero se le puede negar el acceso a la SubRegión 3940. Las subregiones accesibles de un complemento de funciones pueden enumerarse en forma de tabla, en un registro de confianza, en un archivo de configuración o en una base de datos segura. Por ejemplo, en un arreglo basado en computación en nube, una plataforma orquestadora de nube puede mantener una lista o mapeo de recursos de computación virtual (por ejemplo, SubRegión 3910, SubRegión 3920, SubRegión 3940, etc.) y puede definir sus permisos de conexión. Dicha lista o asignación puede permitir conexiones o acciones específicas por parte de la Subregión 3910, la Subregión 3920 y la Subregión 3940 y denegar otras conexiones o acciones. En algunas realizaciones, el canal de comunicación seguro se proporciona permitiendo que todas las comunicaciones pasen a través de uno o más concentradores (por ejemplo, un concentrador que realiza verificaciones de autenticación o autorización). Dichos concentradores pueden ser, por ejemplo, residentes en un cliente del sistema, en un servidor del sistema o en ambos. También se puede establecer una comunicación segura verificando el identificador único de la subregión de origen de la comunicación. Por ejemplo, se puede utilizar una llamada al método getId() para identificar el id de subregión de origen de un mensaje de comunicación y determinar si está en la lista o asignación permitida.
La FIG. 40 representa la ejecución aislada del código del complemento de funciones en el lado del cliente, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 40, el acceso al Sitio 3511 Web mediante el Navegador 131 Web por parte de un Usuario 1530 Final puede dar lugar al acceso al Código 3532 de Complemento de Funciones de Interfaz de Usuario del Complemento 3530 de Funciones. El acceso del Usuario 1530 Final puede resultar en la creación de un Iframe para ejecutar el Código 3532 de Complemento de Funciones de Interfaz de Usuario de forma aislada. En algunas realizaciones, el Código 3532 de Complemento de Funciones de Interfaz de Usuario puede copiarse en diferentes Subregiones 3712-3713 del Sitio 3511 Web para su ejecución aislada. Por ejemplo, el Sitio 3511 Web puede mostrar múltiples Reproductores de Video, cada uno transmitiendo diferentes flujos de video, pero usando el mismo código de complemento de funciones. En algunas realizaciones, el Código 3532-3533 de Complemento de Funciones ejecutándose en un Iframe puede no tener acceso a cookies del lado del cliente (por ejemplo, cookies HTTP).
La FIG. 41 es un diagrama de flujo que muestra los pasos implicados en el acceso y la ejecución del código del sitio web y del complemento de funciones, de acuerdo con algunas realizaciones de la presente divulgación. Como se muestra en la FIG. 41, en el paso 4110, el Sistema 3500 de Alojamiento de Sitios Web aloja sitios web que comparten uno o más elementos de datos, plantillas, porciones de código, rutas u otras funcionalidades comunes en un servidor o conjunto de servidores alojados comunes. Los servidores también pueden alojarse conjuntamente en función de la propiedad o de los privilegios administrativos y de edición de la pluralidad de usuarios. Por ejemplo, el Sistema 3500 de Alojamiento de Sitios Web puede alojar sitios web creados y gestionados por varias entidades o personas independientes y no afiliadas.
En el Paso 4120, el Sistema 3500 de Alojamiento de Sitios Web proporciona acceso a las Herramientas 411 de Edición para editar aún más los sitios web coalojados por el sistema. Como se ha comentado anteriormente, las Herramientas 411 de Edición pueden permitir al usuario editar numerosos aspectos de las páginas web.
En el paso 4130, un esfuerzo por parte de un usuario para acceder a un sitio web con fines de edición da lugar a que el Sistema 3500 de Alojamiento Web evalúe si el usuario que realiza la solicitud tiene acceso o privilegios para editar el sitio web. La evaluación puede depender de la titularidad de un determinado sitio web. En algunas realizaciones, el propietario o administrador de un sitio web puede proporcionar acceso de administración y/o edición a otros usuarios mediante las Herramientas 411 de Edición. Además, en algunas realizaciones, los derechos de edición pueden depender de si el usuario es un usuario registrado o se ha autenticado para acceder al Sistema 3500 de Alojamiento Web.
Si la respuesta al Paso 4130 es no, el acceso solicitado al sitio web es denegado y el usuario puede necesitar solicitar privilegios de edición al administrador del sitio web. El procedimiento 4100 se considera finalizado al no obtener acceso para editar el sitio web. Alternativamente, el procedimiento 4100 puede volver al Paso 4120 o 4130.
Si la respuesta al Paso 4130 es afirmativa, el procedimiento 4110 procede al Paso 4150. En el Paso 4150, se presenta una interfaz para cargar el complemento de funciones al usuario que solicita acceso para editar un sitio web. La interfaz puede ser similar a las comentadas anteriormente para que los usuarios editen el código de la interfaz de usuario o de la interfaz del sistema.
En el Paso 4160 el Sistema 3500 de Alojamiento de Sitios Web recibe los cambios del complemento de funciones y los almacena. Un complemento de funciones cargado por el usuario puede, por ejemplo, incluir ediciones al Código 3533 de Complemento de Funciones de Interfaz del Sistema del Complemento 3530 de Funciones. En algunas realizaciones, las ediciones del usuario pueden incluir ediciones al del Complemento 3530 de Funciones. Alternativamente, un usuario también puede editar la Interfaz 3531 de Usuario del Complemento 3530 de Funciones. En algunas realizaciones, un usuario puede editar toda la Interfaz 3531 de Usuario, el Código 3532 de Complemento de Funciones de Interfaz de Usuario, y el Código 3533 de Complemento de Funciones de Interfaz del Sistema.
Un usuario que edita código de complemento de funciones (por ejemplo, Código 3532 de Complemento de Funciones de Interfaz de Usuario o Código 3533 de Complemento de Funciones de Interfaz del Sistema) puede editar código de complemento de funciones a lo largo de múltiples sesiones resultando en la resolicitud de los Pasos 4120 a 4160, así como menos pasos o pasos adicionales.
En el Paso 4170, el Sistema 3500 de Alojamiento Web ejecuta el Complemento 3530 de Funciones cuando el Sitio 3511 Web es accedido por un usuario (por ejemplo, el Usuario 1530, 3540, 3550, 3560 Final). La ejecución del código del complemento de funciones incluye la creación de un Entorno 3521 de Aislamiento para ejecutar el código. El Entorno 3521 de Aislamiento puede incluir aislamiento en el lado del cliente en un navegador web y en el lado del servidor para ejecutar Interfaz 3532 de Usuario y Código 3530 de Complemento de Funciones de Interfaz 3533 de Sistema respectivamente.
La FIG. 42 es un ejemplo de interfaz de usuario para editar una página web y crear una colección de bases de datos, de acuerdo con algunas realizaciones de la presente divulgación. Por ejemplo, la página web puede ser generada a través de un sistema de desarrollo de páginas web, tal como el proporcionado por WIX.COM. Como se ilustra, se puede crear una base de datos que soporte una o más páginas web dinámicas.
Una Barra 4202 Lateral de Estructura del Sitio puede incluir diversas opciones para editar y configurar el sitio web, tal como un listado de diferentes páginas (por ejemplo, INICIO, ACADEMICOS, EVENTOS, EXPOSICIONES, ÁREA ESTUDIANTIL, Cursos por Titulación, y NOTICIAS), así como opciones para características Públicas, funcionalidad de Interfaz del Sistema, y funcionalidad de Base de Datos. Además, una barra 4204 de herramientas puede incluir diversas opciones para añadir y editar contenido en las páginas web.
Como se ilustra, la interfaz 4206 permite a un usuario configurar una base de datos. La interfaz 4206 puede generarse, por ejemplo, si un usuario selecciona la opción "Base de datos" de la Barra 4202 Lateral de Estructura del Sitio. El usuario puede personalizar la base de datos dándole un nombre único en el campo 4208. En este ejemplo, la base de datos puede denominarse base de datos de "cursos".
La FIG. 43 es un ejemplo de interfaz de usuario para editar una página web y configurar permisos para una colección de bases de datos, de acuerdo con algunas realizaciones de la presente divulgación. Por ejemplo, continuando con el ejemplo anterior, un usuario que crea una base de datos de "cursos" puede acceder a diversas opciones de permisos 4310 diferentes para la base de datos y las correspondientes páginas dinámicas que pueden basarse en ella. Los permisos 4310 pueden referirse al contenido de las páginas web, a la introducción de datos en los formularios, al contenido generado por los usuarios de la página, al contenido restringido a los miembros registrados, a los formularios que sólo los miembros registrados pueden rellenar y a ciertos datos privados a los que sólo pueden acceder determinados usuarios (por ejemplo, los administradores).
La FIG. 44 es un ejemplo de interfaz de usuario para editar una página web y entradas en una colección de bases de datos, de acuerdo con algunas realizaciones de la presente divulgación. Por ejemplo, la base de datos de "cursos" puede estar compuesta por los campos 4412 (Título), 4414 (Descripción), 4416 (Imagen), 4418 (Profesores), y otros. Estos campos pueden incluir información sobre cursos que puede extraerse de la base de datos e incluirse en páginas web dinámicas específicas. En particular, los campos pueden contener contenido textual (por ejemplo, los campos 4412, 4414 y 4418), así como otros contenidos, como imágenes o vídeos (por ejemplo, el campo 4316). Tal como se ilustra, el campo 4416 incluye una imagen correspondiente al curso alicatado TING. En algunas realizaciones, un usuario puede definir además el tipo o diseño de cada página web dinámica y especificar una URL para cada página dinámica. Por ejemplo, los sufijos de la URL pueden corresponder a columnas de la base de datos (por ejemplo, Título).
La FIG. 45 es un ejemplo de interfaz de usuario para editar una página web y mostrar resultados de una colección de bases de datos, de acuerdo con algunas realizaciones de la presente divulgación. Por ejemplo, en una página web dinámica que se haya creado, puede incluirse contenido de la base de datos. Como se ilustra, el contenido 4520 incluye una descripción de un curso de la base de datos. El contenido 4520 se extrae automáticamente de la base de datos sin que el usuario tenga que copiarlo manualmente en la página web. Con esta técnica se pueden crear numerosas páginas dinámicas, cada una de las cuales enlaza con una porción diferente de la base de datos y tiene una disposición única del contenido en función de su enlace a la base de datos.
Las FIG. 46 es un ejemplo de interfaz de usuario para editar una página web y crear una función repetidora, de acuerdo con algunas realizaciones de la presente divulgación. Como se ha descrito anteriormente, se puede añadir una función de resolicitud a un sitio web o página para crear dos o más instancias de elementos (por ejemplo, combinaciones de texto e imágenes) que sean similares en estructura o diseño. Utilizando un repetidor, pueden crearse dos o más instancias de elementos que difieran al menos en un aspecto (por ejemplo, que tengan texto, imágenes, etc. diferentes).
Como se muestra, un usuario puede acceder a un menú de Repetidores 4622 para configurar un repetidor. Por ejemplo, utilizando la barra 4204 de herramientas, un usuario puede seleccionar la opción Listas y Cuadrículas, que permite la creación de repetidores y otros elementos que muestran múltiples objetos. Para rellenar las instancias del repetidor con contenido, un usuario puede vincular el repetidor o instancias individuales a conjuntos de datos, como datos almacenados en una base de datos. En algunas realizaciones, un usuario puede decidir añadir un elemento a cada una de las instancias de forma idéntica. Al añadir el elemento a una instancia, puede añadirse automáticamente a cada instancia. Alternativamente, un usuario puede desear especificar (por ejemplo, a través de código interfaz del sistema o interfaz de usuario) que cada instancia creada por un repetidor debe tener un contenido diferente.
Las FIG. 47 es un ejemplo de interfaz de usuario para editar una página web y mostrar el resultado de una función de resolicitud, de acuerdo con algunas realizaciones de la presente divulgación. Como se ilustra, un usuario ha creado tres combinaciones de elementos 4724 a través de un repetidor. Cada combinación 4247 tiene una estructura similar de una imagen, texto (nombre del lugar), texto (descripción) y un icono de hipervínculo "Leer más". En el modo de edición, el usuario puede modificar aún más el diseño y la apariencia de estas instancias, por ejemplo, cambiando la posición de la imagen con respecto a los elementos de texto, cambiando el hipervínculo, redimensionando los campos, etc. Además, como se ha comentado anteriormente, cada elemento de las instancias puede conectarse a una parte diferente de una base de datos. Por ejemplo, las tres combinaciones de elementos 4724 pueden enlazar cada una a una columna diferente de una base de datos correspondiente al contenido que cada una de ellas debe extraer de la base de datos. De este modo, aunque las tres combinaciones de elementos 4724 tienen un diseño común, cada una tiene un contenido textual o gráfico diferente.
En el presente documento se describen diversas operaciones o funciones, que pueden implementarse o definirse como código o instrucciones de software. Dicho contenido puede ser directamente ejecutable ("objeto" o forma "ejecutable"), código fuente o código de diferencias ("delta" o código "parche"). Las implementaciones de software de las realizaciones descritas en el presente documento pueden proporcionarse a través de un artículo de fabricación con el código o las instrucciones almacenadas en el mismo, o a través de un método de funcionamiento de una interfaz de comunicación para enviar datos a través de la interfaz de comunicación. Una máquina o medio de almacenamiento legible por ordenador puede hacer que una máquina realice las funciones u operaciones descritas e incluye cualquier mecanismo que almacene información en una forma accesible por una máquina (por ejemplo, dispositivo informático, sistema electrónico y similares), tal como medios grabables/no grabables (por ejemplo, memoria de sólo lectura (ROM), memoria de acceso aleatorio (RAM), medios de almacenamiento en disco magnético, medios de almacenamiento óptico, dispositivos de memoria flash y similares). Una interfaz de comunicación incluye cualquier mecanismo que interactúe con un medio cableado, inalámbrico, óptico, etc., para comunicarse con otro dispositivo, como una interfaz de bus de memoria, una interfaz de bus de procesador, una conexión a Internet, un controlador de disco, etc. La interfaz de comunicación puede configurarse proporcionando parámetros de configuración y/o enviando señales para preparar la interfaz de comunicación para proporcionar una señal de datos que describa el contenido del software. Se puede acceder a la interfaz de comunicación mediante uno o más comandos o señales enviados a la interfaz de comunicación.
La presente divulgación también se refiere a un sistema para realizar las operaciones descritas en el presente documento. Este sistema puede estar especialmente construido para los fines requeridos, o puede comprender un ordenador de propósito general activado o reconfigurado selectivamente por un programa informático almacenado en el ordenador. Dicho programa informático puede almacenarse en un medio de almacenamiento legible por ordenador, tal como, por ejemplo, aunque no exclusivamente, cualquier tipo de disco, incluyendo disquetes, discos ópticos, CDROM y discos magneto-ópticos, memorias de sólo lectura (ROM), memorias de acceso aleatorio (RAM), EPROM, EEPROM, tarjetas magnéticas u ópticas, o cualquier tipo de medio adecuado para almacenar instrucciones electrónicas, cada uno de ellos acoplado a un bus de sistema informático.
Las realizaciones de la presente divulgación pueden implementarse con instrucciones ejecutables por ordenador. Las instrucciones ejecutables por ordenador pueden organizarse en uno o más componentes o módulos ejecutables por ordenador. Los aspectos de la divulgación pueden implementarse con cualquier número y organización de dichos componentes o módulos. Por ejemplo, los aspectos de la divulgación no se limitan a las instrucciones específicas ejecutables por ordenador o a los componentes o módulos específicos ilustrados en las figuras y descritos en el presente documento. Otras realizaciones pueden incluir diferentes instrucciones ejecutables por ordenador o componentes con más o menos funcionalidad que la ilustrada y descrita en el presente documento.
Los programas informáticos basados en la descripción escrita y los métodos de esta memoria descriptiva están dentro de la habilidad de un desarrollador de software. Los distintos programas o módulos de programa pueden crearse utilizando diversas técnicas de programación. Por ejemplo, las secciones del programa o los módulos del programa pueden diseñarse mediante JavaScript, Scala, python, Java, C, C++, lenguaje ensamblador o cualquiera de estos lenguajes de programación, así como lenguajes de codificación de datos (tal como XML, JSON, etc.), lenguajes de consulta (tal como SQL), lenguajes relacionados con la presentación (tal como HTML, CSS, etc.) y lenguaje de transformación de datos (tal como XSL). Una o más de estas secciones o módulos de software pueden integrarse en un sistema informático, un medio legible por ordenador no transitorio o un software de comunicaciones existente.
Las palabras "que comprenda", "que tenga", "que contenga", "que incluya" y otras formas similares pretenden ser equivalentes en significado e interpretarse como abiertas, en el sentido de que un elemento o elementos que sigan a cualquiera de estas palabras no pretenden ser una enumeración exhaustiva de dicho elemento o elementos, ni limitarse únicamente al elemento o elementos enumerados. Además, las formas singulares "un", "una" y "el/la" pretenden incluir referencias en plural, a menos que el contexto indique claramente lo contrario.
Antecedentes técnicos Instancias de Ejecución de Servidores Web a Solicitud para Sistemas de Alojamiento y Creación de Sitios Web
Contenido
Sitios web y arquitectura de servidores sin estado 1
El sistema inventivo 2
Escenarios de uso en sistemas anteriores y en el sistema inventivo 3
Utilización del sistema inventivo en un contexto EDT 5
Acrónimos en uso 6
Sitios web y arquitectura de servidores sin estado
1. Cuando el usuario interactúa con un sitio web, normalmente lo hace la mayor parte del tiempo con las páginas del lado del cliente, la aplicación web y el código FE que se ejecuta en la máquina cliente / navegador - en lugar de interactuar con cualquier código BE o servidor web. Sin embargo, este sitio web / aplicación del lado del cliente seguiría haciendo múltiples solicitudes HTTP (u otras) al servidor. Estos pueden incluir, por ejemplo:
1.1. Una solicitud HTTP inicial realizada para cargar la página - que podría desencadenar solicitudes HTTP adicionales para cargar elementos adicionales de la página (tales como imágenes y secuencias de comando incluidas).
1.2. Solicitudes HTTP a mitad de sesión. Por ejemplo, al seleccionar un valor para un campo, la página puede realizar una solicitud HTTP para recuperar un conjunto de posibles valores para el campo dado.
1.3. Solicitudes HTTP relacionadas con datos, tal como el envío de un formulario cumplimentado por el usuario.
1.4. Solicitudes HTTP relacionadas con BE que activan la funcionalidad BE - que pueden ser realizadas por el sistema que sirve el sitio web o utilizando servicios web externos (terceros).
2. "Servidor" en este contexto puede referirse a servidores físicos reales, pero también puede referirse a otras instancias de ejecución de servidores web, tal como VM y contenedores (también conocidos como Dockers). Las solicitudes HTTP, tal y como se tratan a lo largo de este documento, también pueden referirse a solicitudes HTTPS o a cualquier otra solicitud de red.
3. Los usuarios esperan que el sistema (cliente servidor medio de comunicación) responda muy rápidamente, desde la solicitud hasta la recepción de la respuesta inicial. El tiempo de respuesta suele medirse como "tiempo del servidor desde la recepción de la solicitud hasta el envío del primer byte de respuesta" (normalmente se espera que sea de 100 ms o menos). La medición del tiempo en el servidor se utiliza para no tener en cuenta el tiempo de transporte de la red, muy variable.
4. En realidad, completar la respuesta puede llevar un tiempo adicional considerable. Por ejemplo, al cargar una página nueva, el usuario espera que la página empiece a aparecer en su navegador muy rápidamente, pero la carga de la página puede llevar un tiempo adicional considerable, y el usuario también puede empezar a interactuar con la página, aunque no esté completamente cargada.
5. El sistema servidor (normalmente compuesto por múltiples servidores o granjas de servidores) podría responder a estos utilizando un sistema/protocolo sin estado o con estado. Tenga en cuenta que el protocolo HTTP esta sin estado por naturaleza, pero el uso del servidor con estado puede implementarse utilizando técnicas fuera del protocolo (tal como la reescritura de URL o los campos de formulario ocultos).
6. Un sistema con estado se utiliza normalmente cuando un cliente interactúa con un servidor preasignado. Un servidor de este tipo podría proporcionar un contexto de sesión continuo, pero el arreglo es muy difícil de ampliar, ya que los servidores tienen que estar continuamente asociados a (uno o más) usuarios, y pueden permanecer inactivos o parcialmente inactivos, esperando a que llegue la siguiente solicitud HTTP.
7. En un sistema sin estado, cada solicitud HTTP -incluso de una sola página- puede ser servida por un servidor diferente (o instancia de ejecución del servidor). El usuario no es consciente de que "salta" entre diferentes servidores para diferentes solicitudes HTTP, y estos diferentes servidores pueden acceder de forma transparente a recursos externos necesarios para la respuesta (tal como servidores de bases de datos).
8. Un sistema sin estado, es decir, que utilice servidores sin estado, tiene muchas ventajas. En concreto, el sistema es altamente escalable, ya que cualquier solicitud entrante puede dirigirse a cualquier servidor (sin estado) del sistema, y no hay necesidad de tener un tratamiento especial para las conexiones rotas.
9. Como los (múltiples) servidores sin estado del sistema existente deben ser completamente intercambiables, no pueden adaptarse al sitio o página web concretos de que se trate. Por tanto, esta disposición es adecuada para sitios web sencillos y estáticos. Esta disposición no puede funcionar bien cuando se sirven sitios web complejos que requieren código BE específico del sitio (posiblemente incluyendo código proporcionado por el usuario), componentes específicos del sitio o complementos de funciones específicos del sitio.
El sistema inventivo
10. Como se describe en el presente documento, el sistema inventivo implica el arranque rápido de contenedores Docker (o instancias de ejecución del servidor web) que ejecutan una instancia de servidor web configurada para un sitio específico (incluyendo los complementos de funciones específicos y el código proporcionado por el usuario del lado del servidor para este sitio), y hacerlo lo suficientemente rápido como para responder a una solicitud HTTP sin tiempo de espera, y en un plazo total aceptable para los usuarios.
11. Arrancar una nueva máquina virtual suele llevar unosminutos. Iniciar un nuevo contenedor Docker sigue tardando 2-3 segundos. Ambos tiempos no son aceptables.
12. En los sistemas divulgados, se puede proporcionar un grupo de contenedores de reserva que contengan todo el código relevante no específico del sitio, pero sin ningún código específico del usuario/sitio.
13. El sistema puede escuchar en un puerto activo una solicitud para conectarse a un servidor para el sitio web específico. Si hay un contenedor activo asociado con el sitio web específico, el sistema puede conectarse a él. De lo contrario, puede utilizar un contenedor en espera del grupo e inyectar allí el contenido específico del sitio solicitado, o indicarle que cargue dicho contenido. Una vez cargado el contenido específico de un sitio determinado, el contenedor se une a un grupo de contenedores asociados a dicho sitio.
14. Tenga en cuenta que una instancia de contenedor sin estado de este tipo puede servir una solicitud HTTP específica (por ejemplo, que implique la verificación de datos) sin ser la que gestionó la solicitud HTTP original de carga de la página.
15. El contenido inyectado a nivel de sitio puede o no incluir las páginas reales del sitio. Dicha información de la página web puede ser, por ejemplo:
15.1. Material real de la página listo para el navegador (por ejemplo, una colección de código HTML, CSS y JS).
15.2. Datos subyacentes de definición del sitio (por ejemplo, mediante archivos XML o expresiones JSON) que se convierten en material listo para el navegador mediante código del lado del cliente o del servidor (tal como un módulo visor de EDT).
15.3. Código interfaz de usuario / interfaz del sistema, por ejemplo, código JavaScript invocado por la página para ejecutarse en el cliente, en el servidor o en ambos.
16. El sistema puede soltar contenedores de reserva si un sitio no ha estado activo durante un periodo determinado (tal como 15 minutos).
17. Con el fin de preservar el estado del usuario, y mantener la sensación de que está trabajando dentro de una única sesión (teniendo un contexto continuo) el contexto persistente se mantiene utilizando una combinación de almacenamiento del lado del cliente (por ejemplo, almacenamiento local del navegador, cookies,...) y almacenamiento del lado del servidor (por ejemplo, guardando en DB's del servidor).
Escenarios de uso en sistemas anteriores y en el sistema inventivo
18. Supongamos el siguiente escenario de uso típico:
18.1. El usuario introduce una URL en su navegador, solicitando que se cargue una página. La página cargada contiene un formulario de introducción de datos y una cantidad considerable de código f E y BE asociado (específico del nivel del sitio). Se realiza una solicitud HTTP al servidor para obtener la página y su código FE asociado a nivel de sitio, mientras que el código BE debe cargarse en el servidor, pero no enviarse al cliente. El sitio también emplea una serie de componentes (como widgets de visualización) que tienen su propio código Ul, FE y BE.
18.2. El usuario rellena el formulario en un lapso de 10 minutos, generalmente trabajando localmente con el navegador ejecutando una página local con una etiqueta HTML <form>. Esto también se puede hacer usando llamadas Ajax o llamadas Fetch, o cualquier configuración JavaScript o HTML que pueda iniciar una solicitud HTTP.
18.3. El formulario puede realizar algunas solicitudes durante este procedimiento (por ejemplo, obtener listas de valores permitidos de una DB para un campo determinado) que se envían a un servidor. Cada una de estas solicitudes activa una secuencia de comando de BE del lado del servidor que realiza el acceso real a la DB y la recopilación de información (por ejemplo, para evitar enviar las credenciales de acceso a la DB en el código al cliente). Dichas solicitudes pueden implementarse como solicitudes HTTP o utilizando un mecanismo diferente.
18.4. Cuando el usuario envía el formulario, éste es verificado por una secuencia de comando FE. A continuación, el formulario se envía al servidor y activa un procedimiento del servidor que ejecuta el código BE asociado, que puede (por ejemplo) guardar el formulario en una base de datos.
19. En el escenario anterior, la actividad del usuario puede generar (por ejemplo) 20 solicitudes durante un lapso de 10 minutos - utilizando solicitudes HTTP u otro mecanismo. Muchas de estas solicitudes activarían secuencias de comando BE específicas del sitio o secuencias de comando BE específicas de los componentes (para los componentes utilizados en el sitio).
20. Las tecnologías sin estado / con estado anteriores manejarían este escenario de la siguiente manera:
20.1. En el caso de trabajar con un servidor con estado, el servidor que originalmente sirvió la página que contenía el formulario tendría que seguir funcionando -aunque no hiciera nada, excepto quizás servir solicitudes intermedias (tal como la "obtener lista de valores para el campo X" mencionada anteriormente)-hasta que se envíe el formulario rellenado final, lo que podría ocurrir 10 minutos más tarde.
20.2. La anterior tecnología de servidores sin estado no podía arrancar en frío un servidor para cada solicitud HTTP concreta (que contuviera código específico del sitio en cuestión), ni siquiera una VM o un contenedor en el momento oportuno. Por lo tanto, o bien podían soportar sitios que no tuvieran una funcionalidad BE específica, o bien tenían que mantener una instancia de servidor específica ejecutándose durante toda la sesión de rellenado del formulario (y por lo tanto no son realmente sin estado).
21. Utilizando la tecnología inventiva, se asignaría una instancia de servidor sin estado (por ejemplo, un contenedor) para atender cada solicitud HTTP específica (cargar una página, obtener la lista de valores del campo X, guardar el formulario cumplimentado en DB). Esto podría equivaler (por ejemplo) a 20 tiempos de servicio de solicitudes (por ejemplo, 20 x 200 ms == 4 segundos) de uso del tiempo del servidor en lugar de la sesión completa de cumplimentación de formularios de 10 minutos. El servidor asignado podría ser un nuevo contenedor (inyectado con los elementos específicos del sitio) o un contenedor disponible ya adaptado al sitio.
22. Por lo tanto, en el mismo escenario de uso, el sistema inventivo puede utilizar sustancialmente menos recursos del servidor que los sistemas de la técnica anterior - sólo requiere un servidor durante 4 segundosen lugar de 10 minutos (durante la mayor parte del cual la instancia del servidor está inactiva, pero todavía está a la espera de las solicitudes del usuario específico).
23. Esto permite al proveedor de alojamiento web ofrecer el mismo nivel de servicio utilizando una cantidad mucho menor de recursos (servidores, contenedores, etc.).
24. Como nota al margen, dado que el usuario está trabajando localmente con el formulario, si el usuario cierra la ventana del navegador y la vuelve a abrir obtendría generalmente un formulario vacío (y no el parcialmente rellenado). El sistema inventivo puede proporcionar una API a través de la cual el contenido del formulario puede guardarse en el almacenamiento local del navegador. Así, si el usuario cierra una ventana de formulario parcialmente completada y la vuelve a abrir, el formulario reabierto contendría los valores introducidos anteriormente. Esto también funcionaría si el navegador está completamente cerrado.
25. Del mismo modo, las tareas BE pueden seguir proporcionándose información de contexto entre sí, por ejemplo, guardando la información de contexto en una base de datos del servidor (en el lado del servidor) o proporcionando información que debe mantener el cliente y pasar a las invocaciones BE posteriores. Dicha información puede ser de duración limitada a la sesión o persistente según sea necesario (por ejemplo, utilizando el almacenamiento local del navegador).
26. También debe tenerse en cuenta que la inyección de código de componentes específicos y secuencias de comandos FE/BE asociados se realizaría normalmente para todo el sitio (es decir, todos los componentes especiales y secuencias de comandos utilizados por todas las páginas del sitio) en lugar del nivel específico de granularidad de la página. De esta forma, los contenedores inyectados pueden reutilizarse para cualquier página del sitio cada vez que llegue una nueva solicitud HTTP para este sitio (del mismo usuario o de otros usuarios).
27. Sin embargo, el sistema puede aplicar un nivel diferente de granularidad, dependiendo de la cantidad de "material" que se inyecte, por un lado, y del patrón de su uso, por otro. Así, el sistema puede implementar un nivel de granularidad de inyección de (por ejemplo) páginas, grupos de páginas (es decir, secciones de sitios), sitios o grupos de sitios. El caso del grupo de sitios puede ser relevante, por ejemplo, cuando un gran número de sitios son muy similares y utilizan componentes y secuencias de comandos asociadas comunes. De este modo, los contenedores inyectados con el contenido específico del grupo de sitios podrían reutilizarse para servir solicitudes de cualquiera de los sitios del grupo y no sólo de un sitio.
Utilización del sistema inventivo en un contexto EDT
28. Un EDT en línea se caracteriza por tener dos modos de uso:
28.1. Edición del sitio- donde un sitio (por ejemplo, datos XML/JSON o registros de base de datos o material de página HTML real) se edita normalmente mediante una aplicación de edición visual que se ejecuta en el navegador con soporte de servidor. Un sitio de este tipo puede incluir código FE y BE (que también puede ser editable por el editor), así como componentes específicos necesarios para el sitio (por ejemplo, aplicaciones de terceros). El editor también puede invocar el sitio en modo de vista previa. El editor también puede admitir una operación de publicación, en la que se publica una versión del sitio para que la utilicen usuarios externos.
28.2. Modo RT (tiempo de ejecución) - donde el sistema sirve un sitio publicado a los usuarios, mientras activa el código FE o BE según sea necesario.
29. El sistema inventivo descrito anteriormente puede utilizarsetantoen el modo de edición como en el modo RT del sistema.
30. Cuando se trabaje en modo edición:
30.1. El contexto del sitio editado incluye lo siguiente:
30.1.1. La definición completa del sitio (páginas, componentes y datos asociados) que el cliente del editor suele mantener como una estructura en memoria del lado del cliente (por ejemplo, como una expresión JSON).
30.1.2. El código FE del sitio.
30.1.3. El código BE del sitio.
30.2. El código real del editor (código FE del editor que se carga en el cliente código BE del editor que se ejecuta en el servidor) forma parte del código general del sistema (en la "sección general" precargada en los contenedores).
30.3. El JSON del sitio/código del sitio FE/código del sitio BE se guarda en la DB (cuando el usuario hace un guardado explícito).
30.4. Hay guardados intermedios limitados del código FE/BE - por lo que el usuario puede continuar editando el mismo código a través de cualquier contenedor al que se "mueva". Esto es necesario ya que el código FE/BE del sitio no forma parte del código JSON del sitio.
31. Debe tenerse en cuenta que el código del sitio se mantiene en la base de datos para que pueda utilizarse cuando se ejecuta una vista previa, y además para que el editor no tenga que cargar todo el código del sitio (que puede ser grande), sino sólo la sección relevante que se está editando o relacionada con la página actual.
32. Cuando se trabaja en modo de ejecución, el sistema funciona como se ha descrito anteriormente para el servicio normal de sitios web. El WBS puede tener un módulo visor (que sería necesario para todos los sitios editados en el WBS) - dicho módulo formaría parte del código general del sistema precargado en las instancias iniciadas del servidor / contenedor.
33. Así, el sistema inventivo puede ser utilizado por un WBS tanto durante la edición como durante RT.
Acrónimos en uso
O > wíx Coas > Wix Code Basics
��
Introducción
1. Esta solicitud de patente está dirigida a sistemas de creación de sitios web (y otros sistemas de edición visual), y describe sofisticadas herramientas de edición visual que permiten la integración de código proporcionado por el usuario (UPC) tanto en el lado del cliente como del servidor, al tiempo que generan sitios web que pueden ser indexados por motores de búsqueda y pueden proporcionar soporte SEO.
2. Esta solicitud de patente describe múltiples conceptos discutidos en el contexto de Wix Code, una plataforma de desarrollo de sitios sin servidor que se está desarrollando como parte del sistema de construcción de sitios web Wix ofrecido por Wix.Com Ltd. A continuación, se incluye una descripción exhaustiva de dicho sistema. Debe aclararse que la implementación del Wix Code no es la única realización de los conceptos y la tecnología, y que pueden construirse realizaciones adicionales y diferentes de acuerdo con la presente divulgación.
Solicitudes de patente relacionadas
3. La presente solicitud hace referencia (o está relacionada de otro modo) con las solicitudes de patente enumeradas en el apéndice A1, todas las cuales están asignadas al cesionario común de la presente solicitud. La divulgación de cada una de las solicitudes de patente y patentes enumeradas en el apéndice A1 se incorpora expresamente al presente documento, en su totalidad.
Antecedentes
4. El solicitante ha detectado una brecha en el ecosistema de la nube. El panorama de IaaS (Infraestructura como Servicio), PaaS (Plataforma como Servicio) y SaaS (Software como Servicio) ofrece soluciones para VM, Contenedores y Redes, plataformas de distintos tipos para desarrolladores de interfaz del sistema, interfaz del sistema para desarrolladores móviles y software ya preparado para particulares y empresas. Lo que falta en el medio es una plataforma para sitios y aplicaciones web.
5. Con la aparición de Serverless (también conocido como Serverless Computing), todavía no hay jugadores en esta brecha. El solicitante ha desarrollado WixCode, una plataforma para el desarrollo y despliegue de sitios y aplicaciones web, en parte para colmar esta laguna. Esta plataforma proporciona elementos tal como JavaScript optimizado para interfaz de usuario, compatibilidad SEO, constructor de sitios WYSIWYG, métodos web y JavaScript para interfaz del sistema, así como arranque de contenedores en tiempo de solicitud.
6. En particular, los sistemas divulgados proporcionan la capacidad de crear visualmente sitios web mientras se especifica el código incrustado integrado con el sitio web tanto para el código de interfaz del usuario como interfaz del sistema. Todo esto puede hacerse preservando la capacidad del sitio web para ser indexado por los motores de búsqueda y aplicar técnicas SEO.
7. Un sistema de creación de sitios web puede ser un sistema independiente o estar integrado en un sistema de edición más amplio. También puede ser en línea (es decir, las aplicaciones se editan y almacenan en un servidor), fuera de línea o parcialmente en línea (con sitios web que se editan localmente, pero se cargan en un servidor central). Los sistemas divulgados pueden formar parte de un sistema de creación de sitios web en línea, aunque pueden integrarse con otros tipos de sistemas de creación de sitios web.
8. Las plataformas de creación de sitios web basadas en un entorno de diseño visual suelen estar dirigidas a usuarios con conocimientos similares a los necesarios para manejar el paquete Office de Microsoft. Sin embargo, este tipo de usuarios sólo construye el 5% de los sitios.
9. Los sistemas divulgados admiten sitios más complejos, cuya creación suele requerir un mayor nivel de destreza. Este tipo de sitios suelen ser creados por diseñadores, escritores de secuencias de comandos y desarrolladores -e incluyen el 95% de los sitios de Internet. El Apéndice A2 incluye una presentación que describe con más detalle este espectro de creadores y tipos de emplazamientos.
Descripción y arquitectura del sistema
10. El Apéndice A3 incluye una descripción técnica interna en profundidad de un sistema ejemplar y sus elementos.
11. El Apéndice A4 incluye una descripción técnica interna de un sistema ejemplar para usuarios técnicos / desarrolladores.
12. El Apéndice B incluye una serie de guías y tutoriales para el usuario en los que se describen las especificaciones de un sistema ejemplar y su uso por parte de usuarios y desarrolladores.
13. El Apéndice C incluye un conjunto de presentaciones, tutoriales y secuencias de vídeo que ofrecen una introducción general a un sistema ejemplar.
14. El diseño básico de un sistema ejemplar (construido además del sistema básico Wix) consta de 15 subsistemas que se describen a continuación. Un 16° "subsistema" es el código proporcionado por el usuario (UPC), que puede ser proporcionado por el diseñador del sitio y ejecutado como parte del sistema (con la encapsulación y separación adecuadas).
15. Estos subsistemas ejemplares pueden tener presencia del lado del cliente, del lado del servidor o de ambos. Los subsistemas ejemplares pueden incluir, entre otros:
(continuación)
. Estos subsistemas ejemplares, y su funcionalidad a modo de ejemplo, pueden describirse brevemente como sigue:
(continuación)
(continuación)
17. La relación entre los distintos subsistemas puede visualizarse del siguiente modo:
18. En el apéndice A5 se incluye una descripción detallada de cada uno de estos subsistemas ejemplares.
19. El apéndice A6 incluye un algoritmo específico de "superposición de base de datos" para la implementación de una de las formas de realización de la WDT mencionadas anteriormente. Una realización alternativa puede utilizar "registros lápida" (que significan registros que se han eliminado) en la discutida "DB Plus" en lugar de utilizar una "DB Minus".
Detalles del concepto
20. El solicitante ha identificado una serie de áreas, funciones y capacidades que se describen con mayor detalle en el presente documento. Entre ellas figuran las siguientes:
20.1. Funcionalidad de interfaz del sistema personalizada en un entorno de creación de sitios web en línea.
20.2. Vista previa dinámica de páginas web con bases de datos.
20.3. Edición de una base de datos durante la vista previa de una página web virtual.
20.4. Instancia de ejecución de servidor web bajo demanda para alojamiento de sitios web.
20.5. Base de datos común para el funcionamiento en directo y las pruebas de un sitio web.
20.6. Motor automático de recomendación de diseños (Diseño Mágico).
20.7. Recomendaciones automáticas de diseño web para mejorar el SEO.
20.8. Los complementos de funciones segregados cargados por el usuario evitan la infección en sitios web alojados conjuntamente.
20.9. Segregación de complementos de funciones cargados por el usuario para sitios web.
20.10. Los complementos de funciones suministrados por los usuarios amplían las funciones del editor en línea.
20.11. Interfaz del editor de iFrame separada de las herramientas de diseño.
21. El Apéndice D ofrece más detalles y divulgación sobre cada uno de estos conceptos. A continuación, figuran algunas aclaraciones específicas adicionales sobre algunos conceptos.
2. Funcionalidad de interfaz del sistema personalizada en un entorno de creación de sitios web en línea:
22.1. El sistema puede proporcionar soporte específico para arañas de motores de búsqueda a través de una secuencia de comandos o marcador incluido en la etiqueta HEAD de las páginas generadas.
22.2. Un marcador o secuencia de comandos de este tipo puede dirigir a la araña para que utilice el servicio web específico, ayudando a que las páginas sean indexables.
23. Instancia de ejecución de servidor web bajo demanda para alojamiento de sitios web:
23.1 Este concepto implica el arranque rápido de contenedores Dockers que ejecutan una instancia de servidor web configurada para un sitio específico (incluyendo los complementos específicos y el código proporcionado por el usuario del lado del servidor para este sitio), y hacerlo con la suficiente rapidez para responder a una solicitud HTTP sin tiempo de espera, y en un plazo total aceptable para los usuarios. 23.2. Arrancar una máquina virtual suele llevar variosminutos.Arrancar un contenedor Docker sigue tardando 2-3 segundos. Ambos tiempos no son aceptables.
23.3. En los sistemas divulgados, se puede proporcionar un grupo de Dockers en espera (por ejemplo, contenedores) que contenga todo el código relevante no específico del sitio, pero sin ningún código específico del usuario/sitio.
23.4. El sistema puede escuchar en un puerto activo una solicitud para conectarse a un servidor para el sitio web específico. Si hay un Docker activo asociado con el sitio web específico, el sistema puede conectarse a éste. En caso contrario, puede utilizar un Docker en espera del grupo e inyectarle el contenido solicitado, o indicarle que cargue dicho contenido.
23.5. El sistema puede soltar contenedores de reserva si un sitio no ha estado activo durante un periodo determinado (tal como 15 minutos).
24. Base de datos común para el funcionamiento en directo y las pruebas de un sitio web:
24.1. Este concepto implica tener datos provisionales y en vivo ejecutándose en la misma DB.
24.2. Como ya se ha indicado, en el apéndice A6 se detalla un ejemplo de algoritmo.
24.3. Cualquier escritura en la DB por parte del sistema de desarrollo puede crear una copia de los datos. Esta copia puede ser la visible para el sistema de desarrollo. Es posible que los datos de desarrollo no sean visibles para el sitio activo.
25. Segregación de complementos de funciones cargados por el usuario para sitios web:
25.1. El concepto analiza el uso de iFrames para tomar contenidos de un sitio e incorporarlos a otro de forma segura. Sin embargo, dicha incorporación de contenidos puede llevarse a cabo mediante diversos métodos, entre los que se incluyen:
25.1.1. Transferencia del contenido mediante AJAX.
25.1.2. Inclusión directa del contenido remoto sujeto a análisis de código estático, por ejemplo, analizar el código JS para ver si es seguro.
25.2. Los sistemas divulgados utilizan un Iframe más pequeño (y típicamente invisible) para ejecutar el código del complemento de funciones, mientras que la propia Ul de complemento de funciones puede ser nativo del sistema de creación de sitios web. Esto es diferente de la disposición utilizada con las TPA (Aplicaciones de Terceros), en las que parte o toda la interfaz de usuario de la TPA se implementa en un iFrame, aunque la TPA todavía puede comunicarse con otros componentes nativos en la página que aloja la TPA (como se discute en la solicitud de patente TACA Wix - véase apéndice A1).
25.3. Los complementos de funciones también difieren del TPA en que los complementos de funciones normalmente sólo implican código proporcionado por el usuario (que se ejecuta únicamente en el lado del cliente). Por otro lado, el código TPA se ejecuta en el servidor del proveedor de TPA.
25.4. Así, los sistemas divulgados pueden proporcionar los siguientes beneficios:
25.4.1. Permitir la instalación de un complemento de funciones en un sitio para que añada funcionalidad, pero no ponga en peligro el propio sitio web debido al aislamiento del código.
25.4.2. El complemento de funciones no puede acceder a las cookies ni al DOM del sitio, y esta medida de seguridad no puede eludirse como la encapsulación (limitada) que ofrecen por Web Components4 o sistemas similares.
25.4.3. Los sistemas divulgados permiten instalar varios complementos de funciones de modo que no interfieran entre sí (por ejemplo, colocándolos en iFrames separados).
25.4.4. Los sistemas divulgados pueden permitir la instalación de un complemento de funciones que amplía otro complemento de funciones, utilizando un único iFrame para ambos, o utilizando una API entre múltiples iFrames. Estos complementos de funciones no están aislados o Sandboxed unos de otros, por ejemplo, pueden ser parte de una familia de complementos de funciones proporcionados por el mismo proveedor. 25.4.5. Los sistemas divulgados pueden proporcionar una subregión de complemento de funciones segura con una API enriquecida que esté desacoplada del sitio en sí, permitiendo que múltiples complementos de funciones residan en la misma área, y soportando una API enriquecida a través de la $w API descrita anteriormente (posiblemente usando una API cross-iFrame controlada como se describe en la solicitud de patente TACA - véase el apéndice A1).
25.5. Esta disposición difiere de los iFrames normales, ya que los iFrames no tienen una API desarrollada, y no interactúan con el WBS (sistema de creación de sitios web) de alojamiento o la página WBS. También es eficaz para prevenir CSRF (falsificación de solicitudes entre sitios), robo de cookies y XSS (secuencias de comandos entre sitios). Sin embargo, sólo puede utilizarse en una WBS en línea.
25.6. Esto debe contrastarse con los sistemas existentes en el estado de la técnica, que normalmente dependen de que el complemento de funciones esté correctamente escrito, o están limitados a complemento de funciones específicos.
4 https://www.webcomponents.org/
25.7. La implementación puede basarse, por ejemplo, en engancharse a la pasarela para PostMsg y filtrar los mensajes específicos. Así, los sistemas divulgados también pueden implementar una técnica de permisos orientada al usuario, que permite a éste controlar con precisión los permisos de acceso concedidos a cualquier complemento. Esto es similar a la forma en que el sistema operativo de un Smartphone proporciona un control preciso sobre los permisos concedidos a cualquier aplicación instalada (por ejemplo, "¿Puede la App XYZ utilizar el GPS / acceder a tus contactos?"). Sin embargo, esto se hace sin necesidad de descargar una copia del complemento de funciones antes de la instalación.
25.8. Cabe señalar además que los sistemas divulgados, como un WBS en línea, pueden almacenar complementos de funciones en un único lugar, con todas las instalaciones del complemento de funciones actualizadas inmediatamente cuando se actualiza el complemento de funciones. Esto contrasta con los actuales sistemas fuera de línea del estado de la técnica, en los que cada instalación de complemento de funciones es independiente y debe actualizarse por sí misma.
Tabla de apéndices
01 - CGD
Cuadrícula de cálculo
Cuadrícula de cálculo del código Wix
Objetivo y función
La cuadrícula tiene dos funciones principales en el código wix:
• Cuando se desarrolla código de interfaz del usuario e interfaz del sistema, modo editor, proporciona el sistema de archivos subyacente para el código fuente al tiempo que proporciona agrupación de código de interfaz del usuario y ejecución de código de interfaz del sistema para fines de previsualización de forma segura multiinquilino
• Para visualización pública, modo público, rápido, seguro multiinquilino ejecutores fiables para el código interfaz del sistema del usuario.
Arquitectura de cuadrícula informática
Tiempo de ejecución en la nube FKA Elementory
Propósito
• La ejecución en tiempo de ejecución en la nube es el único propósito de la existencia de la cuadrícula informática • Los contenedores en tiempo de ejecución en la nube están diseñados para ser fiables, rápidos y seguros
Rápido
• contenedores de tiempo de ejecución en la nube son contenedores livianos que ejecutan un procedimiento JS de un solo nodo.
• Como se tarda un tiempo relativamente largo en hacer que un contenedor esté listo para servir código de usuario, se mantiene un grupo de contenedores en espera para ese fin
• Es responsabilidad del ciclo de vida de la nube (véase más adelante) asegurarse de que siempre haya suficientes contenedores de reserva para atender la capacidad bajo demanda
Fiable
• En modo público (sin edición)
o Los contenedores son totalmente desechables
o El sistema puede aprovisionar un contenedor en ejecución con código de usuario en menos de 100 ms
• En modo edición
o El código de usuario se archiva automáticamente de forma periódica
o El usuario puede ejecutar y previsualizar su código inmediatamente, ya que la edición del código se realiza en el mismo sistema de archivos en el que se ejecuta el contenedor de ejecución en la nube.
Seguro
• Un contenedor de ejecución en la nube sólo ejecuta una aplicación, por lo que no es posible que se produzcan fugas de contenido
• Los contenedores sólo contienen un nodo JS binario, enlazado estáticamente
• El sistema de archivos raíz del contenedor es de sólo lectura
• Cada contenedor se ejecuta con un identificador de usuario único
• El código de usuario es inyectado por el Trabajador de Alojamiento fuera del contenedor
• Un contenedor no puede acceder a ningún código salvo a los usuarios cuyo código se le asignó • El sistema de archivos de código de usuario no tiene permisos de ejecución
• En el contenedor se aplican limitaciones de cuota de disco, memoria, CPU, red y otros recursos del sistema Ciclo de vida de la nube
• Aunque externo al alojamiento de cuadrícula, el ciclo de vida de la nube es digno de mención en este contexto.
Su función es controlar y gestionar la cuadrícula de computación de código wix.
• El ciclo de vida utiliza dos componentes en el alojamiento de cuadrícula para gestionar el alojamiento y los contenedores en tiempo de ejecución en la nube
a. El Docker daemon: Para iniciar, detener y controlar contenedores de trabajador de alojamiento y tiempo de ejecución de la nube.
b. Trabajador de alojamiento: Para gestionar los permisos del sistema de archivos del contenedor en tiempo de ejecución en la nube, la cuota y las funciones de archivado.
• Relevante para este documento es la función de ciclos de vida para asignar un UID unix por cada contenedor de código de usuario que utiliza el tiempo de ejecución de la nube
Alojamiento de cuadrícula
La cuadrícula de computación está formada por tres componentes principales que son gestionados por el servicio de ciclo de vida de código Wix. Cada alojamiento de la cuadrícula tiene el siguiente componente:
1. Docker Daemon
2. Trabajador anfitrión (en un contenedor Docker)
3. Tiempo de ejecución en la nube conocido como "Elementory" (en un contenedor Docker)
• Cuando una alojamiento de cuadrícula comienza a funcionar, se registra en el ciclo de vida enviando un mensaje contenedor a la IP del alojamiento de cuadrícula junto con sus recursos definidos: CPU y memoria.
• Un alojamiento de cuadrícula debe tener un Docker Daemon instalado y funcionando para que el ciclo de vida de la nube pueda gestionarlo.
Trabajador de alojamiento
El trabajador de alojamiento es parte de los componentes utilizados por el ciclo de vida de la nube para gestionar el alojamiento. Tiene dos responsabilidades:
1. Ampliar la capacidad del ciclo de vida para gestionar y manipular los permisos del sistema, las cuotas, la red, el sistema de archivos y el archivo de código.
2. Proporcionar un sistema de archivos como API para el editor mientras el usuario está editando su código en el editor Wix.
Ciclo de vida del trabajador de alojamiento
1. Creación de contenedores previos al tiempo de ejecución en la nube
a. Crear directorios para el código de uso
b. Establecer los permisos adecuados y la cuota de disco
2. Después de que el contenedor de tiempo de ejecución de nube esté "caliente"
a. Establecer el control del tráfico de red en el contenedor
b. Autoarchivar periódicamente el código del usuario mientras éste edita su código
3. Cuando el ciclo de vida de la nube decide detener un contenedor
a. Guardar y cargar el código de usuario en la base de datos (en modo editor)
4. Ejecutar tareas periódicas programadas por ciclo de vida
a. Localizar y eliminar los contenedores "zombi"
b. Limpiar el disco una vez archivado el código
API del sistema de archivos del trabajador de alojamiento
Como se mencionó anteriormente, la otra responsabilidad del trabajador anfitrión es proveer la API del sistema de archivos virtual(VFS)para el editor. Sus responsabilidades en ese sentido son:
1. Proporcionar manipulaciones básicas del sistema de archivos, tales como:
a. Operaciones de creación, actualización, lectura y eliminación de ficheros y directorios
2. Asegúrese de que las operaciones anteriores se realizan sólo en la mitad del usuario permitido mientras se mantienen las restricciones de cuotas y permisos.
02 - ELM
Elementory
Código Wix - Tiempo de Ejecución en la Nube / Elementory
Panorama general
Tiempo de Ejecución de la Nube(también conocido como Elementory) es un servicio basado en node.js que gestiona las solicitudes de los usuarios tanto para el modo de edición, vista previa y vista. El servicio se encarga de ejecutar código de usuario en múltiples escenarios y de servir y transpilar código de cliente de usuario.
Punto finales Principales
Métodos web - especificados en el documento #4 del subproyecto.
Enrutadores dinámicos - especificados en el documento #8 del subproyecto.
Datos Wix - especificados en el documento #3 del subproyecto.
Puntos finales de Wix (funciones de cálculo) - especificados en el documento #13 del subproyecto.
Archivos estáticos: transpilar, agrupar y servir código de usuario.
Separación entre módulos internos y externos
El servicio se divide en módulos internos y externos, el código de usuario se monta en el módulo externo y el usuario puede acceder a las librerías wix desde allí( wix-data, wix-enrutadors, wix-endpoints, wix-fetch) .
Para limitar el acceso del usuario sólo a los módulos externos, el servicio utiliza el módulo de requisito de alcance (proyecto de código abierto desarrollado por wix).
Transpilación del código de usuario
El código Wix code permite al usuario escribir código usando las últimas características de ECMAscript (hasta es2017 por ahora), una de las responsabilidades de tiempo de ejecución de la nube es transpilar este código a una versión soportada de JavaScript por el entorno de ejecución de la nube.
• Código del lado del cliente: el tiempo de ejecución de la nube tiene un punto final para solicitar archivos.js ymap,el servicio comparte la misma biblioteca central concloud-bundler-serverpara transpilar y agrupar el código del lado del cliente.
• Código de interfaz del sistema - las últimas características de ECMAscript no son compatibles con la versión LTS actual de node(v6.11.0), el servicio utilizababel-registerpara evaluar la transpilación de los archivos necesarios. Ejecución de código de usuario
A través de métodos web, ganchos de datos wix, enrutador personalizado, ganchos de enrutador de enlace de datos y funciones informáticas, el usuario puede escribir código de interfaz del sistema que eventualmente necesita ser ejecutado por el servicio de tiempo de ejecución de nube.
El tiempo de ejecución de nube utiliza node domain para envolver el código de usuario con contexto y permite capturar el seguimiento y los registros de la pila de códigos de usuario.
03 - WDT
Wix Data
WixData
Wix Data API
API de Datos Wix -usada para acceder a la base de datos. API de Datos Wix se utiliza tanto en el código del navegador del lado del cliente (véase CSWW) como en el código de interfaz del sistema del usuario (véase ELM). La documentación de la API puede consultarse aquí.
El módulo API de Datos de Wix también realiza la transformación de datos y la gestión de errores.
La API de Datos Wix se comunica con el Proveedor de Datos Wix usando el Protocolo de Métodos Web (ver WBM).
Proveedor de datos Wix
Proveedor de Datos Wix - es la implementación de la API. Si el usuario no tiene código de interfaz del sistema propio, la implementación se ejecuta y atiende solicitudes de API en Cloud MultiTenant Server; de lo contrario, se ejecuta en el contenedor Docker del usuario (véase ELM). El Wix Data Provider realiza la lógica de Wix Data necesaria:
• Gestiona la autorización. La configuración de permisos define qué permisos tiene cada rol (propietario del sitio, propietario de los datos, cualquiera) (leer, insertar, actualizar, eliminar).
• Gestiona ganchos. Los ganchos permiten al código de usuario interceptar y modificar las solicitudes de Wix Data realizadas a través de la API (véase la documentación aquí)
• Realiza las consultas y transformaciones de datos necesarias para las funciones avanzadas de Wix Data
o Oculta los campos eliminados de los resultados y filtros
o Enriquece los objetos resultantes con campos computados (campo computado es un campo especial definido en el esquema, que permite generar nuevos campos basados en datos de campos existentes) o Une los elementos de la colección referenciados
o Enriquece los documentos que se guardan con la identificación del propietario
El Proveedor de Wix Data conoce el Esquema y los permisos almacenados en VFS.
Docstore
Docstore - servicio que actúa como puente entre MongoDB y el Wix Data Provider.It
• Realiza la traducción de consultas de Wix Data a formato Mongo
• Incluye copia de bases de datos y capacidad de sincronización de datos (lo que nos permite sincronizar los datos de Sandbox a en vivo y de la plantilla al sitio de los usuarios)
• Realiza el enriquecimiento de datos generando identificadores y almacenando las horas de creación y actualización de los documentos
Bibliotecas de usuarios
Por lo que sabemos, no se utiliza directamente ningún código de fuente abierta en ninguno de los proyectos (como en las copias).
Bibliotecas de código abierto utilizadas en Wix Data API y Wix Data Provider:
04 - WBM
Métodos web / RPC
Métodos web WBM / RPC
Los métodos web son funciones exportadas desde módulos ECMAScript que pueden invocarse a través de la red (un módulo de este tipo se denomina módulo web). Se trata de un mecanismo que permite que el código que se ejecuta en CSWW dentro del navegador del usuario final interactúe sin problemas con el código que se ejecuta en ELM. Este mecanismo gestiona la autorización de qué roles tienen permiso para invocar qué métodos web, inyecta información de ámbito de solicitud en los métodos web, propaga errores y registros a CSWW para que se registren en la consola del navegador. Además, permite invocar el mismo código desde el código de usuario tanto en CSWW como en ELM utilizando la misma sintaxis de importación de módulos ECMAScript. Este enfoque permite tener una sensación de "sistema de imagen única" al depurar y desarrollar aplicaciones.
La parte del servidor de los métodos web se ejecuta dentro de ELM y puede invocarse libremente como funciones regulares que devuelven promesas desde código de usuario ejecutándose en ELM, como Ganchos RTR y Enrutadores Personalizados, Ganchos WDT y CFN. WBM también se utiliza como mecanismo RPC para WDT, para que pueda utilizarse del mismo modo en el código interfaz del sistema y en el código de la página. Los proxies de JavaScript para invocar métodos web como funciones normales que devuelven promesas se agrupan con el código de usuario y se ejecutan dentro de CSWW.
El mecanismo se implementa mediante los siguientes componentes:
<•>web-method-domain- adjunta información de ámbito de solicitud a dominios node.js, que posteriormente es recuperada por funciones generadas porweb-module-extensiony adicionalmente anula las funciones de registro por defecto de node.js para recoger registros en este dominio.
•web-module-extension- utiliza el registro de Babel para anular el comportamiento de la función de requerimiento global para transpilar código ECMAScript 2015 para apuntar a la versión de nodo utilizada en ELM y se engancha al mecanismo de requerimiento para envolver funciones exportadas desde módulos web de usuario con.
•web-method-express-enrutador- es el punto de entrada a ELM para las solicitudes procedentes deelementorysupport.Gestiona la autorización de invocaciones a métodos web desde CSWW. También reenvía cualquier registro recopilado durante la ejecución del método web una vez que la ejecución del método web ha finalizado.
•elementory-support- proporciona el lado cliente del método web a través del protocolo de cable. Se ejecuta en CSWW y es invocado por webmethod-proxies. También envía los registros recibidos de Elementory a la consola del navegador del usuario.
• loswebmethod-proxiesse generan realizando un análisis estático de los módulos web para determinar qué funciones se exportan. Se incluyen con el código de usuario para ejecutarse dentro de CSWW.
La carga y ejecución del método web se implementa usandobabel-registerconbabel-preset-es2015-node6. Scopedrequirese utiliza para alterar las ubicaciones del sistema de archivos de los módulos que se pueden importar desde el código de usuario. LosWebmethod-proxiesse generan realizando un análisis estático utilizando el parser acorn y empaquetando los proxies generados junto con el código de la página de usuario utilizando browserify. El protocolo sobre el cable utilizado porelementory-supportyweb-method-express-enrutadorse basa en JSON con extensiones para manejar fechas nativas de JavaScript.
Diagrama de componentes
05 - ZSI
IDE de configuración cero
IDE
El componente IDE es un editor de código online integrado en el Wix Editor.
Puede usarse para editar el código de las páginas existentes del sitio, o editar archivos que existen en el sistema de archivos de Wix Code (archivos públicos y de interfaz del sistema).
El IDE también proporciona una rica finalización de código contextual, integración con el gestor de medios Wix, formateo de código y advertencias y errores personalizados.
Todas estas características personalizadas se construyen sobre un IDE de código abierto ya existente llamado Orion. Finalización del código
El IDE proporciona al usuario un enriquecido completado de código, tanto para el entorno JavaScript estándar como para la Wix Code API.
El completado de código puede sugerir completados para lo siguiente:
1. API del componente de Wix Code ($w) - proporciona sugerencias dependiendo de los elementos que existan en la página actual, por ejemplo "$w('#button1')". Esto significa que el usuario sólo verá sugerencias para los elementos que existan en la página actual, y no para elementos de otras páginas. Estas sugerencias no aparecerán en los archivos públicos/interfaz del sistema normales, sólo al editar el código de la página.
2. APIs generales de Wix Code, como"wix-data", "wix-windoW,que no dependen del contexto del código, lo que significa que están disponibles al editar código para una página o en archivos públicos/interfaz del sistema normales.
3. Objetos y funciones JS, tales como "console.logO", también disponibles en todos los tipos de archivo.
4. Plantillas - proporciona sugerencias de plantillas tanto para importaciones de módulos (por ejemplo "importar ubicación desde 'wix-location'") como para plantillas comunes de Js , como los buclesfor.
5. Parámetros de función - proporciona los parámetros y sus nombres para las funciones
El widget de completado de código también proporciona una breve descripción para cada sugerencia seleccionada, junto con un enlace a la documentación completa.
Integración de Gestor de Medios
Un usuario puede añadir código a un sitio que cambie la fuente de un elemento de imagen, es decir, que reemplace la imagen mostrada. Puede establecer la propiedad fuente de la imagen a cualquier URL de imagen, o a una imagen del gestor multimedia de Wix. Al intentar establecer la propiedad de fuente, el widget de finalización de código sugerirá abrir el gestor de medios. Allí, el usuario puede seleccionar una imagen, y su URL (protocolo personalizado Wix Code URL) se pegará en el código, por ejemplo: '$w("#image1").src = "image://v1/6e7958de786842eb811149ac9c25f73c.jpg/2362_4724/Cotton Candy Cone";" El usuario también puede pasar el ratón por encima de la URL, y se abrirá una información sobre herramientas mostrando la imagen, y un enlace para abrir el gestor multimedia para reemplazar la imagen.
Información técnica
El IDE está construido sobre el proyecto de código abierto Orion [https://wiki.eclipse.org/Orionj. Con el fin de proporcionar nuestra propia experiencia personalizada y Wix correcciones de errores específicos y cambios de comportamiento, anulamos módulos específicos de Orion con la nuestra. En lugar de modificar el código original de Orion, tenemos una configuración personalizada de carga de módulos, que sabe cargar nuestros módulos anulados en lugar de los originales, manteniendo nuestro código separado del código fuente original.
No usamos ninguna otra librería o paquete en el código de producción excepto Orion y las dependencias de Orion.
Para construir y probar el código, utilizamos una miríada de paquetes de código abierto, como grunt, mocha, karma, selenium-webdriver, lodash y más. El código de estos paquetes sólo se utiliza en tiempo de desarrollo y no se envía como parte del producto final.
Para proporcionar el completado de código, dependemos del módulo interno "wix-code-reference-docs". Este módulo depende de todas las librerías de Wix Code que exponen API (como $w) y construye un gran archivo que contiene toda la información necesaria para proporcionar el completado de código. Este archivo se copia durante el procedimiento de compilación y es utilizado en tiempo de ejecución por el IDE.
Todo el código está escrito en JavaScript.
06 - EPT
Plataforma de Editor
Plataforma de Editor
El trabajador de web del lado del cliente y el SDK, permiten ejecutar código personalizado en la aplicación web. La plataforma permite escribir un código que es reutilizable y, por lo tanto, puede distribuirse a múltiples instancias en la misma aplicación web y a través de aplicaciones web. La plataforma consta de los siguientes componentes: •
• Aplicación Entidad Global:Estado compartido entre sus partes
• Enrutadores:Control de URL y resolución de páginas
• Controladores:Trozos lógicos de la aplicación, Múltiples instancias
• APIs:Exponer y mezclar todo
Aplicación Entidad Global
Un estado global para la aplicación permite escenarios tales como:
• Cesta de la compra, agregación de artículos durante una experiencia de compra en varias etapas
• Experiencia de asistente multipágina
• Experiencia de pago en varias etapas (carrito, información de envío, información de cuenta)
• Experiencia de creación que guarda toda la información una vez terminada
La plataforma permite al código de usuario almacenar el estado global de la aplicación para permitir los escenarios anteriores. También proporciona abstracción para que el trabajador web del cliente implemente la transición y limpieza de páginas sin afectar a los aspectos lógicos de la aplicación,
Enrutadores de aplicaciones
La aplicación puede crear enrutadores (ver sección 8) y registrarlos en la web. La aplicación puede almacenar información de configuración en el sitio web, lo que permite al desarrollador de la aplicación crear un único punto final de servidor para el enrutador y tener múltiples configuraciones por el objetivo distribuido. Un ejemplo de requisitos de enrutamiento de un blog puede ser:
1. domain.com/blog/2016/07/26/my-post 1. Página de publicación genérica mostrando
"mi publicación"
2. domain.com/blog/2016/07/26 2. Todas las publicaciones de 26-Jul-2016
3. dominio.com/blog/2016/07 3. 10 primeras publicaciones de Jul-2016
4. dominio.com/blog/2016/07?page=2 4. #11 - #20 publicaciones de Jul-2016
5. dominio.com/blog/tag/a-tag-i-use-a-lot 5. 10 primeras publicaciones con la etiqueta "atag-I..."
6. domaln.comlblog/category/my-category 6. 10 primeras publicaciones de la categoría "migato.."
7. domain.com/blog/2016/07/26/my-100th- 7. Página especial diseñada para mi publicación post número 100
Permitiendo a la aplicación configurar el enrutador y guardarloper-instance/site,el código del servidor del enrutador puede crearse una vez y soportar diferentes formatos de URL (con/sin fechas) y páginas específicas para publicaciones específicas, aunque la estructura de la URL sea la misma. Los usos más comunes son:
• Plantillas de página en cascada basadas en la especificidad (es decir, artículo ^ producto ^ bienes digitales) • Diferentes formatos de URL en función de los requisitos de SEO (optimización para motores de búsqueda) • Adición de páginas añadiendo contenidos en un CMS (sistema de gestión de contenidos)
Controladores
Los controladores permiten a un creador de código de usuario empaquetar una pieza de código con una lista de componentes de forma reutilizable. En el método normal(wix-code),el usuario accede a los componentes basándose en su ID único de página. Esto reduce la opción de utilizarlo dos veces en la misma página y dificulta la distribución. Los controladores tienen las siguientes propiedades:
• Unaconfiguración,guardar en el sitio. Esta configuración permite que el código sea reutilizable, ya que proporciona una forma de diferenciar una instancia del controlador de otra. Por ejemplo, si un código de controlador se conecta a una fuente de datos externa, obtiene información y la presenta mediante una imagen y un texto, la configuración sería el ID del elemento en el sistema remoto. De esta forma, 2 controladores distintos en la misma página pueden representar 2 elementos en el sistema remoto utilizando una imagen y componentes de texto diferentes
•Conexionesa componentes, utilizando rol (una cadena) como nombre, con configuración de conexión. Esto permite escribir por adelantado el código del controlador y luego distribuirlo, independientemente de los ID que reciban los componentes en la página. Esto es especialmente útil para 2 o más controladores en la misma página que acceden a 2 componentes diferentes, que no pueden tener el mismo ID. En la mayoría de los casos, el controlador seleccionará (ver selectores en la sección 15) los componentes a manipular utilizando el rol. Cada componente puede tener varios roles definidos, pero múltiples controladores, para permitir escenarios complejos de enlace de datos y modelos de programación de comportamiento (es decir, cada controlador es responsable de un aspecto diferente del componente, por ejemplo, un componente desplegable puede obtener la lista de opciones de un controlador y guardar la seleccionada a través de otro)
APIs
Cada controlador puede exponer sus propias APIs. Esto hace que el controlador aparezca como cualquier componente, y tiene un comportamiento similar. Permite a otros creadores de código, a nivel de sitio o de otros controladores, reutilizar el código del controlador como una caja negra, convirtiendo el controlador en un bloque de extensión del entorno de ejecución.
07 - CSWW
Trabajador web del lado del cliente
Trabajador web del lado del cliente
El trabajador web del lado del cliente permite extender un sitio web con funcionalidad personalizada. Los usos más comunes de esa extensión son:
• Enriquecimiento dinámico del contenido del sitio
• Flujos de usuarios personalizados
• Interacciones personalizadas
Para permitir esto, manteniendo el SLA, la seguridad y la capacidad de alojar estas extensiones en una nube unificada, se utiliza la siguiente arquitectura:
A continuación, se muestra una lista de los componentes lógicos del sistema:
• Marco superior del sitio: Esta es la página principal de la aplicación web. Se sirve en el dominio de un usuario o en el dominio general del servicio de alojamiento (Wix). Es el motor principal que ejecuta la aplicación web, también conocido como "el visor" o "el entorno de ejecución"
• IFrame sandbox: Para preservar la seguridad del marco superior frente a código malicioso (secuestro de cookies, etc.), se erige un IFrame con un dominio diferente. La diferencia de dominio son los recursos de sistema de Sandboxing (ventana, cookies, etc) y la memoria (toda la comunicación se puede hacer usando postMessage solamente y no por el intercambio de memoria)
• Trabajador web: Un trabajador de web es una capacidad estándar del navegador que permite ejecutar código asíncrono. El trabajador de web crea otra capa de protección al marco superior, ya que toda la comunicación es posible a través de postMessage, y la superficie API disponible globalmente en el trabajador de web es mucho más limitada que la del marco superior. Por ejemplo, el objeto global ventana no está disponible, el acceso DOM (modelo de objetos del documento) está prohibido, lo que significa que el código de trabajador de web no puede manipular los elementos Ul. Además del beneficio de seguridad del trabajador de web, su naturaleza asíncrona también asegura que el marco superior no dejará de responder incluso cuando el trabajador de web haga un uso intensivo de la CPU. Otra ventaja es la capacidad de depurar y hacer una pausa en el código de usuario (código que se ejecuta en el trabajador de web) sin bloquear el contexto de ejecución del marco superior, y permitiendo al usuario ver la propagación del código de usuario en la capa de UI, incluso mientras está en un punto de interrupción
• RMI (interfaz de modelo remoto): Este componente es responsable de crear y mantener un modelo lógico del marco superior, y compartirlo con el trabajador de web, a través de la capa de transporte postMessage. Los cambios en el modelo tendrán efecto en la aplicación web. Por ejemplo, el texto y el enlace de un botón se representan en el modelo. Los cambios de estos valores en el modelo afectarán al componente visual del botón y a su funcionalidad. Además, la capa RMI permite llamar a métodos predefinidos en el marco superior por parte del trabajador de web. Se utiliza para enriquecer la funcionalidad del trabajador de web, y realizar acciones que no están relacionadas con el estado, tal y como lo representa el modelo (es decir, animación). El modelo remoto salva la barrera asíncrona, permitiendo al código de usuario la percepción de código síncrono, que es más sencillo de escribir, aunque las acciones sean asíncronas. Por ejemplo, el código de usuario cambia la URL de una imagen de A a B. La siguiente línea de código lee el valor para determinar las siguientes acciones. El modelo ya tiene el valor cambiado de A a B, por lo que devuelve B, que es el valor coherente, aunque el comportamiento asíncrono del modelo no garantiza que ya se presente en el Ul de la aplicación web
• SDK:El SDK es una capa que envuelve el modelo RMI. Se utiliza para exponer una API más simple al código de usuario, simplificando el modelo en un método consistente y documentado de llamadas y propiedades de establecedores y captadores. Expone métodos del ciclo de vida y el objeto $w como contexto base para el código de usuario. En la sección 15 se ofrece una descripción detallada
08A - RTR
Enrutador
Enrutador RTR
Los enrutadores permiten al propietario del sitio definir una estructura de URL personalizada para su sitio. Los enrutadores son utilizados por las páginas dinámicas para resolver una URL específica a una página y por SEO y el editor para obtener todas las páginas disponibles en el sitio a través de la solicitud de mapa del sitio. Los enrutadores también exponen información SEO adicional para asociarla a una página. Existen dos tipos de enrutadores: los de enlace de datos y los personalizados. Los enrutadores son componentes de la interfaz del sistema que se ejecutan dentro de ELM.
Los enrutadores de enlace de datos conectan automáticamente una estructura URL basada en uno o más campos de base de datos y fragmentos de texto personalizados proporcionados por el propietario del sitio. Esto se puede hacer completamente a través de la Ul en el editor y no requiere código de usuario. Además, estos enrutadores pueden personalizarse mediante ganchos, lo que permite que el código del usuario modifique los parámetros pasados al enrutador, modifique la respuesta y modifique la consulta emitida a WDT.
Los enrutadores personalizados dan el control total de la estructura URL al propietario del sitio. Desde el editor, el propietario del sitio puede crear un enrutador para un prefijo específico, donde el resto de la URL será interpretado por su enrutador personalizado. Las solicitudes de enrutador se gestionan mediante dos funciones proporcionadas por el usuario: enrutador y mapa del sitio. La función de enrutador gestiona la resolución de URL individuales a páginas específicas. La API de enrutadores wix describe los datos que se pasan a esta solicitud. Se espera que esta función devuelva una de las respuestas predefinidas en la API (por ejemplo, OK, no encontrado, prohibido, etc.) junto con cualquier información SEO adicional. La función de mapa del sitio es similar, salvo que se espera que enumere todas las páginas disponibles en la ruta.
El enrutamiento dinámico se consigue mediante dos colaboradores: uno que se ejecuta en el navegador del usuario y otro en la interfaz del sistema. Cuando se carga una página a través de una URL gestionada por un enrutador dinámico, la página HTML predeterminada se carga en el navegador y se realiza una solicitud AJAX a la interfaz del sistema para determinar qué página debe mostrarse. La parte de interfaz del sistema del código no es consciente de qué prefijos son gestionados por qué enrutadores. Todos los datos necesarios para resolver una URL, incluidas las páginas que el enrutador puede elegir mostrar, se envían en esta solicitud y la respuesta de la interfaz del sistema se utiliza para abrir la página dinámica adecuada para la página y rellenarla con datos. El enrutador puede optar por rellenar los datos que se expondrán a la página cuando se abra, de modo que se evite otro viaje de ida y vuelta al servidor.
08B - RTR
Enrutador - detallado
Enrutamiento dinámico
Enrutador de enlace de datos
Enrutamiento personalizado
Introducción
Este documento esboza la arquitectura y los diferentes subsistemas detrás de las capacidades deEnrutamiento Dinámicoque planeamos añadir a la pila editor/visor. A continuación, el documento describe el nuevoEnrutador de Enlace de Datosy la forma en que se construye sobre el modelo de enrutamiento dinámico. Por último, el documento explica cómo los desarrolladores pueden construirEnrutadores Personalizadospara crear sus propias implementaciones de enrutamiento dinámico.
Modelo de enrutamiento dinámico
El Enrutamiento Dinámico permite a un sitio/aplicación wix definir y gestionarURLs Dinámicas.Esto permite a los usuarios y a las aplicaciones editoras crear sitios que tengan algo más que páginas estáticas con URL conocidas en el momento de la publicación.
En última instancia, los usuarios y las aplicaciones pueden:
- Definir patrones de URL que correspondan a páginas renderizadas concretas
- CrearPáginas Dinámicascuyo contenido dependa de las URL dinámicas entrantes
- Exponer estas URL a robots (motores de búsqueda y consumidores automatizados similares) Componentes básicos del modelo de enrutamiento dinámico
Los componentes básicos de este modelo sonAplicaciones, Enrutadores, Rutas, Puntos Finales de Enrutadores, URLs, Páginas Dinámicas, Roles de PáginayMapas de Sitio.A continuación, los exploramos y la forma en que interactúan para crear el modelo de enrutamiento dinámico.
La construcción básica que permite el enrutamiento dinámico es elEnrutador. Un Enrutador es propiedad de una Aplicación.Cada aplicación puede tener más de un enrutador si lo necesita.
Un enrutador es responsable de resolver una URL entrante específica a una página dinámica específica que el espectador debe renderizar.
Las URL dinámicasentrantes tienen la siguiente estructura:<site>/<prefix>/<suffix>:
- <site>:<tiene la forma><my.site.com><para sitios premium, o la forma><user_name.wixsite.com/site_name><para sitios gratuitos.>
-<prefix>:esta parte es la que determina qué enrutador gestionará la URL entrante. Cada enrutador registra un conjunto deprefijos únicosen la cabecera del sitio. Esta información es gestionada por el editor en tiempo de ejecución.El editor se asegura de que no haya dos enrutadores que definan el mismo prefijo. - <suffix>:lo que viene después del prefijo. Esta parte, junto con el prefijo, es utilizada posteriormente por el enrutador para resolver la URL entrante.
Cada enrutador soporta una o másRutas.Una ruta es una plantilla para la parte <suffix> de una URL. Ejemplos de rutas (las rutas están ennegrita):
- my.site.com/blog/
- my.site.com/blog/post-{id}
- my.site.com/blog/{year}/{month}/
- my.site.com/blog/featured-posts
Una aplicación puede soportar siempre todas sus posibles rutas, o puede permitir al usuario seleccionar cuales están habilitadas y cuáles no. Por ejemplo, en una aplicación de blog, el usuario puede decidir si quiere utilizar la función de publicaciones destacadas o no.
Téngase en cuenta que depende de la aplicación y del enrutador específico asegurarse de que puede distinguir entre diferentes rutas. Considere las dos rutas siguientes para una aplicación de blog:
- my.site.com/blog/{year}/
- my.site.com/blog/{author}/
Puede ser difícil saber qué ruta usar para decodificar la URL entrante - puede haber un autor llamado "2016"... en tal caso puede ser mejor crear estas rutas en su lugar:
- my.site.com/blog/{year}/
- my.site.com/blog/authors/(author}/
UnaPágina Dinámicaes simplemente cualquier página a la que un enrutador puede enrutar. LasPáginas dinámicas son propiedad de los enrutadores,<es decir, cada enrutador tiene un conjunto de páginas dinámicas a las que él y>sólo él puede enrutar. Por lo tanto, un enrutador no puede enrutar a una página estática "heredada".
A cada página dinámica se le asigna uno o másRoles de Página.Los roles de página ayudan al enrutador a decidir cómo resolver una URL entrante en una página concreta a renderizar.
El algoritmo (simplificado) funciona del siguiente modo:
1. [tiempo de ejecución de visor] La URL entrante se analiza para decidir qué enrutador la resolverá, basándose en la parte <prefix>
2. el [tiempo de ejecución de visor] llama al punto final de resolve_url del enrutador elegido, pasando la información que el enrutador necesita para resolver la URL a un ID de página dinámico específico.
3. [enrutador elegido] Calcula unalista ordenadade Roles de Página para la URL entrante
4. [enrutador elegido] Selecciona el ID de la página dinámica a resolver, basándose en la lista de páginas dinámicas y su rol de página asociado. Para cada rol de página de la lista ordenada, el enrutador busca una página dinámica que coincida con ese rol. La búsqueda finaliza cuando se encuentra una página dinámica que tiene ese rol. Si no se encuentra ninguna página, la URL se resuelve con un código de respuesta 404.
5. [enrutador elegido] Devuelve al visualizador el ID de la página seleccionada, junto con la información auxiliar necesaria para representar una página dinámica (lo más importante, una carga útil de datos opcional)
6. [visor] Renderiza la página dinámica seleccionada
Nótese que es perfectamente OK que el enrutador resuelva diferentes rutas entrantes al mismo ID de página. Por ejemplo, pensemos en una aplicación de gestión de zoológicos. Esta aplicación registra un Enrutador bajo el prefijo <zoo>, y soporta dos rutas:
- /zoo/animal_of_the_day
- /zoo/animals/{{animal_name}}
<En este caso, ambas rutas resolverán al rol de página {animal_page}. Si la URL entrante>es</zoo/animals/tiger>,<y si>tigre es actualmente el animal del día, ambas rutas resolverán a la página dinámica que renderiza un animal, y ambas renderizarán un hermoso tigre en pantalla.
Una explicación más detallada del enrutamiento
Como hemos visto, el visor utiliza un enrutador para resolver la página que se va a renderizar. Sin embargo, para representar correctamente una página dinámica, hay que tener en cuenta algunas consideraciones más.
Vea un diagrama que explica esto en detalle aquí.
Puntos finales del enrutador
Cada enrutador debe soportar los dos puntos finales siguientes:
-Resolver punto final de URLutilizado para resolver una URL entrante a un ID de página
-Recuperar el punto final del mapa del sitioutilizado para recuperar la lista completa de URLs que este enrutador puede resolver
Estos puntos finales y su comportamiento se detallan a continuación.
El punto final de Resolver-URL
Este punto final se utiliza cuando una URL entrante necesita resolverse a una página dinámica específica.
Resolver entradas de puntos finales de URL
Para resolver una URL entrante, el enrutador necesita potencialmente la siguiente información:
<- Partes de la URL (sitio>, prefijo, sufijo).<Tenga en cuenta que debe incluir la cadena de consulta de la URL (la>parte después de los caracteres '?' y antes de los caracteres '#').
-Instancia firmada por la aplicación:El punto final del enrutador necesita conocer el ID de instancia de la aplicación para saber de qué sitio procede la solicitud entrante. Por ejemplo, considere una aplicación Blog. Para resolver la URL entrante de una publicación de blog específica, el enrutador debe conocer la instancia de la aplicación de blog.
-Credenciales de usuario:Parte de la instancia firmada. El enrutador necesita conocer las credenciales del usuario que está emitiendo la solicitud. Esto es necesario, por ejemplo, para saber si ese usuario tiene permiso para ver la información en la página específica solicitada. Por ejemplo, un enrutador de Blog puede querer prohibir<a los usuarios anónimos ver la página detrás de>my.site.com/blog/admin.
- Arreglo de rutas:[Forma parte de la configuración del enrutador]. Un arreglo de las rutas que admite esta instancia de aplicación. Normalmente, cada ruta proporcionará información sobre su patrón de URL, sobre el Título y otras meta-etiquetas SEO para esta ruta específica, etc. Ver más en la sección SEO más abajo.
-Configuración del enrutador:Información adicional específica de la aplicación y el enrutador. Por ejemplo, considere una aplicación de blog. Supongamos que esta aplicación proporciona una página dinámica con todas las publicaciones de un autor determinado. La URL de una página de este tipo podría ser la<siguiente:>my.site.com/{{author_name}}.<En este caso, hay un enrutador que maneja estas URLs, y necesita ser>capaz de mapear el nombre del autor a un ID de autor específico en su base de datos de publicaciones. Para hacer ese mapeo, la configuración del enrutador tendrá lo siguiente: {author_ID:123}. Cuando se invoque el punto final del enrutador, se recuperarán las publicaciones del autor ID 123.
-Lista de páginas dinámicas y sus roles asociados:Utilizado por el enrutador para seleccionar el ID de página a renderizar basado en la coincidencia de roles como se explicó anteriormente.
Resolver salidas de puntos finales de URL
-ID de página que se va a renderizar.El resultado primario de la resolución de una URL por parte del enrutador.
-Códigos de respuesta HTTP:Como estamos tratando con URLs, debemos tener en cuenta los posibles códigos de respuesta HTTP. Específicamente los códigos de respuesta incluyen: {200, 301, 302, 403, 404}. El tiempo de ejecución del visor utiliza estos códigos para comportarse correctamente.
-Carga útil de datos:El enrutador puede potencialmente devolver una carga útil de datos que más tarde se utiliza para renderizar la página dinámica específica. Esta carga útil puede, por ejemplo, introducirse en un conjunto de datos que se utiliza para enlazar componentes en la página.
-Título:El título de la página que se mostrará. El visor en tiempo de ejecución lo utiliza para establecer el título de la página para el navegador. El título puede calcularse a partir del contenido recuperado para la página dinámica específica.Normalmente, las distintas rutas pueden dar lugar a títulos diferentes.Por ejemplo, laruta</zoo/animal_of_the_day/><puede resolver a la página dinámica para mostrar un animal, con el título>"Nuestro animal<del día ->¡el Tigre!".<La>ruta</zoo/animals/tiger>puede<resolver a la misma página dinámica, pero el título será sólo>"Nuestro tigre".<Por lo tanto, la plantilla para crear el título suele formar parte de la configuración del>enrutador para esa ruta específica.
-Metaetiquetas SEO:Información relacionada con SEO, más sobre esto más adelante.
Página Roles en profundidad
Como se ha explicado anteriormente, el sistema utiliza roles de página para determinar a qué página dinámica real resolver. Los roles de página permiten a las aplicaciones crearAlternativas.Con esto queremos decir que el usuario de una aplicación puede crear páginas dinámicas específicas para contenidos concretos, que pueden diferir de la página dinámica estándar utilizada para otros contenidos.
Por ejemplo, en una aplicación de blog, puede haber dos páginas dinámicas diferentes:
- Página de publicación estándar, con el rol <post-page>
- Página de publicación específica, con el rol <post-page-id-123>.
El enrutador resuelve una URL entrante de la forma<site>/<blog>/<post-id-xxx>. Calculará la siguiente lista ordenada de roles de página: {post-page-id-xxx, post-page}.
Para todas las URLs entrantes que tengan un id diferente de 123, el enrutador resolverá a la página de publicación estándar.Sin embargo, para la URL <site>/<blog>/<post-id-123>, el enrutador resolverá a la página específica para esa publicación 123.
A través de este mecanismo hemos creado unaestrategia alternativapara resolver páginas dinámicas. Si más tarde el usuario decide añadir una página específica para el id de publicación 321, todo lo que tiene que hacer es añadir una nueva página dinámica con el rol de página correcto, y el enrutador sabrá resolver a esa página.
Puntos finales del mapa de sitio
Unm apa de s itioes una lista de las URLs expuestas por un sitio determinado. En el contexto del modelo dinámico, esta lista contiene la lista de URL y, para cada una de ellas, la información añadida que necesitan los consumidores del mapa del sitio.
Los mapas del sitio sirven para dos escenarios diferentes:
- En primer lugar, se utilizan con la intención clásica de exponer la lista de páginas de un sitio a una solicitud de un robot. En este caso, el punto final del mapa del sitio del enrutador calcula la lista completa de URL que puede resolver y las devuelve a la solicitud entrante del robot.
- En segundo lugar, los mapas de sitios también pueden utilizarse en el editor. En este caso, el editor envía una solicitud al punto final del mapa del sitio y utiliza los resultados obtenidos para que el usuario final seleccione una de las URL devueltas. Esto es útil en dos casos distintos:
-Cuando el usuario crea un enlace a una p ág ina dinám ica.Para que se cree el enlace, el editor necesita la URL completa a la que enlazar.
-Cuando e l usuario desea p rev isu alizar una p ágina dinám ica.En este caso, necesitamos conocer la URL exacta que resuelve a esta página para saber cómo proporcionar a la página los datos que necesita para que se muestre correctamente.
Implementar correctamente los mapas de sitios
Deben tenerse en cuenta los siguientes aspectos.
Contabilización de credenciales de usuario
La lista de URLs debe tener en cuenta las credenciales de usuario para la llamada. Para una solicitud robot (anónima), el mapa del sitio sólo debe contener URLs que estén disponibles públicamente. Un robot no debe ver las URL prohibidas a un usuario anónimo. Por ejemplo, supongamos que tenemos una aplicación que tiene un enrutador con<el prefijo <my_app>. Si esa aplicación tiene páginas>ba]o<site>l<my_app>/<admin/salaríes><para gestionar los salarios>de los empleados, esta URL no debería devolverse a quien llama.
Contabilización de las URL que generan un código de respuesta 404
Es posible que un enrutador pueda resolver ciertas URLs, pero que el sitio no haya definido una página dinámica con el rol de página correcto para renderizar esa URL. En estos casos, el enrutador resolvería a un código de respuesta 404. Es responsabilidad del punto final del mapa del sitio del enrutador eliminar dichas entradas de los resultados que devuelve a una solicitud de robot.
Contabilización de rutas
Un enrutador puede potencialmente soportar rutas que no son usadas por un sitio específico. Por ejemplo, considere un enrutador de blog que admita rutas como </posts/post-id> y también </posts/featured-posts>. Sin embargo, en el caso de un blog de un sitio específico, el usuario podría haber decidido no utilizar la capacidad de publicaciones destacadas y, por lo tanto, no marcó ninguna publicación como destacada y ni siquiera creó una página dinámica para publicaciones destacadas.
En tal caso, el mapa del sitio no debería devolver esta URL, de lo contrario un robot podría intentar buscarla y obtendría una respuesta 404, o peor aún, obtendría otra página dinámica con una lista vacía de publicaciones.
La forma de evitar estos problemas es que la generación del mapa del sitio tenga en cuenta las rutas soportadas por la instancia de la aplicación en un sitio, y sólo genere URLs para las rutas soportadas.
Contabilización de los indicadores "sin índice" en una página dinámica
Un usuario puede marcar una página dinámica como "sin índice". Esto significa que no debe ser indexado por un robot de búsqueda. Cuando el punto final del mapa del sitio calcula la lista de URL, también debe calcular el ID de página al que resuelve cada URL. Si ese ID de página está marcado como "sin índice", esa URL debe eliminarse de la lista. Entradas del punto final del mapa del sitio
Para calcular el mapa del sitio, el punto final se basa en las siguientes entradas:
-Instancia firmada:Utilizado por el punto final para saber qué mapa del sitio de instancia de aplicación debe generar
-Credenciales de usuario.Codificado en la instancia firmada, para que el enrutador pueda generar el mapa del sitio que contiene las URL que el usuario tiene permiso para ver
-Indicador "Is_editor':Así, el punto final puede generar un mapa del sitio adecuado para el uso del editor. El editor necesita información para mostrar el mapa del sitio al usuario final, que el robot no necesita.
-Configuración del enrutador.Información sobre la forma en que este enrutador específico genera los mapas del sitio.
-Rutas en uso en este sitio:(como parte de la configuración del enrutador) Lista de rutas soportadas. El mapa del sitio generado sólo debe incluir las rutas que están en uso en la instancia específica de esta aplicación en este sitio específico.
-Lista de las páginas dinámicas de este enrutador y sus roles de página:Se utiliza para asegurarse de que el mapa del sitio sólo incluye URLs que realmente corresponden a una página dinámica. Cualquier URL que no lleve a ninguna página debe excluirse de la lista.
-Indicador "sin índice" por página dinámica para este enrutador (parte de la configuración de ruta):Las URL que resuelven a una página marcada con "sin índice" no deben aparecer en el mapa del sitio generado para un robot. Sin embargo, las mismas URL deben incluirse si la solicitud procede del editor, ya que en ese caso no importa si la página resuelta está indexada o no.
Salidas del punto final del sitio web
Para las solicitudes de robots, se debe emitir lo siguiente:
-Lista de URLque el robot debe escanear
- Por URL, los siguientes parámetros (todos opcionales):
-Fecha de la última modificación
- Cambiar la frecuencia
- Prioridad al índice
Tenga en cuenta que una sola solicitud de mapa del sitio no debe devolver más de 50.000 URLs. En este momento no tenemos previsto permitir la paginación de los resultados: si tiene más de 50.000 URL, omita las adicionales. Para una especificación completa del protocolo sitemap para robots, ver aquí.
Para las solicitudes del Editor, se debe emitir lo siguiente:
-Lista de URL
- por URL, los siguientes parámetros:
-Título amistoso.Se utilizará al crear enlaces en el editor a una página dinámica específica, y por el cuadro de selección de vista previa en el editor.
-ID de página a la que resuelve esta URL.Será utilizado por el diálogo de creación de enlaces del Editor para permitir al usuario seleccionar una URL que resuelva a una página dinámica específica.
Nota al margen: el selector de vista previa
Cuando el usuario quiere previsualizar una página dinámica, el editor debe saber qué sufijo URL utilizar para esta página dinámica. El elemento selector de vista previa invoca el mapa del sitio y filtra los resultados para las URL que se resuelven con este ID de página dinámico. A continuación, el usuario navega por la lista y selecciona la URL por su título amigable. Ahora el editor conoce el sufijo de URL correcto que debe utilizar para mostrar la página dinámica. Nota al margen: creación de enlaces
Supongamos que el usuario quiere crear un enlace a una página dinámica. El editor recupera el mapa del sitio y busca las URL que corresponden a este ID de página. El usuario navega por las URL fijándose en su título amigable, y selecciona una. El editor crea ahora un "enlace de enrutador" a ese ID de página específico, utilizando el sufijo de la URL seleccionada.
Enrutamiento dinámico y metaetiquetas SEO
Un enrutador debería proporcionar meta-etiquetas como parte de su punto final resolver-URL. Entre las principales figuran: "título", "sin índice", "descripción" e "imagen". Depende del enrutador proporcionarlos por URL resuelta, de la forma que tenga sentido para la aplicación y ese enrutador. Es decir, la infraestructura del visor/editor es agnóstica a las metaetiquetas. Cada aplicación puede proporcionar un Iframe para definir el comportamiento de sus metaetiquetas. Este Iframe se muestra como parte del diálogo de configuración de una página dinámica. La información puede conservarse como parte de la configuración del enrutador y utilizarse posteriormente para generar la respuesta correcta.
Cookies y cabeceras HTTP
Las cookies no se envían a los distintos puntos finales. En cuanto a las cabeceras, la lista final de cabeceras que es importante admitir aún está por determinar.
páginas 404 y 403
Estas páginas tienen soporte incorporado como parte del visor/editor infra. El usuario puede crear tales páginas especiales, y si existen, la infra sabrá enrutar a ellas en caso de que se reciba el código de respuesta HTTP apropiado. Problemas entre dominios al implantar un enrutador dinámico
Aún TBD
Ejemplo completo
Aún TBD
El enrutador de enlace de datos
En esta parte del documento, explicamos elEnrutador de Enlace de Datosy la forma en que se construye sobre la infra de enrutamiento dinámico detallada en la primera parte de este documento.
Breve recapitulación de los conceptos de enlace de datos
Suponemos que el lector conoce los fundamentos del modelo de enlace de datos.
Aun así, a continuación, se presenta un breve sumario de los componentes de enlace de datos:
-Colección,un conjunto de registros basado en mongo-DB.
-Esquema:el metamodelo de los datos de una colección. El esquema de una colección se guarda en un archivo de esquema (uno por colección).
<- Gestor de contenidos>:<una aplicación similar a una hoja de cálculo a través de la cual el usuario puede gestionar>el contenido de las colecciones
<- Datos Wix>:<una biblioteca que proporciona acceso a datos, como parte de código wix. Datos Wix tiene una interfaz>de cliente y una capa de interfaz del sistema que se encarga de ejecutar los ganchos proporcionados por el usuario, aplicar permisos, realizar validaciones, etc.
<- Conjunto de datos>,<un elemento editor/visualizador que permite a los usuarios enlazar elementos Ul a datos>proporcionados a través de las APIs de datos wix
-Enlace de datos:capacidad de enlazar un componente visual a datos mediante el uso de un conjunto de datos. -Dev DB:la instancia de base de datos con la que trabaja el editor.
-Prod DB:la instancia de base de datos con la que trabaja un sitio activo.
El enrutador de enlace de datos
Para completar la oferta de nuestro sistema de enlace de datos, deseamos proporcionar un enrutador que tienda un puente entre una URL dinámica y los datos necesarios para renderizar una página dinámica.
Esencialmente, el enrutador de enlace de datos es responsable de parsear una URL entrante, y transformarla en una consulta usando datos de wix. Una vez obtenidos los resultados, se introducen en un tipo especial de conjunto de datos, que a su vez proporciona datos al elemento de la página renderizada.
Repasemos los diferentes elementos que componen este sistema: crear la consulta adecuada, devolver los datos al cliente y utilizar un conjunto de datos especial para enlazar los datos a los componentes de la página.
Transformación de una URL en una consulta de datos wix
<Supongamos que tenemos una colección de>animales<con registro de animales. Supongamos también que queremos>que nuestra página de animales tenga la ruta: /animals/{{animal_name}}. ¿Cómo puede nuestro enrutador generar la consulta de datos wix correcta?
El enrutador debe realizar lo siguiente:
- Saber qué colección consultar ^ mantendremos el nombre de la colección como parte de la configuración del enrutador al definir las rutas.
- Saber qué campo(s) consultar ^ mantendremos un mapeo en la configuración del enrutador. En este caso, asignamos {{animal_name}} al campo "nombre
-Generar la sintaxis de consulta correcta^ esto es un poco más complicado. El valor de la URL está siempre en minúsculas y sin espacios. Sin embargo, el valor de la colección suele estar en una forma más legible para el ser humano. Por ejemplo, el nombre del animal puede ser "lobo gris" en la colección, pero "grey-wolf" en la URL. Para ello, el enrutador debe generar una "consulta regex" que busque en la colección todas las permutaciones posibles de "grey-wolf": {"Grey Wolf", "Grey-Wolf", "grey wolf", etc.}
Devolución de datos al cliente
Esto es bastante sencillo. El enrutador proporciona su carga útil mediante la API resolve_url() y ya está.
Utilizar un conjunto de datos para enlazar los datos obtenidos a los elementos de la UI
Ahora que los datos están disponibles para su uso en el lado del cliente, necesitamos un conjunto de datos para empujar en los componentes de interfaz de usuario en la página. Este conjunto de datos tiene algunas características<especiales, de ahí que lo llamemos>Conjunto de Datos de Enrutadores.<Este conjunto de datos tiene los siguientes>comportamientos especiales:
• En tiempo de ejecución, espera una carga de datos y se inicializa con ella en lugar de emitir una consulta de datos wix por sí misma.
• En tiempo de ejecución, cuando necesita obtener más datos (por ejemplo, cuando se desplaza una cuadrícula, etc.), necesita acceder al filtro definido por el enrutador para esta URL. Por lo tanto, sabe cómo generar una consulta de datos wix que devolverá resultados similares a la consulta creada por el enrutador.
• En el momento de la edición, no permite al usuario anular sus filtros en las partes vinculadas a los elementos URL. Tenga en cuenta que el usuario puede añadir más filtros y especificar la ordenación y el tamaño de la página, como para un conjunto de datos normal.
• En el momento de la edición, no permite al usuario moverlo para que esté en la página maestra (ya que está vinculado a la URL, lo que implica una página específica).
• Otros comportamientos relacionados con la UX (por ejemplo, notificación especial si se va a eliminar, o comportamientos especiales cuando se duplica).
Generación de enlaces a partir de patrones de URL
Centrémonos ahora en la generación de enlaces. Supongamos que queremos una página de índice muy simple, que muestre todos los animales en una cuadrícula, con un enlace a la página única de cada animal. ¿Cómo generamos estos enlaces para utilizarlos en la cuadrícula?
La idea básica es utilizar los conocidos patrones URL, o rutas, definidos para páginas dinámicas para una colección específica. Una vez conocidos estos patrones, podemos generar enlaces a partir de ellos.
Por ejemplo, digamos que tenemos tres patrones de URL diferentes en nuestro sistema:
-[ruta principal]\zoo¥animals ^ página de colección de todos los animales del zoológico
-[ruta hábitat]\zoo\animals/{{habitat}}^ muestra los animales que viven en el {{habitat}}
-[ruta animal]/zoo/animals/{{animal_name}} ^ página específica del animal
Una vez que hemos definido estos patrones, dado un registro en la colección de animales, podemos crear estas tres URLs. Para que esto funcione hay que introducir algunos conceptos nuevos en nuestro sistema.
Extensiones del esquema
<Una>extensión deesquema<es un segmento en el archivo de esquema de una colección que es proporcionado por>una aplicación. Esta extensión suele añadir elementos de esquema a un archivo de esquema existente.
En nuestro caso, una vez que una nueva ruta es añadida (o cambiada, o eliminada) para una colección dada, el sistema modifica la extensión del esquema proporcionada por la aplicación de enlace de datos para la colección<relevante. Para cada ruta, creamos un>campo calculado Efímero<(ver más abajo) que indica al sistema cómo generar>una URL para la ruta.
Campos calculados efímeros
Estos campos son (a) calculados y (b) efímeros. Esto significa que nunca se mantienen en el registro real de la colección, sino que se calculan al recuperar los datos de acuerdo con el cálculo especificado.Todos estos cálculos tienen lugar en la capa de interfaz del sistema de datos wix.
En nuestro caso, para las rutas de ejemplo dadas anteriormente, creamos tres campos de este tipo:
- Main_URL: cadena. Val = "/animals/'
- Habitat_URL: cadena. Val = "/animals/" to_url_part(field_val["habitat"])
- Animal_URL: cadena. Val = "/animals/" to_url_part(field_val["name"])
Nótese que el cálculo anterior no especifica la parte <site>de la URL, ya que es desconocida para el motor da datos wix que realiza los cálculos.Corresponde al enrutador completar el cálculo y añadir la parte <site> que falta para crear URL completas.
Campos de referencia
En futuras versiones, añadiremos campos de referencia de una colección a otras colecciones. La existencia de estos campos permitirá la creación de URL que enlacen desde un elemento de la colección A a elementos de la colección B. Es decir, si tenemos en la colección A un campo de referencia a la colección B, en el que tenemos un ID de un elemento de la colección B, podemos utilizar ese ID para generar los enlaces URL adecuados basándonos en los campos de enlace efímero definidos en la colección B.
Sin embargo, no para la versión actual.
Otras consideraciones para el enrutador de enlace de datos
Roles de página en el enrutador de enlace de datos
Nótese que al menos en la v i de este sistema, no planeamos usar múltiples roles por página dinámica, o permitir al usuario especificar roles personalizados para una página. Esto significa que los usuarios no pueden crear "páginas alternativas" o páginas más específicas de acuerdo con las capacidades genéricas de los roles de página.
Especificación de metaetiquetas SEO
Los metaetiquetas SEO se gestionan a través de un Iframe proporcionado por la aplicación de enlace de datos a la infra de diálogo de configuración de página proporcionada por el editor. A través de ese Iframe, el usuario puede especificar cómo generar metaetiquetas SEO por página dinámica propiedad del enrutador de enlace de datos. Esta configuración es persistida como parte de la configuración del enrutador, y pasada a los puntos finales del enrutador para generar las metaetiquetas correctas basadas en los datos recuperados de la base de datos.
<Por ejemplo, el usuario puede especificar la siguiente expresión para el título de la página "animal":>"¡Conoce a nuestro magnífico {{nombre}}!".<El enrutador generará entonces el título correcto al recuperar los datos.>
El punto final del mapa del sitio
La implementación del mapa del sitio es relativamente sencilla:
- Por colección, recuperar todos sus elementos.
- Como hemos computado campos por ruta URL, ya tenemos la información deseada.
- Todo lo que queda es obtener elconjunto distintode URLs calculadas y devolvérselo a la persona que llama. Ganchos en el enrutador de enlace de datos
Planeamos soportar la habilidad de permitir que el código de usuario se ejecute antes y después de que el enrutador realice su funcionalidad. El mecanismo básico es similar a los ganchos de interfaz del sistema que tenemos en datos de wix hoy en día - el usuario puede registrar una función que será llamada antes o después de que el enrutador se ejecute.
El gancho de antes obtiene los mismos parámetros de entrada que el propio enrutador, y puede o no pasarlos a la implementación real del enrutador.
El gancho de después obtiene los parámetros de salida de la ejecución del enrutador, y puede alterarlos antes de que sean enviados de vuelta como parte de la respuesta HTTP.
Cuestiones pendientes
- dev/prod db
- Permisos a nivel de página
El enrutador personalizado
- Crear un enrutador personalizado
- Creación de páginas dinámicas personalizadas
- API para un enrutador personalizado, incluidos los errores
- Uso de roles de página con un enrutador personalizado
- Uso del enlace de datos con un enrutador personalizado
09 - DYP
Páginas dinámicas
Páginas dinámicas
Descripción general
Cuando creas una página dinámica, estás diseñando un diseño de página que puede usarse una y otra vez, cada vez mostrando diferente contenido de tu colección de base de datos.
A diferencia de una página normal, que sólo tiene una url que puede llevar a ella, una página dinámica puede tener diferentes URLs. El contenido que se muestra en la página depende de la URL que se haya utilizado para acceder a ella.
Dado que una página dinámica muestra un contenido diferente cada vez que se visualiza, no es como una página normal. Una página normal almacena su contenido en la propia página, mientras que el contenido de una página dinámica se almacena en una colección de la base de datos.
Por ejemplo:
Digamos que usted tiene un sitio de recetas y le gustaría diseñar una página que muestre los datos de una sola receta. Con las páginas estáticas normales, tendría que crear una página distinta para cada una de sus recetas. Con las páginas dinámicas, sólo creará una página dinámica y le asignará un patrón de URL que puede determinar la receta específica que debe mostrarse en tiempo de ejecución.
Si cada una de sus recetas (almacenadas en una colección WixData) incluye un campo llamado "título", puede definir que la url de la página dinámica sea "www...Vrecipes/{title}".
Cuando un usuario navega a "www.../recipes/pizza", la página mostrará el contenido de la receta titulada "pizza", etc... Componentes principales / Elementos de Código Wix relacionados
Gestor de contenidos (y base de datos de Datos Wix)
Utilizado por el usuario para crear colecciones y gestionar sus datos
Aplicación de edición de enlace de datos
Enriquece el editor Wix con paneles que permiten al usuario crear y gestionar páginas dinámicas y conectar los componentes de la página a las partes de contenido relevantes para ellos.
Enrutador de enlace de datos
Una aplicación de interfaz del sistema que acepta 2 tipos de solicitudes:
1. Solicitud de enrutamiento - cuando se carga una página dinámica que pertenece a la aplicación de enlace de datos, el visor wix solicita al enrutador la página y el contenido a mostrar para una URL de entrada dada. El enrutador intentará hacer coincidir la URL dada con los patrones definidos por el propietario del sitio y buscará contenidos relevantes en la base de datos. Si se encuentra, el enrutador responde con el identificador y el contenido de la página correspondiente.
2. Solicitud de mapa del sitio - cuando un robot solicita el mapa del sitio de un sitio Wix, y el sitio incluye páginas dinámicas que pertenecen a la aplicación de enlace de datos, se solicitará al enrutador que devuelva una lista de todas las URL posibles que puede resolver.
Aplicación de visor de enlace de datos
Se ejecuta cuando se carga una página dinámica. Recibe el contenido devuelto por el enrutador y lo enlaza a los componentes de la página de acuerdo con sus configuraciones.
Información técnica
Todo el código está escrito en JavaScript.
Utilizamos diferentes bibliotecas de código abierto que se entregan con el código, tal como react, redux, lodash, co y más...
Otras bibliotecas de código abierto se utilizan para construir y probar el código, pero no se envían con él: webpack, babel, mocha, eslint, y más...
Servicios de terceros
Sentry
El código utiliza un servicio de terceros llamado Sentry (https://sentry.io) para registrar flujos problemáticos que ocurren en tiempo de ejecución (tanto en tiempo de editor como de visor).
Cada vez que ocurre algún error, el código envía información sobre el error y el contexto actual a Sentry. Esta información incluye cosas como:
- Versión de la aplicación
- Configuración del editor
- Descripción de los errores
- URL del sitio / editor
- URL de referencia
- Agente de usuario (tipo y versión del navegador...)
- Sistema operativo
- Contenido de la base de datos del usuario
- Código escrito por el usuario en el IDE
- Acciones del usuario que provocan el error
10 - DBG
Enlaces de datos
Conjunto de datos y enlace de datos
El elemento central del sistema de enlace de datos es elConjunto de Datos.Un conjunto de datos es un proveedor de datos del lado del cliente, al que las construcciones visuales (es decir, los componentes del editor) pueden enlazarse bidireccionalmente. También es el canal a través del cual la aplicación cliente gestiona los datos, implementando un protocolo de recuperación y mutación de datos con la capa lógica de la interfaz del sistema y, en última instancia, con el propio almacén de datos.
El tipo más simple de conjunto de datos es unconjunto de datos de colección.Tal conjunto de datos simplemente recupera datos de una colección específica, permite ordenarlos y filtrarlos basándose en los metadatos de campo del modelo subyacente, y permite a sus consumidores iterar sobre los registros y potencialmente crear nuevos y actualizar los existentes. Se trata de unconjunto de datos basado en consultas.Un conjunto de datos de este tipo se maneja mediante una consulta sobre una única colección.
Los elementos del editor pueden estar vinculados a un conjunto de datos. En concreto, una propiedad del elemento editor está enlazada a una representación de campo de colección en el conjunto de datos. Se pueden vincular varios elementos al mismo campo del conjunto de datos.
En tiempo de ejecución, se produce el siguiente escenario (simplificado):
- Se carga una página
- Se ejecuta el código de la página. Para ello, se crean uno o varios conjuntos de datos (más adelante se explica cómo se adjuntan los conjuntos de datos a las páginas).
- El conjunto de datos se conecta ahora a las construcciones de la UI. Esto ocurre de la siguiente manera:
- Localice los componentes de página vinculados a este conjunto de datos.
- Para cada uno de ellos, cree unadaptadorque facilite la interacción entre el conjunto de datos y el componente.
- El adaptador se registra como receptor de los eventos de cambio de ese componente, por lo que puede transmitir los cambios al conjunto de datos.
- Ahora el conjunto de datos se rellena ejecutando su capacidad de recuperación de datos.
- Una vez que se dispone de los datos iniciales, mediante el uso de los adaptadores correspondientes, los datos se establecen en los controles vinculados a datos pertinentes.
- Ahora, el estado del conjunto de datos puede cambiar como reacción a uno de muchos acontecimientos: - Llamadas a "registro siguiente", "registro anterior", etc.
- Llamadas a "página siguiente", "página anterior", etc.
- Cambios en el registro actual mediante entradas del usuario
- Etc.
- Cada vez que se produce un cambio en el estado del conjunto de datos, envía órdenes de actualización a través de sus adaptadores a todos los componentes vinculados
- Además, el conjunto de datos puede"confirmar"los cambios en su almacén cuando se le solicite.
Esto puede ocurrir automáticamente cuando el puntero del "registro actual" se mueve a un nuevo registro, o explícitamente a través de una llamada a la API "confirmar cambios". Más adelante hablaremos de ello.
Estados del conjunto de datos
11 -CMGR
Gestor de contenidos
Gestor de contenidos (CMGR)
CMGR es una aplicación de gestión de datos tipo Excel que permite al usuario manipular los datos almacenados en las colecciones de Datos Wix. La aplicación consta de dos partes principales: Aplicación CMGR Editor y aplicación CMGR My Account, que residen en partes respectivas del sitio Wix.
Gestor de contenidos en editor (CMGR Editor)
El Editor CMGR es abierto por el Trabajador Web del Lado Cliente. Obtiene Editor SDK que es mediador entre Editor API y CMGR y permite a CMGR manipular el estado del sitio Wix. CMGR Editor permite:
- ver y editar datos de prueba/Sandbox de un sitio (usando Wix Data API)
- editar permisos de colección (utilizando el SDK Editor para modificar archivos en Cloud VFS)
- ver y editar ganchos de Wix Data (la edición se realiza en un panel externo en Santa Editor, las modificaciones se almacenan en Cloud VFS)
- sincronizar los datos de la colección desde el Sandbox al en vivo y viceversa (usando Wix Data API)
- previsualizar datos en vivo(mediante la Wix Data API)
- gestionar esquemas: crear nuevos, añadir/editar/eliminar campos (utilizando el SDK Editor para modificar archivos en Cloud VFS)
Gestor de contenidos en My Account (CMGR My Account)
CMGR My Account es abierta por Wix Dashboard. Permite:
- ver y editar datos en vivo de un sitio (usando Wix Data API)
- Añadir campos temporales (no definidos) a los datos que no persisten en el esquema
Cuadrícula del gestor de contenidos
Es componente primario tanto en CMGR Editor como en CMGR My Account. Utiliza el esquema de la colección para construir las columnas de la cuadrícula. El esquema se almacena en el sistema de archivos Wix Code asociado a un sitio Wix en particular. Utiliza los datos del usuario cargados desde Wix Data para construir las filas de la cuadrícula. Permite:
- Gestionar elementos de la colección (filas): añadir, editar, eliminar, duplicar (usando Wix Data API)
- Alternar la visibilidad de los campos
- Filtrar datos (mediante la Wix Data API)
- Ordenar datos (mediante la Wix Data API)
Tipos de datos
CMGR maneja múltiples tipos de datos: cadenas, números, booleanos, fechas, enlaces de páginas, imágenes, arreglos y objetos JavaScript, referencias.
Cadenas, números, booleanos, fechas, arreglos y objetos son tipos primitivos (soportados nativamente por JavaScript).
Los Pagelinks son cadenas especiales que no se almacenan en una colección y son construidas por wixData en tiempo de ejecución dado un patrón para una Página Dinámica. Un Pagelink se puede utilizar para enlazar a una página dinámica en un sitio Wix.
Las imágenes son cadenas a recursos externos o cadenas especiales de Wix Media que hacen referencia a archivos almacenados en servidores de Wix Media. El usuario puede subir imágenes a través de Wix Media Dialog.
Las referencias son punteros a otras colecciones, usadas para permitir uniones entre colecciones de Wix Data. Implementación
La aplicación es renderizada por la estructura de código abierto React:
httDs://aithub.com/facebook/react
El estado de la aplicación se gestiona con la biblioteca de código abierto redux: https://github.com/reactjs/redux<La cuadrícula es renderizada por la librería de código abierto>ag-grid<que consta de tres componentes:>
1. ag-grid (https://github.com/ceolter/ag-grid).
2. ag-grid-enterprise (https://github.com/ceolter/ag-grid-enterprise)
3. ag-grid-react (https://github.com/ceolter/ag-grid-react)
12 - DSEO
SEO dinámico
Wix Code - Descripción del subsistema SEO
El renderizador SEO "regular" para sitios Wix toma los datos JSON estáticos que representan el sitio y los usa para renderizar una versión reducida del sitio para los robots de búsqueda (sin usar la lógica de renderizado regular que se implementa en el lado del cliente).
Dado que Wix Code introduce la posibilidad de que el usuario cambie el sitio dinámicamente, necesitamos un mecanismo diferente/adicional que pueda renderizar el sitio de forma que incluya esos cambios, lo que puede incluir enrutamiento dinámico de páginas y lógica arbitraria del usuario.
Principales subcomponentes del subsistema SEO
• Un servicio de envío ("Cloud SEO Dispatcher") que recibe solicitudes RPC del renderizador Wix SEO y las envía a los trabajadores disponibles para su procesamiento
• Una cuadrícula de "Cloud SEO Workers" que procesan las solicitudes de renderizado.
Cada trabajador ejecuta un navegador Chrome sin cabeza que se utiliza para ejecutar código cliente (también conocido como "Mini Santa") que realiza el procesamiento real.
(incluyendo la ejecución de código de usuario, etc.), y produce el resultado como un conjunto de cambios a aplicar sobre las estructuras de datos estáticas que representan el sitio.
• Un servicio de gestión ("Cloud SEO Lifecycle") que realiza un seguimiento de los trabajadores disponibles y los sincroniza con cualquier cambio de configuración.
Flujo de renderizado
El renderizador SEO regular, cuando reconoce que el sitio está habilitado para WixCode, llama al "Cloud SEO Dispatcher" con los datos relevantes para el renderizado, y espera como respuesta:
• Diferencias para aplicar en los JSON del sitio (para masterPage página actual)
• En caso de enrutamiento dinámico de páginas, la pagelD de la página a renderizar metadatos SEO a renderizar El "Cloud SEO Dispatcher" entrega la tarea de renderizado a uno de los "Cloud SEO Workers" disponibles.
El Trabajador le dice a su instancia administrada de Chrome que renderice el sitio llamando a la función de renderizado de Mini Santa con los parámetros del sitio a renderizar.
La función de renderizado ejecuta el código que renderiza el sitio, pero en lugar de mostrar el resultado en la pantalla computa y emite:
1. Las diferencias entre las estructuras de datos iniciales del sitio estático y las estructuras de datos en tiempo de ejecución tras ejecutar el código de usuario.
2. Información dinámica de la página: qué página renderizar y qué metadatos SEO añadir al resultado renderizado. Estas diferencias resultantes viajan de vuelta por la cadena de llamadas, hasta el renderizador SEO "regular" de Wix, que las aplica a los datos estáticos iniciales y renderiza el HTML final que es enviado de vuelta al rastreador del motor de búsqueda.
13A - CFN
Funciones de cálculo
Wix Code - Funciones de cálculo
Resumen
Para cualquier sitio Wix, un usuario puede tener la capacidad de escribir una función que se expondrá como una interfaz web para el sitio a través del protocolo estándar HTTP.
Esta habilidad es valiosa para integraciones de servidor a servidor, por ejemplo, registrándose a aplicaciones de terceros a través de un Webhook, o exponiendo una REST API para el sitio web.
Añadir una función
<A través del Wix Code IDE un usuario tiene la posibilidad de añadir una>función de cálculo<- que abrirá una página>dedicada para escribir el código de la misma. El nombre de la función representa el prefijo de la ruta web relativa a la dirección del sitio web, a través del cual se puede llamar a la función utilizando el protocolo HTTP.
<Por ejemplo, la función denominada>Calcular<será accesible a través de la URL:>http[s]://mysite.com/_api/endpoints/compute/.<..>
El usuario también puede definir opcionalmente para qué métodos HTTP (GET / POST / PUT / DELETE) estará<disponible la función. El código se almacena en un servicio multiusuario, denominado>VFS,<bajo el espacio dedicado>al sitio del usuario.
El usuario dispondrá de la siguiente información de solicitud HTTP para su procesamiento:
URL, parámetros de consulta, cabeceras, carga útil, método HTTP.
El usuario puede generar una respuesta HTTP con las siguientes partes: código de estado, carga útil, cabeceras.
Ejecución de una Función
Después de que la función está disponible para acceso HTTP, y una petición HTTP es llamada para un servidor web de código wix (despachador), la primera validación es realizada para probar la existencia de una definición de función. Si la función no existe - se devuelve el estado 404 (Not Found). Si la función existe, el código se ejecutará en un<contenedor Docker aislado a través del servidor de aplicaciones>elementory<(ELM) que se ejecuta allí.>
Pruebas antes de publicar y depuración
<Durante la fase de desarrollo de una>función de cálculo<es posible probar la función a través de una HTTP URL de>prueba, la cual es suministrada a través del Wix Code IDE. También es posible ver los registros de la ejecución de la función, ya esté publicada o en desarrollo.
13B - CFN
Funciones de cálculo - detalladas
Wix Code - Funciones de cálculo
Panorama general
Este documento esbozará los requisitos funcionales y la propuesta de especificación técnica para exponer Web Endpoint como una API vía HTTP.
Este documento se basa en el trabajo de investigación
Requisitos Funcionales
Posibilidad de exponer un método de acceso web sin autorización
• Posibilidad de definir los métodos HTTP compatibles: POST, GET, PUT, DELETE (en la misma ruta)
• Capacidad para extraer (leer) el método HTTP, la ruta, las cabeceras, los parámetros de consulta y el cuerpo de la solicitud
• Posibilidad de escribir el código de estado HTTP de la respuesta, las cabeceras
<° Es bueno tenerlo: Posibilidad de definir el encabezado HTTP>Accept<para las solicitudes>
<° Es bueno tenerlo: Posibilidad de definir el encabezado HTTP>Content-Type<de la respuesta>
<• El acceso no autorizado a>los datos<debe ser gestionado por la capa de>datos
Especificación Web API HTTP
Cuando un método es expuesto para acceso web, el método se expondrá con la siguiente especificación.
URI
Sitios gratuitos
Sitio publicado:https://{user namelwixsite.com/ api/endpoints/{site name}/*
Desarrollo:https://{user name}.wixsite.com/ api-dev/endpoints/{site name}/*
Sitios Premium
Sitio publicado:hftps://{user domain}/ api/endpoints/*
Desarrollo:https://{user domain}/ api-dev/endpoints/*
La ruta relativa /_api/endpoints/(y /_api-dev/endpoints/) a la raíz del sitio será el punto de entrada raíz a todas las APIs definidas por el usuario. Llamaremos a este punto de entradaAPI root.Desde la perspectiva del usuario, esta URL será permanente. Los casos de uso cuando la URL va a cambiar son:
En sitio libre - el usuario cambió el nombre del sitio
En el sitio premium - el usuario cambió el dominio
Cuando el usuario cambia las subrutas internas después de laAPI root.
Transferencia del sitio -se puede cambiar el nombre de dominio
Pasar a premium - comprar un dominio / asignar un dominio existente
Todos a Todos - parece que la compatibilidad con versiones anteriores de la API es responsabilidad exclusiva del usuario.
Seguridad
Las URL están en el mismo dominio que el sitio del usuario. El riesgo potencial de seguridad puede surgir si se accede a esas URL a través del navegador, y el usuario escribe algún código no seguro involuntariamente.
Podemos abordar los ataques CSRF y XSS utilizando lo siguiente:
• CSRF - emplear la validación de cookies / encabezados para los agentes de usuario del navegador
• XSS - emplear la funcionalidad Content-Security-Policy por defecto en el dominio del usuario, con opción de exclusión o de definir la lista blanca
Podríamos mejorar aún más la seguridad utilizando SSL.
Solicitar
•Métodos HTTP permitidos:de acuerdo con la definición delendpoint
•El código de la función se encarga de extraer el cuerpo de la solicitud, los encabezados, los parámetros de consulta, la IP
Respuesta
•Código de estado de la respuesta:responsabilidad del código delendpoint
•Es responsabilidad del códigodel endpointsuministrar el cuerpo de una respuesta con el formato apropiado • Las cabeceras de respuesta también pueden suministrarse
Diseño de Wix Code
Prefacio
La dirección general es diferenciar los Módulos Web utilizados por las secuencias de comandos del sitiopúblicode la definición de losmétodosque están expuestos vía web públicamente para cualquier consumidor HTTP -llamémoslesfunciones de cálculo.Permitirá un diseño e implementación más simple, cuando se necesite un código compartido para ser usado desde la secuencia de comandos depúblicoy al mismo tiempo su formato de resultado por defecto no puede usarse tal cual para la exposición defunciones de cálculoweb y necesita algún masaje.
También permitirá definirfunciones de cálculoweb totalmente ajenas a la capa de presentación del sitio (las secuencias de comandos depúblico).
Por ejemplo, una función de cálculo web que escucha a Github Webhook, analiza los datos y almacena alguna información en una colección de base de datos, y hay una página dinámica que presenta los datos de la misma colección. En este caso no se trata de una secuencia de comandos de un sitio público.
Localización
Almacenaremos el código de la función de cálculo en un archivo JS dedicado. El usuario tendrá la posibilidad de definirfunciones decálculo - y el Ul abrirá el fichero donde estará el código de todas lasfunciones decálculo.
Tal vez tengamos que revisar este aspecto, si el código en ese archivo puede llegar a ser grande.
¿Cómo definir una función de cálculo?
Hay 2 aspectos de unafunción de cálculo.
1.El aspecto del tiempo de diseño: cómo el usuario define unafunción de cálculoy configura sus diversos aspectos, como el método HTTP, el tipo de contenido de la solicitud que acepta, el tipo de contenido de la respuesta que genera, etc.
2. El aspecto del tiempo de ejecución: una vez definida lafunciónde cálculo, se debe exponer un HTTPendpointapropiado que, cuando se llame, se redirija a la ejecución del código de lafunción decálculo, y cuando se elimine unafunción decálculo existente, se debe eliminar el HTTPendpointexistente. Por supuesto, esto debe estar disponible sólo después de la publicación del sitio, o antes de la publicación para fines de prueba de la función de cálculo por parte del usuario.
El aspecto del tiempo de diseño
• Definiremos funciones exportadas para cada prefijo de función de cálculo
• Tendremos los siguientes prefijos para las funciones:get_, post_, put_, delete_, use_
•El nombre de la función después del prefijo representará el prefijo de la ruta del punto final web
•TODO: todavía hay que cerrar el aspecto Ul de cómo definir una nueva función de cálculo
Para otras alternativas rechazadas, véaseel Apéndice A.
Pros:
• Definición sencilla, puede ser fácilmente asistida por Ul
• La configuración está cerca del código
• No se necesita reflexión
• Utilizando la actual especificación pública de JS
Contras:
• Enlace dinámico de funciones a llamadas HTTP: no existe configuración predefinida
• Pueden producirse definiciones ambiguas: por ejemplo, get_ y use_ en el mismo punto final
oPuede resolverse mediante un sencillo algoritmo de precedencia, que debería documentarse. Los métodos específicos tienen prioridad sobreuse_*
• Algunos caracteres no pueden formar parte del prefijo (por ejemplo, el carácter "-")
o Todos los caracteres no admitidos en el nombre de la función JS
Estructura de datos de solicitud y respuesta
Nos esforzaremos por tener una estructura de datos unificada para los objetos de solicitud y respuesta como para la función de enrutadores.
El aspecto del tiempo de ejecución - Asignación para la ejecución
Recordatorio - así que tenemos un archivo llamadocompute-functions.jspara cada sitio, donde la URL del punto final a la función de mapeo se encuentra junto con el código de la función en sí.
Asignación del sitio a la función de cálculo de Wix-Code
• Al crear una función de cálculo a través de la interfaz de usuario, se creará un archivo en elcontexto del sitio correspondienteen la ruta/compute-functions.js
Parece que no hay una manera fácil de obtener el Siteld del dominio. Hay 3 llamadas RPC para saber<qué>gridAppId<debemos lanzar.>
Probablemente queramos almacenar en caché esas 3 llamadas RPC, sin embargo, en caso de un cambio de metaSiteld / siteld / domain - necesitamos eventos para actualizar la caché, o actualizar la caché mediante algún sondeo periódico, lo que implicará consistencia eventual (en cualquier alternativa de actualización del caché, ya que no podemos confiar en que los eventos sean a prueba de balas). A nuestro entender, no hay ningún evento de cambio de metaSiteld o cambio de dominio.
La<propuesta es cachear>domain -> gridAppId. gridAppId<puede cambiar potencialmente después de guardar, por lo>que invalidaremos la caché en cada guardado - este evento ya se gestiona en Wix-Code. Sería mejor, si hubiéramos escuchado el evento publicar, si tal existe.
Si hay un cambio en el nombre de dominio / nombre de sitio libre - el nuevo dominio no estará en la caché, por lo que primero realizará todo el flujo para este nuevo dominio de nuevo y la caché.
El caché debería tener alguna política de desalojo basada en la última vez que se tocó.
El Aspecto del Tiempo de Ejecución: Visualización Previa frente a Publicación
<Cuando el usuario desarrolla su función de cálculo, ¿deberíamos proporcionar algún "dev>mode"<para el punto final>web antes de publicarlo?
Para nuevas funciones - es útil si el código de la función manipula datos. El usuario quiere asegurarse de que el nuevo código no corrompe los datos existentes, por lo que quiere probar el código antes de publicarlo. Además, cuando una función de cálculo ya está publicada, y el usuario necesita actualizarla, por ejemplo, para soportar algún protocolo nuevo, no quiere romper la funcionalidad existente de la función, hasta que esté seguro de que el código de su función más reciente funciona como se espera.
¿Cómo debe suministrarse esta capacidad? Es decir, ¿exponer la función actualizada a la web que funcionará en paralelo al punto final web publicado actualmente?
El Algoritmo
<• Cuando se carga el cliente editor, envía su SCARI al servicio>api-dispatcher<(a través de>ide-server)
•<El servicio api-dispatcher tendrá un mapeo>domain -> gridAppId<para pruebas>
o Es posible que queramos separar el segmento editor (pruebas) y el segmento público (acceso api a sitios publicados)
<o Este>gridAppId<representará la versión actual desarrollada en el editor, puede ser la publicada, si no se han>producido cambios desde la publicación, o una recién desarrollada (la no guardada)
<• Siempre que haya una llamada a>wix-code-service<de>cloneCodeApp</>duplicateCodeApp</>createApp -<el>gridAppId<recién generado se propagará al servicio>api-dispatcher
•<El acceso a la versión actualmente desarrollada se realizará a través del>development<URI, tal y como se indica>en la sección URI
<Y entonces, cuando la solicitud para>api-dev<es recibida por>api-dispatcher,<buscará en la caché>el gridAppíd<por dominio. Si no existe, puede volver al protocolo similar al de los sitios publicados, y almacenar en caché el>gridAppídde la última versión guardada.
<Otra alternativa puede ser que en la carga del editor - almacenemos en caché el>instanceld -> gridAppíd<de>wixcode<que fue enviado por el cliente (sin resolución del dominio), y luego en la solicitud>api-dev<real un flujo similar para resolver el dominio como en el diagrama anterior, y almacenar en caché también el>domain -> gridAppíd.
<Y entonces, cuando ocurra>cloneCodeApp</>duplicateCodeApp<- actualiza ambas cachés por>gridAppId<anterior (tendremos también índice inverso por>gridAppId).
Esto también resolverá el problema del "dominio cambiado".
Parece un mecanismo bastante complejo. ¿No podemos tener una limitación y exigir guardar antes de probar? ¿O<quizás algún otro evento "bajo demanda" para probar una API, por ejemplo,>test AP?
Depuración
<Uno de los dolores en el>hackaton<con>webhooks<fue la falta de capacidades de depuración para el código de interfaz>del sistema. Tendremos que añadir alguna capacidad, es una cuestión de producto abierta.
Solución preferida
El usuario tendrá un punto final web para el flujo continuo de salidas console.log, similar a este. [https://webtask.io/docs/api_logs]
Tendremos que considerarlo cuidadosamente, esto puede consumir muchos recursos.
Otras alternativas
• Proporcionar alguna API de registro, y tener algún archivo de registro rodante por sitio, que el usuario tendrá la capacidad de descargar a través del editor.
• Abre un Ul especial endev-mode,donde se imprimirán esos registros
o En realidad esto puede ser una adición a lasolución preferidaanteriormente
• El desarrollador puede proporcionar un encabezado, por ejemplo,x-debug,y a cambio recibirá un encabezado de respuesta con una URL única que contiene la información de depuración sobre la solicitud. Hasta 50 URL por sitio. La información se guardará en la memoria durante 5 minutos
o No debería haber ningún problema de memoria sabio, si esto se mantiene en la memoria de Elementary, dado, que tenemos 200 Elementary por máquina.
Apéndice
Alternativas de Aspecto de Tiempo de Diseño Rechazadas
Alt.1 : Casi un copiar / pegar de jax-rs API
Estaría bien poder usar@decorators,sin embargo, parece que estará disponible para la próxima especificación de javascript, ES8.
El transpilador Babel lo soporta en modo experimental.
Se puede utilizar entonces la reflexión para buscar todos esos métodos de funciones de cálculo y mapearlos de acuerdo con la configuración.
Pros:
• Declaración clara y sencilla
Contras:
• Parece que dicha asignación de los encabezados de tipo decontenido de Aceptación y respuesta de la solicitudserá difícil para el despachador, si, por ejemplo, se utilizan comodines. Tal vez debería suprimirse
•Utilización de especificaciones no finalizadas (actualmente fase 2 - https://github.com/tc39/proposal-decorators) • La reflexión es necesaria para encontrar las correspondencias pertinentes
Alt.2 : La configuración de las funciones de cálculo se almacena separada del código
Se puede suministrar un método especial, de nombre predefinido, donde el mapeo será declarado por el usuario.
Pros:
• Declaración bastante simple
• No se necesita reflexión
• Utilizando la actual especificación pública de JS
Contras:
• El nombre de la función se declara cadena - pueden producirse errores tipográficos
• La configuración está "lejos" del propio método
Alt.3 : Configuración Express
Se tendrá algún objeto global, que actuará como registrador de las funciones de computación, por ejemplo,WixComputeFunctions.
Pros:
•Definición simple, express como API
• La configuración está cerca del código
• No se necesita reflexión
• Utilizando la actual especificación pública de JS
Contras:
• Exposición del objeto global
• Pueden darse definiciones ambiguas: se necesita un algoritmo de precedencia
Alt.3.1 : Función de configuración con sintaxis similar a Express
<Un patrón tipo>express<para configurar el método HTTP, la ruta y la función a ejecutar.>
Pros:
• Definición simple, express como API
• La configuración está cerca del código
• No se necesita reflexión
• Utilizando la actual especificación pública de JS
Contras:
• Pueden darse definiciones ambiguas: se necesita un algoritmo de precedencia
14 -WDB
Wix DB
Panorama general
DocStore es un servicio de datos genérico multiinquilino de estilo documental que expone una API RESTful para la gestión de datos. Cada inquilino puede tener varias bases de datos virtuales independientes. El servicio también cuenta con una API de administración de servidor a servidor (no de cara al usuario) para gestionar las bases de datos de los inquilinos y, posiblemente, desactivar un inquilino.
Modelo de almacenamiento
La base de datos subyacente utilizada para almacenar los datos es MongoDB y el servicio soporta múltiples bases de datos físicas MongoDB para propósitos de fragmentación.
Mapeo de bases de datos virtuales/físicas
Tras la primera solicitud y después de pasar la comprobación de autenticación, cada base de datos virtual del inquilino es asignada a una de las bases de datos físicas MongoDB con las que el servicio está trabajando y a partir de ese momento, todas las solicitudes entrantes de la base de datos de ese inquilino se ejecutan contra esa base de datos física.
El mapeo de la base de datos del inquilino virtual a la base de datos física se mantiene en una base de datos de administración y los registros de mapeo en caliente se mantienen en una caché en memoria basada en LRU.
Modelo de base de datos virtual
Cada base de datos virtual de inquilinos puede contener una o más colecciones de documentos. Cada colección virtual se asigna a una colección física de MongoDB. La asignación de colecciones se realiza mediante un sencillo sistema de espaciado de nombres. Cada colección física se denomina <tenantld>@<vdb-name>@<collection-name>. De este modo, cuando llega una solicitud, tras pasar la comprobación de autenticación, se resuelven el ID de inquilino, la base de datos de destino y el nombre de la colección, se construye el nombre físico de la colección y se puede acceder a ella.
Asignación de bases de datos físicas
Cuando se introduce una nueva base de datos de inquilinos, es necesario asignarle una base de datos física de destino permanente. Actualmente, la selección de la base de datos física se realiza en función del tamaño de la base de datos. Se programa una tarea en segundo plano para que se ejecute periódicamente y recopile estadísticas de todas las bases de datos activas con las que el servicio está configurado para trabajar. Las estadísticas se almacenan en una estructura de datos en memoria, de modo que cuando llegue el momento de asignar una nueva base de datos, se pueda seleccionar rápidamente la más pequeña como objetivo.
15 - $WAPI
$WAPI
$w API
$W API es la forma en que se permite a los usuarios interactuar con los componentes del visor utilizando código. El SDK se utiliza para envolver la capa de comunicación interna utilizada entre el trabajador, donde el código de usuario / extensión se está ejecutando y el tiempo de ejecución (AKA el espectador). A continuación, se muestra un diagrama que representa la arquitectura lógica:
La necesidad
El modelo interno de RMI es demasiado complejo para los usuarios que quieren controlar y modificar sólo partes del sistema, y no está documentado y contiene información propietaria necesaria para funcionar. El $W SDK envuelve esto, y lo convierte en un patrón más común de localizar elementos y manipularlos.
Patrón de codificación:
El patrón de codificación soportado por el $w SDK consta de 2 partes:
1.Eventos del ciclo de vida de la página:Mediante los métodos del ciclo de vida, un código que utiliza el SDK se activa en etapas predefinidas. Durante estas etapas, el SDK está disponible y el código puede realizar diversas tareas, como la carga de datos externos, la inicialización de componentes o el registro de eventos. Actualmente hay un único método disponible, que ocurre antes de que se presente la página, y se llama PageLoad. Al devolver una promesa javascript, el código puede aplazar la presentación de la página hasta que se haya cargado toda la información asíncrona (tal como los datos externos procedentes de wix-data o de servicios externos)
2.Selección:$w representa el contexto global de una página. Pueden existir objetos de contexto similares, por ejemplo, un $item al dibujar elementos repetidores. A partir del contexto, el usuario selecciona elementos mediante una consulta de cadena. Los selectores son similares a los selectores CSS normales, con pequeñas diferencias. La selección puede devolver un único elemento o varios. Por ejemplo.
$w('#myElement') - esto seleccionaría el elemento con myElement ID
Los selectores son de los siguientes tipos:
° Selectores de ID: selección mediante un ID único de página
° Selectores de tipo: selección mediante el tipo de un componente
° Arreglo de selector de tipos
° Selector de rol - esto es usado por los controladores, para seleccionar usando sus propios nombres predefinidos. Un elemento puede tener un ID, y múltiples roles, dados por el controlador
3.Manipulación de elementos:una vez que se adquiere una referencia a un elemento, éste se dota de métodos para manipularlo. Algunos métodos están disponibles en todos los elementos, como ocultar y mostrar un elemento. Algunos métodos sólo están disponibles en determinados elementos. La lista completa figura en la documentación del SDK
4.Registro de eventos:cada elemento admite un conjunto predefinido de eventos. El código que utiliza el SDK puede registrarse en estos eventos y proporcionar métodos de devolución de llamada que se ejecutarán cuando se produzcan. Durante la devolución de llamada, es posible seleccionar y manipular.

Claims (15)

REIVINDICACIONES
1. Un método implementado por ordenador para actualizar una base (124) de datos de interfaz del sistema que contiene conjuntos de datos que pueblan una pluralidad de páginas web dinámicas de un sitio web, comprendiendo el método :
recibir (2602) a través de una interfaz (3531) de usuario, una pluralidad de elementos (211,2710, 2714, 2718, 2906, 3212) de datos, los elementos de datos organizados en uno o más grupos (210, 2710) de al menos un elemento de datos, cada grupo para su visualización en una página web dinámica separada de un sitio web; almacenar (2604) los grupos de al menos un elemento de datos en la base de datos de la interfaz del sistema; generar (2606) una pluralidad de páginas web virtuales y asociar (2612) una URL única a cada una de la pluralidad de páginas web virtuales, en donde:
cada una de la pluralidad de páginas (421, 2712, 3111, 3312) web virtuales se genera utilizando un mapa (230) del sitio que hace referencia a la URL única de cada una de la pluralidad de páginas virtuales, permitiendo el mapa del sitio la navegación entre la pluralidad de páginas web virtuales,
cada página web virtual es una vista previa de una página web dinámica real correspondiente (2910, 2912) antes de que la página web dinámica real correspondiente se active, y
cada una de las páginas web dinámicas reales correspondientes no está diseñada con funcionalidad para actualizar la base de datos de interfaz del sistema;
visualizar (2608) cada grupo de al menos un elemento de datos en una separada de la pluralidad de páginas web virtuales;
visualizar (2610) una herramienta de edición para permitir a un usuario editar una página web virtual de la pluralidad de páginas web virtuales;
recibir (2616, 2618) ediciones de la página web virtual;
traducir (2628) las ediciones de la página web virtual en actualizaciones para la base de datos de interfaz del sistema;
almacenar (2604) las actualizaciones en la base de datos de interfaz del sistema; y
habilitar (2632), durante una vista en vivo de una página web dinámica real correspondiente asociada a la página web virtual, una visualización en la página web dinámica real correspondiente con las actualizaciones realizadas en la página web virtual durante la vista previa.
2. El método implementado por ordenador de la reivindicación 1, en el que cada una de la pluralidad de páginas web virtuales es visualizable dentro de un marco asociado con una interfaz de editor de la interfaz de usuario.
3. El método implementado por ordenador de la reivindicación 1 o 2, que comprende, además: visualizar (2614) una característica seleccionable por el usuario que permite al usuario navegar a través de la pluralidad de páginas web virtuales para mostrar individual y dinámicamente cada una de la pluralidad de páginas web virtuales.
4. El método implementado por ordenador de cualquiera de las reivindicaciones 1 a 3, que comprende, además: visualizar una característica seleccionable por el usuario que permite al usuario seleccionar una página web virtual concreta de la pluralidad de páginas web virtuales basándose en un identificador de la página web virtual concreta.
5. El método implementado por ordenador de la reivindicación 4, en el que el identificador de la página web virtual particular se basa en un elemento de datos asociado con la página web virtual particular.
6. El método implementado por ordenador de cualquiera de las reivindicaciones 1 a 5, en el que la herramienta de edición está configurada para recibir ediciones de los grupos almacenados de al menos un elemento de datos en la base de datos de interfaz del sistema.
7. El método implementado por ordenador de cualquiera de las reivindicaciones 1 a 6, en el que la herramienta de edición está configurada para recibir ediciones de atributos de la pluralidad de páginas web virtuales.
8. El método implementado por ordenador de cualquiera de las reivindicaciones 1 a 7, en el que la herramienta de edición está configurada para recibir ediciones del código que se utiliza para generar la pluralidad de páginas web virtuales.
9. El método implementado por ordenador de cualquiera de las reivindicaciones 1 a 8, en el que la herramienta de edición está configurada para mostrar una pluralidad de segmentos de código esqueleto que representan código real utilizado para generar la pluralidad de páginas web virtuales, y recibir ediciones del código esqueleto que se traducen en ediciones del código real.
10. El método implementado por ordenador de cualquiera de las reivindicaciones 1 a 9, en el que los elementos de datos se reciben a través de la interfaz de usuario desde una fuente externa.
11. El método implementado por ordenador de cualquiera de las reivindicaciones 1 a 10, que comprende, además: acceder a un enrutador (3310) basado en software asociado a la pluralidad de páginas web virtuales; y configurar el enrutador basado en software para generar una versión diferente de cada una de la pluralidad de páginas web virtuales basándose en uno o más segmentos de una URL recibida.
12. El método implementado por ordenador de cualquiera de las reivindicaciones 1 a 11, en el que un subconjunto de cada grupo de al menos un elemento de datos se organiza mediante una función de resolicitud, la función de resolicitud genera una o más instancias visualizadas del subconjunto de cada grupo de al menos un elemento de datos.
13. El método implementado por ordenador de la reivindicación 12, en el que la vista en directo de la página web dinámica real correspondiente incluye la una o más instancias.
14. Un medio legible por ordenador para actualizar una base de datos de interfaz del sistema que contiene conjuntos de datos que poblaron una pluralidad de páginas web dinámicas de un sitio web, conteniendo el medio legible por ordenador instrucciones que, cuando son ejecutadas por al menos un procesador, hacen que el procesador realice el método de cualquiera de las reivindicaciones 1 a 13.
15. Un sistema para permitir ediciones dinámicas a páginas web dinámicas para actualizar una base de datos de la interfaz del sistema que contiene conjuntos de datos que pueblan las páginas web dinámicas, comprendiendo el sistema :
la base de datos de interfaz del sistema; y
al menos un procesador configurado para realizar el método de cualquiera de las reivindicaciones 1 a 13.
ES18848030T 2017-07-24 2018-07-24 Edición de una base de datos durante la previsualización de una página web virtual Active ES2970458T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201762536403P 2017-07-24 2017-07-24
US201862702278P 2018-07-23 2018-07-23
PCT/IB2018/001028 WO2019038588A1 (en) 2017-07-24 2018-07-24 EDITING A DATABASE WHEN PREDICTING A VIRTUAL WEB PAGE

Publications (1)

Publication Number Publication Date
ES2970458T3 true ES2970458T3 (es) 2024-05-28

Family

ID=65014202

Family Applications (2)

Application Number Title Priority Date Filing Date
ES18848030T Active ES2970458T3 (es) 2017-07-24 2018-07-24 Edición de una base de datos durante la previsualización de una página web virtual
ES23180890T Active ES3058727T3 (en) 2017-07-24 2018-07-24 Editing a database during preview of a virtual web page

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES23180890T Active ES3058727T3 (en) 2017-07-24 2018-07-24 Editing a database during preview of a virtual web page

Country Status (9)

Country Link
US (12) US11106860B2 (es)
EP (3) EP4664326A3 (es)
JP (5) JP7546481B2 (es)
AU (3) AU2018319444B2 (es)
BR (1) BR112019024309A2 (es)
CA (1) CA3060362A1 (es)
ES (2) ES2970458T3 (es)
IL (1) IL271915A (es)
WO (1) WO2019038588A1 (es)

Families Citing this family (81)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8671352B1 (en) 2013-05-07 2014-03-11 Axure Software Solutions, Inc. Variable dimension version editing for graphical designs
US9158656B1 (en) * 2014-07-15 2015-10-13 American Express Travel Related Services Company, Inc. Systems and methods for progressively launching websites
US11106860B2 (en) 2017-07-24 2021-08-31 Wix.Com Ltd. Common database for live operation and testing of a website
US20190065487A1 (en) * 2017-08-22 2019-02-28 Salesforce.Com, Inc. Filter logic in a dynamic page previewer
US11392664B1 (en) 2017-08-29 2022-07-19 Massachusetts Mutual Life Insurance Company Dynamic web application based on events
GB201804904D0 (en) * 2018-03-27 2018-05-09 Palantir Technologies Inc Code correction
JP2019211827A (ja) * 2018-05-31 2019-12-12 ファナック株式会社 支援装置
CN109213486A (zh) * 2018-08-20 2019-01-15 北京百度网讯科技有限公司 用于生成用户定制的可视化组件的方法和装置
US10592589B1 (en) 2018-08-21 2020-03-17 Axure Software Solutions, Inc. Multi-view masters for graphical designs
US10691428B2 (en) * 2018-10-24 2020-06-23 Sap Se Digital compliance platform
JP7373563B2 (ja) 2018-11-14 2023-11-02 ウィックス．コム リミテッド． ウェブサイト構築システム用の構成可能なアプリケーションの作成および処理のためのシステムおよび方法
US10757009B2 (en) 2018-11-20 2020-08-25 Amazon Technologies, Inc. Global-scale connectivity using scalable virtual traffic hubs
US11579908B2 (en) 2018-12-18 2023-02-14 Vmware, Inc. Containerized workload scheduling
JP2022100419A (ja) * 2019-04-23 2022-07-06 株式会社ラキール 情報処理システム、情報処理装置、情報処理方法及びプログラム
US12271749B2 (en) 2019-04-25 2025-04-08 VMware LLC Containerized workload scheduling
US11134028B2 (en) 2019-04-26 2021-09-28 NM Nevada Trust Devices, systems and methods for optimizing workload performance of user facing web applications during high load events
CN110362299B (zh) * 2019-06-14 2020-06-26 杭州古德微机器人有限公司 一种基于blockly和树莓派的在线图形化编程系统及其使用方法
US11349839B2 (en) * 2019-06-28 2022-05-31 Google Llc Systems and methods using modular user interfaces for managing network permissions
CN110286896B (zh) * 2019-06-28 2023-03-31 百度在线网络技术（北京）有限公司 可视化编辑方法、装置、设备及存储介质
US11635990B2 (en) 2019-07-01 2023-04-25 Nutanix, Inc. Scalable centralized manager including examples of data pipeline deployment to an edge system
US11501881B2 (en) 2019-07-03 2022-11-15 Nutanix, Inc. Apparatus and method for deploying a mobile device as a data source in an IoT system
US11457009B2 (en) * 2019-07-17 2022-09-27 Infiltron Holdings, Inc. Systems and methods for securing devices in a computing environment
US10789195B1 (en) * 2019-07-17 2020-09-29 Capital One Services, Llc Article, device, and techniques for serverless streaming message processing
CN110389807B (zh) * 2019-07-23 2022-10-25 北京字节跳动网络技术有限公司 一种界面翻译方法、装置、电子设备及存储介质
US11132418B2 (en) * 2019-08-01 2021-09-28 Kindest, Inc. Systems and methods for generating floating button interfaces on a web browser
US11172014B2 (en) * 2019-08-21 2021-11-09 Open Text Sa Ulc Smart URL integration using serverless service
US11645047B2 (en) 2019-09-13 2023-05-09 Axure Software Solutions, Inc. Focused specification generation for interactive designs
WO2021051032A1 (en) * 2019-09-13 2021-03-18 Oracle International Corporation System and method for automatic suggestion and automatic selection for dynamic site compilation within a cloud-based content hub environment
US11727083B2 (en) * 2019-09-13 2023-08-15 Oracle International Corporation System and method for automatic selection for dynamic site compilation within a cloud-based content hub environment
US11531725B2 (en) 2019-09-13 2022-12-20 Oracle International Corporation System and method for providing custom component compilation within a cloud-based con tent hub environment
US11853806B2 (en) 2019-09-27 2023-12-26 Cloudflare, Inc. Cloud computing platform that executes third-party code in a distributed cloud computing network and uses a distributed data store
US11853752B2 (en) * 2019-09-30 2023-12-26 EMC IP Holding Company LLC Migration of web applications between different web application frameworks
US12155731B2 (en) 2019-10-09 2024-11-26 Nutanix, Inc. Platform-as-a-service deployment including service domains
US10997341B1 (en) * 2019-12-12 2021-05-04 Salesforce.Com, Inc. System editing plugin
AU2020100253A4 (en) * 2020-02-21 2020-03-26 Soul & Wolf Pty Ltd Automation of CMS Development for a Website or Web Application
US11023558B1 (en) 2020-04-03 2021-06-01 International Business Machines Corporation Executing functions on-demand on a server utilizing web browsers
CN111625222B (zh) * 2020-05-26 2023-08-04 北京互金新融科技有限公司 前端代码的线上验证系统及验证方法
US11553030B2 (en) * 2020-06-01 2023-01-10 Microsoft Technology Licensing, Llc Service worker configured to serve multiple single page applications
US11514132B2 (en) * 2020-07-14 2022-11-29 Snap Inc. Automatic website data migration
US11848084B1 (en) * 2020-07-23 2023-12-19 Express Scripts Strategic Development, Inc. Automated on-demand generation of custom physical labels for medication containers
US11204975B1 (en) * 2020-08-10 2021-12-21 Coupang Corp. Program interface remote management and provisioning
US12306733B2 (en) 2020-10-21 2025-05-20 Nutanix, Inc. Key value store in a clustered containerized system
US11762531B2 (en) * 2020-10-28 2023-09-19 Axure Software Solutions, Inc. Stateful widget container management for interactive designs
US11321412B1 (en) * 2020-11-04 2022-05-03 Capital One Services, Llc Customized navigation flow
US11726764B2 (en) 2020-11-11 2023-08-15 Nutanix, Inc. Upgrade systems for service domains
US11665221B2 (en) 2020-11-13 2023-05-30 Nutanix, Inc. Common services model for multi-cloud platform
US11271987B1 (en) * 2020-11-26 2022-03-08 Digital.Ai Software, Inc. Universal webhook connectivity via multi-step HTTP transformation
CN112596719B (zh) * 2020-12-25 2024-07-05 中国农业银行股份有限公司 一种生成前后端代码的方法和系统
US11175972B1 (en) * 2021-02-24 2021-11-16 Contentful GmbH Application framework for integrating APPs for editing content of a content management system
US11736585B2 (en) 2021-02-26 2023-08-22 Nutanix, Inc. Generic proxy endpoints using protocol tunnels including life cycle management and examples for distributed cloud native services and applications
WO2022203387A1 (ko) * 2021-03-23 2022-09-29 (주)인스웨이브시스템즈 소스 컴파일러를 구비한 사용자 인터페이스 플랫폼 통합 개발 시스템 및 방법
US11824773B2 (en) 2021-03-30 2023-11-21 Amazon Technologies, Inc. Dynamic routing for peered virtual routers
US12160366B2 (en) 2021-03-30 2024-12-03 Amazon Technologies, Inc. Multi-tenant offloaded protocol processing for virtual routers
US11907402B1 (en) * 2021-04-28 2024-02-20 Wells Fargo Bank, N.A. Computer-implemented methods, apparatuses, and computer program products for frequency based operations
JP2024517703A (ja) 2021-05-04 2024-04-23 ウィックス．コム リミテッド． ツールキャスト管理システム
CN113282291B (zh) * 2021-06-10 2024-07-26 豆盟(北京)科技股份有限公司 小程序的生成方法、装置、设备及存储介质
CN113176878B (zh) * 2021-06-30 2021-10-08 深圳市维度数据科技股份有限公司 自动查询方法、装置和设备
US20230035835A1 (en) * 2021-07-29 2023-02-02 Spark. Orange, LLC System and method of a modular framework for configuration and reuse of web components
US11558448B1 (en) * 2021-09-22 2023-01-17 International Business Machines Corporation Sparse information sharing system
US11562043B1 (en) * 2021-10-29 2023-01-24 Shopify Inc. System and method for rendering webpage code to dynamically disable an element of template code
US12536244B2 (en) * 2021-12-30 2026-01-27 Rakuten Group, Inc. System, method, and computer program for providing an end-to-end solution for frontend page generation
US11989255B2 (en) * 2021-12-30 2024-05-21 Monday.com Ltd. Client-side sorting and updating of paginated data obtained from a server
WO2023132913A1 (en) * 2022-01-07 2023-07-13 Mastercard International Incorporated Systems and methods for use in imposing a common domain
US12216728B2 (en) 2022-02-23 2025-02-04 Wix.Com Ltd. Concurrent website editing system having conflict handling protocol
WO2023194923A1 (en) * 2022-04-05 2023-10-12 Content Square SAS Tracking session events for a webpage iframe
US11922116B2 (en) * 2022-04-11 2024-03-05 Contentful GmbH Annotations in a content model of a content management system
US12147690B2 (en) 2022-11-22 2024-11-19 Red Hat, Inc. Sharing node storage resources with the entire cluster
JP2026500736A (ja) 2022-12-27 2026-01-08 ウィックス．コム リミテッド． 信頼できるコードコンポーネント及び信頼できないコードコンポーネントに基づいたハイブリッドウェブサイトインターフェースのレンダリングをセキュアに可能にすること
WO2024142016A1 (en) 2022-12-30 2024-07-04 Wix.Com Ltd. System and method for integrated temporal external resource allocation
US12436746B2 (en) * 2023-01-10 2025-10-07 Palantir Technologies Inc. Method and system for hosting third-party web widgets for application development
WO2024166066A1 (en) 2023-02-10 2024-08-15 Wix.Com Ltd. System and method for network transaction facilitator support within a website building system
US12021743B1 (en) 2023-03-27 2024-06-25 Amazon Technologies, Inc. Software-defined multi-network-segment gateways for scalable routing of traffic between customer-premise network segments and cloud-based virtual networks
US12483499B2 (en) 2023-03-27 2025-11-25 Amazon Technologies, Inc. Custom configuration of cloud-based multi-network-segment gateways
US20240386197A1 (en) 2023-05-15 2024-11-21 Wix.Com Ltd. System and method for enhanced model interaction integration within a website building system
US12541284B2 (en) 2023-06-12 2026-02-03 Wix.Com Ltd. System and method for integrating custom content object repositories within a website building system
US12489707B1 (en) 2023-06-21 2025-12-02 Amazon Technologies, Inc. Modification of routing and forwarding information for cloud network traffic using customer-specified rules
US20240427832A1 (en) 2023-06-23 2024-12-26 Wix.Com Ltd. System and method for ai-based generation of responsive websites using a website building system
WO2025023987A1 (en) * 2023-07-21 2025-01-30 Inkit, Inc. Methods and systems for file generation and storage
US12278881B1 (en) 2023-10-25 2025-04-15 Microsoft Technology Licensing, Llc Domain agnostic offline runtime for single page applications
US12556633B2 (en) * 2023-12-19 2026-02-17 Genesys Cloud Services, Inc. Dynamic content generation for contact center interactions using artificial intelligence
US12536004B1 (en) 2025-05-13 2026-01-27 Morgan Stanley Services Group Inc. System and method for round-robinediting of a generated user interface

Family Cites Families (155)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6247032B1 (en) * 1997-06-19 2001-06-12 International Business Machines Corp. Automated system and method for approving web site content
WO2000050969A2 (en) * 1999-02-26 2000-08-31 Henry Haugland Mass generation of individual virtual servers, virtual web sites and virtual web objects
US7596606B2 (en) * 1999-03-11 2009-09-29 Codignotto John D Message publishing system for publishing messages from identified, authorized senders
US7289964B1 (en) * 1999-08-31 2007-10-30 Accenture Llp System and method for transaction services patterns in a netcentric environment
US6636242B2 (en) * 1999-08-31 2003-10-21 Accenture Llp View configurer in a presentation services patterns environment
US6728762B1 (en) * 2000-01-04 2004-04-27 International Business Machines Corporation System and method for browser definition of workflow documents
US8065399B2 (en) * 2000-04-17 2011-11-22 Circadence Corporation Automated network infrastructure test and diagnostic system and method therefor
US20020065851A1 (en) * 2000-06-02 2002-05-30 Watson Emerson C. System and method for creating a website
US6732332B1 (en) * 2000-08-28 2004-05-04 Und Aerospace Foundation Automated web site creation system
US6901424B1 (en) * 2000-10-10 2005-05-31 Markettools, Inc. System and method for creating a sample pool for a web-based survey
US20020099738A1 (en) * 2000-11-22 2002-07-25 Grant Hugh Alexander Automated web access for back-end enterprise systems
JP2002202937A (ja) * 2000-12-28 2002-07-19 Ibi Kk ウェブサイト自動作成装置、ウェブサイト自動作成システム、ウェブサイト自動作成方法、及び、記録媒体
US20020165936A1 (en) * 2001-01-25 2002-11-07 Victor Alston Dynamically branded web sites
EP1402352A4 (en) 2001-02-22 2010-08-25 Accenture Global Services Gmbh DISTRIBUTED DEVELOPMENT ENVIRONMENT FOR BUILDING INTERNET APPLICATIONS BY DEVELOPERS AT DISCONTINUED LOCATIONS
US8601492B2 (en) * 2001-03-31 2013-12-03 Siebel Systems, Inc. User interface for multi-channel communication
US7546576B2 (en) * 2001-06-15 2009-06-09 Lightsurf Technology, Inc. Software framework for web-based applications
US7000218B2 (en) * 2001-06-29 2006-02-14 International Business Machines Corporation System and method for developing custom programmable tags
US6985939B2 (en) * 2001-09-19 2006-01-10 International Business Machines Corporation Building distributed software services as aggregations of other services
JP2003150377A (ja) 2001-11-16 2003-05-23 Nec Corp 画面出力モジュール開発システム、画面出力モジュール開発方法及びプログラム並びに記録媒体
US7178108B1 (en) * 2001-12-28 2007-02-13 Sprint Communications Company L.P. System and method for development, maintenance and modification of multiple web sites
JP2004005527A (ja) * 2002-03-28 2004-01-08 Yosuke Hiratsuka 階層型サイト情報作成プログラム
JP2004062402A (ja) * 2002-07-26 2004-02-26 Fujitsu Ltd タイムアウト管理システム、タイムアウト管理サーバ、およびタイムアウト管理プログラム
CA2406876A1 (en) * 2002-10-04 2004-04-04 Ibm Canada Limited-Ibm Canada Limitee Method and apparatus for managing a collection of portlets in a portal server
US7240077B1 (en) * 2002-12-30 2007-07-03 Amazon.Com, Inc. Web site content change management
US7062506B2 (en) * 2003-01-24 2006-06-13 The Cobalt Group, Inc. Staged publication and management of dynamic webpages
US7613687B2 (en) * 2003-05-30 2009-11-03 Truelocal Inc. Systems and methods for enhancing web-based searching
US9778919B2 (en) * 2003-06-27 2017-10-03 Adobe Systems Incorporated Dual context interaction with a content object for facilitating content creation and software development
US7640506B2 (en) * 2003-06-27 2009-12-29 Microsoft Corporation Method and apparatus for viewing and managing collaboration data from within the context of a shared document
US20040268238A1 (en) * 2003-06-30 2004-12-30 Peiya Liu Systems and methods for processing documents using an XML-based process flow description language
US7308643B1 (en) * 2003-07-03 2007-12-11 Google Inc. Anchor tag indexing in a web crawler system
US7403491B2 (en) * 2004-04-15 2008-07-22 Alcatel Lucent Framework for template-based retrieval of information from managed entities in a communication network
JP2006146506A (ja) * 2004-11-18 2006-06-08 Image:Kk Ｗｅｂサイト更新システム、Ｗｅｂサイト更新方法およびＷｅｂサイト更新プログラム
US8019749B2 (en) * 2005-03-17 2011-09-13 Roy Leban System, method, and user interface for organizing and searching information
US7689663B2 (en) * 2005-03-24 2010-03-30 Hewlett-Packard Development Company, L.P. Embedded web-based management method
US7536641B2 (en) * 2005-04-29 2009-05-19 Google Inc. Web page authoring tool for structured documents
US7734644B2 (en) * 2005-05-06 2010-06-08 Seaton Gras System and method for hierarchical information retrieval from a coded collection of relational data
US7734722B2 (en) * 2005-06-02 2010-06-08 Genius.Com Incorporated Deep clickflow tracking
EP1934800A4 (en) * 2005-08-17 2010-12-08 Wideport Com Inc AUTOMATIC WEBSITE GENERATOR
US8117531B1 (en) * 2005-09-23 2012-02-14 Google Inc. Interpreted language translation system and method
US8301997B2 (en) * 2006-01-10 2012-10-30 International Business Machines Corporation System and method for serving multiple data objects and formatting functions in a single request
GB2434947B (en) * 2006-02-02 2011-01-26 Identum Ltd Electronic data communication system
US20070220419A1 (en) * 2006-03-10 2007-09-20 Web.Com, Inc. Systems and Methods of Providing Web Content to Multiple Browser Device Types
US7974956B2 (en) * 2006-07-21 2011-07-05 Yahoo! Inc. Authenticating a site while protecting against security holes by handling common web server configurations
US20080071929A1 (en) * 2006-09-18 2008-03-20 Yann Emmanuel Motte Methods and apparatus for selection of information and web page generation
US20090210631A1 (en) * 2006-09-22 2009-08-20 Bea Systems, Inc. Mobile application cache system
GB0622823D0 (en) * 2006-11-15 2006-12-27 British Broadcasting Corp Accessing content
WO2008063624A2 (en) * 2006-11-17 2008-05-29 Globaltel Media, Inc. System and method for delivering web content to a mobile network
JP5312349B2 (ja) * 2007-02-09 2013-10-09 ノキア コーポレイション 情報コンテンツの一部分をクライアント装置に与える方法およびシステム
US20080243852A1 (en) * 2007-03-26 2008-10-02 International Business Machines Corporation System and Methods for Enabling Collaboration in Online Enterprise Applications
US8499237B2 (en) * 2007-03-29 2013-07-30 Hiconversion, Inc. Method and apparatus for application enabling of websites
WO2008156923A2 (en) * 2007-05-03 2008-12-24 3Dlabs Inc., Ltd. Method for remotely configuring user interfaces for portable devices
US8838728B2 (en) * 2007-05-22 2014-09-16 Nokia Corporation Method, system, apparatus, network entity and computer program product for providing a user with an editable webpage
US10019570B2 (en) * 2007-06-14 2018-07-10 Microsoft Technology Licensing, Llc Protection and communication abstractions for web browsers
US8181246B2 (en) * 2007-06-20 2012-05-15 Imperva, Inc. System and method for preventing web frauds committed using client-scripting attacks
US8577835B2 (en) * 2007-06-28 2013-11-05 Salesforce.Com, Inc. Method and system for sharing data between subscribers of a multi-tenant database service
US8584094B2 (en) * 2007-06-29 2013-11-12 Microsoft Corporation Dynamically computing reputation scores for objects
US7779161B2 (en) * 2007-07-24 2010-08-17 Hiconversion, Inc. Method and apparatus for general virtual application enabling of websites
US8464228B2 (en) * 2007-08-23 2013-06-11 Accenture Global Services Limited Binary library
US9268849B2 (en) * 2007-09-07 2016-02-23 Alexander Siedlecki Apparatus and methods for web marketing tools for digital archives—web portal advertising arts
US8387006B1 (en) * 2007-12-05 2013-02-26 Adobe Systems Incorporated System and method for authoring a web page to be run-time editable
CA2710346A1 (en) * 2007-12-20 2009-07-02 Hsbc Technologies Inc. Automated methods and systems for developing and deploying projects in parallel
JP2009176296A (ja) * 2007-12-27 2009-08-06 Nippon Institute Of Agroinformatics Ltd Ｗｅｂ文書編集方法
CN101488135B (zh) 2008-01-14 2012-07-04 盛大计算机（上海）有限公司 延后个性化网页的设计和获取方法
US7886021B2 (en) * 2008-04-28 2011-02-08 Oracle America, Inc. System and method for programmatic management of distributed computing resources
US8341200B2 (en) * 2008-06-12 2012-12-25 Pomian & Corella, Llc Protecting a web application against attacks through shared files
MY154409A (en) * 2008-07-21 2015-06-15 Secure Corp M Sdn Bhd F Website content regulation
US8627288B2 (en) * 2008-07-22 2014-01-07 Webtrends Inc. Method and system for web-site testing
JP5476709B2 (ja) * 2008-12-09 2014-04-23 富士通株式会社 Ｗｅｂページ編集プログラム及びＷｅｂページ編集装置
JP2010181978A (ja) * 2009-02-03 2010-08-19 Seiko Epson Corp 共同作業装置及び共同作業の制御方法
US9691170B2 (en) * 2009-03-18 2017-06-27 Shutterfly, Inc. Proactive creation of photo products
GB0909695D0 (en) * 2009-06-05 2009-07-22 Maxymiser Ltd On page console
CN102257477B (zh) 2009-09-17 2015-04-15 株式会社三菱东京Ufj银行 应用开发支援装置
US9883008B2 (en) * 2010-01-15 2018-01-30 Endurance International Group, Inc. Virtualization of multiple distinct website hosting architectures
US8438648B2 (en) * 2010-02-16 2013-05-07 Celartem, Inc. Preventing unauthorized font linking
US8850219B2 (en) * 2010-05-13 2014-09-30 Salesforce.Com, Inc. Secure communications
WO2012014248A1 (ja) * 2010-07-25 2012-02-02 株式会社 コアアプリ ファイル公開管理コンピュータプログラム、ファイル公開管理コンピュータシステム
US8966446B1 (en) * 2010-09-29 2015-02-24 A9.Com, Inc. Systems and methods of live experimentation on content provided by a web site
US20120131645A1 (en) * 2010-11-18 2012-05-24 Harm Michael W User Scriptable Server Initiated User Interface Creation
US8839093B1 (en) * 2011-01-12 2014-09-16 Optimizely, Inc. Systems and methods for website optimization
JP5843459B2 (ja) 2011-03-30 2016-01-13 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 情報処理システム、情報処理装置、スケーリング方法、プログラムおよび記録媒体
US8910156B1 (en) * 2011-04-29 2014-12-09 Netapp, Inc. Virtual machine dependency
US8938791B2 (en) * 2011-06-10 2015-01-20 International Business Machines Corporation System and method to control display of a realm name
US8874593B2 (en) * 2011-07-01 2014-10-28 Salesforce.Com, Inc. Testing data silo
US8959427B1 (en) * 2011-08-05 2015-02-17 Google Inc. System and method for JavaScript based HTML website layouts
US8474056B2 (en) 2011-08-15 2013-06-25 Bank Of America Corporation Method and apparatus for token-based virtual machine recycling
WO2013067437A1 (en) * 2011-11-02 2013-05-10 Hoffman Michael Theodor Systems and methods for dynamic digital product synthesis, commerce, and distribution
US20130117152A1 (en) * 2011-11-03 2013-05-09 Cbs Interactive, Inc. Javascript Widget Storefront
US8671417B2 (en) * 2011-12-12 2014-03-11 Microsoft Corporation Lightweight framework for web applications
US8793660B2 (en) * 2011-12-30 2014-07-29 Cellco Partnership Automated testing of programming code for a web service
WO2013106708A1 (en) * 2012-01-11 2013-07-18 Endurance International Group, Inc. Guided workflows for establishing a web presence
DE102013202782A1 (de) 2012-02-20 2013-08-22 Wixpress Ltd Server-basiertes Webseiten-Designsystem, das ein dynamisches Layout und dynamischen Inhalt integriert
WO2013142273A1 (en) * 2012-03-19 2013-09-26 Citrix Systems, Inc. Systems and methods for providing user interfaces for management applications
US9430449B2 (en) * 2012-03-30 2016-08-30 Sdl Plc Systems, methods, and media for managing editable previews of webpages
US9262420B1 (en) * 2012-04-23 2016-02-16 Google Inc. Third-party indexable text
US9672283B2 (en) * 2012-06-06 2017-06-06 Data Record Science Structured and social data aggregator
US20130346849A1 (en) * 2012-06-06 2013-12-26 Minds + Machines Automatic uploading and synchronization of media assets
US8943086B2 (en) * 2012-06-29 2015-01-27 Sap Se Model-based backend service adaptation of business objects
US20140047413A1 (en) * 2012-08-09 2014-02-13 Modit, Inc. Developing, Modifying, and Using Applications
US8522134B1 (en) * 2012-08-13 2013-08-27 Volusion, Inc. Methods and apparatus for in-line editing of web page content with reduced disruption of logical and presentational structure of content
US20140053060A1 (en) * 2012-08-17 2014-02-20 Launchbase, LLC Website development tool
US10585981B2 (en) * 2012-09-13 2020-03-10 Samir Issa Method of data capture, storage and retrieval through user created form templates and data item templates by executing computer-executable instructions stored on a non-transitory computer-readable medium
US9317490B2 (en) * 2012-09-19 2016-04-19 TagMan Inc. Systems and methods for 3-tier tag container architecture
US20140096009A1 (en) * 2012-09-28 2014-04-03 Interactive Memories, Inc. Methods for Searching for Best Digital Color Options for Reproduction of Image-Based Layouts Created through an Electronic Interface
US11449952B2 (en) * 2012-10-01 2022-09-20 Oracle International Corporation Efficiently modeling database scenarios for later use on live data
US9195477B1 (en) * 2012-10-09 2015-11-24 Sencha, Inc. Device profiles, deep linking, and browser history support for web applications
US9185078B2 (en) * 2012-12-18 2015-11-10 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing cross organizational data sharing
US9002997B2 (en) * 2013-01-22 2015-04-07 Amazon Technologies, Inc. Instance host configuration
US10089406B2 (en) * 2013-01-30 2018-10-02 Oracle International Corporation Generating web pages with integrated content
US9712593B2 (en) * 2013-02-04 2017-07-18 Oracle International Corporation Javascript API for WebRTC
US9307031B2 (en) * 2013-02-04 2016-04-05 Oracle International Corporation Generic model for customizing protocol behavior through javascript
WO2014124310A1 (en) * 2013-02-07 2014-08-14 MaxPoint Interactive, Inc. A system for improving shape-based targeting by using interest level data
IL309008B2 (en) 2013-02-10 2025-04-01 Wix Com Ltd Communication interface for third-party applications
US9465586B2 (en) 2013-02-27 2016-10-11 Google Inc. Third party application scriptability
EA201591779A1 (ru) * 2013-03-14 2016-03-31 Викс.Ком Лтд. Система и способ персонализации диалогов
US9971790B2 (en) * 2013-03-15 2018-05-15 Google Llc Generating descriptive text for images in documents using seed descriptors
US20170147480A1 (en) * 2013-04-23 2017-05-25 Google Inc. Test script generation
US20150011338A1 (en) * 2013-07-02 2015-01-08 Jeremy Russotti Training device
US10362145B2 (en) * 2013-07-05 2019-07-23 The Boeing Company Server system for providing current data and past data to clients
US9836330B2 (en) 2013-07-16 2017-12-05 Hitachi, Ltd. Virtual resource management tool for cloud computing service
US9513885B2 (en) * 2013-08-22 2016-12-06 Peter Warren Web application development platform with relationship modeling
US20150058339A1 (en) 2013-08-26 2015-02-26 Go DaddyOperating Company, LLC Method for automating search engine optimization for websites
US9229702B1 (en) * 2013-08-28 2016-01-05 Lithium Technologies, Inc. Systems and methods for application plugin deployment for websites
US9870349B2 (en) * 2013-09-20 2018-01-16 Yottaa Inc. Systems and methods for managing loading priority or sequencing of fragments of a web object
US10853837B2 (en) * 2013-10-07 2020-12-01 Adobe Inc. Integrated testing, targeting and measuring of web site components
US9519525B2 (en) * 2013-11-14 2016-12-13 Dropbox, Inc. File-level commenting
US9817801B2 (en) 2013-12-04 2017-11-14 Go Daddy Operating Company, LLC Website content and SEO modifications via a web browser for native and third party hosted websites
US9607332B1 (en) * 2014-02-07 2017-03-28 Google Inc. Embedded web application gallery
WO2015121813A1 (en) 2014-02-11 2015-08-20 Wix.Com Ltd. System for synchronization of changes in edited websites and interactive applications
US9305000B1 (en) 2014-03-27 2016-04-05 Veritas Us Ip Holdings Llc Creating and publishing service level representations of applications from operational representations
CA2949397A1 (en) * 2014-05-18 2015-11-26 Kai ZHOU Performance testing system and method
US20150363503A1 (en) * 2014-06-12 2015-12-17 Go Daddy Operating Company, LLC System and methods for proposing media for a web page
JP6114480B2 (ja) * 2014-08-11 2017-04-12 日本電信電話株式会社 構築装置、構築方法、および、構築プログラム
US9954936B2 (en) 2015-03-02 2018-04-24 International Business Machines Corporation Migrating legacy applications to a multi-tenant computing environment
EP3070618A1 (en) 2015-03-20 2016-09-21 Michael Weller Computer system and method for dynamic website instantiation
IL271671B2 (en) 2015-06-07 2025-08-01 Wix Com Ltd System and method for the generation of an adaptive user interface in a website building system
US10726371B2 (en) * 2015-06-08 2020-07-28 Sap Se Test system using production data without disturbing production system
WO2016205977A1 (en) 2015-06-26 2016-12-29 Intel Corporation Techniques to run one or more containers on virtual machine
US9864735B1 (en) * 2015-08-27 2018-01-09 Google Llc In-domain webpage editing
US10229214B2 (en) * 2015-12-31 2019-03-12 Ca, Inc. Dynamic web page navigation
US10148790B2 (en) * 2016-03-04 2018-12-04 Bank Of America Corporation Deployment of integrative HTML-based engine from an edge server
US10684839B2 (en) * 2016-06-15 2020-06-16 Red Hat Israel, Ltd. Plugin for software deployment
US10678995B2 (en) * 2016-08-12 2020-06-09 Netsuite, Inc. System and methods for control of content presented on web pages
US20180052809A1 (en) * 2016-08-16 2018-02-22 Microsoft Technology Licensing, Llc Inferring user interaction with an iframe
US10025924B1 (en) * 2016-08-26 2018-07-17 Parallels IP Holdings GmbH Taskless containers for enhanced isolation of users and multi-tenant applications
US10223078B2 (en) * 2016-09-29 2019-03-05 Ca, Inc. Application-type independent dynamic plug-in evaluation tool
US20180097820A1 (en) * 2016-10-03 2018-04-05 Adobe Systems Incorporated Managing content upload and content retrieval
US11537272B2 (en) * 2016-12-21 2022-12-27 Aon Global Operations Se, Singapore Branch Content management system extensions
US10250389B2 (en) * 2017-01-17 2019-04-02 Go Daddy Operating Company, LLC Script verification using a hash
US10671570B2 (en) * 2017-02-01 2020-06-02 Open Text Sa Ulc Web application open platform interface (WOPI) server architecture and applications for distributed network computing environments
US11003668B2 (en) * 2017-02-21 2021-05-11 Sap Se Programming language independent software testing environment
US20180309720A1 (en) * 2017-04-25 2018-10-25 Verisign, Inc. Systems, devices, and methods for automatic website generation and domain name suggestion
US10572361B2 (en) * 2017-04-28 2020-02-25 The Boeing Company Concurrent production use of a production enterprise system and testing of a modified enterprise system
US11106860B2 (en) 2017-07-24 2021-08-31 Wix.Com Ltd. Common database for live operation and testing of a website
US10866935B2 (en) * 2017-08-18 2020-12-15 Benjamin J. Chung File management method
US20200057714A1 (en) * 2018-08-17 2020-02-20 Google Llc Testing data changes in production systems

Also Published As

Publication number Publication date
AU2025237969A1 (en) 2025-10-16
JP2025128112A (ja) 2025-09-02
US10719300B2 (en) 2020-07-21
JP2026063014A (ja) 2026-04-10
US20250335696A1 (en) 2025-10-30
JP2024075645A (ja) 2024-06-04
US20190028531A1 (en) 2019-01-24
IL271915A (en) 2020-02-27
US20190026443A1 (en) 2019-01-24
JP2025000885A (ja) 2025-01-07
US10397305B1 (en) 2019-08-27
US12346650B2 (en) 2025-07-01
US11106860B2 (en) 2021-08-31
ES3058727T3 (en) 2026-03-12
EP4235461A2 (en) 2023-08-30
US20210397776A1 (en) 2021-12-23
JP2020530610A (ja) 2020-10-22
US20190149591A1 (en) 2019-05-16
US20190026296A1 (en) 2019-01-24
US20190258459A1 (en) 2019-08-22
JP7804129B2 (ja) 2026-01-21
EP4664326A3 (en) 2026-05-06
AU2018319444B2 (en) 2023-11-16
US20190026382A1 (en) 2019-01-24
US10326821B2 (en) 2019-06-18
EP4235461B1 (en) 2025-10-29
US10379820B1 (en) 2019-08-13
US10915300B2 (en) 2021-02-09
AU2024200221A1 (en) 2024-02-01
EP3593254B1 (en) 2023-08-02
AU2024200221B2 (en) 2025-07-03
US20190245910A1 (en) 2019-08-08
JP7546481B2 (ja) 2024-09-06
CA3060362A1 (en) 2019-02-28
WO2019038588A1 (en) 2019-02-28
US11875104B2 (en) 2024-01-16
BR112019024309A2 (pt) 2020-11-03
JP7611443B2 (ja) 2025-01-09
EP3593254A4 (en) 2021-01-20
US20190026082A1 (en) 2019-01-24
US10521198B2 (en) 2019-12-31
US20240220706A1 (en) 2024-07-04
EP3593254A1 (en) 2020-01-15
EP4664326A2 (en) 2025-12-17
US10331420B2 (en) 2019-06-25
JP7719932B2 (ja) 2025-08-06
US10209966B2 (en) 2019-02-19
US20190026083A1 (en) 2019-01-24
AU2018319444A1 (en) 2019-10-31
EP4235461A3 (en) 2023-11-15

Similar Documents

Publication Publication Date Title
JP7719932B2 (ja) 仮想ウェブページのプレビュー中におけるデータベースの編集
US11915016B2 (en) System and method for identifying, indexing, and navigating to deep states of mobile applications
Riva Real-World Next. js
Love Progressive Web Application Development by Example: Develop fast, reliable, and engaging user experiences for the web
Klauzinski et al. Mastering JavaScript Single Page Application Development
Khanna et al. Ionic: Hybrid Mobile App Development
Bretet Spring mvc cookbook
Kılıçdağı et al. Laravel Design Patterns and Best Practices
Long et al. Getting started with Roo
Avramidis Development of decision support web application
Manfield Joomla for Developers
Shukla Elasticsearch for Hadoop
Alas Development of an Angular Components Library to be used in Micro-Frontend Architecture
Baxter-Reynolds Multimobile Development: Building Applications for the IPhone and Android Platforms
Saxena Mastering play framework for scala
Portwood II Yii Project Blueprints
Wright Pro SharePoint 2013 App Development