Coordinated method and system for move operation with in-line editing in flat tree table
By using expand key sets and protection mechanisms in a flat tree-like table, the conflict between node movement and inline editing is resolved, ensuring data integrity and consistency, and guaranteeing the smoothness and reliability of user operations.
Patent Information
- Application Number
- CN202611544258.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-10-08
- Publication Date
- 2026-11-06
AI Technical Summary
In flat tree-structured tables, there is a conflict between node movement and inline editing operations, which leads to problems such as data loss, delayed operation feedback, difficulty in ensuring data consistency, and complex transmission of configuration parameters. Existing solutions lack an effective coordination mechanism.
By storing node data in a flat list, maintaining a set of expand keys, detecting uncommitted edits, and setting up protection and recovery mechanisms before and after move operations, we ensure that edits are not lost and achieve unified collaboration between move and edit.
It enables collaborative operation between mobile operations and inline editing, avoids the loss of uncommitted changes, ensures that edits made in collapsed and hidden lines are not missed when saving, and achieves standardized expansion control capabilities in a multi-layer component architecture.
Smart Images
Figure CN123050381A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing and interaction technology, and in particular to a collaborative method and system for moving operations and inline editing in a flat tree table. Background Technology
[0002] In enterprise information systems, tree structures are a widely used data organization method. Data nodes have hierarchical relationships, meaning that several child nodes belong to a certain parent group. Groups can be collapsed or expanded to form a hierarchical and scalable tree view. This type of view is usually presented in the form of a tree table on the front end: in the data layer, group nodes and leaf nodes are stored as flat lists (i.e., one-dimensional arrays). Each node uses a hierarchy field and a parent node identifier field to indicate its relationship with each other. During rendering, the tree-like visual effect is dynamically restored according to the hierarchy.
[0003] In the tree-like table above, users not only need to browse data, but also frequently perform two types of operations: first, moving nodes, including moving them up or down within the same group to adjust their order, and moving nodes from one group to another to change their hierarchical affiliation; second, performing inline editing within the table cells, directly modifying field values, and supporting functions such as saving, canceling, and comparing changes.
[0004] For node movement, there are three representative solutions: First, a drag-and-drop sorting solution, allowing users to drag and drop nodes to the target location using the mouse or touch. Second, an in-situ sort value editing solution, exposing the sorting sequence column in the table, allowing users to manually modify the sorting values to change the order; when moving across groups, the hierarchical belonging field also needs to be modified. Third, an independent tree control panel solution, placing an additional tree control on one side of the table, allowing users to drag and adjust the structure within the tree control before synchronizing the changes back to the table. For editing operations, there are two main existing solutions: First, a modal editing solution, where clicking on a row pops up an editing window, allowing users to make changes in the pop-up before returning to the table. Second, an inline editing solution, where the editing control is activated directly within the cell.
[0005] When the aforementioned move and edit schemes are placed in the same tree table and operate simultaneously, cross-operation conflicts that would not occur if the individual schemes were running independently will be exposed, as follows: First, moving a node triggers a full table reload, resulting in lost navigation positions and the silent discarding of uncommitted changes. In a system architecture where the server is responsible for row sorting authority, moving a node up, down, or across groups causes the server to reorder the relevant rows. Row numbers and even row identifiers (the unique identifiers of rows) may be reassigned. The frontend cannot simply move the row positions locally to complete the move; it must request the complete list data from the server and replace the local state entirely. This full table reload has two consequences: first, rows selected by the user before the move and expanded groups are all lost after the reload, requiring the user to search for them again in the reloaded list; second, if there are uncommitted edits locally, the full table reload will overwrite the local state with server data, and these uncommitted changes are overwritten without notification. Users often only discover the content loss afterward, and existing solutions lack a mechanism to uniformly intercept such risks at the entry point of the move operation.
[0006] Secondly, the results are not visible after moving to a collapsed group. When a user moves a node to a target group that is currently collapsed, the child node rows of the target group are hidden. Therefore, the user cannot immediately see the result after the move is completed. The user needs to manually find and expand the target group to confirm whether the operation was successful, resulting in a delay in feedback.
[0007] Third, neither the drag-and-drop sorting scheme nor the independent tree operation panel scheme can migrate nodes from one group to another; although the in-place editing sort value scheme involves modifying the hierarchy field, it requires users to manually adjust both the sort number and hierarchy field simultaneously, which is cumbersome, makes it difficult to guarantee data consistency, and makes it impossible to easily move nodes across groups.
[0008] Fourth, in a multi-layered nested component architecture, the configuration parameters required for tree rendering are defined by the top layer and consumed by the bottom layer. The expansion and collapse control capabilities of the bottom layer also need to be passed back to the top layer for invocation. Existing solutions lack a standardized cross-layer transmission mechanism, resulting in a complex chain.
[0009] Fifth, a key feature of tree-structured tables is their support for expanding and collapsing groups. In a collapsed state, rows belonging to that group are not visible on the interface. Existing solutions often only traverse currently visible data rows when performing a save operation. This means that if a user edits data within a group, then collapses that group, and then performs a save operation, the edits made within that group are missed because they are no longer visible and cannot be submitted and saved.
[0010] In summary, how to enable node movement and inline editing to work together in the same table component with flat data storage and tree view rendering is a technical problem that has not yet been effectively solved in this field. Based on this, this case is proposed. Summary of the Invention
[0011] The purpose of this invention is to provide a collaborative method and system for moving operations and inline editing in a flat tree-shaped table. It intercepts unsubmitted modifications at the entry point of the moving operation, avoids the entire table being overloaded and silently overwriting local content, actively restores the user's navigation position after the moving operation causes the entire table to be overloaded, and ensures that edits in collapsed and hidden rows are not missed when saving.
[0012] To achieve the above objectives, the present invention provides the following technical solution: A collaborative method for movement operations and inline editing in a flat tree-structured table, characterized by comprising: Step S1: Store all node data of the tree table in the form of a flat list. Each node is labeled with its hierarchical relationship through the hierarchy field and the parent node identifier field. Use this flat list as the complete data reference for the editing scope. Editing changes made by inline editing input are attached to the data of the corresponding node in the flat list. Maintain a set of expand keys to record the group identifiers that are currently expanded. Filter the flat list according to the set of expand keys to obtain a subset of visible data, and use this subset of visible data as the display range. When post-processing the edits, the complete data references are traversed instead of the visible data subset so that the edits in the collapsed hidden lines are fully included when saving; Step S2: In response to the node move operation request, check if there are any unsubmitted and unsaved edits in the flat list; if so, the move operation is prohibited and the process terminates; otherwise, proceed to step S3. Step S3: Initiate node movement through a unified movement operation interface. This interface distinguishes the movement direction through direction parameters. The movement direction includes at least moving up, moving down, and moving to a specified target. When the movement direction is moving to a specified target, the interface also receives a target group identifier. The unified movement operation interface is invoked to submit the node movement operation to the server. The server then performs node rearrangement and returns new complete list data, replacing the flat list entirely with the data returned by the server. After the replacement is complete, a recovery operation is performed based on the direction parameters. If the movement direction is upward or downward, the row that was selected before the replacement will be re-identified as selected in the flat list after the replacement by using the preset "keep selected" flag and the row association identifier. If the movement direction is to move to a specified target, the target group identifier is added to the expand key set to trigger a re-filtering of the replaced flat list, so that the target group is automatically expanded.
[0013] Furthermore, in step S1, the post-processing includes at least a save operation, a change comparison operation, and a cancel operation; The save operation iterates through the complete data reference to collect the edits and modifications of each row and submits them to the server, so that the edits and modifications made in the collapsed and hidden rows are fully included when saving. The change comparison operation is based on the complete data reference, comparing the current value of each row with the original value to generate a change mark, so that the change mark is not lost or misaligned due to the switching of expanded or collapsed states; The cancellation operation iterates through the complete data reference, restoring the modified field values of each row to their original values, so that the edits made in the collapsed and hidden rows are also undone when the operation is cancelled.
[0014] Furthermore, the tree table is composed of four nested components: a business operation layer, a form editing layer, an editing state management layer, and a core table layer. The business operation layer is responsible for arranging user operations and holding table references, the form editing layer is responsible for managing editing controls, the editing state management layer is responsible for maintaining the complete data references, and the core table layer is responsible for consuming tree configurations and performing tree rendering. The configuration parameters required for tree rendering are defined in the business operation layer and passed through the form editing layer and the edit-state management layer as is. The form editing layer and the edit-state management layer do not parse, modify, or consume the configuration parameters, but only deconstruct and actually consume them in the core table layer to perform tree rendering.
[0015] Furthermore, the control method for the expanded key set is exposed layer by layer among the four-layer components through a reference forwarding mechanism, as detailed below: The core table layer provides a method for setting the expand key set. This method is passed from the core table layer to the edit state management layer in the form of a reference. The edit state management layer forwards it to its own reference object and then passes it to the form editing layer. The form editing layer also forwards it to its own reference object and then passes it to the business operation layer. The business operation layer can call this method to update the expand key set through its own table reference.
[0016] Furthermore, the update of the expand key set includes a functional update, which is to update the expand state identifiers recorded therein by appending or removing them based on the current expand key set, rather than replacing the entire expand key set.
[0017] Furthermore, in step S2, the detection is achieved through a preset global dirty state registration table shared across components. When each editing module generates an unsubmitted editing modification, it registers a dirty identifier with the global dirty state registration table with a unique module identifier, and cancels the dirty identifier after the editing modification is saved or revoked or the editing module is uninstalled. The unique module identifier is composed of the component type, the page path, and the module number, enabling the global dirty status registration table to filter by page path to determine whether a dirty identifier exists within the current tab range.
[0018] Furthermore, the activation of the global dirty status registration table is controlled by a function switch. When the function switch is off, the registration table does not record dirty identifiers, and the filtering result is always "no dirty identifiers exist".
[0019] Furthermore, in step S3, the unified mobile operation interface supports batch node movement operations, in which the batch nodes move in the same direction.
[0020] Furthermore, in step S3, if the movement direction is to move to a specified target, a target selection step is also included before performing the movement operation, as follows: A pop-up target selector displays selectable target groups in a tree structure; The server only returns node data of the group type, excluding non-grouped leaf nodes and the row itself that is being moved; The hierarchical fields of the returned data are normalized to start from zero, and a temporary nested tree structure is constructed based on this for the display of the mobile target selector interface. The temporarily constructed nested tree is fully expanded. The tree table described in step S1 maintains a rendering mode that uses the visible subset of data as the display range.
[0021] A collaborative system for movement operations and inline editing in a flat tree-structured table based on the aforementioned method, characterized in that it includes: The data storage module is used to store all node data of the tree table in the form of a flat list. Each node is marked with its belonging relationship through a hierarchy field and a parent node identifier field. The flat list serves as a complete data reference for the editing scope. Editing modifications made by inline editing input are attached to the data of the corresponding node in the flat list. The expansion control module is used to maintain a set of expansion keys to record the group identifiers that are currently in the expanded state, filter the flat list according to the set of expansion keys to obtain a visible data subset, and use the visible data subset as the display range; The post-processing module is used to traverse the complete data reference rather than the visible data subset when post-processing the edited modifications; The gating module is used to respond to a node move operation request by detecting whether there are any unsubmitted and unsaved edits in the flat list; if so, the move operation is prohibited; if not, the move execution module is triggered. The movement execution module is used to initiate node movement through a unified movement operation interface. The unified movement operation interface distinguishes the movement direction by a direction parameter. The movement direction includes at least moving up, moving down, and moving to a specified target. When the movement direction is moving to a specified target, the interface also receives a target group identifier. The module calls the interface to submit the node movement operation to the server, which then performs node rearrangement and returns new complete list data to replace the flat list. After the replacement is completed, a recovery operation is performed based on the direction parameter.
[0022] The technical solution provided in this application has the following beneficial effects: 1. The coordination between move operations and inline editing is seamless. On one hand, before a move operation is initiated, the system checks if there are any uncommitted and unsaved edits in the flat list. If so, the move operation interface is prevented from being called, thus avoiding a table reload triggered by the move that would overwrite the local state with server-side data, causing uncommitted edits to be silently discarded. On the other hand, after the move operation is completed and the table reload occurs, for move-up and move-down operations, the rows selected before the replacement are re-identified as selected in the flat list after the replacement based on their association identifiers. For operations that move to a specified target, the target group identifier is automatically added to the expand key set to trigger re-filtering, causing the target group to expand automatically. Therefore, users do not lose uncommitted edits or navigation positions before or after a move operation, achieving seamless coordination between move operations and inline editing in time.
[0023] 2. Edits made in collapsed / hidden rows are not forgotten during saving. Because save operations in edit mode always iterate through the complete data reference (i.e., all data in the flat list) rather than just the visible subset of data after expansion / collapse filtering, even if the user collapses certain groups, causing the corresponding rows to be removed from the current rendering result, the edits made in these collapsed / hidden rows still exist in the complete data reference and will be fully traversed and submitted to the server during saving. Change comparison and cancellation operations are also based on the complete data reference, ensuring that change markers are not lost or misaligned due to switching between expanded and collapsed states, and edits made in collapsed / hidden rows are also fully undone during cancellation.
[0024] 3. Expandable control capabilities are standardized and passed across layers within a multi-layered component architecture, with clear boundaries of responsibility for each layer. Configuration parameters required for tree rendering are defined in the business operation layer and then passed verbatim through the form editing layer and the edit-state management layer. Intermediate layer components do not parse, modify, or consume these configuration parameters; they are only deconstructed and consumed by the core table layer to execute tree rendering. Simultaneously, the expand key set setting method provided by the core table layer is exposed upwards layer by layer through a reference forwarding mechanism, ultimately being called directly by the business operation layer through its held table reference. This bidirectional information flow design, with configuration passed downwards and capabilities forwarded upwards, ensures that intermediate layer components remain unaware of tree-based capabilities, requiring no code modification for tree-based requirements, and maintaining clear boundaries of responsibility for each of the four component layers.
[0025] 4. Unsubmitted modifications at the mobile operation entry point are uniformly blocked, ensuring consistent and seamless protection. A globally shared dirty status registration table is established across components. Each editing module registers its unsubmitted modification status with a unique module identifier and automatically deregisters when modifications are saved, undone, or the module is uninstalled. The module identifier is a composite of component type, page path, and module number. This allows the registration table to filter for dirty identifiers within the current tab based on page path. The mobile operation interface uses this filtering result as a unified interception criterion. The entire detection and interception mechanism is controlled by a function switch and can be started and stopped as needed. This ensures that mobile operations scattered across multiple entry points are all subject to the same judgment result, preventing any single entry point from independently determining a vulnerability that could bypass protection. Attached Figure Description
[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0027] Figure 1 This is a schematic diagram of the four-layer component architecture and bidirectional information flow of the tree table in the embodiment; Figure 2 This is a schematic diagram of the complete link of the movement operation in the embodiment; Figure 3 This is a schematic diagram illustrating the decoupling of the display range and the editing range in the embodiment; Figure 4 This is a schematic diagram of the global dirty state registration table and the destructive operation gating process. Detailed Implementation
[0028] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0029] Before describing specific embodiments, several terms used in this application will be explained.
[0030] 1. Editing State: The active state of editing interactions in the table, which includes two levels: (a) Presentation layer: The editing control is expanded and the input focus is visible, that is, the visual state in which the user is editing in a cell; (b) Data layer: Field values have modifications that have not yet been committed and saved, referred to as dirty state below.
[0031] The two layers can exist independently. When the edit control is expanded but the content has been saved, the data layer is clean; when the content has been modified but the input box has been collapsed, the data layer is still dirty. In the method of this application, whether a destructive operation (such as a move operation) is blocked by the gating is determined solely by the data layer (whether there are uncommitted modifications), and is unrelated to the presentation layer (whether the edit control is expanded).
[0032] 2. Expand key set: A set of identifiers that records which group rows are currently in an expanded state. The set stores the unique identifier of each group. The core table layer uses this set to determine which child node rows of each group participate in rendering and which are collapsed and hidden.
[0033] 3. Property Passthrough: Pass a property received by the parent component to the child component or a deeper-level grandchild component as is. The intermediate component does not parse, consume, or modify the property.
[0034] 4. Reference forwarding: A technique for exposing internal methods or states across component layers, enabling outer components to call methods defined within deeper child components. A deeper component attaches a method to an exposed reference object, which is then passed up the hierarchy by the middle-level components until it reaches the business logic layer for invocation.
[0035] 5. Dirty State: The state in which there are edits that have not yet been saved in the table. In this application, dirty states are centrally recorded in a global dirty state registry table shared across components, and each editing module registers itself with a unique module identifier.
[0036] 6. Flat list: also known as a one-dimensional array, it stores all node data (including group nodes and leaf nodes) of the tree table in the same array. Each node is labeled with its hierarchical relationship through the hierarchy field and the parent node identifier field. During rendering, the tree-like visual effect is dynamically restored according to the hierarchy.
[0037] 7. Visible data subset: The set of data rows that should currently be included in the table rendering, obtained after filtering the complete flat list through the expand key set.
[0038] 8. Inline Editing: This is an editing method that allows users to directly activate editing controls within table cells and modify field values in-place, unlike modal editing methods that pop up separate editing windows. All edits and modifications in this application originate from inline editing input by the user within table cells.
[0039] 9. Rendering: The process of converting data into visual interface elements and drawing them on the screen. In this application, rendering is based on the visible subset of data (i.e., the display range), and each row in the subset is drawn as a visible row in the table. Child node rows under collapsed groups are not in the visible subset of data and therefore do not participate in rendering. The editing range (complete data reference) is not affected by the rendering range, and post-processing operations such as saving, changing comparisons, and canceling always traverse the complete data.
[0040] This embodiment provides a collaborative method for movement operations and in-line editing in a flat tree-structured table. This method operates within a tree-structured table component consisting of four nested layers: a business operation layer, a form editing layer, an editing state management layer, and a core table layer. By decoupling the display range and editing range at the data level and setting content protection and position restoration mechanisms at both ends of the movement operation, collaborative work between movement operations and in-line editing is achieved within the same table instance. The specific steps of this method are as follows.
[0041] Step S1, as follows Figure 3As shown, all node data of the tree table is stored in the form of a flat list. Each node contains a hierarchy field and a parent node identifier field, used to indicate the hierarchical relationship between nodes. This flat list serves as a complete data reference for the editing scope; that is, edits are always attached to the data of the corresponding nodes in this flat list, regardless of whether these nodes are currently invisible on the interface due to grouping or collapsing. Above the flat list, a set of expand keys is maintained. The expand key set is a collection of identifiers that records which group rows are currently expanded. The core table layer filters the flat list based on this expand key set, retaining child node rows belonging to expanded groups and filtering out child node rows belonging to collapsed groups, thus obtaining a visible subset of data. This visible subset of data serves as the display scope and is used only to determine which rows the table currently renders. This establishes two independent data scopes: the display scope and the editing scope. The former is the data foundation for rendering and display, while the latter is the data foundation for editing operations. Both are maintained independently and do not interfere with each other.
[0042] During inline editing, users directly modify field values within table cells, and the resulting edits are attached to the data of the corresponding node in the flat list. According to the definition of edit state, it comprises two independent layers: the presentation layer and the data layer. The presentation layer refers to whether the editing control is expanded and whether the focus is visible, while the data layer refers to whether there are any uncommitted edits (i.e., a dirty state). In this method, whether a move operation is blocked by the gating system is determined solely by whether there are uncommitted modifications in the data layer, and is unrelated to the presentation layer.
[0043] When a user triggers post-processing of edits, the system always iterates through the complete data reference (i.e., the entire data of the flat list), not the visible subset of data. In this embodiment, the post-processing includes save operations, change comparison operations, and cancel operations.
[0044] The save operation requires traversing the complete data reference, collecting the edits on each row, and submitting them to the server. Even if the user collapses certain groups before saving, causing the corresponding rows to be removed from the current rendering result, the edits made in these collapsed and hidden rows still exist in the complete data reference and will be fully traversed and included in the save result.
[0045] The change comparison operation compares the current value after editing each row with the initial value when it was originally loaded, field by field, and generates visual markers (such as highlighting, color changing, or underlining) for fields with differences. The scope of the change comparison is the complete data reference, not a subset of the visible data. Therefore, even if the user switches between expanded and collapsed states before the change comparison, the change markers will not be lost or misaligned due to collapsing.
[0046] The cancellation operation also requires traversing the complete data reference to restore the modified field values of each row to their original values, and the edits in the collapsed and hidden rows are also completely undone.
[0047] The move operation inevitably causes the server to reorder the relevant rows, and row numbers and even row identifiers may be reassigned. Therefore, the frontend cannot simply move the row positions locally to complete the move; it can only request the complete list data from the server and replace the local state entirely. This full table reload introduces two risks: first, all rows selected by the user before the reload and expanded groups are lost; second, if there are any uncommitted and unsaved edits locally, the reload, which overwrites the local state with server data, will cause these edits to be silently discarded. To address these two risks, this method sets up protection and recovery mechanisms at both the beginning and end of the move operation, as detailed in steps S2 and S3.
[0048] Step S2: Perform the gating decision before the movement. For example... Figure 2 As shown, in response to a node move operation request, the system checks whether there are any uncommitted and unsaved edits in the flat list (i.e., whether the data layer is in a dirty state). If so, the move operation is prohibited and does not proceed to the next step; if not, it proceeds to step S3 through gating.
[0049] like Figure 4 As shown, this detection is achieved through a pre-defined, cross-component shared global dirty state registry. Each editing module (such as the edit-state management table, other independent forms on the page, or editing areas) registers a dirty identifier in the global dirty state registry with a unique module identifier when it generates unsubmitted edits. This dirty identifier is deregistered after the modification is saved or revoked. The editing module also automatically deregisters its dirty identifier upon uninstallation, preventing residual dirty records in the registry from causing permanent error-based disabling of operations after component destruction. The edit-state management layer compares the current data with the original data references to determine if unsubmitted modifications exist and automatically synchronizes this result to the global dirty state registry, eliminating the need for each business page to implement its own judgment logic.
[0050] The module identifier is composed of the component type, the page path, and the module number. This allows the registration form to not only answer whether there is any unsaved content globally, but also to filter by page path to see if there is any dirty flag within the current tab. This prevents dirty status left over from other tabs from accidentally affecting the movement operation of the current tab.
[0051] As a preferred option, the entire gating mechanism is controlled by a function switch. When the function switch is on, the global dirty status register records and filters normally; when the function switch is off, the global dirty status register does not record dirty identifiers, the filtering result is always that no dirty identifier exists, and each operation button resumes normal availability judgment.
[0052] Step S3: Perform the movement operation and restore the navigation position. For example... Figure 2 As shown, after gating is successful, node movement is initiated through a unified movement operation interface. This interface distinguishes the movement direction by a direction parameter, which includes at least moving up, moving down, and moving to a specified target. When the direction is moving to a specified target, the interface also receives a target group identifier to specify which group the node will migrate to. This interface supports batch node movement operations, allowing multiple identifiers of nodes to be moved to be transmitted at once, but all nodes in the same call must move together in the same direction.
[0053] After submitting a move operation to the server by calling this interface, the server performs node rearrangement and returns new complete list data. The frontend then replaces the flat list entirely with the data returned by the server (i.e., a full table reload). After the replacement is complete, a restore operation is performed based on the direction parameters.
[0054] If the movement direction is upward or downward, the row is restored using a preset "keep selected" flag. This flag records the association identifier of the selected row before replacement. After replacement, the corresponding row is repositioned in the flat list after replacement based on this association identifier and re-identified as selected. Therefore, even though a full table reload may cause changes in row identifiers, the user's previously selected rows will automatically be restored to selection without needing to search for them again in the reloaded list. Moving upward and downward does not change the collapsed / expanded state of any groups.
[0055] If the movement direction is to move to a specified target, the target group identifier is added to the expand key set. After the expand key set is updated, the replaced flat list is re-filtered, the target group is included in the expanded state, and its child node rows (including the node rows that have just been moved) appear in the visible data subset. After the table is re-rendered, the group is automatically expanded, and the user can see the movement results without having to manually search and expand it.
[0056] The expansion key set supports a functional update method, which adds or removes a certain identifier based on the current expansion key set, rather than replacing the entire set, ensuring that the user's other existing expansion states are not affected.
[0057] Preferably, this embodiment also includes a move target selector. When the movement direction is to move to a specified target, before calling the unified move operation interface, the system pops up a move target selector, displaying selectable target groups in a tree structure. At this time, the request from the server only returns node data of the group type, excluding non-group leaf nodes and the row being moved itself. The hierarchical field of the returned data is normalized to start from zero (all hierarchical values minus the minimum value), and a nested tree structure is temporarily constructed based on this, specifically for the display of the move target selector interface. This temporarily constructed nested tree is fully expanded by default, so that all candidate target groups are visible when the selector is displayed without having to expand layer by layer, reducing the operations required for users to find target groups. The main table (i.e., the tree table described in step S1) always maintains a flat list rendering mode with the visible data subset as the display range, and is not affected by the construction of the temporary tree within the move target selector.
[0058] As mentioned above, the tree table consists of four nested components: a business operation layer, a form editing layer, an editing state management layer, and a core table layer. In this embodiment, these four components have independent boundaries of responsibility. Figure 1 As shown, the business operation layer is the top layer, responsible for orchestrating user operations (such as movement operations) and holding table references; the form editing layer is the second layer, responsible for managing editing controls; the edit state management layer is the third layer, responsible for maintaining complete data references (i.e., flat lists) and dirty state detection; the core table layer is the bottom layer, responsible for consuming tree configurations and performing tree rendering.
[0059] In this four-layer nested component architecture, the information flow is divided into two directions: One approach is configuration pass-through (i.e., configuration pass-through mechanism): The configuration parameters required for tree rendering (such as whether to fully expand by default, whether to display level numbers, etc.) are defined in the business operation layer and passed down layer by layer through attribute pass-through syntax. The form editing layer and the edit-state management layer act as intermediate layers, without parsing, modifying, or consuming the configuration parameters, but simply passing them as is. The configuration parameters eventually reach the core table layer, where they are deconstructed and actually consumed to execute the tree rendering logic.
[0060] Secondly, there is the capability forwarding mechanism (i.e., reference forwarding): The core table layer provides a method for setting the expand key set. This method is passed from the core table layer to the edit-state management layer in the form of a reference. The edit-state management layer forwards this method to its own reference object, which points to the core table layer. After attaching the expand key setting method to its own reference object, the edit-state management layer continues to pass it up to the form editing layer. The form editing layer also forwards it to its own reference object, which points to the edit-state management layer, and continues to pass it up to the business operation layer. The business operation layer can directly call this setting method through its own table reference to update the expand key set. The update of the expand key set includes the functional update mentioned in step S3.
[0061] Here, it's important to clarify the difference between table references and the references held by the intermediate layers. The table reference held by the business operation layer points to the form editing layer. Through a chain of references forwarded layer by layer from the form editing layer to the edit-state management layer, it ultimately reaches the core table layer. The form editing layer's own reference points to the edit-state management layer, used by the form editing layer to access the attributes and methods within the edit-state management layer. The edit-state management layer's own reference points to the core table layer, used by the edit-state management layer to directly access the attributes and methods within the core table layer. These three differ in their holders, the levels they point to, and the scope of their accessible capabilities.
[0062] This bidirectional information flow design, where configuration is passed down and capabilities are forwarded upward, ensures that the two intermediate components—the form editing layer and the edit-state management layer—remain completely unaware of the tree-like capabilities. The tree-like configuration content flows through uninterrupted without being consumed, and the tree-like control capabilities are forwarded layer by layer via references without being parsed. When tree-like requirements change, only the business operation layer (configuration definition end) and the core table layer (configuration consumer and capability provider end) need to be modified; the code in the two intermediate layers remains unaffected, and the responsibilities of each of the four components remain clearly defined.
[0063] The method for setting the expand key set can be reused in multiple business scenarios, including: expanding the specified group by default after data is loaded, automatically expanding the target group after moving a node to the target group, and automatically expanding the target group after adding a new node to the target group. Each scenario does not need to implement its own expand control logic repeatedly.
[0064] It should also be noted that the gating mechanism of this embodiment, namely the operation gating based on the global dirty state registration table shared across components as described in step S2, can not only be used in the movement operation of this embodiment, but also in other scenarios that require preventing loss, such as switching tabs, closing drawers, performing checkout / check-in or secondary confirmation interception before submitting for approval, etc. The related operations are not limited to movement operations, but may also involve destructive operations such as deletion and addition.
[0065] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.
[0066] Based on the above method, this embodiment also proposes a collaborative system for movement operations and inline editing in a flat tree-shaped table, including: The data storage module is used to store all node data of the tree table in the form of a flat list. Each node is marked with its belonging relationship through a hierarchy field and a parent node identifier field. The flat list serves as a complete data reference for the editing scope. Editing modifications made by inline editing input are attached to the data of the corresponding node in the flat list. The expansion control module is used to maintain a set of expansion keys to record the group identifiers that are currently in the expanded state, filter the flat list according to the set of expansion keys to obtain a visible data subset, and use the visible data subset as the display range; The post-processing module is used to traverse the complete data reference rather than the visible data subset when post-processing the edited modifications; The gating module is used to respond to a node move operation request by detecting whether there are any unsubmitted and unsaved edits in the flat list; if so, the move operation is prohibited; if not, the move execution module is triggered. The movement execution module is used to initiate node movement through a unified movement operation interface. The unified movement operation interface distinguishes the movement direction by a direction parameter. The movement direction includes at least moving up, moving down, and moving to a specified target. When the movement direction is moving to a specified target, the interface also receives a target group identifier. The module calls the interface to submit the node movement operation to the server, which then performs node rearrangement and returns new complete list data to replace the flat list. After the replacement is completed, a recovery operation is performed based on the direction parameter.
[0067] The following section describes the operation of this method in practical use, using specific application scenarios as examples.
[0068] Scenario 1: Zero omissions in saving edits made to collapsed / hidden rows. A user is editing a row in an expanded group, then collapses another group containing a previously edited but unsaved row. When the user clicks save, the system iterates through the complete flat list data reference, not just the currently visible subset. Therefore, the previous edits in the collapsed / hidden row are also included in the saved result and are not missed because the row is currently invisible. Similarly, if the user cancels, the edits in the collapsed / hidden row are completely undone; if the user views the changes before and after collapsing, the change markers are not lost or misaligned due to the collapsing operation.
[0069] Scenario 2: After moving to a collapsed group, the target automatically expands and the result is immediately visible. The user selects a check item, chooses the "Move to" operation, and selects a currently collapsed target group from the pop-up target selector. After the system calls the move interface to complete the move, it automatically adds the identifier of the target group to the expand key set in a function-based appending manner. The group then automatically expands, and the moved check item appears within the target group. The user can immediately confirm the move result without any additional operation. If the user expanded other groups before moving, the expanded state of these groups is retained after the move and is not affected by this append operation.
[0070] Scenario 3: Unified Gating of Dirty States to Prevent Accidental Content Loss. A user modifies a check result in a cell but hasn't saved it. The edit-state management layer compares the current data with the original data reference and determines that there is an uncommitted modification. It then registers a dirty flag in the global dirty state registry table using a unique module identifier composed of the edit-state management layer table, the current page path, and the module number. At this time, the move buttons (move up, move down, move to, etc.) on the table toolbar, when rendered, read the registry table's filtering results for the current tab, indicating the presence of a dirty flag. Therefore, they are uniformly disabled, preventing users from accidentally triggering these operations that would cause uncommitted content to be silently discarded due to table reload. When the user saves the modification, the edit-state management layer deregisters the dirty flag, and the buttons become available again. If the user chooses to undo the modification, deregistration is also triggered, and the buttons become available again. In addition, the same registration form can be reused in other scenarios where it is necessary to prevent the loss of unsaved content. For example, if a user tries to switch tabs when there is a dirty flag, the system will query the registration form and find that the current tab has a dirty flag, and pop up an unsaved confirmation prompt to intercept the switch. The registration form can also be reused in scenarios such as closing drawers containing editing modules, performing checkout / check-in operations, or intercepting secondary confirmations before submitting for approval.
[0071] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. Furthermore, the above embodiments only illustrate several implementation methods of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. For those skilled in the art, several modifications and improvements can be made, and these all fall within the protection scope of the present invention.
Claims
1. A collaborative method for movement operations and inline editing in a flat tree-shaped table, characterized in that, include: Step S1: Store all node data of the tree table in the form of a flat list. Each node is marked with its hierarchical relationship through the hierarchy field and the parent node identifier field. Use this flat list as the complete data reference for the editing scope. Editing changes made by inline editing input are attached to the data of the corresponding node in the flat list. Maintain a set of expand keys to record the group identifiers that are currently expanded. Filter the flat list according to the set of expand keys to obtain a subset of visible data, and use this subset of visible data as the display range. When post-processing the edits, the complete data references are traversed, rather than the visible subset of data; Step S2: In response to the node move operation request, check if there are any unsubmitted and unsaved edits in the flat list; if so, the move operation is prohibited. Otherwise, proceed to step S3; Step S3: Initiate node movement through a unified movement operation interface. This interface distinguishes the movement direction through direction parameters. The movement direction includes at least moving up, moving down, and moving to a specified target. When the movement direction is moving to a specified target, the interface also receives a target group identifier. The unified movement operation interface is invoked to submit the node movement operation to the server, which then performs node rearrangement and returns new complete list data to replace the flat list. After the replacement is completed, a recovery operation is performed based on the direction parameters. If the movement direction is upward or downward, the row that was selected before the replacement will be re-identified as selected in the flat list after the replacement by using the preset "keep selected" flag and the row association identifier. If the movement direction is to move to a specified target, the target group identifier is added to the expand key set to trigger a re-filtering of the replaced flat list, so that the target group is automatically expanded.
2. The method for coordinating movement operations and inline editing in a flat tree-shaped table as described in claim 1, characterized in that, In step S1, the post-processing includes at least a save operation, a change comparison operation, and a cancel operation; The save operation iterates through the complete data reference to collect the edits and modifications of each row and submits them to the server, so that the edits and modifications made in the collapsed and hidden rows are fully included when saving. The change comparison operation is based on the complete data reference, comparing the current value of each row with the original value to generate a change mark, so that the change mark is not lost or misaligned due to the switching of expanded or collapsed states; The cancellation operation iterates through the complete data reference, restoring the modified field values of each row to their original values, so that the edits made in the collapsed and hidden rows are also undone when the operation is cancelled.
3. The method for coordinating movement operations and inline editing in a flat tree-shaped table as described in claim 1, characterized in that, The tree-like table is composed of four nested components: a business operation layer, a form editing layer, an editing state management layer, and a core table layer. The business operation layer is responsible for arranging user operations and holding table references, the form editing layer is responsible for managing editing controls, the editing state management layer is responsible for maintaining the complete data references, and the core table layer is responsible for consuming tree configurations and performing tree rendering. The configuration parameters required for tree rendering are defined in the business operation layer and passed through the form editing layer and the edit-state management layer as is. The form editing layer and the edit-state management layer do not parse, modify, or consume the configuration parameters, but only deconstruct and actually consume them in the core table layer to perform tree rendering.
4. The method for coordinating movement operations and inline editing in a flat tree-shaped table as described in claim 3, characterized in that, The control method for the expanded key set is exposed layer by layer among the four-layer components through a reference forwarding mechanism, as follows: The core table layer provides a method for setting the expand key set. This method is passed from the core table layer to the edit state management layer in the form of a reference. The edit state management layer forwards it to its own reference object and then passes it to the form editing layer. The form editing layer also forwards it to its own reference object and then passes it to the business operation layer. The business operation layer can call this method to update the expand key set through its own table reference.
5. The collaborative method for movement operations and inline editing in a flat tree table as described in claim 4, characterized in that, The update of the expand key set includes a functional update, which is to update the expand state identifiers recorded therein by appending or removing them based on the current expand key set, rather than replacing the entire expand key set.
6. The collaborative method for movement operations and inline editing in a flat tree-shaped table as described in claim 1, characterized in that, In step S2, the detection is achieved through a preset global dirty state registration table shared across components. When each editing module generates an unsubmitted editing modification, it registers a dirty identifier with the global dirty state registration table with a unique module identifier, and cancels the dirty identifier after the editing modification is saved or revoked or the editing module is uninstalled. The unique module identifier is composed of the component type, the page path, and the module number, enabling the global dirty status registration table to filter by page path to determine whether a dirty identifier exists within the current tab range.
7. The collaborative method for movement operations and inline editing in a flat tree table as described in claim 6, characterized in that, The activation of the global dirty status registration table is controlled by a function switch. When the function switch is off, the registration table does not record dirty identifiers, and the filtering result is always "no dirty identifiers exist".
8. The method for coordinating movement operations and inline editing in a flat tree-shaped table as described in claim 1, characterized in that, In step S3, the unified mobile operation interface supports batch node movement operations, in which the batch nodes move in the same direction.
9. The method for coordinating movement operations and inline editing in a flat tree table as described in claim 1, characterized in that, In step S3, if the movement direction is to move to a specified target, a target selection step is also included before performing the movement operation, as follows: A pop-up target selector displays selectable target groups in a tree structure; The server only returns node data of the group type, excluding non-grouped leaf nodes and the row itself that is being moved; The hierarchical fields of the returned data are normalized to start from zero, and a temporary nested tree structure is constructed based on this for the display of the mobile target selector interface. The temporarily constructed nested tree is fully expanded. The tree table described in step S1 maintains a rendering mode that uses the visible subset of data as the display range.
10. A collaborative system for movement operations and inline editing in a flat tree-shaped table based on the method of any one of claims 1 to 9, characterized in that, include: The data storage module is used to store all node data of the tree table in the form of a flat list. Each node is marked with its belonging relationship through a hierarchy field and a parent node identifier field. The flat list serves as a complete data reference for the editing scope. Editing modifications made by inline editing input are attached to the data of the corresponding node in the flat list. The expansion control module is used to maintain a set of expansion keys to record the group identifiers that are currently in the expanded state, filter the flat list according to the set of expansion keys to obtain a visible data subset, and use the visible data subset as the display range; The post-processing module is used to traverse the complete data reference rather than the visible data subset when post-processing the edited modifications; The gating module is used to respond to a node move operation request by detecting whether there are any unsubmitted and unsaved edits in the flat list; if so, the move operation is prohibited; if not, the move execution module is triggered. The mobile execution module is used to initiate node movement through a unified mobile operation interface. The unified mobile operation interface distinguishes the movement direction through a direction parameter. The movement direction includes at least moving up, moving down, and moving to a specified target. When the movement direction is moving to a specified target, the interface also receives a target group identifier. The interface is called to submit the node movement operation to the server, which then performs node rearrangement and returns new complete list data to replace the flat list. After the replacement is completed, a recovery operation is performed based on the direction parameters.