Agnostic Page Builder Meta Model Architecture

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current website development technologies, such as web application frameworks, require time-consuming and costly refactoring when transitioning between different frameworks, and existing systems fail to efficiently adapt to changing website needs.

Innovation Solution

A technology-agnostic page builder system that uses an agnostic page editor to modify and render pages independently of specific technologies, allowing administrators to select renderers and technologies based on user needs, with a meta model data interchange format for content and layout management.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a specific web application framework is used for website development, then certain advantages and functionalities are provided, but transitioning to a new framework becomes time-consuming and costly

Engineering Contradiction:
Improveframework functionalityVSAvoidtransition time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system segments the website development process into two independent layers: a technology-agnostic page builder that handles content creation and a separate renderer that handles framework-specific rendering. This segmentation allows the page builder to remain framework-independent while the renderer adapts to different frameworks, eliminating the need to refactor the entire system during framework transitions.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a renderer as an intermediary component between the page builder and the web application framework. This renderer acts as a mediator that translates the framework-independent page models into framework-specific renderings, allowing the system to switch frameworks without affecting the page builder or requiring content editors to adapt to new technologies.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If web application frameworks are updated to new technologies, then improved functionalities and advantages are achieved, but the refactoring process is costly and time-consuming

Engineering Contradiction:
Improvetechnology adaptabilityVSAvoidrefactoring cost
Core Design Contradiction:
Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The page builder is designed with universal, framework-agnostic functionality that can work with multiple different web application frameworks. By making the core page building capabilities universal and framework-independent, the system can adapt to new technologies simply by updating or swapping the renderer component, rather than requiring costly and complex refactoring of the entire system.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Power

If framework-specific solutions are used, then optimal performance for that framework is achieved, but the system cannot easily adapt to changing website needs or new technologies

Engineering Contradiction:
Improverendering performanceVSAvoidtechnology flexibility
Core Design Contradiction:
PowerVSAdaptability or versatility

Solution Approach 1:

The system implements dynamic adaptability by allowing the renderer to be swapped or updated based on the desired web application framework. The page builder dynamically generates framework-independent page models that can be rendered by different renderers optimized for specific frameworks, enabling the system to adapt to changing needs and new technologies while maintaining optimal rendering performance for each framework.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS11886532B1Technology agnostic page builder architecture
Publication Date: 2024.01.30 PROGRESS SOFTWARE CORP
  • US11886532B1 patent drawing
  • US11886532B1 patent drawing
  • US11886532B1 patent drawing

AI summary

A system and method for technology agnostic page editing and/or rendering that includes receiving a first modification request associated with a first page, the first modification request generated by an agnostic page editor, the agnostic page editor compatible with a plurality of renderers from which an administrative user identifies a first set of renderers to be associated with the first page; modifying a first meta model associated with the first page based on the first modification request, the first meta model using a data interchange format; obtaining, by a first renderer belonging to the first set of renderers, the meta model associated with the first page; rendering, by the first renderer belonging to the first set of renderers, the first page for presentation to the administrative user using the first meta model; and sending first rendered content for presentation of the first page.