Framework-Agnostic Web Page Builder Using Declarative Component Hierarchy

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Web developers face the challenge of rewriting complex web pages when underlying web development frameworks change or become deprecated, leading to impractical and time-consuming updates.

Innovation Solution

A system that allows web developers to compose web pages using custom web components and declarative markup, enabling dynamic updates of underlying script libraries without requiring page rewrites, through a page-builder subsystem that stores page descriptions in a relational database and constructs HTML documents on demand.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If web developers use imperative code and specific framework APIs to control web page structure and operation, then the web pages can function with the current framework, but the developers must rewrite the pages when the framework becomes deprecated or changes

Engineering Contradiction:
Improveweb page functionalityVSAvoidframework compatibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces a framework-agnostic intermediate representation layer that mediates between the web page definition and the actual framework implementation. This intermediate layer uses generic constructs (components, bindings, actions) that can be mapped to multiple different frameworks, allowing the page to remain functional while adapting to framework changes without rewriting the core page logic.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the web page into distinct components with defined interfaces, separating the page structure and behavior from the specific framework implementation. This segmentation allows each component to be independently defined in terms of its data bindings and actions, making the overall page adaptable to different frameworks while maintaining functional reliability.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If web developers rewrite complex web pages to use newer frameworks, then the pages can use supported frameworks, but the rewriting process becomes impractical and time-consuming

Engineering Contradiction:
Improveframework supportVSAvoidpage rewriting time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent performs preliminary action by defining web pages in terms of framework-independent components, data bindings, and actions during the development phase. This preliminary structuring in an abstract representation allows the pages to automatically adapt to newer frameworks without requiring time-consuming rewrites, as the core page logic remains framework-agnostic.

Inventive Principle:
Principle #10Preliminary action

3Ease of operation

If web pages are composed with imperative code to define how to achieve desired results, then the pages can control structure and operation precisely, but the complexity of the code increases and maintenance becomes difficult

Engineering Contradiction:
Improvepage control capabilityVSAvoidcode complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent creates a simplified copy or abstraction of the actual framework API through generic component definitions. Instead of using complex imperative framework-specific code, developers work with simplified component declarations that capture the essential structure and behavior, reducing code complexity while maintaining precise control capability through the intermediate representation layer.

Inventive Principle:
Principle #26Copying

Data Source

PatentEP3531306B1System for building and modeling web pages
Publication Date: 2021.02.17 SERVICENOW INC
  • EP3531306B1 patent drawingFigure 1
  • EP3531306B1 patent drawingFigure 2
  • EP3531306B1 patent drawingFigure 3

AI summary

Disclosed is a computing system configured to receive input declaring structure of a web page, including declarations of component hierarchy and data-binding between components of the web page, and to responsively generate and store, cooperatively in a plurality of tables of a database, a representation of the web page including references to underlying scripts interpretable to define structure and operation of the components. Further, the computing system is configured to thereafter receive, from a client device, a request for such a page and, in response to the request, (i) to query the database in order to ascertain component tree-structure of the page, (ii) based on the ascertained component tree-structure, to construct a markup document that represents the ascertained component tree-structure and includes a component loader operative to load the underlying scripts, and (iii) to output the constructed markup document for rendering by a web browser executing on the client device.