Display method and related device

Abstract

The embodiment of the application discloses a display method and related equipment, the method is applied to a first device, the method comprises the following steps: displaying a first interface, the first interface comprises one or more menu items; in the process of running a main application or a sub-application, if there is a user change operation on the sub-application, a first fusion menu configuration file is acquired; the first fusion menu configuration file is generated based on a menu configuration file of the main application and a menu configuration file of the sub-application; the first interface is switched to display a second interface based on the first fusion menu configuration file, the second interface comprises one or more menu items, and the menu items of the first interface are different from those of the second interface. In the case of adding a sub-application, deleting a sub-application, and the like, the embodiment of the application automatically performs dynamic refreshing display of a page based on a first fusion menu configuration file, and can timely present new menu items or delete unusable menu items for a user.

Description

Technical Field

[0001] This invention relates to the field of graphical user interface (GUI), and more particularly to a display method and related equipment. Background Technology

[0002] Micro-frontend architecture is an architecture that aggregates multiple independently deployable small frontend applications into a whole. A micro-frontend architecture typically includes a main application and one or more sub-applications. Sub-applications can be extended applications nested within the main application's content area.

[0003] Generally, both the main application and the sub-applications include corresponding menu items. When a user accesses a Uniform Resource Locator (URL) address corresponding to the main application or the sub-application, the webpage corresponding to that URL can display the menu items corresponding to the main application and the sub-application.

[0004] Meanwhile, how to dynamically refresh web pages and promptly display newly added menu items or delete unusable menu items when sub-applications are added or deleted is a concern in the industry. Summary of the Invention

[0005] This application discloses a display method and related device that can automatically refresh the page dynamically based on the latest fusion menu configuration file when adding or deleting sub-applications, and can promptly present new menu items or delete unusable menu items for users.

[0006] The first aspect discloses a display method, which can be applied to a first device, a module within the first device (e.g., a chip, a central processing unit, etc.), or a logic module or software capable of implementing all or part of the functions of the first device. The following description uses an application to a first device as an example. The display method may include: displaying a first interface, which includes one or more menu items for accessing a main application or a sub-application corresponding to the main application; during the operation of the main application or the sub-application, in the event of a user's modification operation on the sub-application, obtaining a first fused menu configuration file; the first fused menu configuration file is generated based on the menu configuration file of the main application and the menu configuration file of the sub-application, the menu configuration file of the main application or the sub-application including menu item information of the corresponding application, the menu item information including the name of each menu item of the corresponding application and its corresponding hierarchical relationship; and switching the first interface to a second interface based on the first fused menu configuration file, the second interface including one or more menu items, the menu items of which are different from those of the first interface.

[0007] In this embodiment, the user interface can be displayed based on a merged menu configuration file. The merged menu configuration file can be generated based on the menu configuration files of the main application and its corresponding sub-applications, and can include information about each menu item for each application, such as the name of each menu item and its corresponding hierarchical relationship. Therefore, during the operation of the main application or a sub-application, if there are user changes to the sub-application, such as adding or deleting a sub-application, the first device can obtain the latest merged menu configuration file, i.e., the first merged menu configuration file. Then, the user interface can be dynamically refreshed based on the first merged menu configuration file, allowing for timely presentation of new menu items or deletion of unusable menu items.

[0008] As one possible implementation, the method may further include: sending a first request for a first Uniform Resource Locator (URL) address; receiving a first response resource, the first response resource including an HTML file corresponding to the first URL address, a script file corresponding to the first URL address, and a second fusion menu configuration file; the display of the first interface includes: parsing the second fusion menu configuration file through the script file corresponding to the first URL address to obtain menu item information for each application; and displaying the first interface based on the menu item information for each application and the HTML file corresponding to the first URL address.

[0009] In this embodiment, the first device can parse the second fusion menu configuration file based on the corresponding script file to obtain the name and hierarchical relationship of the menu items corresponding to each application, and then display the page in conjunction with the corresponding HTML file. In this case, the processing logic of the backend microservices and the display of the frontend page can be decoupled. Therefore, when adding a sub-application, it is not necessary to shut down the backend running microservices. When modifying or uninstalling a sub-application, only the microservices corresponding to that sub-application need to be shut down, and the microservices corresponding to other applications do not need to be shut down, which can ensure the continuity of business.

[0010] As one possible implementation, the first integrated menu configuration file includes a corresponding timestamp, which indicates the time when the user performs a change operation on the sub-application, and the process of obtaining the first integrated menu configuration file when there is a user change operation on the sub-application includes: periodically obtaining the timestamp of the first integrated menu configuration file; and obtaining the first integrated menu configuration file when the timestamp of the first integrated menu configuration file is updated.

[0011] In this embodiment, a corresponding timestamp can be recorded when generating the fusion menu configuration file. Subsequently, the first device can periodically obtain the latest timestamp of the fusion menu configuration file and use this timestamp to determine whether the fusion menu configuration file has been updated. This reduces the amount of data transmitted each time, thereby saving transmission resources.

[0012] In one possible implementation, the first interface includes an import application control, the change operation includes a add operation, and the user's add operation on the sub-application includes: receiving the user's first operation on the import application control; in response to the first operation, selecting the application service package of the first application and sending a first installation request, the first installation request including the application service package of the sub-application, the application service package of the first application including the microservice file, Nginx configuration file and menu configuration file corresponding to the sub-application.

[0013] In this embodiment, it is possible to dynamically add sub-applications by importing controls during the operation of the main application or sub-application, offering high flexibility and strong scalability. Furthermore, this method does not require changes to other currently used code files, such as other currently used HTML files or currently running microservice files, thus improving the development and deployment efficiency of new applications. In addition, with this method, if a new application needs to be added, only the corresponding micro-application file, microservice file, menu configuration file, and Nginx configuration file need to be provided; therefore, users can develop corresponding sub-applications according to their actual needs.

[0014] In one possible implementation, the first interface also includes a delete control corresponding to each sub-application. The change operation includes a delete operation. The user's delete operation on the sub-application includes: receiving a second operation from the user on the delete control corresponding to the sub-application; and in response to the second operation, sending a first delete request, the first delete request including the identifier of the sub-application.

[0015] In this embodiment, it is possible to dynamically delete or uninstall a sub-application via a deletion control during the operation of the main application or sub-application, which provides high flexibility.

[0016] As one possible implementation, the menu item information also includes internationalization configuration information for each menu item, which is used to display the menu items based on different language environments.

[0017] In this embodiment of the application, the menu item information may also include internationalization configuration information corresponding to each menu item. For example, a menu item may correspond to names in multiple languages. The first device may display the menu items based on different language environments to meet the usage needs of different users and improve the user experience.

[0018] As one possible implementation, the menu item information also includes the URL address corresponding to each menu item.

[0019] In this embodiment of the application, the menu item information may also include the URL address corresponding to each menu item, so that when a user clicks a menu item with the mouse, access to the URL address corresponding to that menu item can be triggered.

[0020] The second aspect discloses a display method that can be applied to a second device or a Kubernetes cluster, or to modules within the second device or Kubernetes cluster, or to logical modules or software capable of implementing all or part of the functions of the second device or the Kubernetes cluster. The following description uses an application to a second device as an example. The display method may include: in the event of a user's modification operation on a sub-application corresponding to a main application, generating a first fused menu configuration file based on the menu configuration file of the main application and the menu configuration file of the sub-application. The menu configuration file of the main application or sub-application includes menu item information for the corresponding application, including the name of each menu item and its corresponding hierarchical relationship; sending the first fused menu configuration file to the first device, the first fused menu configuration file being used to switch the display of a first interface to a second interface, the first interface including one or more menu items, the second interface including one or more menu items, and the menu items of the first interface and the second interface being different.

[0021] In this embodiment, when there are user changes to sub-applications, such as adding or deleting sub-applications, the second device can obtain the latest merged menu configuration file, i.e., the first menu configuration file, based on the menu configuration files of the current main application and the corresponding sub-applications. Then, the second device can send the first menu configuration file to the first device, so that the first device can switch the first interface to the second interface based on the first merged menu configuration file, promptly presenting new menu items to the user or deleting unusable menu items, etc.

[0022] As one possible implementation, a menu item corresponds to a menu item object. The menu item object includes one or more of the following: the name, address, and sub-menu item objects of the corresponding menu item. The process of generating the first fused menu configuration file based on the menu configuration file of the main application and the menu configuration file of the sub-application includes: merging the sub-menu item objects belonging to the same menu item object in the menu configuration file of the main application and the menu configuration file of the sub-application to generate the first fused menu configuration file.

[0023] In this embodiment, when merging menu configuration files, the sub-menu item objects belonging to the same menu item object in the main application's menu configuration file and the menu configuration file of the corresponding sub-application can be merged to generate a first merged menu configuration file. This merging method is highly efficient, thereby improving the efficiency of dynamic user interface refresh and thus enhancing the user experience.

[0024] In one possible implementation, the change operation includes a new operation, and the method may further include: receiving a first installation request from the first device, the first installation request including an application service package of a first application, the application service package of the first application including a menu configuration file corresponding to the first application; generating a first fused menu configuration file based on the menu configuration file of the main application and the menu configuration file of the sub-application corresponding to the main application includes: generating a first fused menu configuration file based on the menu configuration file corresponding to the first application, and the menu configuration file of the main application and the menu configuration file of the sub-application corresponding to the main application.

[0025] In this embodiment, the addition of sub-applications is supported, offering high flexibility and scalability. Furthermore, this approach allows for dynamic page refresh by simply generating a new merged menu configuration file based on the current main application and sub-application's menu configuration files when adding a sub-application. No changes are required to other currently used code files, such as HTML files or running microservice files, thus improving the development and deployment efficiency of new applications.

[0026] In one possible implementation, the change operation includes a deletion operation, and the method may further include: receiving a first deletion request from the first device, the first deletion request including an identifier of a first application; deleting the menu configuration file, microservice file, and Nginx configuration file corresponding to the first application based on the identifier of the first application; generating a first merged menu configuration file based on the menu configuration file of the main application and the menu configuration files of the sub-applications corresponding to the main application includes: generating a first merged menu configuration file based on the menu configuration file of the main application and the menu configuration files of the sub-applications corresponding to the main application, wherein the sub-applications corresponding to the main application do not include the first application.

[0027] In this embodiment, the deletion of sub-applications is supported, offering high flexibility. Furthermore, in this approach, when deleting a sub-application, a new merged menu configuration file can be generated based on the current main application and sub-application's menu configuration files for dynamic page refresh and display. This eliminates the need to modify other currently used code files, such as other currently used HTML files or currently running microservice files, thus improving the efficiency of application deletion.

[0028] The third aspect discloses an electronic device including a processor and a memory, wherein the processor calls a computer program stored in the memory to implement the display method provided in the first aspect and any possible implementation thereof, or to implement the display method provided in the second aspect and any possible implementation thereof.

[0029] The fourth aspect discloses a computer cluster that can be used to execute the display methods provided in the second aspect and any possible implementation thereof.

[0030] The fifth aspect discloses a computer-readable storage medium storing a computer program or computer instructions that, when executed, implement the display methods disclosed in the above aspects.

[0031] The sixth aspect discloses a chip including a processor for executing a program stored in a memory, which, when executed, causes the chip to perform the display methods disclosed in the above aspects.

[0032] As one possible implementation, the memory is located outside the chip.

[0033] The seventh aspect discloses a computer program product comprising computer program code, which, when executed, causes the display methods disclosed in the above aspects to be performed.

[0034] It should be understood that the implementation and beneficial effects of the above-mentioned aspects or any possible implementation methods of this application can be referred to each other. Attached Figure Description

[0035] The accompanying drawings are provided to more clearly illustrate the technical solutions of the embodiments of this application. The drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figures 1A-1F These are schematic diagrams of a set of user interfaces provided in the embodiments of this application;

[0037] Figure 2 This is a schematic diagram of a system architecture disclosed in an embodiment of this application;

[0038] Figure 3 This is a schematic diagram of a scenario for importing an application, as disclosed in an embodiment of this application.

[0039] Figure 4This is a schematic diagram of the structure of an application service package disclosed in an embodiment of this application;

[0040] Figure 5 This is another system architecture diagram disclosed in the embodiments of this application;

[0041] Figure 6 This is a flowchart illustrating a display method disclosed in an embodiment of this application;

[0042] Figure 7 This is a flowchart illustrating another display method disclosed in an embodiment of this application;

[0043] Figure 8 This is a flowchart illustrating another display method disclosed in an embodiment of this application;

[0044] Figure 9 This is a flowchart illustrating another display method disclosed in an embodiment of this application;

[0045] Figure 10 This is a flowchart illustrating another display method disclosed in an embodiment of this application;

[0046] Figure 11 This is a flowchart illustrating another display method disclosed in an embodiment of this application;

[0047] Figure 12 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. Detailed Implementation

[0048] This application discloses a display method that can automatically refresh the page display based on the latest integrated menu configuration file when adding or deleting sub-applications, thus providing users with timely access to new menu items or the removal of unavailable menu items. The technical solutions in this application will be clearly and completely described below with reference to the accompanying drawings.

[0049] To better understand the embodiments of this application, the relevant terms and technologies of the embodiments of this application will be described below.

[0050] A Uniform Resource Locator (URL) is a standard address for a resource on the Internet. A URL can also be called a webpage address or simply a website address.

[0051] A container is a virtualization technology in computer operating systems. This technology allows processes to run in relatively independent and isolated environments (such as those with independent file systems, namespaces, and resource views), thereby simplifying software deployment, enhancing software portability and security, and improving system resource utilization. Container technology is widely used in service-oriented scenarios within the cloud computing field, and container development is gradually becoming a mainstream application development technology.

[0052] Kubernetes (k8s) is an open-source platform for the automated deployment, scaling, and operation of container clusters. It features disaster recovery, horizontal scaling (elastic scaling), service discovery, load balancing, version rollback, and storage orchestration, and is widely used in the construction and management of computer clusters.

[0053] A Pod (container group) is generally the smallest deployment unit in Kubernetes (the smallest resource object for running containerized applications). Each Pod can contain one or more containers (a group of containers), which can be used to run applications, such as user business applications. Furthermore, containers within a Pod can share network and namespaces, etc.

[0054] It's important to note that containers generally have independent file systems, and applications within a container can only access its own file system. In other words, different containers are generally not visible to each other. To achieve file sharing between different containers within a Pod, or between different containers in different Pods, you can mount the containers that need file sharing to the same volume / directory. For example, suppose you have two containers, Container 1 and Container 2. To achieve file sharing between Container 1 and Container 2, you can mount a directory from the host operating system of the electronic device to a directory within Container 1 and Container 2, such as the root directory within Container 1 and Container 2. This way, data stored in the root directory of Container 1 or Container 2 can be automatically synchronized to the corresponding host directory. That is, files in the root directory of Container 1, files in the root directory of Container 2, and files in the corresponding host directory can be the same.

[0055] Microservices is a software architecture style that builds complex, large applications by using small functional blocks that focus on a single responsibility and function. These functional blocks communicate using language-independent application programming interfaces (APIs), such as APIs that follow the representational state transfer (REST) ​​design style (RESTful APIs).

[0056] Micro frontends are an extension of the microservices concept. They abandon the large monolithic approach and decompose the entire frontend into small, simple modules. These modules can be developed, tested, and deployed independently, while still being presented as a single product. It should be understood that a micro frontend architecture is an architectural style that aggregates multiple independently deliverable small frontend applications into a cohesive whole. Micro frontend architectures can include Qiankun, Wujie, and Qingtian architectures, among others.

[0057] It should be noted that a micro-frontend architecture can include a main application (base application) and one or more sub-applications. Sub-applications can be extended applications nested within the main application's content area.

[0058] It's understandable that micro-frontends and microservices can be used together; a micro-frontend can serve as the front-end interface layer for a microservice. The main application and sub-applications within a micro-frontend can communicate with the backend microservices to obtain necessary data or execute business logic.

[0059] Browser / server (B / S) architecture is a network architecture pattern in which the user interface is presented through a browser, but the main business logic is processed on the backend (server side). For example, users can access the corresponding webpage by entering a URL in the browser, and can interact with the webpage using the mouse, keyboard, etc., to request data from the backend, or send data to the backend and process it through pre-defined functions.

[0060] In related technologies, when using architectures such as B / S (Browser / Server) architecture, users can first start one or more microservices on the backend to respond to Hypertext Transfer Protocol (HTTP) requests initiated by the frontend. For example, the microservices running on the backend can define different processing logic for different requests to different URLs, such as the processing logic for a GET request initiated for URL 1. For a given URL, when accessing that URL, the corresponding microservice on the backend will generally return resource files such as Hypertext Markup Language (HTML) files, Cascading Style Sheets (CSS) files, JavaScript (JS) files, or TypeScript (TS) files, so that the browser can render the corresponding user interface based on these files. Furthermore, for an already built backend, the resource files returned for a given URL are usually fixed, and the content of the resource files is also unchanging. For example, the content of the HTML file corresponding to that URL is unchanging, and the display format and content of the HTML file corresponding to that URL are already defined through various HTML tags. Therefore, the content of the webpage displayed for that URL is also unchanging. If you need to change the content displayed on the webpage corresponding to a URL (such as adding or deleting menu items), you generally need to rewrite or modify the HTML file corresponding to that URL.

[0061] Furthermore, in practice, there may be a coupling relationship between the resource files returned by a URL and the corresponding microservices. For example, the resource files may be nested within the code of the corresponding microservices (e.g., the HTML file to be returned may be nested within the code of the corresponding microservices). In this case, if new functionality needs to be added to the current webpage, it is generally necessary to repurchase the corresponding software from the software vendor, including the corresponding microapplication files (including HTML, CSS, JS, or TS files, etc.) and microservice files. Moreover, to implement the addition of functionality to the webpage, the software vendor will typically modify the software code corresponding to the currently running microservices; that is, the new microservice files may differ from those of the currently running microservices. Therefore, after repurchasing the corresponding software, it is necessary to shut down or pause the currently running backend microservices, and then restart the microservices based on the new microservice files to respond to HTTP requests initiated by the frontend and implement the added functionality on the webpage.

[0062] As we can see, adding new features to a webpage requires first shutting down or pausing the currently running backend microservices. This means pausing backend business processing and then restarting the microservices based on the new microservice files. During this period between shutting down the currently running backend microservices and restarting them, users cannot access the corresponding webpage. This is unacceptable for frequently accessed webpages. Furthermore, this approach involves changes to currently used microservice files and resource files (such as HTML files), resulting in high coupling and hindering software development.

[0063] To address the aforementioned issues, this embodiment of the application provides corresponding menu configuration files for the main application and sub-applications. Furthermore, the existing menu configuration files for the main application and sub-applications can be merged to obtain a merged menu configuration file. The corresponding webpage can then be displayed based on this merged menu configuration file. When a sub-application is added, modified, or uninstalled, the existing menu configuration files for the main application and sub-applications can be merged again to obtain a new merged menu configuration file. The corresponding webpage can then be displayed based on this new merged menu configuration file. In this approach, the front-end can display webpages based on the merged menu configuration file. Therefore, when adding, modifying, or uninstalling a sub-application, the front-end webpage can be dynamically refreshed, promptly displaying new functions or deleting corresponding functions. Moreover, this approach decouples the processing logic of the back-end microservices from the display of the front-end page. Therefore, when adding a sub-application, it is not necessary to shut down the back-end running microservices. When modifying or uninstalling a sub-application, only the microservice corresponding to that sub-application needs to be shut down; the microservices corresponding to other applications do not need to be shut down, ensuring business continuity.

[0064] The following section, using the display interface of the first device as an example, describes a display method involved in the embodiments of this application.

[0065] Please see Figure 1A , Figure 1A This is a schematic diagram of a user interface provided in an embodiment of this application. For example... Figure 1AAs shown, the display (such as a screen) of the first device can display a user interface 101, which displays a page with application icons. This page can be the application desktop of the first device. The first device can be any terminal device with a display screen, such as a laptop, desktop computer, tablet computer, mobile phone, etc. The first device can also communicate with a second device (such as a server) to realize data interaction between the two. The page can include a taskbar displaying information such as time and date, and multiple application icons. For example, the page can include an email application icon, a calculator application icon, a file application icon, a music application icon, a text editor application icon, a weather application icon, a browser application icon 1011, etc.

[0066] If a user needs to launch the browser application, they can move the mouse pointer over the browser application icon 1011 and then perform an input operation (such as double-clicking) on ​​the browser application icon 1011. In response to the input operation on the browser application icon 1011, the first device can launch the browser and display the browser page. The user can then enter the desired network address, such as a URL (uniform resource locator), in the address bar at the top of the browser page. Figure 1B As shown, the URL address corresponding to the application management sub-function under the system management function of a certain front-end application can be "http: / / 192.168.206.128 / system / manage". The user can enter this URL address in the address bar 1012 and then perform an input operation on the address bar 1012 (such as pressing Enter). In response to the input operation on the address bar 1012, the first device can access the corresponding second device. The second device can return the HTML file, CSS file, JS file, and other resource files, as well as the fusion menu configuration file, corresponding to the URL address to the first device. The first device can then display the user interface 102 based on the resource files and fusion menu configuration file returned by the second device.

[0067] The user interface 102 may include a primary menu display area 1013, and may also include a display area 1014 for sub-menu items corresponding to the system management menu items within the primary menu display area 1013. The primary menu display area 1013 may display one or more primary menu items, such as the home menu item, resource menu item, device menu item, monitoring menu item, and system management menu item. The sub-menu item display area 1014 may display one or more secondary menu items corresponding to the system management menu items, such as the user menu item, security menu item, upgrade menu item, system configuration menu item, license menu item, and application management menu item. It should be understood that primary menu items such as the home menu item, resource menu item, device menu item, and monitoring menu item may also each include corresponding secondary menu items. It should also be understood that a secondary menu item may also include corresponding tertiary menu items; for example, secondary menu items such as the security menu item and system configuration menu item under the system management menu item may include corresponding tertiary menu items. In this embodiment, menu items can be nested hierarchically. A first-level menu item can include one or more second-level menu items, a second-level menu item can include one or more third-level menu items, a third-level menu item can include one or more fourth-level menu items, and so on. Of course, a menu item may not have any sub-menu items.

[0068] It should be noted that, in this embodiment of the application, each application (including main application and sub-applications) may include one or more corresponding menu items, and each menu item may include a corresponding address and name. The menu configuration file of each application may include the addresses and names corresponding to all menu items included in the application, as well as the hierarchical relationship between these menu items.

[0069] In this embodiment, a merged menu configuration file can be obtained based on the menu configuration file of the main application and the menu configuration file of the corresponding sub-application. The merged menu configuration file can include the addresses and names of all menu items in the main application and the corresponding sub-application, as well as the hierarchical relationship between these menu items. The display of menu items on the user interface can be based on the merged menu configuration file.

[0070] The user interface 102 may also display currently imported applications, such as applications A through E, where each application can be a sub-application. The user interface 102 may also include an import application control 1015. If a user needs to import an application to add functionality to the webpage, they can click the import application control 1015 with the mouse. In response to this operation, the first device can display the user interface 103.

[0071] like Figure 1CAs shown, in user interface 103, the user can select the application service package to be imported. For example, the user can select the application service package corresponding to application F, as shown in area 1016. After the user selects the application service package corresponding to application F, the user can open control 1017 by clicking the mouse. In response to this operation, the first device can display user interface 104.

[0072] like Figure 1D As shown, in user interface 104, the first device is importing application F, which may include an import information display area 1018 for application F, such as the application name, status, importer, and import time of application F. During the import process of application F, the first device can send the application service package corresponding to application F to the second device. The application service package corresponding to application F may include the microservice file, micro-application file, menu configuration file, etc., corresponding to application F. Accordingly, the second device can receive the application service package from the first device, and then the second device can parse the application service package corresponding to application F to obtain the microservice file, micro-application file, menu configuration file, etc., corresponding to application F. Furthermore, the second device can deploy the microservice corresponding to application F based on the microservice file, or it can re-merge based on the menu configuration files of all applications to obtain a new merged menu configuration file, for example, re-merging based on the menu configuration files of the main application and application A-application F. When the second device successfully deploys the microservice corresponding to application F and obtains the new merged menu configuration file, application F is successfully imported. Afterwards, the second device can send the new merged menu configuration file to the first device. Accordingly, the first device can receive a new fusion menu configuration file from the second device, and the first device can refresh the page based on the new fusion menu configuration file to display the user interface 105.

[0073] like Figure 1E As shown, in the user interface 105, a new menu item 1019 for application F has been added to the first-level menu display area 1013, and a new menu item 1020 for application F has also been added to the second-level menu display area 1014, serving as a second-level menu item under the system management menu item. It is evident that in this approach, menu items can be displayed based on a merged menu configuration file. Therefore, when adding new features to a webpage by importing applications, the menu configuration files of all applications can be merged again to obtain a new merged menu configuration file. Furthermore, the first device can dynamically refresh the page based on the new merged menu configuration file, promptly presenting new features to the user and improving the user experience. Moreover, in this embodiment, the backend microservices can be decoupled from micro-application files, menu configuration files, etc., meaning that the frontend code and backend code are decoupled from each other. Therefore, when adding new features to a webpage, the backend microservices do not need to be shut down, ensuring the continuity of business operations.

[0074] After that, if a user needs to uninstall or delete an application, they can click the corresponding delete control to remove it. For example, ... Figure 1F As shown, in the user interface 106, the user can delete application F by clicking the delete control 1021 in the import information display area 1018 corresponding to application F. During the deletion of application F, the first device can send a deletion instruction to the second device. Accordingly, the second device can receive the deletion instruction from the first device, and then the second device can close or remove the microservice corresponding to application F, and delete the microservice files, micro-application files, menu configuration files, etc., corresponding to application F. Furthermore, the second device can also re-merge the menu configuration files of all applications to obtain a new merged menu configuration file, for example, re-merging the menu configuration files of the main application and application AE. Afterwards, the second device can send the new merged menu configuration file to the first device. Accordingly, the first device can receive the new merged menu configuration file from the second device, and the first device can refresh the page based on the new merged menu configuration file, displaying, for example... Figure 1B The user interface 102 shown.

[0075] As can be seen, in the above process, if a new sub-application needs to be added, the corresponding application service package can be directly imported using the import control; if a sub-application needs to be deleted, the corresponding delete control can be clicked directly. Furthermore, after adding or deleting a sub-application, the menu configuration files of all existing applications can be merged again to obtain a new merged menu configuration file. Then, the menu items can be refreshed and displayed based on this new merged menu configuration file. In this approach, the menu items and the corresponding HTML file of the webpage can be decoupled. That is, menu items do not need to be directly defined in the HTML file of the webpage; instead, JSON code, TS code, etc., can be embedded in the HTML file. The new merged menu configuration file is parsed using the embedded JSON code, TS code, etc., and the parsed menu items can then be embedded in the HTML file or referenced in the HTML file, thereby achieving dynamic refreshing of the menu items.

[0076] Furthermore, in this embodiment, the micro-application file and microservice file corresponding to a sub-application are decoupled. Therefore, when adding or deleting a sub-application, it is not necessary to modify the currently running microservice file. Accordingly, it is not necessary to shut down or pause the currently running microservice in the backend, thus ensuring the continuity of business operations.

[0077] It is understood that the above-described application scenarios of the embodiments of this application are illustrated in the form of browser web pages. However, in other embodiments of this application, they may also be presented in the form of mini programs, APP (Application), etc. The embodiments of this application do not limit this.

[0078] It should be noted that, Figures 1A-1F The user interface shown is merely illustrative and does not constitute a limitation thereof. In other embodiments of this application, the user interface may display more or fewer controls, content, etc., or the content may be laid out in different ways. Figures 1A-1F The user interface shown is primarily intended to illustrate the display method provided in this application embodiment. This method allows for the dynamic addition or deletion of applications when a user accesses a webpage. Furthermore, it automatically refreshes the webpage after a successful addition or deletion of an application, promptly presenting new menu items or removing unavailable ones. It should be understood that related descriptions can also be found in the following... Figure 6 , Figure 7 , Figure 8 and Figure 9 The descriptions in the illustrated embodiments will not be repeated in detail here.

[0079] Please see Figure 2 , Figure 2 This is a schematic diagram of a system architecture disclosed in an embodiment of this application. For example... Figure 2 As shown, the system architecture may include a first device 201 and a k8s cluster 202.

[0080] The first device 201 and the Kubernetes cluster 202 can communicate (exchange data). For example, the first device 201 and the Kubernetes cluster 202 can communicate with each other via a network. It should be understood that the individual nodes in the Kubernetes cluster 202 can also communicate with each other.

[0081] It should be noted that the first device 201 can be a laptop, desktop computer, tablet computer, mobile phone, or other devices. This application embodiment does not impose specific limitations on the first device 201.

[0082] A Kubernetes cluster 202 can include multiple nodes. Figure 2 The diagram illustrates four nodes: node a 2021, node b 2022, node c 2023, and node d 2024. Each node in the Kubernetes cluster 202 can be one or more servers, specifically blade servers, high-density servers, rack servers, cabinet servers, etc.

[0083] It should be understood that nodes in a Kubernetes cluster 202 can include two types: control nodes and worker nodes.

[0084] The management node is primarily responsible for managing and maintaining the entire Kubernetes cluster, ensuring that all nodes work collaboratively. For example, the management node needs to perform resource scheduling, detect and respond to cluster events so that services running on the cluster can function properly.

[0085] Worker nodes are the carriers in the cluster responsible for running Pods and user containers (i.e., various service processes).

[0086] In this embodiment, the first device 201 may include a display screen and may have software such as a browser installed. During a user's access to a webpage through the first device 201, if an application is added or deleted from the corresponding webpage, the corresponding service in the Kubernetes cluster 202 can add or delete the menu configuration file corresponding to that application. Then, it can re-merge all current menu configuration files to obtain a new merged menu configuration file, which can be sent to the browser on the first device. Accordingly, the browser can receive the new merged menu configuration file and refresh the webpage based on it, thus promptly presenting newly added menu items or deleting unusable menu items to the user.

[0087] The following is combined Figure 3 This section provides a brief overview of the process for users to import applications via their browser.

[0088] like Figure 3 As shown, a Kubernetes cluster 202 can include various services deployed in Pods, such as Web UI (web user interface) (2025), Helm Mgt (2026), Docker Registry (2027), API Server (2029), etc. It can be understood that these services can be understood as code programs running in Pods.

[0089] It should be noted that the embodiments of this application do not impose specific limitations on the deployment of services such as Web UI (2025), Helm Mgt (2026), Docker Registry (2027), and API Server (2029). For example, services such as Web UI (2025), Helm Mgt (2026), Docker Registry (2027), and API Server (2029) can be deployed on different nodes of the Kubernetes cluster. Furthermore, services such as Web UI (2025), Helm Mgt (2026), Docker Registry (2027), and API Server (2029) can be deployed in different Pods on the same node of the Kubernetes cluster, such as in different Pods on the management node.

[0090] The Web UI (2025) can receive requests from Browser 2011 and distribute them to the corresponding services for processing based on the information carried in the requests. Furthermore, the Web UI (2025) can also return resource files to Browser 2011, such as the response resource files corresponding to the requests sent by Browser 2011.

[0091] Helm Mgt (2026) can be understood as a package management tool that facilitates application (service) deployment and management. Helm Mgt (2026) typically deploys applications based on chart packages. An application's chart package can be understood as a collection of files required for deploying that application, including Kubernetes resource files such as Deployment files. Deployment files define the application's deployment method and update strategy; for example, they can define the number of Pod replicas to be created, images, container ports, etc. Deployment files are usually in YAML format, which is highly readable and easy to understand; files using YAML format are often simply called YAML files.

[0092] The Docker Registry (2027) can be understood as an image repository or chart repository, storing Kubernetes resource files required for application deployment, such as Deployment files. It's important to note that for different applications, the corresponding Kubernetes resource files (such as YAML files) of a certain type may have a few differences in content, while most of the content may be the same. Therefore, to address this, template resource files can be set up for these applications, where the unchanging content can be retained, and the changing content can be filled with placeholder variables. Then, corresponding value files, such as values.yaml files, can be configured for different applications. These value files store the values ​​corresponding to the variables in the template resource files, thus obtaining the complete Kubernetes resource files required for application deployment.

[0093] The API Server (2029) primarily acts as the API gateway for the Kubernetes cluster 202, receiving requests from clients and other system components or services. In response to these requests, resources can be created, updated, or deleted within the Kubernetes cluster 202. For example, Helm Mgt (2026) can send an application (service) deployment request to the API Server (2029), and in response, the API Server (2029) can deploy the corresponding application (service) into a Pod.

[0094] In this embodiment, a user can send an application service package (such as the application service package corresponding to application F) to the Web UI (2025) through a browser (2011) to request the deployment of the corresponding service. After receiving the application service package sent by the browser (2011), the Web UI (2025) can send the application service package to Helm Mgt (2026). The application service package can be a compressed file, and its specific structure can be found in [reference needed]. Figure 4 ,like Figure 4As shown, an application service package 401 corresponding to an application may include a front-end micro-application portion 4011 and a microservice portion 4012 related to the micro-application. The front-end micro-application portion 4011 may include a micro-application file 40111 and an Nginx configuration file 40112. Specifically, the micro-application file 40111 may include corresponding HTML, CSS, and JS files, as well as a menu configuration file corresponding to application F. The Nginx configuration file 40112 mainly includes corresponding HTTP configurations and routing configurations. The microservice portion 4012 may include microservice files corresponding to one or more microservices, such as microservice files corresponding to service 1, service 2, ..., service N, where N is a positive integer. These microservice files are used to deploy the corresponding microservices. In other words, a micro-application can correspond to one or more microservices, and these microservices can be used to support the corresponding micro-application in implementing its functions.

[0095] After receiving the application service package from the Web UI (2025), Helm Mgt (2026) can decompress the application service package to obtain the micro-application files, Nginx configuration files, and microservice files. Furthermore, Helm Mgt (2026) can mount the micro-application files and Nginx configuration files to a preset directory, that is, store them in the corresponding host directory 2028. Figure 3 As can be seen, the Web UI (2025) and Helm Mgt (2026) can mount the same host directory 2028, enabling file sharing between them. Helm Mgt (2026) can also deploy corresponding microservices based on microservice files. For example, for the microservice file corresponding to service 1, Helm Mgt (2026) can deploy service 1 to the k8s cluster. In this embodiment, the microservice file corresponding to service 1 can be either the chart package or the values ​​file. If the microservice file corresponding to service 1 is the chart package, Helm Mgt (2026) can directly send a deployment request to the API Server (2029), which can include the chart package corresponding to service 1. Then, the API Server (2029) can deploy service 1 to the k8s cluster based on the chart package. (See also...) Figure 3Furthermore, Helm Mgt (2026) can push the chart package corresponding to service 1 to the Docker Registry (2027). If the microservice file corresponding to service 1 is the values ​​file corresponding to service 1, without including the complete Kubernetes resource files required for deploying service 1, Helm Mgt (2026) can pull the chart package corresponding to service 1 from the Docker Registry (2027). This chart package may include template resource files. Then, Helm Mgt (2026) can send a deployment request to the API Server (2029), which can carry the pulled chart package and the values ​​file corresponding to service 1. Afterwards, the API Server (2029) can deploy service 1 (2030) to the Kubernetes cluster based on the values ​​file and chart package corresponding to service 1.

[0096] In addition to the aforementioned microservice deployment operations, after Helm Mgt (2026) stores the micro-application files and Nginx configuration files obtained from the decompressed application service package in the host directory 2028, the Web UI (2025) can apply the Nginx configuration file. Furthermore, it can re-merge all menu configuration files mounted in the current host directory 2028 to obtain a new merged menu configuration file. The Web UI (2025) can then send the new merged menu configuration file to the browser 2011. Correspondingly, the browser 2011 can receive the new merged menu configuration file and refresh the webpage based on it, thus promptly presenting the menu items corresponding to the newly added application (such as application F) to the user.

[0097] It should be noted that the above Figure 2 The system architecture shown is merely illustrative and does not constitute a limitation. The methods provided in this application embodiment can also be applied to other architectures, and are not limited to Kubernetes clusters. For example, Figure 5 In the architecture shown, the first device 201 can communicate with the second device 501, and all backend services (such as the Web UI (2025)) can be deployed on the second device 501. For example, the backend can use multiple servers, but these servers do not form a Kubernetes cluster; they can be used for load balancing, reverse proxying, etc. It should also be noted that the above... Figure 3The software structure shown is merely illustrative and does not constitute a limitation. For example, in other embodiments of this application, the Kubernetes cluster may not include services such as HelmMgt (2026) and Docker Registry (2027). The microservice files in the application service package uploaded by the user may directly include the Kubernetes resource files required to deploy the corresponding service. Subsequently, the corresponding service can be deployed directly based on these Kubernetes resource files.

[0098] The following is about Figure 5 The system architecture shown will be further explained.

[0099] like Figure 5 As shown, the system architecture may include a first device 201 and a second device 501. The first device 201 and the second device 501 can communicate (data exchange) with each other. For example, the first device 201 and the second device 501 can communicate with each other through a network.

[0100] It should be noted that the second device 501 can be a laptop computer, desktop computer, server, or other devices. This application embodiment does not impose specific limitations on the second device 501.

[0101] In this embodiment, a user can send an application service package (e.g., the application service package corresponding to application F) to a second device 501 via a first device 201 (e.g., through the browser of the first device), requesting the deployment of the corresponding service. After receiving the application service package from the first device 201, the second device 501 can decompress the application service package to obtain micro-application files, Nginx configuration files, and microservice files, which are then stored locally. Furthermore, the second device 501 can deploy the corresponding microservice based on the microservice files and apply the Nginx configuration file. In addition, the second device 501 can re-merge all currently stored menu configuration files to obtain a new merged menu configuration file. After obtaining the new merged menu configuration file, the second device 501 can send it to the first device 201. Correspondingly, the first device 201 can receive the new merged menu configuration file and then refresh the webpage based on it, thereby promptly presenting the menu items corresponding to the newly added application (e.g., application F) to the user.

[0102] Similar to adding an application, for deleting an application, the second device 501 can, after deleting the corresponding application's menu configuration file, re-merge all currently stored menu configuration files to obtain a new merged menu configuration file. It can also send the new merged menu configuration file to the first device 201. Accordingly, the first device 201 can receive the new merged menu configuration file and then refresh the webpage based on it, thereby promptly hiding or deleting unusable menu items from the webpage.

[0103] Based on the above system architecture, please refer to Figure 6 , Figure 6 This is a flowchart illustrating a display method disclosed in an embodiment of this application. Figure 6 As shown, this is the processing flow for adding a new application in a Kubernetes cluster architecture. This processing flow may include, but is not limited to, the following steps:

[0104] 601. The first device displays a first interface, which includes an address bar.

[0105] Specifically, when a user needs to access a webpage, they can open the browser on the first device, and then the first device can display a first interface. The first interface can be any tab in the browser; this embodiment does not limit this. For example, a user can create a new tab in the browser, and this new tab can be the corresponding first interface.

[0106] 602. The first device receives the user's first action on the address bar and sends a first request to the Web UI.

[0107] To access a webpage, such as the webpage corresponding to the application management sub-function under the system management function of a front-end application, a user can perform a first operation on the address bar of the first interface. Correspondingly, the first device can receive the user's first operation on the address bar of the first interface and can send a first request to the Web UI based on the first operation. The Web UI can then receive the first request from the first device. The first request is used to request a first response resource. In one possible implementation, the first request can be a GET request. A GET request is a type of HTTP request, generally used to request and retrieve data.

[0108] The user's first action on the address bar could be: the user enters the first URL address (e.g., "http: / / 192.168.206.128 / system / manage") in the address bar of the first interface, and then performs an input action on the address bar (e.g., pressing Enter). See reference [link / reference]. Figure 1B The user interface shown.

[0109] 603. The Web UI sends a first response resource to the first device based on the first request. The first response resource includes a second fusion menu configuration file.

[0110] After receiving a first request from the first device, the second device can send a first response resource to the first device based on the first request. Correspondingly, the first device can receive the first response resource from the second device. The first response resource can be the response resource corresponding to a first URL address, specifically including resource files such as HTML files, CSS files, and JS files corresponding to the first URL address, and a second integrated menu configuration file.

[0111] In this embodiment, a main application or sub-application may correspond to one or more menu items, and each menu item may correspond to a name and a URL address. A main application or sub-application may also correspond to a menu configuration file. Each menu configuration file may include the name and URL address corresponding to each menu item of the application. Furthermore, the menu configuration file stores the hierarchical information of each menu item (such as indicating hierarchical information through nesting relationships). This hierarchical information can be used to indicate the hierarchical relationship of a menu item, such as whether the menu item is a first-level menu item, a second-level menu item, or a third-level menu item, etc.

[0112] For example, the menu configuration file of the main application corresponding to the first URL address can be a JSON file, and its specific content can be as follows:

[0113]

[0114]

[0115] The menu configuration file can include an array of "menu" objects. Each "menu" object array can store one or more first-level menu item objects. Each first-level menu item object can correspond to one first-level menu item. A first-level menu item object can also include a "children" field, which stores the corresponding child menu items (second-level menu items). Similarly, second-level menu item objects can also include a "children" field, which stores the corresponding child menu items (third-level menu items). Likewise, third-level, fourth-level, and so on, can also include a "children" field. Furthermore, each menu item object can include a "label" field and a "url" field. The "label" field indicates the name of the corresponding menu item, and the "url" field indicates the URL address of the corresponding menu item. It should be understood that a menu item object can begin with a left curly brace '{' and end with a right curly brace '}'.

[0116] As seen in the menu configuration file of the main application corresponding to the first URL address, the main application corresponding to the first URL address can have a first-level menu item "Home," and the URL address corresponding to this menu item can be " / home." It should be understood that the URL address in the menu configuration file is not a complete URL address, but a relative address, omitting the preceding service method (such as http), the host Internet Protocol (IP) address, or the domain name (sometimes including the port number). In this case, assuming that the service method "http" and the IP address "192.168.206.128" are omitted, the complete URL can be http: / / 192.168.206.128 / home. It should also be understood that when a user clicks on a menu item, it can trigger access to the URL address corresponding to that menu item.

[0117] It should be noted that the aforementioned second integrated menu configuration file is derived from the menu configuration file of the main application corresponding to the first URL address and the menu configuration files of all sub-applications corresponding to that main application. For example, the sub-applications corresponding to this main application include resource sub-applications, device sub-applications, monitoring sub-applications, system management sub-applications, etc. For instance, the specific content of the menu configuration file for the system management sub-application can be as follows:

[0118]

[0119]

[0120] As can be seen, the menu configuration file of the system management sub-application can include a first-level menu item "System Management", the URL address of which can be " / system". Furthermore, the "children" field of the "System Management" menu item object stores corresponding second-level menu item objects, such as "User", "Security", "Upgrade", "System Configuration", "License", and "Application Management". These second-level menu item objects may not include third-level menu item objects.

[0121] When merging different menu configuration files, sub-menu item objects of the same menu item object can be merged. Specifically, second-level menu item objects under the same first-level menu item object in different menu configuration files can be merged, as can third-level menu item objects under the same second-level menu item object. Similarly, fourth-level menu item objects under the same third-level menu item object can be merged, as can fifth-level menu item objects under the same fourth-level menu item object, and so on. For example, the menu configuration file of the main application and the menu configuration file of the system management sub-application, as shown above, can be merged to obtain the following merged menu configuration file:

[0122]

[0123]

[0124] As can be seen, the menu configuration file of the main application includes a "Home" first-level menu item object, and the menu configuration file of the system management sub-application includes a "System Management" first-level menu item object. These two first-level menu item objects can then be stored in the merged menu configuration file. Similarly, based on this, the menu configuration files of the resource sub-application, device sub-application, and monitoring sub-application can be merged to obtain a second merged menu configuration file.

[0125] 604. The first device displays a second interface based on the first response resource, the second interface including one or more menu items.

[0126] After receiving the first response resource from the Web UI, the first device can display a second interface based on the first response resource. Specifically, the first device can parse the first response resource using its browser engine (parse the HTML, CSS, JS, and other resource files and the second integrated menu configuration file within the first response resource), and can display the second interface based on the parsing results. The second interface may include one or more menu items, and the first interface can be referenced... Figure 1B The user interface 102 shown.

[0127] It is understandable that the content display on the webpage is primarily based on HTML files, which can embed or reference CSS files, JS files, etc. The JS file may include JS code that parses the second merged menu configuration file. This JS code can parse the second merged menu configuration file so that the corresponding area in the second interface can display the corresponding menu items. It should be noted that after the JS code parses the second merged menu configuration file, it can obtain the names and corresponding URLs of all menu items stored in the second merged menu configuration file. However, the menu items displayed in the second interface may be a subset or all of these menu items; the specific display depends on the processing logic of the JS code, and this application embodiment does not specifically limit this. Furthermore, for different URL addresses, the JS files in the corresponding response resources may be different. That is, the processing logic of the JS code in the response resources corresponding to different URL addresses may be different, thereby presenting different menu item displays.

[0128] In one possible implementation, steps 601-603 may be omitted, and the user can directly access an application software in the first device to make the first device display the second interface.

[0129] 605. The first device sends a first installation request to the Web UI, the first installation request including the application service package of the first application.

[0130] In this embodiment, dynamically adding sub-applications is supported. Therefore, when a user needs to add a sub-application to the main application corresponding to the first URL address, a first installation request can be sent to the Web UI. The first installation request may include the application service package of the first application, i.e., the application service package of the sub-application to be added. The application service package of the first application can be a compressed file, specifically including the micro-application file, micro-service file, Nginx configuration file, menu configuration file, etc., corresponding to the first application. For example, ... Figure 1B , Figure 1C As shown, users can add sub-applications to a webpage using the corresponding import application control.

[0131] It is understood that the above describes sending the first installation request to the Web UI through the first device, but this application does not limit this, and other devices besides the first device can also send the first installation request to the Web UI.

[0132] 606. The Web UI sends the first installation request to Helm Mgt.

[0133] After receiving the first installation request from the first device, the Web UI can send the first installation request to the Helm Mgt. Correspondingly, the Helm Mgt can receive the first installation request from the Web UI.

[0134] 607. Helm Mgt decompresses the application service package of the first application, which will give you the corresponding micro-application files, Nginx configuration files, microservice files, and menu configuration files.

[0135] After receiving the first installation request from the Web UI, Helm Mgt can decompress the application service package of the first application carried in the first installation request, obtaining the corresponding micro-application files, Nginx configuration files, microservice files, menu configuration files, etc. Furthermore, the micro-application files, Nginx configuration files, and menu configuration files can be stored in the corresponding target directory. In this embodiment, both Helm Mgt and the Web UI can be mounted to this target directory.

[0136] The micro-application files corresponding to the first application can include resource files such as HTML, CSS, and JS files related to the URLs corresponding to the menu items of the first application. For example, assuming the first application includes menu item 1 and menu item 2, and the URLs corresponding to menu item 1 and menu item 2 are address 1 and address 2 respectively, the micro-application files corresponding to the first application can include resource files such as HTML, CSS, and JS files related to address 1 and address 2. These resource files can be used to display the web pages corresponding to address 1 and address 2. The Nginx configuration file corresponding to the first application can include HTTP configuration, routing configuration, etc., related to the first application. The microservice files corresponding to the first application can be used to deploy the microservices corresponding to the first application. For example, the microservices corresponding to the first application can include microservice 1 and microservice 2. In this case, the microservice files corresponding to the first application can include microservice files for deploying microservice 1 (such as the chart package corresponding to microservice 1) and microservice files for deploying microservice 2 (such as the chart package corresponding to microservice 2). The menu configuration file corresponding to the first application includes the menu items of the first application and the URL address corresponding to each menu item. For example, assuming that for the first application, menu item 1 is a fault prediction menu item and menu item 2 is a resource usage monitoring menu item, then microservice 1 can be the microservice corresponding to menu item 1, which can be used to provide fault prediction functionality. For example, microservice 1 can collect various status information of the server in real time (such as temperature information, humidity information, etc.), and then perform fault prediction based on this status information, and can return the fault prediction results to the front end for display, so as to remind the user to take precautions in advance. As another example, microservice 2 can be the microservice corresponding to menu item 2, which can be used for resource usage monitoring functionality. For example, microservice 2 can collect various resource usage data of the server in real time (such as CPU utilization, memory utilization, disk space remaining, etc.), and can return this collected resource usage data to the front end for display, so that the user can understand the server's resource usage status. It should be understood that the above description of the microservices and menu items corresponding to the first application is only an illustrative example and does not constitute a limitation.

[0137] 608. The Web UI uses the Nginx configuration file corresponding to the first application.

[0138] After Helm Mgt decompresses the application service package of the first application and saves the Nginx configuration file corresponding to the first application into the target directory, in order for the URL address corresponding to the first application to be successfully accessed, the Web UI can use the Nginx configuration file corresponding to the first application. That is, the Web UI can use the HTTP configuration, routing configuration, etc. related to the first application to make the HTTP configuration, routing configuration, etc. related to the first application effective.

[0139] 609. Helm Mgt deploys microservices based on the microservice files corresponding to the first application.

[0140] After Helm Mgt decompresses the application service package of the first application to obtain the microservice file corresponding to the first application, Helm Mgt can deploy the corresponding microservice based on the microservice file. For example, assuming that the microservice file corresponding to the first application may include a microservice file for deploying microservice 1, Helm Mgt can deploy microservice 1 to the Kubernetes cluster. In this embodiment, the microservice file corresponding to microservice 1 can be either a chart package or a values ​​file. If the microservice file corresponding to microservice 1 is a chart package, Helm Mgt can directly send a deployment request to the API Server, which can carry the chart package corresponding to microservice 1. Then, the API Server can deploy microservice 1 to the Kubernetes cluster based on the chart package corresponding to microservice 1. Furthermore, Helm Mgt can push the chart package corresponding to microservice 1 to the Docker Registry. If the microservice file corresponding to microservice 1 is the values ​​file for microservice 1, excluding the complete Kubernetes resource files required for deploying microservice 1, Helm Mgt can pull the chart package corresponding to microservice 1 from the Docker Registry. For example, the application service package of the first application can also include an identifier for the chart package corresponding to microservice 1, such as the chart package name or index, etc. Helm Mgt can pull the chart package corresponding to microservice 1 from the Docker Registry based on this identifier. This chart package may include template resource files. Then, Helm Mgt can send a deployment request to the API Server, which can include the pulled chart package and the values ​​file corresponding to microservice 1. The API Server can then deploy microservice 1 to the Kubernetes cluster based on the values ​​file and the chart package.

[0141] 610. The Web UI re-integrates all menu configuration files in the target directory to obtain the first integrated menu configuration file.

[0142] Because a first application has been added, in order to display the menu items of the first application in the user interface, the Web UI can re-merge all menu configuration files in the target directory. In other words, the Web UI can re-merge the menu configuration file of the main application corresponding to the first URL address with the menu configuration files of all its sub-applications to obtain a first merged menu configuration file.

[0143] For example, the first application can be application A, and the menu configuration file of application A can be as follows:

[0144]

[0145]

[0146] As can be seen, the menu configuration file for application A can include a first-level menu item "Application A", whose corresponding URL address can be " / app-A". Furthermore, the "children" field of the "Application A" menu item object stores the corresponding second-level menu item objects. In addition, a menu item corresponding to application A can also be a second-level menu item under the "System Management" menu item. Accordingly, the "children" field of the "System Management" menu item object can include the second-level menu item object corresponding to that second-level menu item, that is, {"label":"a menu item of application A", "url":" / app-A / menu-A",}.

[0147] It should be noted that, since each menu item object can include a corresponding menu item name and URL address, in this embodiment, a menu item object corresponding to one application can be flexibly configured in the "children" field of a menu item object corresponding to another application. That is, a menu item corresponding to one application can be a parent menu item of a menu item corresponding to another application. For example, the "System Management" menu item of the aforementioned System Management sub-application can be a parent menu item of the "A Menu Item of Application A" menu item of application A.

[0148] The first fusion menu configuration file can be shown as follows:

[0149]

[0150]

[0151] As can be seen, the first integrated menu configuration file includes a first-level menu item corresponding to application A, and a menu item of application A can be used as a second-level menu item under the "System Management" menu item. This greatly improves the flexibility of menu item configuration.

[0152] It is understood that the above processing flow involves re-merging all menu configuration files in the target directory to obtain the first merged menu configuration file. However, this application embodiment does not limit the method of obtaining the first merged menu configuration file. For example, in one possible implementation, the first merged menu configuration file and the menu configuration file of the first application can be merged to obtain the first merged menu configuration file.

[0153] In one possible implementation, each sub-application's menu configuration file can have a corresponding timestamp. This timestamp can be the time when the corresponding application service package is decoded to obtain the application's menu configuration file, or it can be the time when the corresponding application service package is received. In this case, when merging the menu configuration files, if all menu configuration files in the target directory are being merged again, they can be merged sequentially in ascending order of their timestamps. For example, assuming the configuration files include menu configuration file 1 (the main application's menu configuration file), menu configuration file 2, and menu configuration file 3, with menu configuration file 2 having a timestamp of "2011 / 11 / 12 12:24:25" and menu configuration file 3 having a timestamp of "2011 / 11 / 12 12:55:25", menu configuration file 1 and menu configuration file 2 can be merged first to obtain a merged menu configuration file corresponding to menu configuration file 1 and menu configuration file 2. Then, menu configuration file 3 can be merged with this merged menu configuration file to obtain the final first merged menu configuration file.

[0154] It should be noted that, in this embodiment, the execution order of steps 608 and 609 is not limited. Steps 608 and 609 can be executed in parallel with steps 610 or 611, or they can be executed sequentially with steps 610 or 611. Furthermore, when executed sequentially, the execution order of steps 608, 609, and 610 / 611 is not limited. Step 608 can be executed first, followed by step 609, and then steps 610 / 611; alternatively, step 609 can be executed first, followed by step 608, and then steps 610 / 611.

[0155] 611. The Web UI sends the first merge menu configuration file to the first device.

[0156] Specifically, in one possible implementation, the first device can first determine whether the latest merged menu configuration file is the same as the currently used merged menu configuration file. If they are the same, no processing is required; otherwise, the page can be displayed based on the latest merged menu configuration file. For example, the first device can periodically request the latest merged menu configuration file from the Web UI, and then compare the latest merged menu configuration file with the currently used one. If they are the same, no processing is required; otherwise, the page can be displayed based on the latest merged menu configuration file. As another example, each merged menu configuration file can include a corresponding timestamp to indicate its generation time. In this case, the first device can periodically request the timestamp of the latest merged menu configuration file from the Web UI, and then compare the timestamp of the latest merged menu configuration file with the timestamp of the currently used one. If they are the same, no processing is required; otherwise, the page can be displayed based on the latest merged menu configuration file. This method of determining whether the merged menu configuration file has been updated based on its timestamp can reduce the amount of data transmitted each time, thereby saving transmission resources.

[0157] In another possible implementation, after the Web UI generates the first merged menu configuration file, it can directly send the configuration file to the first device. The first device can then directly display the page based on the first merged menu configuration file.

[0158] 612. The first device switches the second interface to a third interface based on the first fusion menu configuration file. The third interface includes one or more menu items, and the third interface includes different menu items than the second interface.

[0159] After receiving the first fusion menu configuration file, the first device can refresh the second interface based on the first fusion menu configuration file to display the menu items corresponding to the first application in the user interface, thereby displaying a third interface. The third interface may include one or more menu items, and the third interface includes different menu items than the second interface.

[0160] It should be noted that, in one possible implementation, the menu configuration file may also include other information. For example, an application's menu configuration file may also include the API version information and website application information (such as the website title). The API version information can indicate the software development kit (SDK) version used by the application, and the website application information can indicate the name of the current website. As another example, an application's menu configuration file may also include a display flag for each menu item, indicating whether the menu item is displayed in the user interface. For instance, each menu item object may include a "show" field, where a value of "true" indicates that the menu item can be displayed, and a value of "false" indicates that the menu item is not displayed. Furthermore, an application's menu configuration file may also include access permissions for each menu item, indicating which users or user groups can access the menu item. In one possible implementation, if the currently logged-in user does not have access permissions for a particular menu item, that menu item may not be displayed in the user interface. In other words, the user interface can display menu items that the currently logged-in user has access to, instead of displaying menu items that the currently logged-in user does not have access to.

[0161] It should be noted that when the menu configuration file includes API version information, when adding a sub-application later, you can first check whether the SDK version of the sub-application matches the SDK version of the main application. If they do not match, the sub-application cannot be added and no processing is required. If they match, the sub-application can be added, and you can then merge the menu configuration files and deploy the corresponding microservices for the sub-application.

[0162] It should be noted that the menu configuration file mentioned above directly displays the corresponding menu item name, such as the "Home" menu item. However, to meet the needs of different users, a menu item can have names in multiple languages. For example, the "Home" menu item can have both the Chinese name "Home" and the English name "home". In this case, the menu item can be displayed based on the user's selected language. If the user selects Chinese, "Home" can be displayed; if the user selects English, "home" can be displayed.

[0163] It is understood that this application embodiment does not impose specific limitations on the display order of multiple first-level menu items (such as Home, Resources, Devices, Monitoring, etc.) or the display order of multiple sub-menu items under a certain menu item (such as multiple second-level menu items under the System Management menu item). For example, these menu items can be displayed according to the storage order in the integrated menu configuration file, or, in one possible implementation, each menu item can be assigned an ID, and then displayed in ascending order of ID.

[0164] It should be understood that in this embodiment, each menu item can correspond to a URL address. However, whether the display of menu items on a webpage corresponding to a URL address is based on the fusion menu configuration file depends on the HTML file corresponding to that URL address. If the HTML file corresponding to the URL address includes a script program for parsing the fusion menu configuration file (e.g., a JS or TS file for parsing the fusion menu configuration file is included), and the display of the webpage is defined based on the parsing result, then the menu items on the webpage can be displayed based on the fusion menu configuration file. If the HTML file corresponding to the URL address does not include a script program for parsing the fusion menu configuration file, then the display of menu items on the webpage does not need to be based on the fusion menu configuration file.

[0165] It should also be understood that, in this embodiment of the application, since the display of menu items on the webpage is controlled by a fusion menu configuration file, in actual situations, when the basic functions developed by the software vendor cannot meet the user's needs, the user can develop or open-source the relevant function-related micro-application files, micro-service files, Nginx configuration files, etc., and provide the corresponding menu configuration file. Then, the menu configuration files can be fused again to obtain a new fusion menu configuration file, and the page can be refreshed and displayed based on the new fusion menu configuration file.

[0166] The above processing flow supports dynamically adding sub-applications. Furthermore, a first unified menu configuration file can be generated based on the menu configuration file of the newly added sub-application, and the menu items corresponding to the newly added sub-application can be presented to the user in a timely manner based on the first unified menu configuration file. Moreover, this method does not require changes to other code files (such as HTML files or currently running microservice files), thus improving the development and deployment efficiency of new applications. In addition, with this method, if a new application needs to be added, only the corresponding micro-application file, microservice file, menu configuration file, and Nginx configuration file need to be provided, offering strong scalability. Therefore, users can develop corresponding sub-applications according to their actual needs.

[0167] Based on the above system architecture, please refer to Figure 7, Figure 7 This is a flowchart illustrating another display method disclosed in an embodiment of this application. Figure 7 As shown, this is the process for deleting an application in a Kubernetes cluster architecture. This process may include, but is not limited to, the following steps:

[0168] 701. The first device displays a first interface, which includes an address bar.

[0169] Step 701 is the same as step 601, and you can refer to the relevant description in step 601 above.

[0170] 702. The first device receives the user's first action on the address bar and sends the first request to the Web UI.

[0171] Step 702 is the same as step 602, and you can refer to the relevant description in step 602 above.

[0172] 703. The Web UI sends a first response resource to the first device based on the first request. The first response resource includes a second fusion menu configuration file.

[0173] Step 703 is similar to step 603, and you can refer to the relevant description in step 603 above.

[0174] 704. The first device displays a second interface based on the first response resource, the second interface including one or more menu items.

[0175] Step 704 is similar to step 604, and you can refer to the relevant description in step 604 above.

[0176] 705. The first device sends a first deletion request to the Web UI, the first deletion request including the identifier of the first application.

[0177] In this embodiment, dynamic deletion of sub-applications can be supported. Therefore, when a user needs to delete the first sub-application of the main application corresponding to the first URL address, a first deletion request can be sent to the Web UI. The first deletion request may include the identifier of the application to be deleted, such as the identifier of the first application. It should be understood that the identifier of the first application can be used to identify the first application.

[0178] It is understood that the above describes sending the first deletion request to the Web UI via the first device. However, this application does not limit this, and other devices besides the first device can also send the first deletion request to the Web UI. For example, such as... Figure 1F As shown, users can delete a sub-application by clicking the delete control corresponding to the sub-application.

[0179] 706. The Web UI sends the first delete request to Helm Mgt.

[0180] After receiving the first deletion request from the first device, the Web UI can send the first deletion request to the Helm Mgt. Correspondingly, the Helm Mgt can receive the first deletion request from the Web UI.

[0181] 707.Helm Mgt deletes the menu configuration file of the first application.

[0182] After receiving the first deletion request from the Web UI, Helm Mgt can delete the menu configuration file of the first application in the target directory based on the identifier of the first application carried in the first deletion request. In addition, Helm Mgt can also delete other files related to the first application in the target directory, such as other files in the first application's micro-application files.

[0183] 708. Modify Nginx configuration in the Web UI.

[0184] The Web UI can modify the Nginx configuration based on the identifier of the first application carried in the first deletion request, that is, delete the Nginx configuration previously used for the first application. For example, the Web UI can determine the first application based on the identifier of the first application carried in the first deletion request, and then delete the Nginx configuration previously used for the first application.

[0185] 709. Helm Mgt shuts down the microservice corresponding to the first application.

[0186] Helm Mgt can shut down the microservice corresponding to a previously deployed first application based on the identifier of the first application carried in the first deletion request. For example, Helm Mgt can determine the first application based on the identifier of the first application carried in the first deletion request, and then shut down the microservice corresponding to the previously deployed first application.

[0187] 710. The Web UI re-integrates all menu configuration files in the target directory to obtain the first integrated menu configuration file.

[0188] Since the menu configuration file of the first application stored in the target directory has been deleted, in order to remove the menu items of the first application in the user interface, the Web UI can re-merge based on all menu configuration files in the target directory. That is, the Web UI can re-merge the menu configuration file of the main application corresponding to the first URL address and the menu configuration files of all sub-applications corresponding to that main application to obtain a first merged menu configuration file. For details on merging the merged menu configuration files, please refer to the relevant description in step 610 above; it will not be elaborated upon here.

[0189] It is understood that the above processing flow involves re-merging all menu configuration files in the target directory to obtain the first merged menu configuration file. However, this application embodiment does not limit the method of obtaining the first merged menu configuration file. For example, in one possible implementation, the content corresponding to the menu configuration file of the first application can be deleted from the second merged menu configuration file to obtain the first merged menu configuration file.

[0190] It should be noted that, in this embodiment, the execution order of steps 708, 709, and 610 is not limited. Steps 708, 709, and 710 can be executed in parallel or sequentially. Furthermore, when executed sequentially, the execution order of steps 708, 709, and 710 is not limited; step 708 can be executed first, followed by step 709, and then step 710, or step 709 can be executed first, followed by step 708, and then step 710.

[0191] 711. The Web UI sends the first merge menu configuration file to the first device.

[0192] Step 711 is similar to step 611, and you can refer to the relevant description in step 611.

[0193] 712. The first device switches the second interface to a third interface based on the first fusion menu configuration file. The third interface includes one or more menu items, and the third interface includes different menu items than the second interface.

[0194] After receiving the first fusion menu configuration file, the first device can refresh the second interface based on the first fusion menu configuration file to remove the menu item corresponding to the first application from the user interface, thereby displaying a third interface. The third interface may include one or more menu items, and the third interface includes different menu items than the second interface.

[0195] The above Figure 6 and Figure 7 The corresponding embodiments describe the processing flow for adding and deleting applications. In addition to these two cases, there may also be cases where applications are modified. For cases where applications are modified, the micro-application files, menu configuration files, etc., corresponding to the original application can be deleted first, and the microservices corresponding to the original application can be shut down. Then, the microservices can be deployed based on the new microservice files corresponding to the original application. Furthermore, a new merged menu configuration file can be obtained based on the new menu configuration file corresponding to the original application to facilitate the refresh and display of the webpage.

[0196] Based on the above Figure 5 Please refer to the system architecture shown. Figure 8 , Figure 8This is a flowchart illustrating another display method disclosed in an embodiment of this application. For example... Figure 8 As shown, the processing flow may include, but is not limited to, the following steps:

[0197] 801. The first device displays a first interface, which includes an address bar.

[0198] Step 801 is the same as step 601, and you can refer to the relevant description in step 601 above.

[0199] 802. The first device receives the user's first operation on the address bar and sends a first request to the second device.

[0200] Step 802 is similar to step 602, and you can refer to the relevant description in step 602 above.

[0201] 803. The second device sends a first response resource to the first device based on the first request, the first response resource including a second fusion menu configuration file.

[0202] Step 803 is similar to step 603, and you can refer to the relevant description in step 603 above.

[0203] 804. The first device displays a second interface based on the first response resource, the second interface including one or more menu items.

[0204] Step 804 is similar to step 604, and you can refer to the relevant description in step 604 above.

[0205] 805. The first device sends a first installation request to the second device, the first installation request including the application service package of the first application.

[0206] Step 805 is similar to step 605, and you can refer to the relevant description in step 605 above.

[0207] 806. The second device decompresses the application service package of the first application to obtain the micro-application file, Nginx configuration file, microservice file, and menu configuration file corresponding to the first application.

[0208] After receiving the first installation request from the first device, the second device can decompress the application service package of the first application carried in the first installation request, and obtain the micro-application file, Nginx configuration file, microservice file, and menu configuration file corresponding to the first application. The second device can then store the micro-application file, Nginx configuration file, and menu configuration file corresponding to the first application in the target directory.

[0209] Step 806 is similar to step 607, and you can refer to the relevant description in step 607 above.

[0210] 807. The second device uses the Nginx configuration file corresponding to the first application.

[0211] Step 807 is similar to step 608, and you can refer to the relevant description in step 608 above.

[0212] 808. The second device deploys microservices based on the microservice files corresponding to the first application.

[0213] Step 808 is similar to step 609, and you can refer to the relevant description in step 609 above.

[0214] 809. The second device re-merges all menu configuration files in the target directory to obtain the first merged menu configuration file.

[0215] Step 809 is similar to step 610, and you can refer to the relevant description in step 610 above.

[0216] 810. The second device sends the first fusion menu configuration file to the first device.

[0217] Step 810 is similar to step 611, and you can refer to the relevant description in step 611 above.

[0218] 811. The first device switches the second interface to a third interface based on the first fusion menu configuration file. The third interface includes one or more menu items, and the third interface includes different menu items than the second interface.

[0219] Step 811 is similar to step 612, and you can refer to the relevant description in step 612 above.

[0220] Based on the above Figure 5 Please refer to the system architecture shown. Figure 9 , Figure 9 This is a flowchart illustrating another display method disclosed in an embodiment of this application. For example... Figure 9 As shown, the processing flow may include, but is not limited to, the following steps:

[0221] 901. The first device displays the first interface, which includes an address bar.

[0222] Step 901 is the same as step 601, and you can refer to the relevant description in step 601 above.

[0223] 902. The first device receives the user's first operation on the address bar and sends a first request to the second device.

[0224] Step 902 is similar to step 602, and you can refer to the relevant description in step 602 above.

[0225] 903. The second device sends a first response resource to the first device based on the first request, the first response resource including a second fusion menu configuration file.

[0226] Step 903 is similar to step 603, and you can refer to the relevant description in step 603 above.

[0227] 904. The first device displays a second interface based on the first response resource, the second interface including one or more menu items.

[0228] Step 904 is similar to step 604, and you can refer to the relevant description in step 604 above.

[0229] 905. The first device sends a first deletion request to the second device, the first deletion request including the identifier of the first application.

[0230] Step 905 is similar to step 705, and you can refer to the relevant description in step 705 above.

[0231] 906. The second device deletes the menu configuration file of the first application.

[0232] After receiving a first deletion request from the first device, the second device can delete the menu configuration file of the first application in the target directory based on the identifier of the first application carried in the first deletion request. In addition, the second device can also delete other files related to the first application in the target directory, such as other files in the first application's micro-application files.

[0233] 907. Modify the Nginx configuration on the second device.

[0234] Step 907 is similar to step 708, and you can refer to the relevant description in step 708 above.

[0235] 908. The second device shuts down the microservice corresponding to the first application.

[0236] Step 908 is similar to step 709, and you can refer to the relevant description in step 709 above.

[0237] 909. The second device re-merges all menu configuration files in the target directory to obtain the first merged menu configuration file.

[0238] Step 909 is similar to step 710, and you can refer to the relevant description in step 710 above.

[0239] 910. The second device sends the first fusion menu configuration file to the first device.

[0240] Step 910 is similar to step 611, and you can refer to the relevant description in step 611.

[0241] 911. The first device switches the second interface to a third interface based on the first fusion menu configuration file. The third interface includes one or more menu items, and the third interface includes different menu items than the second interface.

[0242] Step 911 is similar to step 712, and you can refer to the relevant description in step 712 above.

[0243] Based on the above system architecture, please refer to Figure 10 , Figure 10 This is a flowchart illustrating another display method disclosed in an embodiment of this application. For example... Figure 10 As shown, the processing flow may include, but is not limited to, the following steps:

[0244] 1001. The first device displays a first interface, which includes one or more menu items.

[0245] A main application or sub-application can have one or more menu items, each with a name and a URL. A menu item can be used to access the main application or its corresponding sub-application. For example, a menu item corresponding to the main application can be used to access the main application, such as accessing a specific function within it. Similarly, a menu item corresponding to a sub-application can be used to access the sub-application, such as accessing a specific function within it.

[0246] In one possible implementation, the first device can send a first request to a first URL address to a second device or a Web UI, and then receive a first response resource from the second device or the Web UI. This first response resource may include an HTML file, a script file (such as a JS file, TS file, etc.) corresponding to the first URL address, and a second merged menu configuration file. The first device can then parse the second merged menu configuration file using the script file corresponding to the first URL address to obtain menu item information for each application included in the second merged menu configuration file. Afterwards, the first device can display a first interface based on the menu item information for each application and the HTML file corresponding to the first URL address.

[0247] 1002. During the operation of the main application or sub-application, if there is a user's change operation on the sub-application, the first device obtains the first fusion menu configuration file.

[0248] In this embodiment, during the operation of the main application or sub-application, the user can dynamically add sub-applications to the main application, delete existing sub-applications, and modify existing sub-applications. Therefore, in order to promptly display new menu items or delete unusable menu items in the user interface, the first device can obtain a first fusion menu configuration file when adding or deleting sub-applications, so that the user interface can be refreshed based on the first fusion menu configuration file.

[0249] The first integrated menu configuration file can be generated based on the main application's menu configuration file and the menu configuration files of the corresponding sub-applications. An application's menu configuration file can include the menu item information of the corresponding application. The menu item information of an application can include the name of each menu item of the corresponding application and its corresponding hierarchical relationship, and can also include the URL address of each menu item of the corresponding application.

[0250] For example, the first interface may include import application controls, such as... Figure 1B As shown. When a new sub-application needs to be added, the first device can receive the user's first operation on the imported application control. In response to this first operation, the application service package of the sub-application can be selected, that is, the application to be added can be selected (as described above). Figure 6 The first application in the illustrated embodiment is an application service package, which can send a first installation request to a second device or a Web UI. The first installation request may include the application service package of the selected sub-application, which may include the corresponding micro-application file, micro-service file, Nginx configuration file, menu configuration file, etc.

[0251] For example, the first interface may also include a delete control for each sub-application. When a sub-application needs to be deleted, the first device may receive a second operation from the user on the delete control for a specific sub-application. In response to the second operation, the first device may send a first delete request to the second device or the Web UI. The first delete request may include the identifier of the sub-application, that is, the identifier of the sub-application to be deleted.

[0252] In one possible implementation, each merge menu profile may include a corresponding timestamp, which can be used to indicate when a new merge menu profile is regenerated when a user makes changes to a sub-application. Therefore, the first device can periodically obtain the timestamp of the latest merge menu profile. If the timestamp of the latest merge menu profile is compared with the timestamp of the currently used merge menu profile, and they are the same, it indicates that the merge menu profile has not been updated and no action is needed. If they are different, it indicates that the merge menu profile has been updated, and the page can be displayed based on the latest merge menu profile.

[0253] 1003. The first device switches the first interface to a second interface based on the first fusion menu configuration file. The second interface includes one or more menu items, and the menu items of the first interface and the second interface are different.

[0254] After receiving the first fusion menu configuration file, the first device can switch the first interface to a second interface based on the configuration file, so as to promptly present new menu items or delete unusable menu items in the user interface. The second interface may include one or more menu items, and the menu items of the first interface and the second interface are different; that is, the first interface and the second interface may include different menu items.

[0255] Based on the above system architecture, please refer to Figure 11 , Figure 11 This is a flowchart illustrating another display method disclosed in an embodiment of this application. For example... Figure 11 As shown, the processing flow may include, but is not limited to, the following steps:

[0256] 1101. In the event of user changes to the sub-application corresponding to the main application, a first merged menu configuration file is generated based on the menu configuration file of the main application and the menu configuration file of the sub-application.

[0257] An application's menu configuration file can include information about the menu items of the application. This information can include the name of each menu item and its corresponding hierarchy, as well as the URL of each menu item.

[0258] In this embodiment, when there are user changes to the sub-applications, such as adding, deleting, or modifying sub-applications, the merged menu configuration file can be regenerated. For example, the second device or Web UI can regenerate the first merged menu configuration file based on the main application's menu configuration file and the menu configuration files of the corresponding sub-applications.

[0259] It should be understood that, in the embodiments of this application, the menu item information of an application may include one or more menu item objects. A menu item object may correspond to a menu item of the application, and a menu item object may include the name and address of the corresponding menu item. If the menu item includes corresponding sub-menu items, then the menu item object may also include the sub-menu item objects corresponding to the menu item object. For example, sub-menu item objects can be nested through the "children" field.

[0260] In one possible implementation, the second device or Web UI can merge the sub-menu item objects belonging to the same menu item object in the main application's menu configuration file and the sub-application's menu configuration file to generate a first merged menu configuration file.

[0261] For example, when adding a sub-application, the second device or Web UI can receive a first installation request from the first device. This first installation request may include the application service package of the sub-application to be added, such as the application service package of the first application. The application service package of the first application may include the menu configuration file corresponding to the first application. Then, the second device or Web UI can generate a first merged menu configuration file based on the menu configuration file corresponding to the first application, as well as the menu configuration files of the main application and the sub-applications corresponding to the main application. In other words, the second device or Web UI can generate a first merged menu configuration file based on the menu configuration file of the current main application and the menu configuration files of the sub-applications (including the first application) corresponding to the main application.

[0262] For example, when deleting a sub-application, the second device or Web UI can receive a first deletion request from the first device. This first deletion request may include the identifier of the sub-application to be deleted, such as the identifier of the first application. Then, the second device or Kubernetes cluster (such as the Web UI, Helm Mgt, etc.) can delete the first application's menu configuration file, microservice files, Nginx configuration files, etc. Afterward, the second device or Web UI can generate a first merged menu configuration file based on the main application's menu configuration file and the menu configuration files of the corresponding sub-applications. In this case, the sub-applications corresponding to the main application do not include the first application. That is, the second device or Web UI can generate a first merged menu configuration file based on the current main application's menu configuration file and the menu configuration files of the corresponding sub-applications (excluding the first application).

[0263] 1102. Send a first fusion menu configuration file to the first device. The first fusion menu configuration file is used to switch the first interface to be displayed as the second interface. The first interface includes one or more menu items, and the second interface includes one or more menu items. The menu items of the first interface and the second interface are different.

[0264] After the second device or Web UI generates the first merged menu configuration file, it can send the first merged menu configuration file to the first device so that the first device can dynamically refresh the page display, present new menu items in the user interface, or delete unavailable menu items.

[0265] It should be noted that the relevant information (i.e., the same or similar information) and related descriptions in the different embodiments described above can be referenced from each other.

[0266] It should be understood that the above Figure 6 , Figure 7 The above processing flow is illustrated using examples such as the first device, Web UI, and Helm Mgt as the execution entities for the interaction illustration, but this application does not limit the execution entities for this interaction illustration. For example, Figure 6 , Figure 7 The first device in the process can also be a chip, chip system, etc. that supports the implementation of the method by the first device, or a logic module or software (such as a browser) that can implement all or part of the functions of the first device. Figure 6 , Figure 7 The Web UI in the text can also be a chip, chip system, electronic device, etc. that supports the implementation of this method by the Web UI.

[0267] It should also be understood that the above Figure 8 , Figure 9 The above processing flow is illustrated using the first and second devices as examples of the execution entities in the interaction illustration, but this application does not limit the execution entities of this interaction illustration. For example, Figure 8 , Figure 9 The first device in the process can also be a chip, chip system, etc. that supports the implementation of the method by the first device, or a logic module or software that can implement all or part of the functions of the first device. Figure 8 , Figure 9 The second device can also be a chip, chip system, etc. that supports the implementation of the method, or a logic module or software that can implement all or part of the functions of the second device.

[0268] Based on the above system architecture, please refer to Figure 12 , Figure 12This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. The electronic device 1200 may include a processor 1201, a communication interface 1202, and a memory 1203. The processor 1201, communication interface 1202, and memory 1203 may be interconnected or interconnected via a bus 1204.

[0269] For example, memory 1203 is used to store computer programs and data of electronic device 1200. Memory 1203 may include, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM). Communication interface 1202 is used to support electronic device 1200 in communication, such as receiving or sending data.

[0270] For example, processor 1201 may be a central processing unit (CPU), a complex programmable logic device, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A processor may also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, etc.

[0271] In one embodiment, the electronic device 1200 can be the first device described above, and the processor 1201 can be used to read the program stored in the memory 1203 and execute the above-mentioned program. Figure 6 , Figure 7 , Figure 8 , Figure 9 , Figure 10 or Figure 11 The operations performed by the first device or components in the first device in the method embodiments shown can be referred to the above-mentioned descriptions, and will not be repeated in detail here.

[0272] In one embodiment, the electronic device 1200 may run components such as the aforementioned Web UI or Helm Mgt, and the processor 1201 may be used to read the program stored in the aforementioned memory 1203 and execute the aforementioned... Figure 7 , Figure 8 , Figure 10 or Figure 11The operations performed by components such as Web UI or Helm Mgt in the method embodiments shown can be referred to the relevant descriptions above, and will not be repeated in detail here.

[0273] In one embodiment, the electronic device 1200 can be the second device described above, and the processor 1201 can be used to read the program stored in the memory 1203 and execute the above-mentioned program. Figure 8 , Figure 9 , Figure 10 or Figure 11 The operations performed by the second device or components in the second device in the method embodiments shown can be referred to the above-mentioned descriptions, and will not be repeated in detail here.

[0274] It should be noted that, Figure 12 The electronic device 1200 shown is merely one implementation of the embodiments of this application. In actual applications, the electronic device 1200 may include more or fewer components, which is not limited here.

[0275] This application also discloses a computer-readable storage medium storing instructions thereon, which, when executed, perform the methods described in the above method embodiments.

[0276] This application also discloses a computer program product including instructions that, when executed, perform the methods described in the above method embodiments.

[0277] Obviously, the embodiments described above are only some embodiments of this application, and not all embodiments. The term "embodiment" as used herein means that a specific feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily indicate the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand, explicitly and implicitly, that the embodiments described herein can be combined with other embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application. The terms "first," "second," "third," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects and are not used to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, it may include a series of steps or units, or optionally, steps or units not listed, or optionally other steps or units inherent to these processes, methods, products, or devices. It is understandable that the equal sign in the above conditional judgment can be either greater than or less than one side. For example, the above conditional judgment of a threshold being greater than, less than, or equal to can also be changed to a conditional judgment of the threshold being greater than or equal to, or less than. This is not limited here.

[0278] It is understood that the accompanying drawings show only the parts relevant to this application and not all of them. It should be understood that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0279] The terms “component,” “module,” “system,” “unit,” etc., used in this specification are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a unit can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, and / or distributed between two or more computers. Furthermore, these units can be executed from various computer-readable media on which various data structures are stored. Units can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from a second unit interacting with another unit between a local system, a distributed system, and / or a network; for example, the Internet interacting with other systems via signals).

[0280] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A display method, characterized in that, The method is applied to a first device, and the method includes: Display a first interface, which includes one or more menu items, the menu items being used to access the main application or a sub-application corresponding to the main application; During the operation of the main application or the sub-application, if a user makes a change to the sub-application, a first integrated menu configuration file is obtained. This first integrated menu configuration file is generated based on the main application's menu configuration file and the sub-application's menu configuration file. The main application's or sub-application's menu configuration file includes menu item information for the corresponding application, including the name of each menu item and its corresponding hierarchical relationship. The sub-application is an extended application nested within the main application's content area. The sub-application includes a corresponding microservice file, a micro-application file, and a menu configuration file. The micro-application file and the microservice file are decoupled. Based on the first fusion menu configuration file, the first interface is switched to display as the second interface, which includes one or more menu items. The menu items of the first interface and the second interface are different.

2. The method according to claim 1, characterized in that, The method further includes: Send a first request for the first Uniform Resource Locator (URL) address; Receive a first response resource, the first response resource including an HTML file corresponding to the first URL address, a script file corresponding to the first URL address, and a second fusion menu configuration file; The first display interface includes: The second fusion menu configuration file is parsed using the script file corresponding to the first URL address to obtain the menu item information for each application; The first interface is displayed based on the menu item information of each application and the HTML file corresponding to the first URL address.

3. The method according to claim 1 or 2, characterized in that, The first integrated menu configuration file includes a corresponding timestamp, which is used to indicate the time when the user performs a change operation on the sub-application and the first integrated menu configuration file is generated. The step of obtaining the first fusion menu configuration file when there is a user's change operation on the sub-application includes: Periodically obtain the timestamp of the first fusion menu configuration file; If the timestamp of the first fusion menu configuration file is updated, retrieve the first fusion menu configuration file.

4. The method according to claim 3, characterized in that, The first interface includes an import application control, the change operation includes a add operation, and the user's add operation for the sub-application includes: Receive the user's first operation on the imported application control; In response to the first operation, the application service package of the first application is selected, and a first installation request is sent. The first installation request includes the application service package of the first application, which includes the microservice file, Nginx configuration file, and menu configuration file corresponding to the first application.

5. The method according to claim 4, characterized in that, The first interface also includes a delete control for each sub-application, the change operation includes a delete operation, and the user's delete operation for the sub-application includes: Receive a second user action regarding the delete control corresponding to the sub-application; In response to the second operation, a first deletion request is sent, the first deletion request including the identifier of the sub-application.

6. A display method, characterized in that, The method includes: During the operation of the main application or sub-application, if a user makes a change to the sub-application corresponding to the main application, a first merged menu configuration file is generated based on the menu configuration file of the main application and the menu configuration file of the sub-application. The menu configuration file of the main application or the sub-application includes menu item information of the corresponding application, and the menu item information includes the name of each menu item of the corresponding application and its corresponding hierarchical relationship. The sub-application is an extended application nested in the content area of ​​the main application. The sub-application includes a microservice file, a micro-application file, and a menu configuration file corresponding to the sub-application. The micro-application file corresponding to the sub-application is decoupled from the microservice file. The first fusion menu configuration file is sent to the first device. The first fusion menu configuration file is used to switch the first interface to be displayed as the second interface. The first interface includes one or more menu items, and the second interface includes one or more menu items. The menu items of the first interface and the second interface are different.

7. The method according to claim 6, characterized in that, Each menu item corresponds to a menu item object, and the menu item object includes one or more of the following: the name of the corresponding menu item, the address, and sub-menu item objects. Generating the first fused menu configuration file based on the main application's menu configuration file and the sub-application's menu configuration file includes: The menu configuration files of the main application and the menu configuration files of the sub-application are merged to generate a first merged menu configuration file.

8. The method according to claim 6 or 7, characterized in that, The change operation includes a new operation, and the method further includes: Receive a first installation request from the first device, the first installation request including an application service package of a first application, the application service package of the first application including a menu configuration file corresponding to the first application; The process of generating the first fused menu configuration file based on the menu configuration file of the main application and the menu configuration file of the corresponding sub-application includes: A first fused menu configuration file is generated based on the menu configuration file corresponding to the first application, the menu configuration file of the main application, and the menu configuration file of the sub-application corresponding to the main application.

9. The method according to claim 6 or 7, characterized in that, The change operation includes a deletion operation, and the method further includes: Receive a first deletion request from the first device, the first deletion request including the identifier of the first application; Delete the menu configuration file, microservice file, and Nginx configuration file corresponding to the first application based on the identifier of the first application; The process of generating the first fused menu configuration file based on the menu configuration file of the main application and the menu configuration file of the corresponding sub-application includes: A first fused menu configuration file is generated based on the menu configuration file of the main application and the menu configuration file of the sub-application corresponding to the main application. The sub-application corresponding to the main application does not include the first application.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory, wherein the processor invokes a computer program or computer instructions stored in the memory to implement the method as described in any one of claims 1-5 or the method as described in any one of claims 6-9.

Images