A graphical file editing system and method

Abstract

The application discloses a kind of graphical file editing system and method.The system is deployed in the form of IDE plug-in, including: editor extension module of the embedded browser of JBCefBrowser integrated through FileEditorProvider interface;File recognition module based on file suffix scheduling corresponding editor;Graphical engine based on component metadata registry and classified rendering of JSON / XML data;Event processing module supporting three-stage drag and eight-way scaling;Event-driven communication module based on window.postMessage;Operation module of file and code synchronization through PSI interface;File template management module based on.ft template.The method includes: editor registration embedding, file recognition loading, content analysis rendering, interactive event processing, data persistence synchronization and template file creation steps.The application realizes the graphical drag editing of structured file in IDE, significantly improves development efficiency and standardization.

Description

Technical Field

[0001] This invention relates to the field of integrated development environment (IDE) plugin development and file editing technology, specifically to a graphical file editing system and method based on an IDE plugin platform, which is particularly suitable for development tool plugins for visual editing of structured files such as JSON and XML. Background Technology

[0002] As software development becomes increasingly complex, Integrated Development Environments (IDEs) have become essential tools for developers to write, debug, and manage code. Modern IDEs, such as IntelliJ IDEA, not only provide powerful code editing, syntax highlighting, intelligent code completion, and version control, but also support plugin extensions to meet the personalized needs of different development scenarios. Currently, numerous plugins for programming languages ​​such as Java and Kotlin support code generation, formatting, and static analysis, significantly improving development efficiency.

[0003] However, in specific development scenarios such as bank teller systems and enterprise application configuration management, developers often need to frequently write and maintain a large number of structured files, such as configuration files, interface description files, and process definition files in JSON (JavaScript Object Notation) and XML (Extensible Markup Language) formats. These files typically have strict syntactic structures and hierarchical relationships. Traditional text editors only provide syntax highlighting and basic formatting checks; developers still need to manually write and adjust the file content, a tedious and error-prone process. Especially when the file structure is complex and deeply nested, relying solely on text editing makes it difficult to intuitively understand the logical relationships between nodes, further impacting development and maintenance efficiency.

[0004] Currently, while some standalone visual JSON / XML editing tools exist, they typically run as standalone applications and cannot be seamlessly integrated with developers' IDE workflows. This necessitates frequent tool switching during development, disrupting the continuity of the development environment. Furthermore, the existing IDE plugin market lacks dedicated plugins that deeply integrate with IDE underlying capabilities (such as the Program Structure Interface (PSI), provide graphical drag-and-drop editing for structured files, and support interactive operations with code files.

[0005] Therefore, the existing technology has the following main problems:

[0006] 1. Inefficient editing method: Editing of structured files such as JSON and XML still mainly relies on manual text writing, lacking an intuitive graphical interface.

[0007] 2. Poor tool integration: Standalone visualization editing tools cannot be embedded in the IDE environment, resulting in fragmented workflows and reduced efficiency.

[0008] 3. Lack of intelligent assistance: Existing editing methods are difficult to utilize the code understanding capabilities of the IDE (such as PSI) to achieve automated and standardized operations on file content.

[0009] 4. Single interaction experience: It does not support advanced graphical interactions such as component-based dragging, scaling, and batch operations, and the editing experience is unfriendly.

[0010] To address the above problems, there is an urgent need for a structured file editing solution that can be integrated within the IDE environment, provide graphical editing capabilities, and deeply integrate with the underlying development interfaces of the IDE. Summary of the Invention

[0011] The present invention aims to solve the problems of inefficient structured file editing methods, poor tool integration, lack of intelligent assistance, and lack of advanced interactions in the existing IDE environment, and provides a graphical file editing system and method integrated within the IDE. By extending the traditional text editor to an interactive interface that supports visual drag-and-drop editing, intuitive, efficient, and standardized editing of structured files such as JSON and XML is achieved, and it is deeply integrated with the code understanding and operation capabilities of the IDE, thereby significantly improving development efficiency and file quality.

[0012] To achieve the above object, the present invention proposes a graphical file editing system and method. The system is deployed in the form of an IDE plugin, and the core lies in constructing a graphical editing framework that can be embedded in the IDE editor area. The system dynamically matches the corresponding graphical editor through a file type recognition module, renders the visual interface using embedded browser technology, and provides drag-and-drop, configuration, and linkage operation capabilities based on the component model. At the same time, the system deeply integrates the program structure interface (PSI) of the IDE, supports structured editing and linkage updates of code files such as Java, and realizes an integrated editing experience from the interface to the code.

[0013] The graphical file editing system provided by the present invention is deployed in the form of an IDE plugin and includes the following core modules:

[0014] Editor extension and embedding module: Register a custom editor based on the editor extension interface of the IDE plugin platform, and use embedded browser technology to embed the graphical user interface into the IDE editor area to achieve seamless integration of the graphical editor and the IDE native editing environment.

[0015] File type identification and scheduling module: Dynamically identifies file type based on file extension and schedules the corresponding graphical editor for loading, supporting parallel editing of multiple file types.

[0016] Graphical rendering engine: Includes component classification units and dynamic rendering units, used to parse structured content such as JSON and XML into visual components, and perform differentiated rendering according to component type, supporting separate components, container components, table components and tab components, etc.

[0017] Interactive event handling module: Implements graphical interactive functions such as drag, zoom, selection, and attribute configuration, and supports three-dimensional drag protocol, eight-way control point zoom mechanism and cross-container event transmission.

[0018] Front-end and back-end communication interface module: Based on WindowAPI, it establishes an event-driven bidirectional communication channel with the front-end interface, and uses JSON format to encapsulate commands and data to achieve efficient data synchronization between the graphical interface and the IDE back-end.

[0019] File and code operation module: Integrates the IDE's program structure interface, supports persistent reading and writing of source structured files, and can also operate on Java and other code files to achieve automatic synchronization of configuration and code.

[0020] File template management module: Provides custom file creation functionality based on IDE template mechanism, supports predefined file templates, and standardizes the initial file structure.

[0021] Corresponding to the system, the graphical file editing method provided by this invention includes the following steps:

[0022] Editor registration and embedding steps: When the IDE starts, register the custom graphical editor through the plugin extension mechanism, and when the user opens the target file, embed the embedded browser into the editor panel to replace or display the traditional text view in parallel.

[0023] File recognition and interface loading steps: Match and load the corresponding graphical editing interface based on the file extension of the opened file, and initialize the canvas and component library.

[0024] Content parsing and graphics rendering steps: Read the structured file content, map the data nodes to visual components through the component classification engine, and dynamically lay out and draw styles according to the preset rendering mode.

[0025] Interactive response and editing processing steps: Respond to user operations such as dragging, scaling, and property modification on the graphical interface, update component state and layout in real time, and transmit operation intentions to the backend through event communication mechanism.

[0026] Data synchronization and persistence steps: The backend receives operation instructions from the frontend, parses and converts them into modification actions on the source files, and calls the IDE document management interface to save the files; at the same time, if the editing operation is associated with code files, the code structure is automatically updated through the PSI interface.

[0027] File creation and template application steps: A graphical creation entry is provided, and users can quickly generate structured files that conform to the specifications through templates. The system automatically initializes the file content and component structure.

[0028] The template supports variable substitution and initial structure presets to ensure the standardization and consistency of newly created files.

[0029] The implementation of this invention, by transforming a traditional text editor into a graphical editing environment integrated within an IDE, brings about multi-dimensional and perceptible significant technological improvements, the specific effects of which are as follows:

[0030] 1. A Qualitative Leap in Editing Efficiency: A real-time rendering engine and drag-and-drop graphical editor are integrated into the IDE plugin. When the system parses configuration files, it maps them to component models in memory via a syntax tree and renders them as a visual canvas. When developers drag icons from the component library to the target location, the background calls a code generator to insert standardized JSON / XML code snippets at the precise nodes in the syntax tree based on the drag position and component properties. This design automatically generates handwritten code, significantly improving the efficiency of editing complex nested structures, making it particularly suitable for scenarios such as bank teller systems that require processing a large number of configuration items.

[0031] 2. Development Environment Integration: Deeply integrated as an IDE plugin, this feature extends the IDE's file editor registry to associate the opening of specific file types (such as .xface) with a custom graphical editor component. This editor shares the same window frame, theme system, and shortcut key bindings as the code editor, leveraging the IDE's multi-window split-screen capability to display code and graphics side-by-side. This design eliminates the need for developers to switch between separate tools and the IDE, allowing them to directly open and adjust associated interface configuration files side-by-side while writing Java service code. This seamlessly integrates configuration work into the coding process, maintaining continuity in development thinking.

[0032] 3. Configuration and Code Integration: A bidirectional synchronization engine is built based on the IDE's PSI (Program Structure Interface). When saving the graphical configuration, the system locates the corresponding Java class file through file association mapping, uses the PSI's JavaPsiFacade utility class to create private field declarations at the abstract syntax tree level, and calls the code style manager to generate standardized getter / setter methods. Conversely, it listens for code file change events, compares the syntax tree differences before and after the change, and automatically updates the state of the corresponding components in the graphical interface. Through this design, the interface description and data model achieve strong consistency binding through the underlying syntax tree. Any modification made by the developer to either end will be automatically synchronized to the other end, completely freeing the user from the tedious work of manually maintaining synchronization and avoiding runtime errors caused by configuration and code disconnect.

[0033] 4. Enhanced Interactive Experience: The graphical editor adopts a layered architecture, with the component layout engine and constraint solver implemented at the bottom layer. When dragging and dropping components, the layout engine calculates the optimal insertion point and draws preview lines based on the target container type (such as grid or flow layout) and the positions of existing components. When resizing, the constraint solver calculates new dimensions in real time that satisfy the constraints of the parent container. During batch operations, unified attribute updates in the command mode are achieved by maintaining the set of selected components. This design achieves the interactive experience of a Figma-level professional design tool, enabling testers or business analysts unfamiliar with the syntax to directly participate in interface prototype construction after brief training. The lowered technical threshold expands the scope of participation in configuration work and improves team collaboration efficiency.

[0034] 5. Strict Enforcement of Standards: During the file creation phase, a predefined standard template is loaded through the template engine to generate an initial syntax tree containing a standard root structure, required nodes, and preset attributes. During graphical editing, the attribute panel integrates a real-time validator to perform regular expression matching and mandatory checks on key attributes such as component IDs. Violations of standards are flagged by a warning displayed through the IDE's notification system, and incorrect saving is prevented. This design enforces standard constraints throughout the entire configuration creation and editing process, laying a data foundation for subsequent automated deployment, code analysis, and system integration.

[0035] 6. Flexible Architecture Expansion: The core architecture adopts a metadata-driven design. The front-end rendering engine is a general-purpose interpreter that dynamically renders components based on their definitions in the component metadata repository. Adding new components only requires adding a JSON description to the metadata repository, defining their properties, events, and rendering styles. Back-end communication is based on a general event bus built using JSON format and the Window API. When supporting new file formats (such as YAML), only the corresponding parser and serializer need to be implemented to convert them into a unified internal component model. This design allows plugins to continuously evolve along with the technology stack, and new requirements (such as 3D charts and YAML configurations) can be quickly supported without modifying the core code.

[0036] 7. Readability and Maintainability: The graphical engine converts the configuration file's syntax tree into a visual node-connection diagram. Each configuration node corresponds to a graphical box, and parent-child or reference relationships between nodes are represented by arrowed connecting lines. The graphical editor supports direct drag-and-drop adjustment of node order, double-clicking nodes to open the property panel for parameter modification, and all operations are reflected in real-time on the underlying syntax tree's node rearrangement and property updates. This design transforms hundreds of lines of text configuration into a clear and visual flowchart, allowing new employees to quickly understand the system structure, architects to efficiently evaluate refactoring solutions, and troubleshooting by directly locating abnormal nodes on the graph, greatly enhancing the system's maintainability. Attached Figure Description

[0037] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 EasyFace plugin system architecture and data interaction overview diagram;

[0039] Figure 2 : Schematic diagram of the working principle of the multimodal component rendering engine;

[0040] Figure 3 : A schematic diagram illustrating the principle of the graphical editing interface for XML / Pageflow files;

[0041] Figure 4 : Schematic diagram of the principle of the graphical editing interface for JSON / XFace files;

[0042] Figure 5 : Sequence diagram of creating a new file based on a template and starting the editor;

[0043] Figure 6: Interactive sequence diagram of synchronized graphical editing and saving. Detailed Implementation

[0044] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings and embodiments. The described embodiments are only a part of the embodiments of the present invention, and not all of them. 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.

[0045] Glossary and Terminology:

[0046] To enable those skilled in the art to accurately understand this invention, the key terms and English abbreviations involved in the embodiments are first explained in a unified manner:

[0047] IDE: Integrated Development Environment. In this invention, it refers to IntelliJ IDEA Community Edition and its compatible platforms, which are the basic software for running plugins.

[0048] SDK: Software Development Kit. Specifically refers to IntelliJ Platform SDK, which provides the libraries, APIs, and tools needed to develop IDEA plugins.

[0049] API: Application Programming Interface. Refers to the predefined functions, classes, and methods in the IntelliJ Server SDK, which plugins can call to implement specific functionalities.

[0050] JCEF: Java Chromium Embedded Framework. A library that allows embedding Chromium-based browser components in Java Swing / AWT applications, used in this invention to host graphical web interfaces.

[0051] PSI: Program Structure Interface. A core set of APIs provided by the IDE for parsing, traversing, and manipulating the abstract syntax tree of source code (such as Java and XML).

[0052] JSON: JavaScript Object Notation. A lightweight data-interchange format that uses a text format that is completely independent of programming languages ​​to store and represent data.

[0053] XML: Extensible Markup Language. A markup language used to mark up electronic documents to give them structure.

[0054] DOM: Document Object Model. It is the programming interface for HTML and XML documents, representing the structure of the document and allowing programs to dynamically access and update the document's content, structure, and style.

[0055] Vue: A progressive JavaScript framework for building user interfaces. In this invention, it is used to build the front-end interface of a graphical editor.

[0056] CSS: Cascading Style Sheets. A computer language used to style documents such as HTML or XML, describing the appearance and layout of components.

[0057] EventListener: An event listener. A programming construct used to listen for specific events (such as clicks or drags) and execute corresponding code.

[0058] FileEditorProvider: An extension point interface defined in the IDESDK, used to register and provide custom file editors.

[0059] FileDocumentManager: The core service in the IDESDK for managing the mapping and persistence between files and documents.

[0060] Unless otherwise defined, the technical terms used in this application have the meanings commonly understood by those skilled in the art. If multiple interpretations exist for a term, the broadest and most reasonable interpretation shall prevail to maximize the protection of the technical contributions of this invention.

[0061] The graphical file editing system described in this invention is a software module deployed as an IDE plugin. Its core architecture and component interaction relationships are as follows: Figure 1 As shown.

[0062] Figure 1 The contents include:

[0063] 1) System layered structure:

[0064] Top level: IDE plugin runtime environment, representing the runtime context of the plugin in integrated development environments such as IntelliJ IDEA.

[0065] Middle layer: The main body of the graphical file editing system plugin, which contains 7 core functional modules.

[0066] The bottom layer: the IDE platform API and service call layer, which represents the interaction interface between the plugin and the IDE's underlying layer.

[0067] 2) Core functional modules (arranged from top to bottom):

[0068] The file type identification and scheduling module is responsible for identifying file types based on file extensions and scheduling the corresponding graphical editors.

[0069] Editor extension and embedding module: Register and create custom graphical editors based on the FileEditorProvider interface.

[0070] Graphical rendering engine: The core engine that renders JSON / XML structured data into visual components.

[0071] Interactive event handling module: handles graphical interactive operations such as dragging, zooming, and selection.

[0072] Front-end and back-end communication interface module: Based on window.postMessage, it enables communication between the front-end graphical interface and the back-end IDE logic.

[0073] File and code operation module: Operates Java code files through the PSI interface to achieve linkage between configuration and code.

[0074] File template management module: Generates an initial file structure that conforms to the specifications based on .ft template files.

[0075] 3) Relationships between modules:

[0076] Arrows indicate the direction of data flow and the relationship between calls.

[0077] The upper-layer module interacts with the lower-layer IDE service through the communication interface module.

[0078] The various functional modules work together to form a complete graphical editing process.

[0079] The following is a detailed explanation of each core module:

[0080] 1. Editor extensions and embedded modules:

[0081] The core of this module is a custom FileEditor. During implementation, a class (e.g., XFaceFileEditor) needs to be created to implement the IDE's FileEditor interface, along with a FileEditorProvider (e.g., XFaceEditorProvider) for registration. In the `createComponent()` method of XFaceFileEditor, the core is to instantiate a JBCefBrowser object (IntelliJ's wrapper for JCEF). This browser component is set as the root container for the entire editor UI. The initial URL loaded by the browser points to a local HTTP service or an HTML file (e.g., index.html) bundled within a plugin; this page serves as the front-end entry point for the graphical editor.

[0082] 2. File type identification and scheduling module:

[0083] The scheduling logic is implemented in FileEditorProvider. Its accept() method determines the file extension (e.g., .xface, .pageflow) of the file to be opened (VirtualFile). Developers need to declare the file types supported by this FileEditorProvider in the plugin configuration file plugin.xml. When a match is found, the IDE will call the provider's createEditor() method to create and return the aforementioned XFaceFileEditor instance, thus replacing the default text editor with a graphical editor.

[0084] 3. Graphical rendering engine:

[0085] This engine runs in an embedded browser and is powered by the Vue framework. Its core is a component classification function (handleComponentContainer). This function receives JSON configuration data (i.e., file content) from the backend and a component metadata repository. The metadata repository is a JavaScript object that defines the rendering mode (separateItem, containerItem, etc.), default properties, and corresponding Vue single-file components for each component type (such as Input, Panel, DataGrid).

[0086] Its composition and principle are as follows Figure 2 As shown in the diagram, this illustration demonstrates the workflow of the multimodal component rendering engine, illustrating the complete process from inputting a JSON / XML node tree to outputting a visual DOM tree. It includes the following:

[0087] 1) The processing flow has three stages:

[0088] ① Input stage:

[0089] Input: A JSON / XML node tree representing the content of a structured file.

[0090] ② Processing stage:

[0091] Component classification engine (handleComponentContainer):

[0092] Core processing unit.

[0093] Query the component metadata registry based on the node type field.

[0094] Determine the rendering mode for each node.

[0095] Rendering mode determination and distribution:

[0096] The nodes are categorized into four rendering modes.

[0097] Call the corresponding rendering function.

[0098] ③ Output stage:

[0099] Output: A visual component DOM tree for rendering in the browser.

[0100] 2) Four rendering modes:

[0101] ① SeparateItem:

[0102] Applicable to basic form elements (input boxes, buttons, etc.).

[0103] It uses CSS absolute positioning for independent rendering.

[0104] ② Container-type components (containerItem):

[0105] Suitable for layout components that support nesting (panels, grids, etc.).

[0106] Built-in child component recursive rendering channel.

[0107] ③ Table column component (tableItem):

[0108] An inline rendering unit optimized for tables.

[0109] ④ TabPaneItem:

[0110] A dynamic container that supports multiple tabs.

[0111] 3) Engine operating characteristics:

[0112] Metadata-based interpreter pattern.

[0113] Supports dynamic expansion of component types.

[0114] It enables the automatic conversion of data into visualizations.

[0115] The specific functions are as follows:

[0116] Rendering process: The engine recursively traverses the node tree of the configuration data. For each node, it queries the metadata based on its type field to determine the rendering mode.

[0117] Decoupled components: The corresponding Vue component is rendered directly, and it is placed at the specified coordinates on the canvas using CSS absolute positioning (position:absolute).

[0118] Container component: First render a container shell (e.g., ...<divclass=container> Then, it uses the children node data as a new parameter to recursively call the rendering engine and inserts the generated child component DOM into the container.

[0119] Table column component: When rendering the table component, treat it as a special child item and use an inline block layout.

[0120] Tab component: Rendered as a container with tab headers, each tab corresponds to a list of child nodes.

[0121] In graphical editing systems, container components (such as panels and grid layouts) need to be able to receive drag-and-drop deployments. To achieve this, the system employs a dynamic registration and deployment area mechanism for containers:

[0122] Registration timing: When a container component is rendered or its properties are changed, the system automatically calls the registerDroppable(containerId) method to register it as a dropable area and record its layout information (such as position, size, and list of child components).

[0123] Data structure: Each droppable container maintains a list of droppableZones, which records the sub-regions within it that can be dropped (e.g., divided by rows, columns, or grids).

[0124] Dynamic updates: When sub-components are added, deleted, or their layout is adjusted within the container, the system updates the delivery area information in real time to ensure the accuracy of hover prediction.

[0125] Linked with hover prediction: During the dragging process, the system performs collision detection based on the current mouse position and the registered delivery area, and dynamically highlights the best delivery position.

[0126] When using a graphical rendering engine to perform differentiated rendering of different file types, the processing interface is as follows: Figure 3 As shown in the image, this diagram illustrates the layout of the graphical editing interface for XML / Pageflow type files. It employs a two-column design and is optimized for business process editing. The interface includes:

[0127] 1) Two main areas of the interface:

[0128] ① Left canvas area:

[0129] Visual editing area for business processes.

[0130] The business process is presented in the form of a flowchart.

[0131] Example process:

[0132] Start → Approval → End (First line)

[0133] Submit → Review → Archive (Second line)

[0134] Arrows are used to connect nodes to indicate the flow of the process.

[0135] ② Component library on the right:

[0136] List of process node components.

[0137] Example nodes: Start node, Approval node, End node, Submit node, etc.

[0138] Users can drag and drop nodes from this area onto the canvas to build the process.

[0139] 2) Workflow editing features:

[0140] Nodes are represented by rectangles and include the node name.

[0141] Arrows indicate the direction of process flow.

[0142] Supports complex workflow layouts with multiple rows and columns.

[0143] It intuitively demonstrates the parallel and sequential relationships in business processes.

[0144] 4. Front-end and back-end communication interface module:

[0145] This serves as a bridge connecting the front-end graphical interface and the back-end IDE logic, employing an event communication mechanism based on the browser's window object.

[0146] Front-end host: In index.html, define the global window.processMessageFromHost function and call window.addEventListener to listen for custom events such as editor-event.

[0147] Backend call: In the IDE plugin code (Java), obtain the CefBrowser object through JBCefBrowser, call its executeJavaScript method, and execute scripts such as window.postMessage({type:'load',data:fileContent}) to send instructions and data to the frontend.

[0148] Front-end notification: When the front-end needs to notify the back-end (such as when saving a request), it calls window.dispatchEvent(newCustomEvent('host-event',{detail:{action:'save',data:jsonStr}})).

[0149] Backend listening: The IDE implements the CefClient event listener and overrides the onProcessMessageReceived method to receive events from the frontend.

[0150] 5. Interactive event handling module:

[0151] This module implements graphical interactive functions including dragging, zooming, and selection. The system supports batch operations on multiple components by selecting them with the mouse; see [link / reference]. Figure 4 This image shows the layout of the graphical editing interface for JSON / XFace type files, which uses a three-column design.

[0152] The contents include:

[0153] 1) Three main areas of the interface:

[0154] ① Left-side component library:

[0155] Includes a list of predefined, draggable components.

[0156] Example components: input box, button, drop-down list, table, etc.

[0157] Users can drag and drop components from this area onto the canvas.

[0158] ②Middle canvas area:

[0159] The main workspace for visual editing.

[0160] Displays the component tree structure of the current file.

[0161] Example: Contains a panel container with a button component inside.

[0162] It supports interactive operations such as dragging, scaling, and selection.

[0163] ③Right-side property panel:

[0164] Displays the configurable properties of the selected component.

[0165] Example attributes: tag, ID, style, etc.

[0166] Supports real-time editing and preview.

[0167] 2) Interaction illustration:

[0168] The drag-and-drop relationship between the component library and the canvas.

[0169] The selection relationship between components in the canvas and the property panel.

[0170] A collaborative editing model across three regions.

[0171] In practice, the user interface functions are as follows:

[0172] Selection status management: The system maintains a global array of selectedItemsList, which records the identifiers of the currently selected components.

[0173] Synchronous highlighting mechanism: When the user presses the mouse and drags to form a selection box, the system calculates the components that intersect with the selection box in real time, adds them to the selectedItemsList and immediately applies highlighting styles (such as thicker borders and semi-transparent backgrounds), and achieves instant visual feedback through dynamic binding of CSS class names.

[0174] Batch operation support: After selecting multiple components, users can perform batch attribute modification, alignment, deletion and other operations through the right-click menu or property panel.

[0175] To achieve a more natural interactive experience, the system supports a cross-level event propagation mechanism, allowing events to penetrate the container and act directly on its child components:

[0176] Event propagation strategy: For interactive events such as right-click menus and double-clicks, the system defaults to propagation mode. The event is first captured at the container layer, and if the target is determined to be a child component, the event continues to be propagated down to the child component for processing.

[0177] Implementation method: Listen for canvas events uniformly on the front end through event delegation, and dynamically determine the final component to receive the event based on the event triggering position and component hierarchy tree.

[0178] Typical applications: When a user double-clicks a button inside a container, the button's property editing panel is directly triggered; right-clicking on the container brings up a menu, allowing the user to perform batch operations on all its child components.

[0179] Based on cross-level event propagation, the system has specifically optimized the penetration handling of right-click menus and double-click events:

[0180] Double-click penetration: When a user double-clicks within the container area, the system uses a hit detection to determine the child components below the clicked location. If a child component is hit, its default double-click behavior is triggered (e.g., entering edit mode); if not, the container itself responds to the double-click (e.g., expanding / collapsed).

[0181] Right-click menu penetration: When you right-click on a container, the system displays both the container-level menu and the child component-level menu options. Users can choose to edit a child component and jump directly to the child component's property panel. It also supports batch operations on all selected child components within the container via right-click when multiple components are selected.

[0182] 6. File and Code Operation Module:

[0183] This module operates independently of the graphics editing process, but can be triggered by the communication middleware. When the Java source code needs to be modified according to the graphics configuration, the system performs the following PSI operation:

[0184] The PsiFile of the target Java file can be obtained using PsiManager.getInstance(project).findFile(virtualFile).

[0185] Use PsiTreeUtil.findChildOfType(psiFile,PsiClass.class) to iterate and find the target class PsiClass.

[0186] A PsiField object representing a private field is created using PsiElementFactory.getInstance(project).createFieldFromText(privateString userName;, null).

[0187] Call `targetClass.add(newField)` to add the field to the class body. All PSI modifications must be wrapped in `WriteCommandAction.runWriteCommandAction` to ensure thread safety and trigger file refresh and index updates in the IDE.

[0188] 7. File Template Management Module:

[0189] The system extends the IDE's FileTemplate mechanism, allowing the generation of compliant, structured file initial content from predefined .ft format template files, and registering custom creation actions in the IDE's New menu. The templates support Velocity template language syntax, including variable placeholders and conditional logic, used to dynamically generate initial file content based on user input.

[0190] The overall interaction diagram of the method flow of this invention can be referred to. Figure 5 and Figure 6 .

[0191] Figure 5 This demonstrates the complete interactive flow of a user creating a new file based on a template and launching a graphical editor, presented in the form of a sequence diagram. It includes the following:

[0192] 1) Participants:

[0193] User actions: These refer to the user's interactive behaviors.

[0194] Plugin System: EasyFace Plugin Core Logic.

[0195] IDE platform: IntelliJ IDEA platform service.

[0196] File system: Operating system file reading and writing.

[0197] 2) Process steps (in chronological order):

[0198] Create files based on templates:

[0199] The user initiates a request to create a new file.

[0200] Plugin system query template files.

[0201] The IDE platform reads the template content.

[0202] Return to template content, and the plugin generates the initial file.

[0203] The IDE platform creates physical files.

[0204] Returns a status indicating that the file was created successfully.

[0205] Launch the graphical editor:

[0206] The user double-clicks to open the file.

[0207] The plugin system matches the editor type based on the file extension.

[0208] Launch the corresponding graphical editor on the IDE platform.

[0209] The graphical editor has started up and users can now edit.

[0210] 3) Interaction method:

[0211] Arrows indicate the direction of message passing.

[0212] The dashed line represents the lifeline of the participating party.

[0213] The text labels each interactive step with its specific details.

[0214] Figure 6 This demonstrates the complete data flow after a user performs editing operations on the graphical interface, showing how data is synchronized from the front end to the back end, saved to a file, and subsequently updated in the code. It includes the following:

[0215] 1) Participants:

[0216] User: The person who performs the graphical operation.

[0217] Frontend: The graphical interface that runs in an embedded browser.

[0218] Backend: Java logic within the IDE plugin.

[0219] File: A physical file that stores structured content (JSON / XML).

[0220] Code: The Java source code file associated with the configuration file.

[0221] 2) Data synchronization process:

[0222] Editing stage:

[0223] Users drag and drop components onto the canvas.

[0224] The front end updates the data model.

[0225] Users modify component properties.

[0226] Preservation stage:

[0227] The front end sends a save request.

[0228] The backend retrieves the latest data model.

[0229] The backend saves the data to a file.

[0230] The file system returned a success message indicating that the save was successful.

[0231] Code synchronization phase:

[0232] The backend updates the associated Java code synchronously via the PSI interface.

[0233] Code update complete.

[0234] The front end receives confirmation that the save is complete.

[0235] 3) Key features:

[0236] It demonstrates the data flow under a front-end and back-end separation architecture.

[0237] This embodies a two-way synchronization mechanism between files and code.

[0238] It presents a complete closed loop from user operations to persistent storage.

[0239] The following example illustrates the key steps of a user creating a new .xface file, editing it, and saving it:

[0240] Step S1: Create a file based on the template

[0241] The user right-clicks the project directory and selects New->XFaceSketchFile (this menu item is registered in NewGroup by the plugin via plugin.xml). The user enters the filename LoginDialog and presses Enter. The system generates the LoginDialog.xface file in the specified location based on the template file named xface-sketch.xface.ft. This template predefines the basic JSON structure of the file, such as {type:Panel,name:,children:[]}.

[0242] Step S2: The graphical editor starts automatically.

[0243] The user double-clicks the newly created LoginDialog.xface file. Since the file extension is associated with XFaceEditorProvider, the IDE calls its createEditor method. The system creates a new editor tab, in which an embedded browser loads the graphical editing interface. The interface layout consists of a component library on the left, a canvas in the middle, and a property panel on the right.

[0244] Step S3: Load and render file content

[0245] During editor initialization, the backend reads the raw JSON text of LoginDialog.xface via VirtualFile and passes it to the frontend via executeJavaScript. The frontend graphical rendering engine parses the JSON, and since the current content consists of only an empty Panel, it renders a rectangular area representing the panel in the center of the canvas.

[0246] Step S4: Drag and drop editing and attribute configuration

[0247] The user drags a Button component from the component library on the left to the panel area in the canvas. The front-end interaction system triggers a three-level drag-and-drop protocol:

[0248] 1) Start dragging: Record the type of the component being dragged.

[0249] 2) Hover prediction: When the mouse hovers over the panel container, the system calculates and highlights the possible placement of the button.

[0250] 3) Confirm deployment: Release the mouse, and the system will insert a new button node data to the end of the children array in the panel.

[0251] Subsequently, the user clicks the button graphic on the canvas, and its configurable properties are simultaneously displayed in the properties panel on the right. The user changes the text property to "Login" and the id property to "btnLogin". These changes are updated in real time to the data model maintained by the front end.

[0252] Step S5: Save and sync to file

[0253] The user presses the Ctrl+S shortcut. The IDE triggers a save event. This plugin has globally listened to ApplicationActivationListener.TOPIC and captured the save command.

[0254] The backend calls the frontend's window.getCurrentModel() function (or a similar interface) via executeJavaScript to request the latest JSON data.

[0255] The frontend serializes the current complete component data model into a JSON string and sends it back to the backend via dispatchEvent.

[0256] After receiving the data, the backend obtains the VirtualFile of the current editor and the corresponding Document object.

[0257] In the write operation command, use FileDocumentManager.getInstance().saveDocument(document) to write a new JSON string to the physical file.

[0258] If association rules are configured, the system will further parse the new JSON, find all IDs, and call the PSI module to ensure that the corresponding fields exist in the associated Java classes.

[0259] Step S6: Multiple editors working in parallel

[0260] Users can open another .pageflow flow file without closing the current editor. The system will match another PageFlowEditorProvider based on the file extension and create a second, independent editor tab.

[0261] The two editors use different front-end pages and communication channels, are completely independent, do not interfere with each other, and achieve parallel editing.

[0262] The rendering algorithm described in this application uses a registry in the code as its classification basis (component metadata xfaceComponentMeta). For example:

[0263] javascript

[0264] constcomponentMeta={

[0265] Input:{renderMode:'separateItem',defaultWidth:100,defaultHeight:32},

[0266] FormPanel:{renderMode:'containerItem',canContain:['Input','Button']},

[0267] DataGrid:{renderMode:'tableItem',hasColumns:true},

[0268] TabPane:{renderMode:'tabPaneItem'}

[0269] };

[0270] The engine determines which rendering sub-function to call based on the renderMode, achieving decoupling and easy extensibility.

[0271] The `window.dispatchEvent` described in this application is key to achieving loosely coupled communication between the front-end and back-end. The data structure it transmits is a standard envelope:

[0272] json

[0273] {

[0274] eventId:uuid,

[0275] action:SAVE_REQUEST|LOAD_DATA|PROPERTY_UPDATE,

[0276] payload:{...} / / Specific data related to the action

[0277] }

[0278] This approach allows events to be listened to and handled in any Vue component, enabling cross-component and cross-level communication.

[0279] The functions performed by the systems, apparatuses, modules, or units described in this application should be understood as the corresponding steps in the method claims. Conversely, method steps should also be understood as being implementable by the corresponding systems, apparatuses, modules, or units.

[0280] A preferred embodiment of the present invention has been fully deployed and used in the development environment of the cooperative alliance. It is mainly used for the development and maintenance of bank teller systems and business process management platforms of multiple member banks, involving a large number of user interface (UI) configurations and business process (Workflow) definition files.

[0281] I. Implementation Scenarios and Objects

[0282] In this embodiment, the system primarily serves two types of key user roles:

[0283] 1. Business configuration personnel:

[0284] Role Description: Typically a business analyst or product manager in a banking business department, without a strong programming background, but familiar with banking business processes and interface interaction logic.

[0285] Use cases: When it is necessary to quickly configure or adjust the transaction interface (such as the large deposit and withdrawal confirmation interface, the corporate account information entry interface) or approval process (such as the loan approval process, the compliance inspection process) in the counter system according to business needs.

[0286] Pain points: In the past, requirements had to be submitted to the development team, and developers had to manually write or modify JSON / XML configuration files, which resulted in high communication costs, long iteration cycles, and was prone to configuration errors due to misunderstandings.

[0287] 2. Software Development Engineer:

[0288] Role Description: A Java development engineer in the bank's technology department, responsible for the implementation of backend business logic and its interaction with the frontend interface.

[0289] Use case: When implementing business functions, it is necessary to create or modify entity classes and service classes related to the interface, and ensure consistency with the interface configuration file (.xface) and process definition file (.pageflow).

[0290] Pain points: It requires switching between IDEs, text editors, and even independent configuration tools to manually synchronize interface configurations and code logic, resulting in a lot of repetitive work and inconsistencies that can lead to runtime errors.

[0291] The system primarily processes two types of core files:

[0292] .xface files: Formatted in JSON, these files describe the component structure, layout, properties, and event bindings of a counter system's graphical user interface (GUI). For example, the .xface file of a transfer transaction interface defines the input fields, dropdown lists, buttons, and other components included in the interface, along with their arrangement.

[0293] .pageflow files: These are in XML format and are used to define the nodes, flow conditions, role permissions, and backend service calls of a business process. For example, a .pageflow file for a corporate account opening process describes the complete steps from document acceptance to review, verification, and account opening completion.

[0294] II. Implementation Process and Typical Application Scenarios of the Examples

[0295] Taking the launch of the smart deposit product purchase function by a member bank of the cooperative alliance as an example, the application process of this system is illustrated:

[0296] Scenario: The bank is launching a new smart deposit product, which requires adding a purchase interface to the counter system and a transaction process that includes risk assessment steps.

[0297] Step 1: Rapid prototyping by business personnel

[0298] Business analysts can right-click on the project directory in the IDE, select "Create Deposit Product Purchase Interface," and the system will automatically generate an initial .xface file (such as SmartDepositPurchase.xface) based on the over-the-counter transaction template.

[0299] Double-click the file to launch the graphical editor. Business users can drag and drop product introduction panels, amount input boxes, term selection drop-down lists, risk warning text, and confirmation buttons from the component library on the left onto the canvas, and set the labels, default values, validation rules, etc. of each component through the property panel on the right.

[0300] The entire process requires no JSON syntax writing; the interface prototype can be built within 10 minutes through visual arrangement and configuration.

[0301] Step 2: Developers implement business logic and process orchestration

[0302] When Java developers are writing the backend purchase service (PurchaseService.java), they should open the associated .pageflow file (such as SmartDepositFlow.pageflow).

[0303] In the graphical workflow editor, developers can drag and drop the start node, risk assessment node (which calls RiskAssessmentService), transaction execution node (which calls PurchaseService), and result page node onto the canvas, and connect them with arrows to define the flow logic.

[0304] The system automatically generates the corresponding XML process definition based on the graphical arrangement and ensures that the node ID, service call parameters and method signatures in the backend code are consistent.

[0305] Step 3: Configure automated code synchronization

[0306] When a business user configures a new assessment question (such as "Do you understand the liquidity risk of this product?") for a risk assessment node in the interface and saves it, the system not only updates the .pageflow file, but also automatically adds an enumeration value to the corresponding Java enumeration class (RiskQuestion.java) through the PSI interface.

[0307] The developers added a new fee calculation method to the code for purchasing services and added a specific annotation to the method. When the system reloads the .xface file, this new method option automatically appears in the service binding drop-down list of the interface component properties panel, allowing business users to select and bind it.

[0308] Step 4: Team Collaboration and Version Control

[0309] All .xface and .pageflow files are stored in text format (JSON / XML) and are included in Git version control along with the source code.

[0310] During the code review phase, reviewers can not only see the differences in Java code, but also intuitively see the changes in interface layout or flowcharts through the system's visual comparison function, greatly improving review efficiency and accuracy.

[0311] III. Implementation Results of the Examples

[0312] Since its deployment in the collaborative alliance development environment, this system has achieved significant performance improvements, specifically in the following aspects:

[0313] 1. Development efficiency doubled, delivery cycle shortened:

[0314] For business configuration personnel, the efficiency of creating and modifying configuration files has been improved by more than 80%, reducing the average time required from 1-2 days (including communication, waiting for development, and confirmation of modifications) to 2-3 hours for completion and verification.

[0315] For development engineers, the automation of configuration and code synchronization saves about 40% of the time spent on manually synchronizing and debugging configuration consistency, allowing them to focus more on core business logic development.

[0316] The average delivery cycle for overall functional features (from requirement submission to test readiness) has been shortened by more than 50%.

[0317] 2. Configuration quality and standardization reach the extreme:

[0318] Through a mandatory template mechanism and graphical constraints (such as mandatory field validation, dropdown option restrictions, and naming convention checks), all generated .xface and .pageflow files achieve 100% structural standardization, completely eliminating configuration file parsing failures caused by typos, format errors, or missing mandatory fields.

[0319] In a recent large version iteration involving more than 300 configuration items, the number of configuration-related bugs dropped to zero, whereas in previous iterations of similar size, bugs caused by configuration errors typically accounted for 15%-20% of the total.

[0320] 3. Lower the technical barrier and promote cross-role collaboration:

[0321] Business personnel can independently complete most of the interface configurations and simple process adjustments after a brief training (about half a day), reducing reliance on development resources and enabling direct visualization and configuration of business requirements.

[0322] The development and business teams communicate using a unified graphical language, which reduces misunderstandings about requirements and makes the collaboration process smoother.

[0323] 4. System maintainability and readability are greatly enhanced:

[0324] Faced with thousands of complex configuration files accumulated in the existing system, new employees can understand key business interfaces and processes within hours through graphical views, whereas reading plain text XML / JSON might have taken several days in the past.

[0325] When restructuring a system or streamlining business processes, architects can quickly perform impact analysis and module division using printed visual flowcharts or interface structure diagrams.

[0326] 5. Lays the foundation for automated testing and deployment:

[0327] The well-structured and highly readable graphical configuration makes it easier to write and maintain automated test scripts (such as UI automated tests and process integration tests).

[0328] When used in conjunction with a CI / CD pipeline, it enables automated syntax checking of configuration files and visual regression testing comparisons, further improving delivery quality and deployment reliability.

[0329] It should be noted that the specific embodiments disclosed in this specification are merely illustrative and do not constitute a limitation on the scope of protection of this invention. Any modifications, equivalent substitutions, or improvements made by those skilled in the art based on the technical concept of this invention without departing from the essential scope of this invention should be included within the scope of protection of this invention.

Claims

1. A graphical document editing system, characterized in that, The system, which is deployed as a plugin in an integrated development environment (IDE), includes: The editor extension and embedding module registers a custom file editor based on the FileEditorProvider extension point interface of the IDE plugin platform. By implementing the FileEditor interface and creating a JBCefBrowser embedded browser instance as the core component of the editor, the graphical user interface is embedded into the IDE editor tab area. The file type identification and scheduling module matches the editor type based on the file extension of the file to be edited in the accept() method of FileEditorProvider, and schedules the corresponding custom graphical editor to load the corresponding visual editing interface based on the extension point mapping relationship declared in the IDE plugin configuration file. The graphical rendering engine includes a component classification unit and a dynamic rendering unit. The component classification unit is based on a predefined component metadata registry. By parsing the node type field of JSON / XML structured data, it classifies data nodes into separate components, container components, table components, and tab components. The dynamic rendering unit calls the corresponding rendering function according to the component type to generate an independent DOM structure using CSS absolute positioning, a recursive container structure supporting nested child components, a table inline column structure, and a dynamic tab container structure, respectively. The interactive event handling module, based on the front-end JavaScript event listening mechanism and state management, implements a drag protocol that includes three stages: drag start, hover prediction, and precise placement. It injects control points in eight directions into each visual component to achieve visual size adjustment, and performs batch processing on multiple components through box selection. The front-end and back-end communication interface module establishes an event-driven bidirectional communication channel based on the window.postMessage and window.dispatchEvent mechanisms by defining global message handling functions and event listeners in the embedded browser front-end page and executing script instructions in the IDE back-end through the executeJavaScript method, and encapsulates operation instructions and data payloads in JSON format. The file and code operation module obtains the abstract syntax tree representation of Java files through the IDE's PSI program structure interface, uses PsiElementFactory to create code structure elements and inserts them into the target class, and uses the FileDocumentManager service to complete the read, write and persistence operations of structured files. The file template management module extends the IDE's FileTemplate mechanism, generating initial content for structured files that conform to the specifications from predefined .ft format template files, and registering custom creation actions in the IDE's New menu.

2. The system according to claim 1, characterized in that, The component metadata registry in the graphical rendering engine defines the following metadata fields for each component type: component identifier, rendering mode identifier, default size attribute, list of acceptable sub-component types, and corresponding front-end Vue component or React component reference.

3. The system according to claim 1, characterized in that, In the drag-and-drop protocol implemented by the interactive event handling module, the hover prediction stage uses a collision detection algorithm based on the mouse position and the existing component layout within the container to dynamically calculate and highlight the estimated position of the component after it is deployed.

4. The system according to claim 1, characterized in that, The JSON data payload structure defined by the front-end and back-end communication interface module includes: event unique identifier eventId, action type enumeration actionType, source component identifier sourceId, target container identifier targetId, and data object payload containing specific operation parameters.

5. The system according to claim 1, characterized in that, When performing PSI operations, the file and code operation module wraps the code structure modification operation in WriteCommandAction.runWriteCommandAction to ensure thread safety and trigger the IDE's code index update.

6. The system according to claim 1, characterized in that, The predefined .ft format template files in the file template management module support Velocity template language syntax, include variable placeholders and conditional judgment logic, and are used to dynamically generate the initial content of the file based on user input.

7. A graphical file editing method, applied in an IDE plugin environment, characterized in that, The method includes the following steps: Editor registration and embedding steps: During the plugin initialization phase, a custom editor is registered by implementing the FileEditorProvider interface. When a file with a specific extension is detected to be open, an editor component containing an embedded browser instance of JBCefBrowser is created and embedded in the IDE editing area. File recognition and interface loading steps: Extract the file extension of the target file, query the editor mapping relationship defined in the plugin configuration, load the corresponding graphical editing interface resources and initialize the visual canvas; Content parsing and component rendering steps: Read the content of the structured file, convert it into a data node tree through the parsing engine, classify each node based on the component metadata registry, and recursively call the corresponding rendering function to generate a visual component tree; Interactive response and event handling steps: Listen for user drag, click, and input operations on the graphical interface, trigger corresponding processing logic according to the event type, update the front-end data model, and synchronize the operation intention to the back-end through the event channel; Data persistence and code synchronization steps: In response to file save commands, the front-end data model is serialized into a structured format and saved to the source file via FileDocumentManager; if there are associated code files, the corresponding class structure is automatically updated through the PSI interface, specifically including: obtaining the PsiFile of the target Java file through PsiManager, traversing to find the target PsiClass, using PsiElementFactory to create code structure elements, and wrapping all PSI modification operations in WriteCommandAction for execution; Templated file creation steps: In response to the new file request, an initial file structure is generated based on the selected template file, and the corresponding graphical editor is automatically opened for subsequent editing.

8. A graphical document editing method according to claim 7, characterized in that, In the content parsing and component rendering steps, the rendering of container type nodes adopts a recursive depth-first traversal algorithm. First, the container shell DOM element is generated, then the rendering process is recursively called for each of its child nodes, and finally the child component DOM is inserted into the container.

9. A graphical document editing method according to claim 7, characterized in that, In the data persistence and code synchronization steps, the IDE's save event is captured by globally listening to the ApplicationActivationListener.TOPIC topic, the executeJavaScript call is used to obtain the latest data model from the front-end interface, and the file save and code update operations are performed in WriteCommandAction.

10. A graphical document editing method according to claim 7, characterized in that, The interaction response and event handling steps include processing the component size adjustment operation as follows: listening for mouse press events at eight control points and recording the initial position and size; calculating the new size and position in real time during mouse movement; updating the component's CSS style and data model; and triggering the saving of checkpoints when the mouse is released.

Images