A multi-IDE-based adaptive development method and device, an electronic device, and a program product
By listening to native IDE events and converting them into standardized requests, the central logic module executes business logic according to common specifications, solving the platform barrier problem of IDE plugin development, realizing cross-platform reuse of core logic, reducing development costs and improving user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HUNDSUN TECH
- Filing Date
- 2026-05-08
- Publication Date
- 2026-06-05
Smart Images
Figure CN122152301A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of business data processing, and more specifically, to a multi-IDE-based adaptation development method, apparatus, electronic device, and program product. Background Technology
[0002] In the software development field, an Integrated Development Environment (IDE) is a core tool for developers, integrating code editing, compilation and interpretation, debugging, project management, and other full-process functions, effectively reducing operational complexity and improving development efficiency. IDE plugins, as key components for extending IDE functionality, provide customization capabilities for specific scenarios such as code generation and tool view display, further expanding the IDE's applicability. They are crucial for optimizing the development experience and improving efficiency and are widely used in various software development projects. However, there are serious platform barriers to the development of existing IDE plugins: mainstream IDEs are based on independent architectures, and plugins need to be developed using their own proprietary technology stacks and APIs. Furthermore, the technologies of different platforms are incompatible, which leads to the need for repeated development of plugins for multiple platforms. This model has significant drawbacks: First, it has high R&D costs, with repetitive development consuming resources and requiring the team to master multiple technology stacks; second, it has a poor user experience, with differences in the functions and interfaces of plugins across multiple platforms, requiring users to install and maintain them separately; and third, it has low technology reusability, with core logic tied to the IDE, making it difficult to reuse code across platforms. Summary of the Invention
[0003] The purpose of this application is to provide a multi-IDE-based adaptive development method, device, electronic device, and program product to reduce development and maintenance costs.
[0004] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a multi-IDE-based adaptive development method, including: When the target IDE's adaptation communication module listens to a native IDE event, it determines a standardized request corresponding to the native IDE event based on the event mapping rules; the standardized request includes the event type, business parameters, and IDE identifier. The adaptation communication module sends the standardization request to the central logic module; The central logic module determines the target business logic information corresponding to the standardized request based on the event type; the target business logic information is determined based on the common logic specifications and execution standards that support various IDEs; The central logic module executes the target business logic information according to the business parameters and the IDE identifier to obtain the business logic processing result of the target business logic information. The central logic module encapsulates the business logic processing result into a standardized response and feeds the standardized response back to the adaptation communication module; The adaptation communication module converts the standardized response into a call instruction that matches the target IDE according to the environment mapping rules; The target IDE executes the target instructions.
[0005] Optionally, before the step of determining the standardized request corresponding to the IDE native event according to the event mapping rules when the target IDE's adaptation communication module listens to the IDE native event, the method further includes: When the target IDE starts, the adaptation communication module checks whether the central logic module has started; If not started, the adaptation communication module triggers the central logic module to start; If activated, the adaptation communication module establishes a communication connection with the central logic module.
[0006] Optionally, the step of the central logic module executing the target business logic information according to the business parameters and the IDE identifier to obtain the business logic processing result of the target business logic information includes: If the target business logic information indicates the invocation of a third-party service, then the central logic module invokes the third-party service to obtain the business logic processing result of the target business logic information.
[0007] Optionally, the step of the central logic module determining the target business logic information corresponding to the standardized request based on the event type includes: The central logic module determines the corresponding target business logic operation based on the event type; The central logic module constructs the target business logic information according to the execution order of all the target business logic operations.
[0008] Optionally, the step of the central logic module executing the target business logic information according to the business parameters and the IDE identifier to obtain the business logic processing result of the target business logic information includes: The central logic module executes each of the target business logic operations according to the business parameters and the IDE identifier in the execution order to obtain the business logic processing result.
[0009] Secondly, embodiments of this application provide a multi-IDE-based adaptation development device, including: a target IDE, a corresponding adaptation communication module, and a central logic module; The adaptation communication module is used to determine a standardized request corresponding to the IDE native event according to the event mapping rules when the target IDE's adaptation communication module listens for the IDE native event; the standardized request includes the event type, business parameters, and IDE identifier; and send the standardized request to the central logic module. The central logic module is used to determine the target business logic information corresponding to the standardized request based on the event type; the target business logic information is determined based on the common logic specifications and execution standards that support various IDEs; the target business logic information is executed according to the business parameters and the IDE identifier to obtain the business logic processing result of the target business logic information; the business logic processing result is encapsulated into a standardized response, and the standardized response is fed back to the adaptation communication module; The adaptation communication module is also used to convert the standardized response into a call instruction that matches the target IDE according to the environment mapping rules; The target IDE is used to execute the target instructions.
[0010] Optionally, the adapter communication module is further configured to check whether the central logic module is started when the target IDE starts; if it is not started, the adapter communication module is triggered to start; if it is started, a communication connection is established with the central logic module.
[0011] Optionally, the central logic module is specifically used to invoke the third-party service to obtain the business logic processing result of the target business logic information if the target business logic information indicates the invocation of a third-party service.
[0012] Optionally, the central logic module is specifically used to determine the corresponding target business logic operation based on the event type; and to construct the target business logic information based on the execution order of all the target business logic operations.
[0013] Optionally, the central logic module is specifically used to execute each of the target business logic operations according to the execution order based on the business parameters and the IDE identifier, so as to obtain the business logic processing result.
[0014] Thirdly, embodiments of this application provide an electronic device, including: Memory, used to store one or more programs; processor; When the one or more programs are executed by the processor, the method as described in any one of the first aspects above is implemented.
[0015] Fourthly, embodiments of this application provide a program product, wherein when the program contained in the program product is executed by a processor, it implements the method as described in any one of the first aspects above.
[0016] Compared to existing technologies, the multi-IDE-based adaptation development method, apparatus, electronic device, and program product provided in this application embodiment listens to native IDE events through an adaptation communication module, transforms them into standardized requests according to event mapping rules, then executes the target business logic according to general specifications and encapsulates standardized responses through a central logic module, and finally transforms them into native IDE API call instructions by the adaptation communication module through environment mapping rules. This technical approach shields the heterogeneity of events and APIs across different IDEs, decouples core business logic from the IDE, achieves "develop once, reuse across multiple IDEs," significantly reducing R&D and maintenance costs; at the same time, it ensures consistency in the functionality and interface of various IDE plugins, simplifies user installation and upgrade operations, improves user experience, and provides a convenient adaptation path for supporting new IDEs, enhancing scalability.
[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 A flowchart illustrating a multi-IDE-based adaptive development method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating another multi-IDE-based adaptation development method provided in an embodiment of the present invention; Figure 3 A flowchart illustrating another multi-IDE-based adaptation development method provided in an embodiment of the present invention; Figure 4 A swimlane diagram illustrating the flow of a multi-IDE-based adaptive development method provided for embodiments of the present invention; Figure 5 A swimlane diagram illustrating another multi-IDE-based adaptive development method provided for embodiments of the present invention; Figure 6 A swimlane diagram illustrating another multi-IDE-based adaptive development method provided for embodiments of the present invention; Figure 7A swimlane diagram illustrating another multi-IDE-based adaptive development method provided for embodiments of the present invention; Figure 8 A flowchart illustrating a multi-IDE-based adaptive development method provided in an embodiment of the present invention; Figure 9 A flowchart illustrating a multi-IDE-based adaptive development method provided in an embodiment of the present invention; Figure 10 A schematic diagram of a signaling interaction process based on an IDE, an adaptive communication module, and a central logic module is provided for an embodiment of the present invention. Figure 11 A schematic diagram of a multi-IDE-based adaptive development device provided in an embodiment of the present invention; Figure 12 A schematic diagram of another multi-IDE-based adaptation development device provided in an embodiment of the present invention; Figure 13 A schematic diagram of another multi-IDE-based adaptation development device provided in an embodiment of the present invention; Figure 14 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0021] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0022] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0023] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0024] In existing technologies, Integrated Development Environment (IDE) plugins are key tools for improving software development efficiency. However, in current technological practices, plugin development faces significant platform barriers. Different IDE platforms, such as Visual Studio Code, IntelliJ series, and Visual Studio, all require developers to use a specific and incompatible technology stack tied to the IDE to independently develop plugins.
[0025] However, existing technologies have the following problems: 1) High R&D costs: To implement a plugin function that can be used in multiple IDEs (such as code generation, tool views, etc.), the development team must use different technology stacks to completely and repeatedly implement all front-end and back-end logic several times, which results in a huge waste of R&D resources and high manpower and learning costs.
[0026] 2) Inconsistent user experience: Because each plugin is developed and maintained independently, the plugin functionality, interface, and update frequency often differ across different IDEs. Users must also install, manage, and upgrade plugins individually in each IDE. Any feature update may require users to perform operations one by one and restart all environments, resulting in high usage and maintenance costs.
[0027] 3) Poor technology reusability: The core functional logic is deeply coupled with the SDK of a specific IDE, making it difficult to reuse code assets across different platforms, which seriously restricts development efficiency and long-term technological evolution.
[0028] To address the technical challenges of incompatible IDE platform technology stacks, which lead to the inability to reuse plugin functionality across platforms, high development costs, and difficult maintenance, this application uses standardized protocols and bidirectional conversion mechanisms to shield the underlying differences in event handling, API calls, and UI rendering within the IDE. The core of its technical implementation lies in decoupling the traditional monolithic plugin into two key components: a platform-independent central logic module and a lightweight, embedded adaptation communication module within the IDE.
[0029] This application standardizes events and requests: To address the heterogeneity of event mechanisms and APIs across different IDEs, an adaptation communication module deployed within the IDE is responsible for capturing the native events of its respective IDE (such as VSCode's onDidOpenFile event). After capture, this IDE-specific event information is translated and encapsulated into a request using a predefined, platform-independent, standardized data protocol format. This protocol defines a unified event name, parameter structure, and context information. Subsequently, this standardized request is sent to the centralized logic processing module.
[0030] This application achieves command and view adaptation: After receiving a standardized request, the central logic module executes unified business logic without being aware of the specific type of the source IDE platform. Upon completion, if the IDE needs to update the interface or perform operations, the central logic module generates a standardized response command, which is sent back to the source IDE's adaptation communication module. Upon receiving this standard command, the adaptation communication module is responsible for translating it into native API calls that can be executed in the current IDE environment.
[0031] Specifically, Figure 1 A flowchart illustrating a multi-IDE-based adaptive development method provided in this embodiment of the invention is shown below. Figure 1 The method includes the following steps: Step 103: When the target IDE's adaptation communication module listens to the IDE's native event, it determines the standardized request corresponding to the IDE's native event according to the event mapping rules.
[0032] The standardized request includes event type, business parameters, and IDE identifier. The event mapping rule refers to the set of rules used to convert IDE native events (such as user-triggered file open events and function command events) into standardized requests that conform to the standardized protocol. It includes the correspondence between IDE native event types and standardized request event names, as well as the format conversion rules between IDE native event parameters and standardized request parameters.
[0033] Step 104: The adaptation communication module sends a standardization request to the central logic module.
[0034] Step 105: The central logic module determines the target business logic information corresponding to the standardized request based on the event type.
[0035] The target business logic information is determined based on the common logic specifications and execution standards that support various IDEs.
[0036] Step 106: The central logic module executes the target business logic information based on the business parameters and IDE identifier to obtain the business logic processing result of the target business logic information.
[0037] Step 107: The central logic module encapsulates the business logic processing results into a standardized response and feeds the standardized response back to the adaptation communication module.
[0038] Step 108: The adaptation communication module converts the standardized response into a call command that matches the target IDE according to the environment mapping rules.
[0039] The environment mapping rule refers to the set of rules used to convert standardized instructions issued by the centralized logic processing module into native API calls that can be executed by the current IDE. It includes the correspondence between standardized instruction types and native API names of the IDE, and the format adaptation rules between standardized instruction parameters and native API parameters of the IDE, so as to adapt to the differences in the running environment of different IDEs.
[0040] Step 109: The target IDE executes the target instructions.
[0041] The multi-IDE-based adaptation development method provided in this invention listens to native IDE events through an adaptation communication module, transforms them into standardized requests according to event mapping rules, then executes the target business logic according to general specifications and encapsulates the standardized response through a central logic module, and finally transforms it into native IDE API call instructions by the adaptation communication module through environment mapping rules. This technique shields the heterogeneity of events and APIs across different IDEs, decoupling core business logic from the IDE and achieving "develop once, reuse across multiple IDEs," significantly reducing R&D and maintenance costs. Simultaneously, it ensures consistency in the functionality and interface of plugins across different IDEs, simplifies user installation and upgrade operations, improves user experience, and provides a convenient adaptation path for supporting new IDEs, enhancing scalability.
[0042] Optionally, the specific target business logic operation to be executed by the central logic module varies depending on the event type. Below is one possible implementation method for determining the target business logic operation to be executed; specifically, in... Figure 1 On this basis, Figure 2 A flowchart illustrating another multi-IDE-based adaptation development method provided in this embodiment of the invention is shown below. Figure 2 Step 105 includes: Step 105-1: The central logic module determines the corresponding target business logic operation based on the event type.
[0043] Optionally, based on general logic specifications and execution standards, the target business logic operation may include, but is not limited to: standard interactive execution operation, state management operation, context management operation, information analysis and extraction operation, file rendering operation, and third-party interactive operation.
[0044] The standard interactive execution operation can be a standard operation that can be triggered for different event types, such as request parsing, response packaging, and writing files.
[0045] This state management operation can be used for event listening, such as listening for file changes.
[0046] This context management operation ensures that context is passed between different functions.
[0047] This information analysis and extraction operation can be used to parse price inquiry content, parse third-party responses, and so on.
[0048] This file rendering operation can be an HTML webpage rendering operation, a file template rendering operation when generating a file, etc.
[0049] This third-party interaction operation refers to the operation related to interaction with a third-party system, such as interaction operations through HTTP connection, database connection, etc.
[0050] Step 105-2: The central logic module constructs the target business logic information according to the execution order of all target business logic operations.
[0051] Optionally, for different event types, the corresponding target business logic operations can be combined based on different execution orders to form the corresponding target business logic information.
[0052] Optionally, for different event types, the central logic module obtains the business logic processing result based on the execution order of the corresponding target business logic operations. The following provides a possible implementation method for obtaining the business logic processing result; specifically, in... Figure 1 On this basis, Figure 3 A flowchart illustrating another multi-IDE-based adaptation development method provided in this embodiment of the invention is shown below. Figure 3 Step 106 includes: Step 106-1: The central logic module executes each target business logic operation in the order of execution based on the business parameters and IDE identifier to obtain the business logic processing result.
[0053] Optionally, the following explanation uses several development functions as examples.
[0054] Example 1: Taking the development feature - local file visualization as an example, Figure 4 This is a swimlane diagram illustrating the flow of a multi-IDE-based adaptive development method provided in this embodiment of the invention. See details. Figure 4 The process includes the following steps: Step 1. The user double-clicks the file.
[0055] This file can be any file in the development interface.
[0056] Step 2. The IDE's communication module is adapted to call the event listener.
[0057] Step 3. The IDE's adaptation and communication module listens for "file open events" through event listeners.
[0058] The file open event is a native IDE event mentioned earlier.
[0059] Step 4. The IDE's adaptation and communication module determines the file path / file status through event mapping rules.
[0060] Step 5. The IDE's adaptation communication module sends a standardization request to the central logic module.
[0061] Step 6. The central logic module parses the request.
[0062] Parsing standardized requests is a standard interactive execution operation.
[0063] Step 7. Open file event in the central logic module.
[0064] Optionally, the standardized request mentioned above may include an event type attribute, so that the central logic module can determine whether it is an open file event based on the attribute. If it is not an open file event, it will not proceed to the subsequent steps of opening the file.
[0065] Step 8.1 The central logic module reads the file.
[0066] This file is the one that the user opens by double-clicking.
[0067] Step 8.2 The central logic module performs data cleaning and structuring.
[0068] It should be noted that steps 8.1 and 8.2 belong to the information analysis and extraction operations mentioned above.
[0069] Step 9.1 The central logic module renders the UI page.
[0070] Step 9.2 The central logic module obtains the HTML content / address.
[0071] It should be noted that steps 9.1 and 9.2 belong to the file rendering operations mentioned above.
[0072] Step 10.1. The central logic module listens to UI components.
[0073] Step 10.2. The central logic module makes changes to the UI components.
[0074] It should be noted that steps 10.1 and 10.2 belong to the aforementioned state management operations.
[0075] Step 11. Perform structure serialization on the central logic module.
[0076] It should be noted that step 11 belongs to the information analysis and extraction operation mentioned above.
[0077] Step 12. The central logic module performs file writing.
[0078] It should be noted that step 12 is a standard interactive operation as described above.
[0079] Step 13. The central logic module executes a standardized response.
[0080] It should be noted that step 13 is a standard interactive operation as described above.
[0081] Step 14. The IDE parses the response.
[0082] Step 15. The IDE loads the page through the UI container.
[0083] In this example, the communication module listens for file open events and transforms them into standardized requests. The central logic module then uniformly executes operations such as file reading, data processing, and UI rendering. The standardized response then adapts to the IDE's native API. This achieves core logic reuse, eliminating the need to repeatedly develop file visualization code for different IDEs, reducing development costs, and ensuring consistency in file visualization functionality and interface across IDEs, thus improving the user experience.
[0084] Example 2: Taking the development of a remote data visualization function as an example, since it involves data querying from a third party, the execution entities in this example include not only the user, IDE, and central logic module, but also a third-party device: the interface management system. Specifically, Figure 5 This is a swimlane diagram illustrating another multi-IDE-based adaptive development method provided in this embodiment of the invention. See details... Figure 5 The process includes the following steps: Step 1. The user opens the interface view.
[0085] Step 2. The IDE's communication module is adapted to call the event listener.
[0086] Step 3. The IDE's adaptation communication module listens for the "interface attempt to open event" through an event listener.
[0087] The event that this interface attempts to open belongs to the native IDE event mentioned above.
[0088] Step 4. The IDE's adaptation communication module determines the interface manager system configuration through event mapping rules.
[0089] Step 5. The IDE's adaptation communication module sends a standardization request to the central logic module.
[0090] Step 6. The central logic module parses the request.
[0091] Parsing standardized requests is a standard interactive execution operation.
[0092] Step 7. The central logic module identifies the interface attempt to initialize the event.
[0093] Step 8.1. The central logic module obtains interface information.
[0094] Step 8.2. The interface management system performs permission verification.
[0095] Optionally, for permission verification, you can set an individual access-key. When viewing interface data, you need to add the access-key to the request data, and the interface management system will use the individual access-key to perform permission verification.
[0096] Step 8.3. Perform data query in the interface management system.
[0097] Step 9. The central logic module parses the interface information.
[0098] The parsing interface information belongs to the information analysis and extraction operation described above.
[0099] Step 10.1. The central logic module renders the UI page.
[0100] Step 10.2. The central logic module obtains the HTML content / address.
[0101] It should be noted that steps 10.1 and 10.2 belong to the file rendering operations mentioned above.
[0102] Step 11. The central logic module executes a standardized response.
[0103] It should be noted that step 11 is a standard interactive operation as described above.
[0104] Step 12. The IDE parses the response.
[0105] Step 13. The IDE loads the page through the UI container.
[0106] In this example, the adaptation communication module captures and standardizes the interface view open event, while the central logic module uniformly interfaces with the interface management system to complete permission verification, data querying, and parsing. Standardized responses are then adapted for IDE display. This avoids redundant development of remote data interaction and visualization logic across multiple IDEs, reduces wasted development resources, ensures a consistent interface data visualization experience for users of different IDEs, and simplifies plugin maintenance.
[0107] Example 3: Taking code generation as an example, since it involves a third-party system, the execution entity in this example includes not only the user, IDE, and central logic module, but also the third-party system. Specifically, Figure 6 This is a swimlane diagram illustrating another multi-IDE-based adaptive development method provided in this embodiment of the invention. See details... Figure 6 The process includes the following steps: Step 1. The user clicks the "Generate Code" menu.
[0108] Step 2. The IDE's communication module is adapted to call the event listener.
[0109] Step 3. The IDE's adaptation and communication module listens for the "Generate Code Menu Click Event" through an event listener.
[0110] The code generation menu click event is a native IDE event mentioned earlier.
[0111] Step 4. The IDE's adaptation and communication module determines the project / selected flowchart through event mapping rules.
[0112] Step 5. The IDE's adaptation communication module sends a standardization request to the central logic module.
[0113] Step 6. The central logic module parses the request.
[0114] Parsing standardized requests is a standard interactive execution operation.
[0115] Step 7. The central logic module identifies and generates code events.
[0116] Step 8.1. The central logic module parses the process information.
[0117] Step 8.1 is part of the information analysis and extraction operation described above.
[0118] Step 8.2. The central logic module obtains information about the associated database tables.
[0119] Step 9.1. Obtain interface information from the third-party system.
[0120] Step 9.2. The third-party system obtains the information of the related database tables.
[0121] Steps 8.2, 9.1, and 9.2 all belong to the third-party interaction operations mentioned above.
[0122] Step 10. Construct code generation context for the central logic module.
[0123] Step 10 is a context management operation as described above.
[0124] Step 11. The central logic module obtains the HTML content / address.
[0125] Step 11 is a file rendering operation as described above.
[0126] Step 12. The central logic module writes files.
[0127] Optionally, the file writer can generate the desired file, such as a Java file in the src directory or an XML file in the script directory.
[0128] Step 13. The central logic module executes a standardized response.
[0129] Steps 12 and 13 both belong to the standard interactive execution operations described above.
[0130] It should be noted that steps 10.1 and 10.2 belong to the file rendering operations mentioned above.
[0131] Step 14. The IDE parses the response.
[0132] Step 15. Refresh the workspace in the IDE.
[0133] Optionally, refreshing the workspace serves the purpose of writing files in step 12 within the central module (not the IDE). Some IDEs have their own file caching mechanisms, and without refreshing, files may become out of sync. For example, the most obvious symptom is that the file content seen in the IDE is not the latest, or the file may not even be visible in the IDE.
[0134] In this example, the adaptation communication module transforms the code generation menu click event into a standardized request, while the central logic module uniformly parses process information, connects to third-party systems to obtain data, constructs context, and generates code. This enables the core code generation logic to be reused across IDEs, reducing the development complexity of supporting m languages across n IDEs. Feature updates only require maintenance of the central module, minimizing the need for users to upgrade plugins one by one.
[0135] Example 4: Taking the development function - auxiliary coding as an example, since it involves a third-party system, the execution entity in this example includes not only the user, IDE, and central logic module, but also the third-party system, i.e., the code generation service. Specifically, Figure 7 This is a swimlane diagram illustrating another multi-IDE-based adaptive development method provided in this embodiment of the invention. See details... Figure 7 The process includes the following steps: Step 1. When the user moves the cursor, the cursor changes.
[0136] Step 2. The IDE's communication module is adapted to call the event listener.
[0137] Step 3. The IDE's adaptation and communication module listens for "cursor changes" through event listeners.
[0138] The cursor change is a native IDE event mentioned earlier.
[0139] Step 4. The IDE's adaptation and communication module determines the cursor information / file path through event mapping rules.
[0140] Step 5. The IDE's adaptation communication module sends a standardization request to the central logic module.
[0141] Step 6. The central logic module parses the request.
[0142] Parsing standardized requests is a standard interactive execution operation.
[0143] Step 7. The central logic module identifies auxiliary coding events.
[0144] Step 8. The central logic module determines whether the cache exists.
[0145] Optionally, a code file may depend on a number of other files. If all its dependencies have been resolved once, they can be saved in a cache. The next time the same file is edited, it is not necessary to resolve its dependencies again; they can be retrieved directly from the cache. The cache stores the skeletal information of each dependent file, i.e., the components.
[0146] If this step exists, proceed to step 11.1; otherwise, proceed to step 11.2.
[0147] Step 9.1. The central logic module calls the file listener.
[0148] Step 9.2. The central logic module monitors file changes through a file listener.
[0149] Steps 9.1 and 9.2 both belong to the state management operations described above.
[0150] Step 10. The central logic module determines whether parsing is required.
[0151] Step 11.1. The central logic module acquires materials.
[0152] Step 11.2. Central Logic Module Parsing Syntax Explanation.
[0153] Step 11.3. The central logic module parses the associated code syntax tree.
[0154] Steps 11.1, 11.2, and 11.3 all belong to the information analysis and extraction operations described above.
[0155] Step 12.1. Concatenate the context of the central logic module.
[0156] Step 12.2. Update materials in the central logic module.
[0157] In step 12.2, the materials are updated to be synchronized with step 11.1 in order to execute the subsequent step 12.1. Furthermore, both steps 12.1 and 12.2 belong to the context management operations described above.
[0158] Step 13. The code generation service executes the code generation.
[0159] The output code belongs to the third-party interaction operation mentioned above.
[0160] Step 14. Parse the recommended code for the central logic module.
[0161] The code parsing recommendation belongs to the information analysis and extraction operation described above.
[0162] Step 15. The central logic module executes a standardized response.
[0163] Step 15 is a standard interactive execution operation as described above.
[0164] It should be noted that steps 10.1 and 10.2 belong to the file rendering operations mentioned above.
[0165] Step 16. The IDE parses the response.
[0166] Step 17. Refresh the workspace in the IDE.
[0167] In this example, the adaptation communication module listens for cursor change events and standardizes their transmission, while the central logic module independently handles syntax tree parsing, context concatenation, and code output service interaction. Development complexity is reduced from n*m to n+m, eliminating the need for each IDE to implement core logic such as syntax parsing separately. This ensures consistency and efficiency of auxiliary coding functions across different IDEs and language development scenarios, reducing maintenance costs.
[0168] Optionally, this application also provides a possible implementation of initialization, specifically, in Figure 1 On this basis, Figure 8 A flowchart illustrating a multi-IDE-based adaptive development method provided in this embodiment of the invention is shown below. Figure 8 Before step 103, the following is also included: Step 100: When the target IDE starts, the adapter communication module checks whether the central logic module is started.
[0169] If the program is not started, proceed to step 101; if it is started, proceed to step 102.
[0170] Step 101: The adaptation communication module triggers the start of the central logic module.
[0171] Step 102: Adapt the communication module and establish a communication connection with the central logic module.
[0172] Optionally, in some scenarios, the completion of the target business logic information requires the use of third-party service information. Below is one possible implementation method for calling third-party services. Specifically, in... Figure 1 On this basis, Figure 9 A flowchart illustrating a multi-IDE-based adaptive development method provided in this embodiment of the invention is shown below. Figure 9 Step 106 includes: Step 106-2: If the target business logic information indicates the invocation of a third-party service, the central logic module invokes the third-party service to obtain the business logic processing result of the target business logic information.
[0173] Optionally, to illustrate the information interaction between the user, IDE, adaptation communication module, and central logic module involved in the above example, the following uses an IDE and adaptation communication module as an example to provide an exemplary description of the signaling interaction between the various modules. Specifically, Figure 10 This invention provides a schematic diagram of a signaling interaction process based on an IDE, an adaptive communication module, and a central logic module, as illustrated in this embodiment. Figure 10 The process includes: Step 1: The user sends a startup instruction to the IDE.
[0174] Step 2: Activate the corresponding communication adapter module in the IDE.
[0175] Step 3: The adaptation communication module sends a check to the central logic module to see if the process has started.
[0176] If the central logic module has been started, proceed to step 4. If it has not been started, proceed to step 5.
[0177] Step 4: The central logic module sends a confirmation message to the adaptation communication module that the process is ready.
[0178] Step 5: Establish a bidirectional communication connection between the adaptation communication module and the central logic module.
[0179] Step 6: The central logic module responds to the adapter communication module with a successful connection.
[0180] It should be noted that steps 3 through 6 can be used as an optional process mechanism to check whether the central logic module has been started.
[0181] Step 7: The user initiates an operation with the IDE.
[0182] The execution operation is based on the operations corresponding to various development functions in the above example, such as "double-clicking the file", "opening the interface view", "clicking the generate code menu", "cursor change", etc.
[0183] Step 8: Adapt the communication module to listen for IDE events.
[0184] Step 9: Adapt the communication module for forward translation, that is, convert the IDE's native time into a standardized request.
[0185] Step 10: The adaptation communication module sends a standardization request to the central logic module.
[0186] Step 11: The central logic module executes the target business logic information and obtains the business logic processing result.
[0187] Step 12: The central logic module performs reverse translation, that is, based on the business logic processing results, it encapsulates a standardized response.
[0188] Step 13: The central logic module sends a standardized response to the adaptation communication module.
[0189] Step 14: The communication module sends a call command to the IDE.
[0190] Step 15: The IDE displays the results to the user.
[0191] It should be noted that the process of steps 7 to 15 can be used as a continuous listening and looping interaction mechanism.
[0192] Step 16: The user sends a shutdown instruction to the IDE.
[0193] Step 17: Adapt the communication module to capture the close event.
[0194] Step 18: The adaptation communication module sends a disconnection notification to the central logic module.
[0195] Step 19: Release resources from the central logic module.
[0196] It should be noted that for steps 16 to 19, the IDE shutdown mechanism is provided based on user instructions.
[0197] To perform the steps and corresponding technical effects of the above examples, this application provides a multi-IDE-based adaptive development device, specifically... Figure 11 A schematic diagram of a multi-IDE-based adaptive development device provided in an embodiment of the present invention is shown below. Figure 11 The multi-IDE-based development device 20 includes IDE-1, IDE-2 and a central logic module 201.
[0198] Among them, IDE-1 is equipped with an adaptation communication module 200a, IDE-2 is equipped with an adaptation communication module 200b, and the central logic module 201 maintains the target business logic information.
[0199] If the user performs the above development operations based on IDE-1, then IDE-1 is the target IDE in the above example. If the user performs the above development operations based on IDE-2, then IDE-2 is the target IDE in the above example. This application does not limit the number of IDEs involved in this device; it depends on business needs.
[0200] Combination Figure 11 Using IDE-1 as the target IDE, this paper introduces the various functions of this multi-IDE-based development device.
[0201] The adaptation communication module 200a is used to determine the standardized request corresponding to the IDE native event according to the event mapping rules when the target IDE's adaptation communication module 200a listens to the IDE native event; the standardized request includes the event type, business parameters and IDE identifier; and sends the standardized request to the central logic module.
[0202] The central logic module 201 is used to determine the target business logic information corresponding to the standardized request based on the event type; the target business logic information is determined based on the common logic specifications and execution standards that support various IDEs; the target business logic information is executed according to business parameters and IDE identifiers to obtain the business logic processing result of the target business logic information; the business logic processing result is encapsulated into a standardized response and the standardized response is fed back to the adaptation communication module 200a.
[0203] The 200a communication adapter is also used to convert standardized responses into call instructions that match the target IDE, based on environment mapping rules.
[0204] The target IDE is used to execute target instructions.
[0205] Optionally, the adapter communication module 200a is also used to check whether the central logic module is started when the target IDE starts; if it is not started, it triggers the central logic module to start; if it is started, it establishes a communication connection with the central logic module.
[0206] Optionally, the central logic module 201 is specifically used to call a third-party service to obtain the business logic processing result of the target business logic information if the target business logic information indicates that a third-party service should be called.
[0207] Optionally, the central logic module 201 is specifically used to determine the corresponding target business logic operation based on the event type; and to construct target business logic information based on the execution order of all target business logic operations.
[0208] Optionally, the central logic module 201 is specifically used to execute each target business logic operation in the order of execution according to the business parameters and IDE identifier, so as to obtain the business logic processing result.
[0209] To illustrate the above implementation method of the multi-IDE-based adaptive development device, the following example demonstrates the implementation of the "auxiliary coding" function using a two-IDE architecture. Specifically, Figure 12 A schematic diagram of another multi-IDE-based adaptive development device provided in an embodiment of the present invention is shown below. Figure 12 For each IDE in this multi-IDE-based adaptation development device 20, it only needs to maintain its own adaptation plugin. This adaptation plugin includes configuration files and basic adaptation source code.
[0210] Taking IDE-1 as an example, it maintains configuration files and the source code for each development function that can be implemented. For example, the source code for development function 1 (auxiliary coding), the source code for development function 2, the source code for development function 3, and so on.
[0211] Taking feature 1 as an example, its source code mainly includes general logic specifications and execution standards, as well as a UI container. These general logic specifications and execution standards may include, but are not limited to, initialization methods, methods for creating the front-end interface, and saving methods, etc.
[0212] The core processing logic and UI implementation of this development function 1 are deployed on the central logic module 201. The core processing logic is implemented using the target business logic information, while the UI implementation is provided by the UI interface.
[0213] Furthermore, for each IDE, its adapter plugin can interact with the central logic module 201 through agreed-upon specifications (remote calls / network communication, etc.). The message processing source code used for this communication is implemented through the adapter communication module of each IDE, such as the adapter communication module 200a of IDE-1.
[0214] Based on the above mechanism, by reusing the target business logic information and UI implementation, the workload of multiple IDEs is simplified, while ensuring the consistency of the target business logic information and UI interface.
[0215] It should be noted that for each development function, a correspondence between a general logical specification and an execution standard is established through a function identifier, such as Development Function-1, Development Function-2, etc. These general logical specifications are similar to the definitions of the various target business logic operations corresponding to the business logic of that development function. Based on these functional specifications, a message is sent to the central logic module 201 on the right through message processing. This message may contain the IDE type and specification identifier. The "message processing module" of the central logic module 201 identifies the corresponding function, such as "editor for auxiliary coding," and then identifies its various specifications and the target business logic operations corresponding to each specification. For the same function, different IDEs may have different specifications to execute. For example, for "editor," the target business logic operations corresponding to IDE-1 are 1-3; while the target business logic operations corresponding to IDE-2 are 1-4.
[0216] After the central logic module 201 executes the target business logic operations one by one, it updates the business logic processing results to its corresponding UI interface and business system interface. It also provides feedback to the IDE's UI container so that the IDE can preview the results.
[0217] Specifically, taking the deployment of a VS Code plugin in IDE-1 and an IntelliJ plugin in IDE-2 to implement "assisted coding" development functionality as an example. Correspondingly, Figure 13 A schematic diagram of another multi-IDE-based adaptive development device provided in an embodiment of the present invention is shown below. Figure 13The configuration file for IDE-1 is package.json, which declares custom editors through customEditors.
[0218] The editor implementation: InterfaceEditorProvider.ts is initialized via ResolveEditor and renders the UI within the webview container.
[0219] Its adaptation mechanism for the 200a communication module: messageProcessor.ts is responsible for communicating with the core logic module, using Resolve to parse requests and POST to send responses.
[0220] Similarly, the configuration file for IDE-2 is plugin.xml, which registers the file editor through fileEditorProvider.
[0221] The editor implementation: InterfaceEditor.java creates components using getComponent and renders them in the CefBrowser container.
[0222] Its adaptation mechanism for the 200b communication module: messageProcessor.java is also responsible for message parsing and sending, and is aligned with the logic on the VSCode side.
[0223] The message processing module acts as a communication bridge across IDEs. It receives messages from different IDE plugins and forwards them to the central logic module 201 for processing.
[0224] This message processing module selects the appropriate messageProcessor implementation based on the IDE type (VSCode / IntelliJ) to ensure consistency in message format and processing logic. This design allows the core logic layer to be completely independent of which IDE is being used above, focusing solely on processing standardized messages.
[0225] For the central logic module 201, its business processing logic is as follows: FileReadWrite.ts handles file reading and writing, UiHandler.ts handles UI interaction logic, and Other.ts contains other auxiliary functions.
[0226] Its UI: Interface.vue and Interface.js, developed using Vue and JavaScript, are the visual interface of the editor, rendered into different IDEs via Webview / CefBrowser.
[0227] Since the code for the central logic module 201 is fully reusable, there's no need to write separate code for different IDEs. Through a layered structure of "IDE plugin layer, message adaptation layer, and core logic layer," the core business logic is decoupled from the IDE implementation details. The target business logic information and UI code only need to be written once within the provided architecture, and the communication module adapts to run in different IDEs, significantly reducing redundant development. Furthermore, a unified messageProcessor handles cross-layer messages, ensuring stable and reliable communication between different IDE plugins and the core logic.
[0228] Continuing with the example of the development process of assisted coding, existing technologies typically divide coding assistance plugins into two parts: an IDE plugin and a code generation service. The IDE plugin is responsible for parsing the code syntax tree based on the user's cursor information and concatenating context information. The code generation service is responsible for providing recommended code based on the context information and common knowledge. The IDE receives the recommended code and inserts it at the cursor position.
[0229] At this point, the plugin's developers face a problem: Java developers might use Eclipse / IntelliJ / VSCode, and C++ developers might use Visual Studio / VSCode / CLion. To ensure that all developers can use the coding assistance features, it is necessary to support the same language on multiple IDEs and also to support multiple languages on one IDE. The development complexity of n IDEs supporting m languages may be n*m.
[0230] Based on the above example in this application, see the above. Figure 7 Simply add cursor listener events to each IDE plugin. After listening for cursor changes, send the cursor information to the central logic module. The central logic module no longer depends on the IDE but uses a single syntax parsing tool to parse / update the code syntax tree, concatenate context information, communicate with the code generation service to obtain recommended code, and then feed it back to the IDE plugin to be inserted into the editor. This reduces the development complexity to n+m.
[0231] This invention also provides an electronic device that can execute all the steps of the examples described above to achieve the corresponding technical effects. Specifically, Figure 14 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. See also: Figure 14 The electronic device 30 includes: a memory 301 and a processor 300; Memory 301 is used to store one or more programs; Processor 300; When one or more programs are executed by a processor, the electronic device 30 can achieve the steps and corresponding technical effects when it performs the steps shown in the above-described method examples.
[0232] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0233] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0234] If a function is implemented as a software module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a program product. This program product is stored in a computer-readable storage medium and includes several instructions or programs to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0235] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
[0236] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.
Claims
1. A multi-IDE-based adaptive development method, characterized in that, include: When the target IDE's adaptation communication module listens to a native IDE event, it determines the standardized request corresponding to the native IDE event according to the event mapping rules. The standardized request includes the event type, business parameters, and IDE identifier; The adaptation communication module sends the standardization request to the central logic module; The central logic module determines the target business logic information corresponding to the standardized request based on the event type; the target business logic information is determined based on the common logic specifications and execution standards that support various IDEs; The central logic module executes the target business logic information according to the business parameters and the IDE identifier to obtain the business logic processing result of the target business logic information. The central logic module encapsulates the business logic processing result into a standardized response and feeds the standardized response back to the adaptation communication module; The adaptation communication module converts the standardized response into a call instruction that matches the target IDE according to the environment mapping rules; The target IDE executes the target instructions.
2. The method according to claim 1, characterized in that, Before the step of determining the standardized request corresponding to the IDE native event according to the event mapping rules when the target IDE's adaptation communication module listens to the IDE native event, the method further includes: When the target IDE starts, the adaptation communication module checks whether the central logic module has started; If not started, the adaptation communication module triggers the central logic module to start; If activated, the adaptation communication module establishes a communication connection with the central logic module.
3. The method according to claim 1, characterized in that, The steps of the central logic module executing the target business logic information according to the business parameters and the IDE identifier to obtain the business logic processing result of the target business logic information include: If the target business logic information indicates the invocation of a third-party service, then the central logic module invokes the third-party service to obtain the business logic processing result of the target business logic information.
4. The method according to claim 1, characterized in that, The step of the central logic module determining the target business logic information corresponding to the standardized request based on the event type includes: The central logic module determines the corresponding target business logic operation based on the event type; The central logic module constructs the target business logic information according to the execution order of all the target business logic operations.
5. The method according to claim 1, characterized in that, The steps of the central logic module executing the target business logic information according to the business parameters and the IDE identifier to obtain the business logic processing result of the target business logic information include: The central logic module executes each target business logic operation in the order of execution based on the business parameters and the IDE identifier to obtain the business logic processing result.
6. A multi-IDE-based adaptive development device, characterized in that, include: The target IDE, the corresponding adaptive communication module, and the central logic module; The adaptation communication module is used to determine a standardized request corresponding to the IDE native event according to the event mapping rules when the target IDE's adaptation communication module listens for the IDE native event; the standardized request includes the event type, business parameters, and IDE identifier; and send the standardized request to the central logic module. The central logic module is used to determine the target business logic information corresponding to the standardized request based on the event type; the target business logic information is determined based on the common logic specifications and execution standards that support various IDEs; the target business logic information is executed according to the business parameters and the IDE identifier to obtain the business logic processing result of the target business logic information; the business logic processing result is encapsulated into a standardized response, and the standardized response is fed back to the adaptation communication module; The adaptation communication module is also used to convert the standardized response into a call instruction that matches the target IDE according to the environment mapping rules; The target IDE is used to execute the target instructions.
7. The apparatus according to claim 6, characterized in that, The adapter communication module is further configured to check whether the central logic module is started when the target IDE starts; if it is not started, the adapter communication module is triggered to start; if it is started, a communication connection is established with the central logic module.
8. The apparatus according to claim 6, characterized in that, The central logic module is specifically used to invoke the third-party service to obtain the business logic processing result of the target business logic information if the target business logic information indicates that a third-party service should be invoked.
9. An electronic device, characterized in that, include: Memory, used to store one or more programs; processor; When the one or more programs are executed by the processor, the method as described in any one of claims 1-5 is implemented.
10. A program product, characterized in that, When the program product contains a program that is executed by a processor, it implements the method as described in any one of claims 1-5.