Multi-Level Undo Architecture for Asynchronous Grid Data
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Web applications lack multi-level undo capabilities, making data editing perilous and inefficient, especially when dealing with complex data on enterprise servers, as users cannot easily revert actions without affecting saved files.
Innovation Solution
A multi-level undo architecture that uses a control-driven cascading changes system, allowing for seamless change tracking in asynchronous and synchronous scenarios, distinguishing between implicit and explicit changes to provide comprehensive undo and redo functionality, supported by a grid object for tabular data representation and visualization.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If web applications transact data with the server according to individual post-backs that commit data as the user navigates, then data consistency with the server is maintained, but the user cannot undo actions after navigation and editing performance decreases
Solution Approach 1:
The patent segments the undo functionality into multiple levels: local client-side undo for individual edits and server-side undo for saved changes. This allows users to undo actions at different stages without compromising data consistency, resolving the contradiction between maintaining reliability and providing ease of operation.
Solution Approach 2:
The patent introduces an intermediary undo mechanism that sits between the user interface and the server transaction. This intermediary layer captures edit events locally, enables undo operations before server commitment, and only commits to the server when explicitly saved, thus maintaining both data consistency and undo capability.
2Reliability
If users perform frequent saves to maintain data consistency, then data is consistently synchronized with the server, but the effective edit performance decreases proportionately
Solution Approach 1:
The patent implements preliminary action by capturing and buffering edit events locally on the client side before server commitment. Users can perform multiple edits and undos locally without triggering server saves, and only commit to the server when explicitly saved, thus maintaining data synchronization while significantly improving edit performance.
Solution Approach 2:
The patent enables continuity of useful action by allowing users to continue editing and undoing operations locally without interruption from server save operations. The system continuously tracks edit events in a buffer, maintaining the editing flow while deferring server communication until explicit save actions occur.
3Device complexity
If web applications lack multi-level undo capabilities, then the system architecture remains simple, but the user experience becomes perilous when editing complex data
Solution Approach 1:
The patent segments the undo system into distinct layers: a client-side undo buffer for immediate edit reversals and a server-side change tracker for saved change reversals. This segmentation provides comprehensive undo capability for complex data editing while maintaining a manageable system architecture through clear separation of concerns.
Solution Approach 2:
The patent adds another dimension to the undo capability by implementing multi-level undo that operates at different stages of the data lifecycle (local edits vs. saved changes). This dimensional approach enhances user experience safety without proportionally increasing system complexity, as each level operates independently with its own undo mechanism.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Architecture for multi-level undo on a client in grid-based applications. The architecture is a control driven cascading changes system where change tracking works seamlessly in asynchronous (and synchronous) scenarios. A client application is associated with a grid object and, instantiates and configures the grid object. The application can initiate a change to data in the grid and/or the user can edit the data in the grid directly. A result of the change is a notification to the application, the notification including an order key. The application consumes the notification and can then append new changes based on synchronous or asynchronous computations by calling an update function using the order key. The application uses the key to attach further updates which are properly collected together for undo/redo.