Online table processing method, architecture, server and storage medium

Abstract

The invention provides an online table processing method and architecture, a server and a storage medium, and belongs to the technical field of online data processing.The method comprises the steps that in response to a service request for any online table, a service event corresponding to the service request is recognized through a target adapter, and the target adapter packages adapter ports corresponding to multiple service events; forwarding the business event to a business event matching exclusive business plug-in corresponding to the online table; and based on the exclusive business plug-in, realizing a business demand corresponding to the business event. Therefore, the business logic does not need to be dispersed in each scattered component, the code coupling is reduced, the function development difficulty is reduced, codes are easy to understand and maintain, and the reusability of the codes is improved.

Description

Technical Field

[0001] This application belongs to the field of online data processing technology, and in particular relates to an online table processing method, architecture, server, and storage medium. Background Technology

[0002] Currently, the front-end application layer consists of a user interface and an electronic page control (Spread control). All user operations (such as selecting cells, editing content, opening drop-down selections, or selecting a range of tables) will trigger corresponding front-end events.

[0003] Front-end events facilitate communication and interaction between front-end page controls and the back-end through platform-pre-built callbacks (Actions), specifically by sending callbacks to the back-end server. The back-end then executes different user actions on pages that have registered the corresponding callback callbacks, thus triggering the corresponding front-end events.

[0004] However, different front-end pages correspond to different adapters to implement the corresponding events, and different events in the adapters need to be implemented differently. This results in different business logics being scattered in various fragmented components, with high code coupling. As a result, during code maintenance, it is necessary to maintain the code for different events in multiple adapters, leading to differences in code readability and maintainability. Summary of the Invention

[0005] The purpose of this application is to provide an online form processing method, architecture, server, and storage medium, aiming to solve the problems of poor readability and maintainability of online form processing code.

[0006] A first aspect of this application provides an online form processing method, the method comprising: In response to a business request for any online form, the target adapter identifies the business event corresponding to the business request. The target adapter encapsulates various conversion interfaces corresponding to different business events. Forward the business event to the dedicated business plugin that matches the business event in the online table; Based on the dedicated business plugin, the business requirements corresponding to the business events are realized.

[0007] A second aspect of this application provides an online table processing architecture, the architecture including: a front-end application layer, a cache layer, and a database layer; The front-end application layer is equipped with a target adapter, which is used to interact with the front-end application through page controls. The target adapter is used to identify the business event corresponding to the business request and forward the business event to the dedicated business plugin that matches the business event corresponding to the online table. The cache layer is equipped with a cache manager, which is used to cache grid data through the cache manager. When a storage instruction is received, it interacts with the database layer to upload the grid data to the database layer. The database layer is used to store grid data.

[0008] A third aspect of this application provides a server including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the online table processing method described above.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the online table processing method described above.

[0010] A fifth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the online table processing method as described above.

[0011] The beneficial effects of the embodiments of the present invention compared with the prior art are as follows: In this embodiment, a target adapter encapsulates various business events to identify business requests for a table. The request is then dispatched to the corresponding dedicated business plugin for that online table. This dedicated plugin fulfills the business requirements associated with the business event. By dispatching requests to the appropriate plugin based on the business event, there is no need to set up a separate adapter for each online table, simplifying the online table's interface. Only the business type needs to be matched with the appropriate plugin. This avoids dispersing business logic across various components, reducing code coupling, lowering development complexity, making the code easier to understand and maintain, and improving code reusability. Attached Figure Description

[0012] Figure 1 A schematic diagram of the processing architecture of an online form provided in an exemplary embodiment is shown; Figure 2 This illustrates the interaction process between a front-end page and a tabular database provided in an exemplary embodiment; Figure 3 A schematic diagram of a system architecture for implementing an online form processing method is shown in an exemplary embodiment; Figure 4 A schematic diagram of an abstract base class for a business plugin provided in an exemplary embodiment is shown; Figure 5A schematic diagram of the functional architecture of a cache manager provided in an exemplary embodiment is shown; Figure 6 An exemplary embodiment of a page control command execution system and a table template initialization system is shown. Figure 7 A flowchart illustrating an exemplary embodiment of a method for processing online forms is shown. Figure 8 A flowchart illustrating an exemplary embodiment of a method for processing online forms is shown. Figure 9 A flowchart illustrating an exemplary embodiment of a method for processing online forms is shown. Figure 10 A flowchart illustrating an exemplary embodiment of a method for processing online forms is shown. Figure 11 A schematic diagram of the structure of an online form processing apparatus provided in an exemplary embodiment is shown; Figure 12 A schematic diagram of the structure of a server provided in an exemplary embodiment is shown. Detailed Implementation

[0013] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0014] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0015] First, the relevant terms used in this application will be explained.

[0016] Adapter (Action): A processing class that enables communication and interaction between online page controls and the backend.

[0017] Command object: An abstract representation of front-end user operations (such as cell editing and area selection), used to pass between different layers of the system.

[0018] Business plugins: Pluggable functional modules that encapsulate specific business logic (such as data validation and formula calculation).

[0019] Cache Manager: The core component responsible for managing server memory and the tabular data model in the distributed cache.

[0020] Currently, the front-end application layer consists of a user interface and spreadsheet controls. All user actions (such as selecting cells, editing content, opening dropdown selections, or selecting a table range) trigger corresponding front-end events. These front-end events communicate with the back-end through platform-predefined actions, i.e., callbacks are sent to the back-end server. The back-end then executes different user actions and triggers corresponding front-end events by registering pages with the appropriate callback actions.

[0021] In some embodiments, the online form management platform does not have a unified scaffolding tool for the development and use of online page controls. The front-end application layer includes the user interface and online page controls (Spread controls). Users input operations on the online form through the user interface, and the corresponding front-end events triggered by the user input operations are determined through the online page controls.

[0022] Currently, different front-end pages use different adapters to implement the corresponding events. See also Figure 1 This illustrates a schematic diagram of the processing architecture for an online form provided in an exemplary embodiment. Figure 1 As shown, after each page control receives the corresponding front-end event, it forwards it to the corresponding business plugin through the adapter of the table. Each business plugin integrates the business logic code for all events that the online table can implement.

[0023] In the above implementation, different front-end pages (online forms) correspond to different adapters, and different events in the adapters need to have different implementations. When handling specific business logic, the above design results in the business logic being scattered in various fragmented components, with high code coupling, lack of unified abstraction and management, which increases the difficulty of developing new functions, poor code readability and maintainability, lack of unified abstraction and standardization, low code reusability, and high development difficulty.

[0024] Furthermore, in some embodiments, even minor changes triggered by any event will trigger a complete interaction between the front-end page and the table database (including reading, parsing, and saving). See Figure 2, which illustrates an exemplary embodiment of the interaction process between the front-end page and the table database. When a user opens an online table, a large text file is retrieved from the table database. This large text file includes the online table's style, format, data, and other table data. When editing the online table or saving data, it is still necessary to trigger interaction with the table database to save the large text file.

[0025] However, online spreadsheet files have extremely large fields and contain a vast amount of information. Therefore, frequent input and output can easily lead to page response delays and freezes, severely impacting the smoothness and user experience. Furthermore, frequent interaction with the spreadsheet database puts a heavy load on the system. Due to the lack of an effective caching medium, every user operation involves direct communication with the database layer. This interaction model not only incurs unnecessary network transmission overhead and wastes network resources, but also places continuous high concurrency pressure on the database server, limiting the system's ability to support user access and affecting its overall scalability.

[0026] To improve the efficient management and interaction of data in online forms, this application provides an online form processing method. This method uses a target adapter encapsulated with various business events to identify business requests for the form. The request is then dispatched to the corresponding dedicated business plugin for that online form. This dedicated plugin then fulfills the business requirements associated with the business event. By dispatching requests to the appropriate plugin based on the business event, there is no need to set up a separate adapter for each online form, simplifying the online form's program interface. Only the business type needs to be matched with the appropriate plugin. This eliminates the need to distribute business logic across various fragmented components, reducing code coupling, simplifying development, making the code easier to understand and maintain, and improving code reusability.

[0027] The present application will now be described with reference to specific embodiments. The online form processing method provided in this application is applied to a server, which is a server for providing online form processing functions. In some embodiments, the server is communicatively connected to at least one user device, wherein the user device can provide an interactive interface for the online form to the user. Accordingly, the user can operate on the online form through the user device, and the user device sends a business request corresponding to the user's operation to the server, which then processes the online form based on the business request. The user device can be a mobile phone, tablet computer, computer, or other electronic device. The server can be a single server, a server cluster consisting of multiple servers, or a cloud server, etc. In the embodiments of this application, the user device and the server are not specifically limited. See Figure 3 This illustrates a schematic diagram of a system architecture for implementing an online form processing method, provided by an exemplary embodiment. Figure 3 As shown, the system architecture includes a front-end application layer, a caching layer, and a database layer.

[0028] This front-end application layer is used to implement unified event forwarding and command dispatching, connecting user interaction and back-end logic. It provides a unified target adapter, such as SIHCReportSpreadAction, which implements table control operations. This adapter encapsulates various callback events for online tables, such as cell click (getLookupData), area selection (selectedSpread), cell value update (updateCellValue), and formula update (updateFormula). The front-end application platform adopts a listener design pattern, registering matching listeners and callbacks for business events generated in the target adapter. This decoupling through listeners and callbacks allows business code to simply register and implement the corresponding type of listener or callback, achieving a single responsibility principle.

[0029] This target adapter encapsulates interfaces for various callback events. For example, clicking a cell (getLookupData) is used to retrieve search data; selecting a table range on the front end and retrieving it on the back end (selectedSpread) is used to retrieve the selection information on the back end based on the cell range selected by the user on the front end; updating a cell on the front end (updateCellValue) is triggered when the user edits a cell; updating a formula on the front end (updateFormula) is triggered when the user edits or modifies a formula, etc.

[0030] Register relevant listeners or callbacks in the business plugin based on the business event, thereby implementing the business event through the business plugin. See also Figure 4 It illustrates a schematic diagram of the abstract base class (SihcSpreadBasePlugin) of a business plugin provided in an exemplary embodiment, as shown below. Figure 4 As shown, the base class of this business plugin can register various listener classes, enabling listener registration and deregistration operations. This business plugin includes the core plugin base class (SliteSpreadBasePlugin), the event registration management center (IRegisterEvent), the batch post-processing coordinator (IAfterEventHandle), the notification listener interface (NotifyListener), the pre- and post-processor listener interfaces (ISpreadListener), and the notification event parameters (NotifyEvent).

[0031] The plugin base class (SliteSpreadBasePlugin) provides basic event logic code, such as table selector (selector: SpreadSelector), event chain (eventChain: SpreadEventChain), getting the selected coordinate range in the online table (getSpreadSelector: SpreadSelector), getting the current online table information manager (getSheetData: SheetManager), and getting the necessary parameters for server operations on the online table (getSpreadParam: SpreadlModelParam), etc.

[0032] The Event Registry (IRegisterEvent) provides interfaces for plugins to register front-end triggered events, such as the pre-registration notification interface (registerBeforeEvent(ActionNameEnum name, NotifyListenerIs)), the post-registration notification interface (registerAfterEvent(ActionNameEnum name, NotifyListenerIs)), the unregistration interface 1 (unregisterBeforeEvent(ActionNameEnum name)), and the unregistration interface 2 (unregisterAfterEvent()ActionNameEnum name)).

[0033] The batch post-processing coordinator (IAfterEventHandle) is used to coordinate and manage the batch execution of all post-events, such as audit logs, data computation, notification sending, cache updates, etc. Its core method is afterSpreadEventHandle(actionNameEnum ActionName).

[0034] The Notification Listener interface is used to execute specific business notification events. Its core method for executing notifications can be doNotify(NotificationEvent event).

[0035] The `ISpreadListener` interface is used to implement a unified listener for pre- and post-event handling. Before business logic execution, the `doBeforeNotify` (`NotifyEvent`) event is invoked to handle data validation, permission checks, and preprocessing. After business logic execution, the `doAfterNotify` (`NotifyEvent`) event is invoked to handle audit logging, data synchronization, and notification sending.

[0036] The NotifyEvent parameter is used to implement data carrier and flow control. The event type is specified by the event type enumeration name: ActionNameEnum, the execution of subsequent operations is controlled by isCancel: boolean, the event parameter param: Object provides a unified event parameter container, and the specific event operation method is called by the event operation method (+method(type): type).

[0037] This caching layer is used for data management and intermediate scheduling. It includes a cache manager (SheetManager) that manages in-memory objects. In some embodiments, this cache manager implements a two-level caching mechanism between the server and the table database, dynamically maintaining the data model of the entire table page (typically represented as a List) in memory. <List <cell>>The Table object and ReportCacheDto subclass configuration information). All data read and write operations triggered by frontend commands first apply to the cache of this page.

[0038] See Figure 5 This illustrates a schematic diagram of the functional architecture of a cache manager provided in an exemplary embodiment. Figure 5 As shown, the cache manager's functional interface includes a table configuration cache object, ReportCacheDto, which is the core data transformation and caching object in the table system. Within this table configuration cache object, various configurations utilize a unified caching interface. For example, region configuration, fast data retrieval configuration, variable configuration, and other configurations can all be implemented using the interfaces provided in this table configuration cache object. For some common attributes, an operation type `operate: OperateEnum` is defined, such as add, query, update, or delete. These states can be converted to each other, thus affecting the data stored in the database. For some abstract methods, subclasses implement methods, such as converting a cached DTO to a dynamic object (`convertDynamicObject: DynamicObject`) and converting a dynamic object to a cached DTO (`dyConvert2Dto: ReportCacheDto`).

[0039] The cache manager's functional interface also includes a cache management class, which contains some core components, such as a cell mapping table (table: List). <List <cell>> This is used to map each cell in the online table, storing cell values ​​and settings; `CacheObjInvoker` is the caching executor for managing the table template's configuration item cache; `RelationDto` is used for the `AreaSettingDto`, a method for revelation operations on the previous period's or the same period last year's data retrieval area; `HighlightArea` is a list of highlighted areas. <List <cell>> is used to implement the currently highlighted area; formulaCell:Cell is used to implement the cell where the formula is currently being set. This cache management class includes some core methods, such as the getCell(int row, int col):Cell method for quickly accessing cell data in the cache; and getInvoker():CacheObjInvoker for accessing the cached configuration data executor, used to access the table's template configuration and business rules.

[0040] This cache manager achieves efficient business logic, secure address access, and modification of cached data through a specific invoker, avoiding the performance overhead of directly manipulating the database. This specific invoker can be configured as needed; in this embodiment, no specific limitation is made. For example, the specific invoker could be ReportCacheInvoker, etc. By avoiding direct database operations, page response speed is improved. For example, when editing a table containing 10,000 data items, the specific invoker in this cache manager reduces page response latency from an average of 2000 milliseconds in the prior art to below 200 milliseconds; the number of database requests is reduced from interaction for every operation to a single batch interaction during saving, resulting in a database pressure reduction of over 90%.

[0041] See Figure 6 This illustrates a page control command execution system and a table template initialization system provided in an exemplary embodiment. For example... Figure 6 As shown, the system includes a command abstract class (SpreadCommand), a batch executor (SpreadBatchInvoker), and a template initialization service (QueryInitCache).

[0042] The abstract command class (SpreadCommand) defines the standard interface for manipulating online page controls, encapsulating operations on front-end page controls and supporting advanced features such as undo and redo. This abstract command class (SpreadCommand) includes several attributes, such as: parameter type initParam, used to store various types of initialization data; execution command invokeMethod, used to represent the command to be executed; execution method name getMethodName, used to represent the name of the method to be executed; and parameter call getParameters, used to retrieve the parameters of the invoked page controls.

[0043] The SpreadBatchInvoker is used to execute commands for multiple page controls in batches. It includes various methods, such as a list of commands. <spreadcommand>Front-end page proxy viewProxy: ClientViewProxy, control identifier spreadKey: String, get command instance getInstance, and batch execute command call, etc.

[0044] The template initialization service (QueryInitCache) is used to load the configuration data of the table template into the cache. This service includes several public methods, such as queryByRepConfld:List, which queries a dynamic collection of objects containing the template configuration data. <dynamicobject>Query the DTO collection of template configuration data: getReportCacheData: List<?extends ReportCacheDto> Returns the classpath of the DTO object corresponding to the dynamic object, used to instantiate the DTO object getCacheClass: String.

[0045] This cache manager also provides configuration dependency data management. Accordingly, this cache layer not only stores tables, but also manages various metadata and configuration information such as table template variables (RepRuntimeVar), area settings (AreaSettingDto), and system data retrieval rules (AutoAreaSettingDto). Based on the commonalities of table configuration data, it uniformly abstracts the configuration parent class ReportCacheDto, defines common behavior methods and public properties of complex objects, and provides unified query and add login methods in ReportCacheInvoker and QueryInitCache. It provides configuration data functional support for subsequent complex business rules such as template copying, version control, and data entry tasks. Only a small amount of development work is required to realize the writing and use of configuration data for online tables, which can greatly reduce the development cycle and the secondary development time on the project site.

[0046] This database layer is used to achieve stable data persistence, responsible for the persistent storage and retrieval of table template configuration data and business data. Through the table template configuration data loading service, the system loads table template configuration data, such as template structure, variables, and region settings, into the cache layer as needed during initialization, building a complete table runtime environment and meeting the requirements for data consistency. Users complete the online table settings, including styles, formulas, and rule data such as data entry areas, calculation areas, variables, data retrieval rules, and reverse lookup rules. This configuration data is then first saved in the cache layer. After the user clicks the "Save" button on the page, the configuration data is uniformly stored in the database to prevent data inconsistencies.

[0047] In some embodiments, this system architecture also provides interfaces for commonly used control instructions and encapsulates commonly used command interfaces. During secondary development on-site, existing commands can be directly invoked or custom commands can be quickly developed, improving secondary development efficiency. The system architecture provides online table data and configuration data query interfaces, facilitating subsequent development and the invocation of dependent functional modules, thus improving development efficiency.

[0048] In this embodiment, a target adapter encapsulates various business events to identify business requests for a table. The request is then dispatched to the corresponding dedicated business plugin for that online table. This dedicated plugin fulfills the business requirements associated with the business event. By dispatching requests to the appropriate plugin based on the business event, there is no need to set up a separate adapter for each online table, simplifying the online table's interface. Only the business type needs to be matched with the appropriate plugin. This avoids dispersing business logic across various components, reducing code coupling, lowering development complexity, making the code easier to understand and maintain, and improving code reusability.

[0049] The online form processing method provided in this application will be described below with reference to the method embodiments. See also Figure 7 The diagram illustrates a flowchart of an online form processing method provided by an exemplary embodiment. As an example and not a limitation, the method is applied to a server in which the aforementioned system architecture is deployed.

[0050] S701, in response to a business request for any online form, the server identifies the business event corresponding to the business request through a target adapter, which encapsulates various adapters corresponding to different business events.

[0051] In response to a business request for any online form, the server triggers a target adapter to identify the business event corresponding to the request via a page control callback. Accordingly, the server receives the user-input business request through page controls in the front-end application layer; and identifies the corresponding business event through these page controls.

[0052] In some embodiments, the target adapter can identify the business event corresponding to the business request through the business event corresponding to the page control; or, the target adapter can identify the business event corresponding to the business request through the operation content of the business request. In this application embodiment, the method by which the target adapter identifies business events is not specifically limited.

[0053] This target adapter is provided by the front-end application layer. This front-end application layer implements unified event routing and command dispatching, connecting user interaction with back-end logic. It provides a unified target adapter, such as SIHCReportSpreadAction, which implements table control operations. This adapter encapsulates various callback events for online tables, such as cell click (getLookupData), area selection (selectedSpread), cell value update (updateCellValue), and formula update (updateFormula). The front-end application platform uses a listener design pattern, registering matching listeners and callbacks for the business events generated by the target adapter. This decoupling through listeners and callbacks allows business code to simply register and implement the corresponding type of listener or callback, achieving a single responsibility principle.

[0054] This target adapter encapsulates interfaces for various callback events. For example, clicking a cell (getLookupData) is used to retrieve search data; selecting a table range on the front end and retrieving it on the back end (selectedSpread) is used to retrieve the selection information on the back end based on the cell range selected by the user on the front end; updating a cell on the front end (updateCellValue) is triggered when the user edits a cell; updating a formula on the front end (updateFormula) is triggered when the user edits or modifies a formula, etc.

[0055] Accordingly, when a user triggers a business request through the front-end page, the server receives the request through the front-end application layer and then invokes the callback event corresponding to that request. For example, when a user clicks a cell through the front-end page, the server receives the request through the front-end application layer, identifies it as a cell click, and invokes the cell click (getLookupData) event.

[0056] It's important to note that the server can initialize the selected table before this step. Accordingly, the user selects the online table they wish to manipulate via their device, and the selected online table is sent to the server. The server then loads the relevant table data based on the selected online table. For example, the user may use a table control callback (SpreadSelector) on the front end to make requests such as selecting a region or editing a cell. These requests trigger a callback from the table control to the target adapter (SIHCReportSpreadAction), which then identifies the corresponding business event for that request.

[0057] In some embodiments, the server sends a retrieval request to the table database based on the selected online table, retrieving the relevant table data for that online table from the table database. In other embodiments, the server queries the cache manager for the relevant table data of the selected online table. If the cache manager finds the relevant table data of the online table in its local cache, it loads the table using the locally cached data. If the cache manager does not find the relevant table data of the online table in its local cache, it then executes the step of sending a retrieval request to the table database. This caching layer is used to implement data management and intermediate scheduling. The caching layer includes a cache manager (SheetManager), which manages memory objects. In some embodiments, the cache manager is used to implement a two-level caching mechanism between the server and the table database, enabling dynamic maintenance of the entire table page's data model (typically represented as a List) in memory. <List <cell>>The Table object and ReportCacheDto subclass configuration information). All data read and write operations triggered by frontend commands first apply to the cache of this page.

[0058] Accordingly, in response to the loading operation for the online table, the server queries the table data in the local cache; if the table data in the local cache includes the target table data of the online table, the target table data is loaded from the local cache; if the table data in the local cache does not include the target table data of the online table, a data retrieval request is sent to the database, the local cache is updated based on the target table data, and the target table data sent by the database is loaded.

[0059] The relevant table data includes template configuration data and business data. Template configuration data includes the table's template structure, table style, formulas, etc., while business data includes the table's unique rule data, such as settings for fill-in areas, calculations, variables, and data retrieval rules. Since the template configuration data is standardized, in some embodiments, the server's cache manager can cache multiple types of template configuration data. In this step, the server can query the template configuration data matching the selected online table from the template configuration data, and retrieve the business data of the online table from the table database.

[0060] In this implementation, the table data of the online table is cached in the cache manager set in the server. When the relevant table data needs to be loaded, the relevant table data can be retrieved from the local cache first. When the relevant table data is retrieved from the local cache, the server does not need to interact with the table database again. This reduces the direct interaction between the server and the table database, reduces the communication pressure, and thus prevents problems such as system lag.

[0061] S702, the server forwards the business event to the corresponding business event matching plugin in the online table.

[0062] The server identifies the business event through the target adapter, dispatches the business event to the basic business plugin of the online form, registers the required business processor for the business event with the basic business plugin, and obtains the dedicated business plugin matching the business event. This step can be achieved through the following steps: S7021, the server retrieves the basic business plugin corresponding to the online form.

[0063] The server dispatches the business event to the basic business plugin of the online form through the target adapter.

[0064] S7022, the server will register the business processor required to implement the business event to the basic business plugin, and obtain the exclusive business plugin that matches the business event.

[0065] The business processor refers to the processor required by the business plugin to implement the relevant logic code of the business event. The business processor can be a listener (triggered by control events) or a callback handler (triggered by custom buttons).

[0066] Based on business events, relevant listeners or callbacks are registered in the business plugin, thereby implementing the business event through the plugin. The base class of this business plugin can register various listener classes, enabling listener registration and deregistration operations. This business plugin includes the core plugin base class (SliteSpreadBasePlugin), the event registration management center (IRegisterEvent), the batch post-processing coordinator (IAfterEventHandle), the notification listener interface (NotifyListener), the pre- and post-processor listener interfaces (ISpreadListener), and the notification event parameters (NotifyEvent).

[0067] The plugin base class (SliteSpreadBasePlugin) provides basic event logic code, such as table selector (selector: SpreadSelector), event chain (eventChain: SpreadEventChain), getting the selected coordinate range in the online table (getSpreadSelector: SpreadSelector), getting the current online table information manager (getSheetData: SheetManager), and getting the necessary parameters for server operations on the online table (getSpreadParam: SpreadlModelParam), etc.

[0068] The Event Registry (IRegisterEvent) provides interfaces for plugins to register front-end triggered events, such as the pre-registration notification interface (registerBeforeEvent(ActionNameEnum name, NotifyListenerIs)), the post-registration notification interface (registerAfterEvent(ActionNameEnum name, NotifyListenerIs)), the unregistration interface 1 (unregisterBeforeEvent(ActionNameEnum name)), and the unregistration interface 2 (unregisterAfterEvent()ActionNameEnum name)).

[0069] The batch post-processing coordinator (IAfterEventHandle) is used to coordinate and manage the batch execution of all post-events, such as audit logs, data computation, notification sending, cache updates, etc. Its core method is afterSpreadEventHandle(actionNameEnum ActionName).

[0070] The Notification Listener interface is used to execute specific business notification events. Its core method for executing notifications can be doNotify(NotificationEvent event).

[0071] The `ISpreadListener` interface is used to implement a unified listener for pre- and post-event handling. Before business logic execution, the `doBeforeNotify` (`NotifyEvent`) event is invoked to handle data validation, permission checks, and preprocessing. After business logic execution, the `doAfterNotify` (`NotifyEvent`) event is invoked to handle audit logging, data synchronization, and notification sending.

[0072] The NotifyEvent parameter is used to implement data carrier and flow control. The event type is specified by the event type enumeration name: ActionNameEnum, the execution of subsequent operations is controlled by isCancel: boolean, the event parameter param: Object provides a unified event parameter container, and the specific event operation method is called by the event operation method (+method(type): type).

[0073] In this step, the server determines the business processor required to implement the business event, registers the required business processor through the event registration management center (IRegisterEvent) in the basic business plugin, and obtains the exclusive business plugin matching the business event.

[0074] S7023, the server forwards the business event to the dedicated business plugin corresponding to the online form.

[0075] The server dispatches the business event to the dedicated business plugin that matches the business event, and the dedicated business plugin fulfills the business requirements corresponding to the business event.

[0076] In this implementation, a matching business processor is registered based on the business events generated in the target adapter. This decoupling is achieved through the business processor, so that the business code only needs to register and implement the corresponding type of listener or callback, thus realizing the single responsibility principle.

[0077] S703, the server implements the business requirements corresponding to this business event based on this dedicated business plugin.

[0078] This dedicated business plugin calls the service interface corresponding to the business event, thereby executing the corresponding logic code and fulfilling the corresponding business requirements.

[0079] In some embodiments, the template initialization service (QueryInitCache) is used to load the configuration data of the table template into the cache. This template initialization service (QueryInitCache) includes several public methods, such as queryByRepConfld:List, which queries a dynamic collection of objects containing template configuration data. <dynamicobject>Query the DTO collection of template configuration data: getReportCacheData: List<?extends ReportCacheDto> Returns the classpath of the DTO object corresponding to the dynamic object, used to instantiate the DTO object getCacheClass: String.

[0080] This system architecture also provides interfaces for commonly used control commands and encapsulates commonly used command interfaces. During on-site secondary development, existing commands can be directly invoked or custom commands can be quickly developed, improving development efficiency. Correspondingly, in response to a setting request, the server invokes control commands based on the setting request and provides the service interfaces required by the setting request based on the control commands. The system architecture provides online table data and configuration data query interfaces, facilitating subsequent development and the invocation of dependent functional modules, thus improving development efficiency.

[0081] Correspondingly, this cache manager also provides configuration dependency data management. Accordingly, this cache layer not only stores tables, but also manages various metadata and configuration information such as table template variables (RepRuntimeVar), area settings (AreaSettingDto), and system data retrieval rules (AutoAreaSettingDto). Based on the commonalities of table configuration data, a unified configuration parent class ReportCacheDto is abstracted, defining common behavior methods and public properties of complex objects. Unified query and add login methods are provided in ReportCacheInvoker and QueryInitCache, providing configuration data functional support for subsequent complex business rules such as template copying, version control, and data entry tasks. Only a small amount of development work is required to realize the writing and use of configuration data for online tables, which can greatly reduce the development cycle and the secondary development time on the project site.

[0082] In this embodiment, a target adapter encapsulates various business events to identify business requests for a table. The request is then dispatched to the corresponding dedicated business plugin for that online table. This dedicated plugin fulfills the business requirements associated with the business event. By dispatching requests to the appropriate plugin based on the business event, there is no need to set up a separate adapter for each online table, simplifying the online table's interface. Only the business type needs to be matched with the appropriate plugin. This avoids dispersing business logic across various components, reducing code coupling, lowering development complexity, making the code easier to understand and maintain, and improving code reusability.

[0083] When implementing corresponding business requirements through dedicated business plugins, the task handler calls the corresponding service interface to fulfill the business requirements corresponding to the relevant business events. See also... Figure 8 The diagram illustrates a flowchart of an online form processing method provided by an exemplary embodiment. As an example and not a limitation, the method is applied to a server in which the aforementioned system architecture is deployed.

[0084] S801, in response to a business request for any online form, the server identifies the business event corresponding to the business request through a target adapter, which encapsulates various adapters corresponding to different business events.

[0085] This step is based on the same principle as step S701, and will not be repeated here.

[0086] S802, the server forwards the business event to the corresponding business event matching plugin in the online table.

[0087] This step is based on the same principle as step S702, and will not be repeated here.

[0088] S803, the server calls the business logic processing interface corresponding to the business event based on the task processor registered in the dedicated business plugin.

[0089] The task handler includes a listener and a callback. The listener is used to handle business events triggered by controls, such as data entry events. The callback is used to handle business events triggered by custom buttons, such as save events.

[0090] S804, the server implements the business requirements corresponding to the business event based on this business logic interface.

[0091] When the business event is a cell entry event, the task processor is a listener. In some embodiments, the server can obtain the data entered in the cell through the listener and cache the data through a cache manager. In other embodiments, the server can first validate the listened-in data, and only cache it after the validation is successful. Accordingly, this process can be implemented through the following steps, including: (1) The server listens to the information filled in the target cell of the online table through the listener.

[0092] When a user edits a cell on their device, the front-end table control triggers the `updateCellValue` event. This event carries the information entered in this edit. For example, if the edit operation modifies the value of cell A1 to 100, then the event carries the position information of cell A1 and the modified value, i.e., row = x, column = y, value = 100. See also... Figure 9 After the server receives the event through the target adapter, it distributes the event to the corresponding business plugin so that the business plugin can trigger the corresponding listener.

[0093] (2) The server calls the verification service through the listener, which is used to verify the information entered.

[0094] This verification service is used to validate the information entered by the user. In some embodiments, the server verifies the entered information according to preset entry rules. For example, it determines whether the entered information is valid based on the values ​​in the preceding and following cells, as well as preset cell size rules.

[0095] Please continue reading Figure 9 The server triggers the listener to execute the doNotify() method through the business plugin. Then the listener calls the updateCellValue interface, which in turn calls the verification service. The verification server then verifies the information entered.

[0096] (3) When the information is verified, the server updates the data of the target cell in the cache based on the information.

[0097] After the verification service completes the verification, it sends the verification result back to the cache operator. The cache operator determines whether to update the cache manager based on the verification result. When the verification passes, it updates the corresponding cell in the cache manager and records the verification result in the cache. Correspondingly, the cache manager returns a cache success notification. The cache operator also returns the verification result to the listener. If the verification result indicates that the verification passed, no other operations are performed. If the verification result indicates that the verification was incorrect, the listener sends a notification to the front-end table control, which then marks the corresponding cell on the front end to indicate that the input value is incorrect.

[0098] When the business event is a save event, the task handler is a callback. In some embodiments, the server calls the cache operation business interface through the callback. The cache operation business interface is used to retrieve the table data to be stored in the cache manager and store the table data to be stored in the table database.

[0099] See Figure 10 When the user clicks the "Save" button, the front-end table control triggers the `save_op` operation event. Based on this event, the table's business plugin provides feedback on the online table control's table style and cell values. The front-end table control then triggers the `saveSpread` event, which is dispatched by the target adapter to the corresponding business plugin, triggering a callback method for business logic processing. The callback calls the cache operator's database entry interface to retrieve the cached table and dependency configuration data from the cache manager. The cache operator then calls the unified database entry interface to store the table data in the representation database for persistent storage. Correspondingly, the table database performs storage operations, simultaneously writing the table's business data and configuration data. Upon successful storage, a successful storage message carrying the table data is returned to the cache operator. The cache operator then returns a success message to the front-end table control so that the table control can provide feedback to the user through the user's device. After successful storage, the control is rebuilt and the latest configuration data is cached.

[0100] In this embodiment, a target adapter encapsulates various business events to identify business requests for a table. The request is then dispatched to the corresponding dedicated business plugin for that online table. This dedicated plugin fulfills the business requirements associated with the business event. By dispatching requests to the appropriate plugin based on the business event, there is no need to set up a separate adapter for each online table, simplifying the online table's interface. Only the business type needs to be matched with the appropriate plugin. This avoids dispersing business logic across various components, reducing code coupling, lowering development complexity, making the code easier to understand and maintain, and improving code reusability.

[0101] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0102] See Figure 11 It shows a schematic diagram of the structure of an online form processing apparatus provided in this application, including various units for performing the various steps in the above embodiments, see [link to diagram]. Figure 11 The online form processing device includes: The identification unit 1101 is used to identify the business event corresponding to any business request for any online form through the target adapter. The target adapter encapsulates multiple adapters corresponding to various business events. Dispatch unit 1102 is used to forward the business event to the dedicated business plugin for matching the business event corresponding to the online table. The processing unit 1103 is used to implement the business requirements corresponding to the business event based on the dedicated business plugin.

[0103] In some embodiments, the dispatching unit 1102 is configured to obtain the basic business plugin corresponding to the online form; register the business processor required to implement the business event to the basic business plugin to obtain the exclusive business plugin matching the business event; and forward the business event to the exclusive business plugin corresponding to the online form.

[0104] In some embodiments, the processing unit 1103 is configured to call the business logic processing interface corresponding to the business event based on the task processor registered in the dedicated business plugin; and implement the business requirements corresponding to the business event based on the business logic interface.

[0105] In some embodiments, the business event is a cell entry event, and the task processor is a listener; the processing unit 1103 is used to listen to the entry information of the target cell in the online table through the listener; to call the verification service through the listener, the verification service is used to verify the entry information; when the entry information passes the verification, the data of the target cell in the cache is updated based on the entry information.

[0106] In some embodiments, the business event is a save event, and the task processor is a callback; the processing unit 1103 is used to call the cache operation business interface through the callback, the cache operation business interface is used to obtain the table data to be stored in the cache manager, and store the table data to be stored in the table database.

[0107] In some embodiments, the identification unit 1101 is configured to receive a business request input by a user through a page control in the front-end application layer; and to identify the business event corresponding to the business request through the page control.

[0108] In some embodiments, the device further includes: The query unit is used to query locally cached table data in response to a load operation on the online table; The loading unit is used to load the target table data from the local cache if the table data in the local cache includes the target table data of the online table. The sending unit is configured to send a data retrieval request to the database if the local cached table data does not include the target table data of the online table, update the local cache based on the target table data, and load the target table data sent by the database.

[0109] In this embodiment, a target adapter encapsulates various business events to identify business requests for a table. The request is then dispatched to the corresponding dedicated business plugin for that online table. This dedicated plugin fulfills the business requirements associated with the business event. By dispatching requests to the appropriate plugin based on the business event, there is no need to set up a separate adapter for each online table, simplifying the online table's interface. Only the business type needs to be matched with the appropriate plugin. This avoids dispersing business logic across various components, reducing code coupling, lowering development complexity, making the code easier to understand and maintain, and improving code reusability.

[0110] Figure 12 This is a schematic diagram of a server provided in an exemplary embodiment of this application. Figure 12 As shown, the server 12 in this embodiment includes a processor 120, a memory 121, and a computer program 122 stored in the memory 121 and executable on the processor 120, such as an online form processing program. When the processor 120 executes the computer program 122, it implements the steps in the various online form processing method embodiments described above, for example... Figure 7 Steps S701 to S703 are shown. Alternatively, when the processor 120 executes the computer program 122, it implements the functions of each unit in the above-described device embodiments, for example... Figure 11 The functions of units 1101 to 1103 are shown.

[0111] For example, the computer program 122 can be divided into one or more units, which are stored in the memory 121 and executed by the processor 120 to complete this application. The one or more units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 122 in the server 12. For example, the computer program 122 can be divided into an identification unit 1101, a dispatching unit 1102, and a processing unit 1103, with the specific functions of each module as follows: The identification unit 1101 is used to identify the business event corresponding to any business request for any online form through the target adapter. The target adapter encapsulates multiple adapters corresponding to various business events. Dispatch unit 1102 is used to forward the business event to the dedicated business plugin for matching the business event corresponding to the online table. The processing unit 1103 is used to implement the business requirements corresponding to the business event based on the dedicated business plugin.

[0112] The server 12 can be any server with control functions. The server 12 may include, but is not limited to, a processor 120 and a memory 121. Those skilled in the art will understand that... Figure 12 This is merely an example of server 12 and does not constitute a limitation on server 12. It may include more or fewer components than shown, or combine certain components, or different components. For example, server 12 may also include input / output devices, network access devices, buses, etc.

[0113] The processor 120 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0114] The memory 121 can be an internal storage unit of the server 12, such as a hard drive or RAM. The memory 121 can also be an external storage device of the server 12, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or FlashCard. Furthermore, the memory 121 can include both internal and external storage units of the server 12. The memory 121 is used to store the computer program and other programs and data required by the terminal device. The memory 121 can also be used to temporarily store data that has been output or will be output.

[0115] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0116] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0117] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0118] In the embodiments provided in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0119] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0120] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0121] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0122] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the above method embodiments.

[0123] This application also provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps described in the various method embodiments above.

[0124] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.< / dynamicobject> < / cell> < / dynamicobject> < / spreadcommand> < / cell> < / cell> < / cell>

Claims

1. An online form processing method, characterized in that, The method includes: In response to a business request for any online form, the target adapter identifies the business event corresponding to the business request. The target adapter encapsulates various conversion interfaces corresponding to different business events. Forward the business event to the dedicated business plugin that matches the business event in the online table; Based on the dedicated business plugin, the business requirements corresponding to the business events are realized.

2. The method as described in claim 1, characterized in that, The step of forwarding the business event to the dedicated business plugin for matching the business event corresponding to the online table includes: Obtain the basic business plugin corresponding to the online form; Register the business processor required to implement the business event to the basic business plugin to obtain the exclusive business plugin that matches the business event; The business event is forwarded to the dedicated business plugin corresponding to the online form.

3. The method as described in claim 1, characterized in that, The implementation of the business requirements corresponding to the business event based on the dedicated business plugin includes: The task processor registered in the dedicated business plugin calls the business logic processing interface corresponding to the business event. The business requirements corresponding to the business events are implemented based on the business logic interface.

4. The method as described in claim 3, characterized in that, The business event is a cell entry event, and the task processor is a listener; The process of calling the business logic processing interface corresponding to the business event based on the task processor registered in the dedicated business plugin includes: The listener monitors the information entered into the target cell in the online form. The listener invokes the verification service, which is used to verify the submitted information. When the information entered passes verification, the data in the target cell in the cache is updated based on the information entered.

5. The method as described in claim 3, characterized in that, The business event is a save event, and the task processor is a callback. The process of calling the business logic processing interface corresponding to the business event based on the task processor registered in the dedicated business plugin includes: The callback invokes the cache operation business interface, which is used to obtain the table data to be stored in the cache manager and store the table data to be stored in the table database.

6. The method as described in claim 1, characterized in that, The response to a business request for any online form, identifying the business event corresponding to the business request through the target adapter, includes: Receive business requests from the user through page controls in the front-end application layer; The page controls are used to identify the business events corresponding to the business requests.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: In response to a load operation on the online table, query the locally cached table data; If the table data in the local cache includes the target table data of the online table, load the target table data from the local cache; If the local cached table data does not include the target table data of the online table, a data retrieval request is sent to the database, the local cache is updated based on the target table data, and the target table data sent by the database is loaded.

8. An online table processing architecture, characterized in that, The architecture includes: a front-end application layer, a caching layer, and a database layer; The front-end application layer is equipped with a target adapter, which is used to interact with the front-end application through page controls. The target adapter is used to identify the business event corresponding to the business request and forward the business event to the dedicated business plugin that matches the business event corresponding to the online table. The cache layer is equipped with a cache manager, which is used to cache grid data through the cache manager. When a storage instruction is received, it interacts with the database layer to upload the grid data to the database layer. The database layer is used to store grid data.

9. A server comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the online table processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the online table processing method as described in any one of claims 1 to 7.

Images