A dynamic menu implementation method, system, device and medium

Abstract

The application discloses a kind of implementation method and system and device and medium of dynamic menu, it is related to tree menu technical field, by obtaining the login data of first user to obtain the role data of first user, first user is divided into second user and third user based on the role data of first user.Second user corresponds the acquisition of menu tree, the generation and screening of menu tree are controlled by front end, and back end only needs to return the menu authority identification array corresponding to second user, reduces the complexity of data request;Third user corresponds the acquisition of menu tree, some special user authority system has fixed role authority, each role authority has fixed menu authority, by controlling the one-to-one mapping relationship of role authority and menu authority, the corresponding menu authority of third user is obtained by front end to obtain the corresponding menu tree, without carrying out back end request, reduces the dependence degree of back end interface request.

Description

Technical Field

[0001] This invention relates to the field of tree menu technology, and more specifically, to a method, system, device, and medium for implementing dynamic menus. Background Technology

[0002] In current back-end and front-end projects, there is often a need for different menus to be displayed for different users. The common approach is for the back-end to build a menu tree, filter the menu tree according to different user permission logic, and then return the complete menu tree structure after filtering to the front-end. The front-end then retrieves the complete menu tree and renders it. This method of displaying the menu tree mainly relies on the back-end to build the menu tree and control the dynamic rendering logic of the menu tree, which increases the dependence on back-end interface requests and the complexity of data requests. Summary of the Invention

[0003] To reduce the dependence on backend interface requests and the complexity of data requests during the display and rendering of the menu tree, this invention provides a method for implementing a dynamic menu, the method comprising:

[0004] S1. Obtain the login data of the first user;

[0005] S2. Based on the login data of the first user, obtain the role data of the first user;

[0006] S3. Match the first user's role data with preset role data. If the match fails, proceed to step S4. If the match succeeds, proceed to step S7.

[0007] S4. Construct a first initial menu tree through the front end. The user whose role data fails to match the preset role data in the first user's role data is the second user. The second user has a non-empty proper subset of the first initial menu tree.

[0008] S5. Based on the fact that the second user owns a non-empty proper subset of the first initial menu tree, the backend obtains the menu permission identifier array corresponding to the second user and returns it to the frontend;

[0009] S6. Based on the menu permission identifier array corresponding to the second user, the front end filters the first initial menu tree to obtain the first sub-menu tree;

[0010] S7. Multiple first menu trees are constructed through the front end. The multiple first menu trees form a one-to-one mapping relationship with multiple user roles. The user whose role data of the first user is successfully matched with the preset role data is the third user.

[0011] S8. Based on the mapping relationship between multiple first menu trees and multiple user roles, the front end obtains the second sub-menu tree corresponding to the third user.

[0012] The principle of this invention is as follows: First, the login data of the first user is obtained to acquire the user's role data. Then, based on the matching result between the first user's role data and preset role data, the first user is divided into a second user and a third user (if the match fails, the user is the second user; if the match succeeds, the user is the third user). To obtain the menu tree corresponding to the second user, a complete menu tree, i.e., the first initial menu tree, is first constructed through the front end. The second user possesses a non-empty proper subset of this first initial menu tree. Then, the back end obtains the menu permission identifier array corresponding to the second user and returns it to the front end. The front end then filters the first initial menu tree based on the returned menu permission identifier array corresponding to the second user to obtain the first sub-menu tree corresponding to the second user. To obtain the menu tree corresponding to the third user, multiple first menu trees are first constructed through the front end, and these multiple first menu trees have a one-to-one mapping relationship with multiple user roles. Based on the third user's role data, the menu tree corresponding to that role is obtained, i.e., the second sub-menu tree corresponding to the third user is obtained. Obtaining the menu tree for the second user allows the front-end to control the generation and filtering of the menu tree, while the back-end only needs to return an array of menu permission identifiers corresponding to the second user. The back-end does not need to construct the menu tree and return the complete menu tree to the front-end, reducing the complexity of data requests. Obtaining the menu tree for the third user involves a system with fixed role permissions for some special user permissions. Each role permission has fixed menu permissions. By controlling the one-to-one mapping relationship between role permissions and menu permissions, the front-end obtains the corresponding menu permissions for the third user's role permissions, thereby obtaining the corresponding menu tree without making back-end requests, reducing the dependence on back-end interface requests.

[0013] Preferably, constructing the first initial menu tree via the front end includes: hierarchically placing data from the menu database into N arrays, where N is a positive integer ≥ 2; obtaining the first data in the first-level array; obtaining the second data in the second-level array and concatenating it with the corresponding data in the first data; continuously obtaining data from the N arrays until obtaining the Nth data in the Nth-level array and concatenating it with the corresponding data in the (N-1)th data.

[0014] The menu tree is a data structure consisting of a hierarchical set of n finite nodes and a relationship defined on that set. The elements in the set are called nodes of the tree, and the defined relationship is called a parent-child relationship. The parent-child relationship establishes a hierarchical structure between the nodes of the tree. According to the hierarchical structure of the elements in the menu tree, the data in the menu database is divided into N arrays, with the data in each array being of the same level. The first data in the first-level array is the root node. Then, through the parent-child relationship between the data in the menu tree, the second data in the second-level array is obtained and concatenated with the corresponding data in the first data (this can be achieved through a tree menu plugin). The data in the menu database is processed in the above way to obtain the first initial menu tree.

[0015] Preferably, the front-end filtering the first initial menu tree to obtain the first sub-menu tree includes: adding a filter identifier to all data in the first initial menu tree based on the menu permission identifier array corresponding to the second user; and recursively filtering the first initial menu tree based on the filter identifier.

[0016] The menu permission identifier array refers to an array of unique identifiers for menu permissions. The menu permission identifier, or Permission, is a key field for controlling permissions. The system matches this permission identifier with the `@RequiresPermissions` annotation specified in the Controller. Only after a successful match can the system access the URL address (Uniform Resource Locator, meaning the menu data corresponding to the permission identifier is retrieved by accessing this URL address). Based on the second user's menu permission identifier array, the system accesses the menu data corresponding to the second user. Based on the access results, filter identifiers (such as `visible: true` and `visible: false`) are added to the data in the first initial menu tree. Then, based on the added filter identifiers, the first initial menu tree is recursively filtered to obtain the first sub-menu tree.

[0017] Preferably, recursive filtering of the first initial menu tree includes: the filtering identifier includes a first filtering identifier and a second filtering identifier; matching the filtering identifier of the data in the first initial menu tree with the first filtering identifier and the second filtering identifier; when the filtering identifier of the data in the first initial menu tree matches the first filtering identifier successfully, the first initial menu tree data corresponding to the successful match of the first filtering identifier is retained; when the filtering identifier of the data in the menu tree matches the second filtering identifier successfully, the first initial menu tree data corresponding to the successful match of the second filtering identifier is deleted.

[0018] The first filtering identifier is used to retain the menu tree data belonging to the second user in the first initial menu tree, and the second filtering identifier is used to delete the menu tree data that does not belong to the second user in the first initial menu tree. Finally, the first sub-menu tree corresponding to the second user is obtained by filtering the first initial menu tree with the first and second filtering identifiers.

[0019] Preferably, constructing multiple first menu trees through the front end includes:

[0020] a1. Construct a second initial menu tree using the aforementioned front-end;

[0021] a2. Assign permission values ​​to each node of the second initial menu tree based on the role permissions of the third user, wherein the permission value of each node is 0 or 1;

[0022] a3. Determine the permission value of each node in the second initial menu tree, delete the node with a permission value of 0 from the second initial menu tree, and keep the node with a permission value of 1.

[0023] a4. Repeat steps a2 to a3 to obtain multiple first menu trees corresponding to multiple users.

[0024] In this specific role-based access control system, each role's permissions correspond to its own menu permissions. When constructing the first menu tree for each role via the front-end, the front-end first builds a second initial menu tree that includes the menu permissions for all roles. Then, based on the third user's role permissions, each node in the second initial menu tree is assigned a permission value of 0 or 1. Nodes with a permission value of 0 are deleted, while nodes with a permission value of 1 are retained. This yields the first menu tree based on the user's role permissions. Repeating these steps allows for the creation of multiple first menu trees for each role. The front-end obtains the corresponding first menu tree by retrieving the user's role information without making back-end requests, thus reducing reliance on back-end APIs.

[0025] Preferably, the method further includes: the front end performing optimization processing on the first sub-menu tree and the second sub-menu tree, including obtaining the number of times the second user performs selection operations on each node in the first sub-menu tree and comparing it with a preset number of operations, and shrinking the menu tree nodes corresponding to the preset number of operations to hidden nodes under the parent node corresponding to the first sub-menu tree node; further including obtaining the number of times the third user performs selection operations on each node in the second sub-menu tree and comparing it with the preset number of operations, and shrinking the menu tree nodes corresponding to the preset number of operations to hidden nodes under the parent node corresponding to the second sub-menu tree node.

[0026] When the terminal displays a multi-level menu tree, the user needs to expand each node to find the desired node. However, if the user needs to find data for a node that is far from the root node in the menu tree, expanding each node one by one will cause the menu tree to occupy a lot of display space. Therefore, by setting hidden nodes, nodes that need to be expanded but do not require further operation can be hidden. Then, the number of operations on the nodes is used to determine from which level of the menu tree to set hidden nodes, thereby reducing the amount of display space occupied by the menu tree expansion.

[0027] Preferably, the method further includes: the front-end rendering the optimized first sub-menu tree and the second sub-menu tree to obtain a corresponding dynamic menu. Specifically, the front-end receives relevant data from the optimized first and second sub-menu trees, and then renders the page to present it to the user in the form of a menu tree.

[0028] To reduce the dependence on backend interface requests and the complexity of data requests during the display and rendering of the menu tree, this invention also provides a dynamic menu implementation system, the system comprising:

[0029] The first acquisition unit is used to acquire the login data of the first user;

[0030] The second acquisition unit is used to acquire the role data of the first user based on the login data of the first user;

[0031] The matching unit is used to match the role data of the first user with preset role data. If the matching fails, the process proceeds to the first construction unit; if the matching succeeds, the process proceeds to the second construction unit.

[0032] The first construction unit is used to construct a first initial menu tree through the front end. The user whose role data fails to match the preset role data is the second user. The second user has a non-empty proper subset of the first initial menu tree.

[0033] The third acquisition unit is used to acquire the menu permission identifier array corresponding to the second user and return it to the front end based on the fact that the second user owns a non-empty proper subset of the first initial menu tree;

[0034] The filtering unit is used to filter the first initial menu tree to obtain a first sub-menu tree based on the menu permission identifier array corresponding to the second user;

[0035] The second construction unit is used to construct multiple first menu trees through the front end. The multiple first menu trees form a one-to-one mapping relationship with multiple user roles. The user whose role data matches the preset role data is the third user.

[0036] The fourth acquisition unit is used to acquire the second sub-menu tree corresponding to the third user based on the mapping relationship between multiple first menu trees and multiple preset roles.

[0037] The present invention also provides an apparatus for implementing a dynamic menu, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method for implementing the dynamic menu.

[0038] The present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the method for implementing the dynamic menu.

[0039] One or more technical solutions provided by this invention have at least the following technical effects or advantages:

[0040] This invention controls the generation and filtering of the menu tree through the front end, and the back end only needs to return the corresponding menu permission identifier array, which reduces the complexity of data requests. For some special user permission systems, the front end sets a one-to-one correspondence between role permissions and menu permissions, and directly hands over the control of user menu permissions to the front end without making back end requests, thus reducing the dependence on back end interface requests. Attached Figure Description

[0041] The accompanying drawings, which are provided to further illustrate embodiments of the invention and constitute a part of this invention, are not intended to limit the scope of the invention.

[0042] Figure 1 This is a flowchart illustrating a method for implementing a dynamic menu in this invention;

[0043] Figure 2 This is a schematic diagram of the system composition for implementing a dynamic menu in this invention. Detailed Implementation

[0044] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, where there is no conflict, the embodiments of the present invention and the features thereof can be combined with each other.

[0045] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0046] Example 1

[0047] Please refer to Figure 1 The diagram below illustrates a method for implementing a dynamic menu according to the present invention. The method includes:

[0048] S1. Obtain the login data of the first user;

[0049] S2. Based on the login data of the first user, obtain the role data of the first user;

[0050] S3. Match the first user's role data with preset role data. If the match fails, proceed to step S4. If the match succeeds, proceed to step S7.

[0051] S4. Construct a first initial menu tree through the front end. The user whose role data fails to match the preset role data in the first user's role data is the second user. The second user has a non-empty proper subset of the first initial menu tree.

[0052] S5. Based on the fact that the second user owns a non-empty proper subset of the first initial menu tree, the backend obtains the menu permission identifier array corresponding to the second user and returns it to the frontend;

[0053] S6. Based on the menu permission identifier array corresponding to the second user, the front end filters the first initial menu tree to obtain the first sub-menu tree;

[0054] S7. Multiple first menu trees are constructed through the front end. The multiple first menu trees form a one-to-one mapping relationship with multiple user roles. The user whose role data of the first user is successfully matched with the preset role data is the third user.

[0055] S8. Based on the mapping relationship between multiple first menu trees and multiple user roles, the front end obtains the second sub-menu tree corresponding to the third user.

[0056] The front-end can be selected from other front-ends such as Bootstrap, Layui, or Angular, and the back-end can be selected from other back-ends such as Laravel, CakePHP, or Django. The selection of the front-end and back-end can be adjusted according to actual needs, and this invention does not impose specific limitations.

[0057] The process of constructing the first initial menu tree via the front end includes: hierarchically placing data from the menu database into N arrays, where N is a positive integer ≥ 2; obtaining the first data in the first-level array; obtaining the second data in the second-level array and concatenating it with the corresponding data in the first data; continuously obtaining data from the N arrays until obtaining the Nth data in the Nth-level array and concatenating it with the corresponding data in the (N-1)th data. For example, the first initial menu tree includes four levels of menus, and the menu database includes data (A, B, C, D, E, F, G). Therefore, when constructing the first initial menu tree, the data in the menu database needs to be hierarchically placed into four arrays (A in the first-level array, B and C in the second-level array, D, E, and F in the third-level array, and G in the fourth-level array). The first data (A) in the first-level array is used as the root node of the menu tree. The second data (B and C) in the second-level array is concatenated with the corresponding data (A) in the first-level array. The third data in the third-level array is concatenated with the corresponding data in the second-level array (D, E, and B are concatenated, F and C are concatenated). The fourth data in the fourth-level array is concatenated with the corresponding data in the third-level array (G and D are concatenated), thus completing the construction of the first initial menu tree. The above data is only for illustrative purposes and can be adjusted according to actual needs. This invention does not impose specific limitations.

[0058] The process of filtering the first initial menu tree to obtain the first sub-menu tree by the front end includes: adding filter flags to all data in the first initial menu tree based on the menu permission flag array corresponding to the second user; and recursively filtering the first initial menu tree based on the filter flags. The menu permission flag, or Permission, is a key field for controlling permissions. The system matches this permission flag with the @RequiresPermissions annotation specified in the Controller. Only after a successful match can the URL address (Uniform Resource Locator, i.e., accessing the URL address to obtain the menu data corresponding to the permission flag) be accessed. The system accesses the menu data corresponding to the second user based on the menu permission flag array, adds filter flags (such as visible: true and visible: false) to all data in the first initial menu tree based on the access results, and then recursively filters the first initial menu tree based on the added filter flags to obtain the first sub-menu tree.

[0059] The recursive filtering of the first initial menu tree includes: the filtering identifiers include a first filtering identifier and a second filtering identifier; matching the filtering identifiers of the data in the first initial menu tree with the first filtering identifier and the second filtering identifier; when the filtering identifier of the data in the first initial menu tree successfully matches the first filtering identifier, the first initial menu tree data corresponding to the successful match of the first filtering identifier is retained; when the filtering identifier of the data in the menu tree successfully matches the second filtering identifier, the first initial menu tree data corresponding to the successful match of the second filtering identifier is deleted. For example, if the first filtering identifier is visible: true and the second filtering identifier is visible: false, matching the filtering identifiers of the data in the first initial menu tree with the first filtering identifier and the second filtering identifier, when the filtering identifier of the data in the first initial menu tree successfully matches the first filtering identifier visible: true, the corresponding first initial menu tree data is retained; when the filtering identifier of the data in the first initial menu tree successfully matches the second filtering identifier visible: false, the corresponding first initial menu tree data is deleted. The above example is only for illustrative purposes; the filtering identifiers can be selected according to actual needs, and this invention does not impose specific limitations.

[0060] Among them, building multiple first menu trees through the front end includes:

[0061] a1. Construct a second initial menu tree using the aforementioned front-end;

[0062] a2. Assign permission values ​​to each node of the second initial menu tree based on the role permissions of the third user, wherein the permission value of each node is 0 or 1;

[0063] a3. Determine the permission value of each node in the second initial menu tree, delete the node with a permission value of 0 from the second initial menu tree, and keep the node with a permission value of 1.

[0064] a4. Repeat steps a2 to a3 to obtain multiple first menu trees corresponding to multiple users.

[0065] For example, the second initial menu tree includes a root node H, nodes I and J connected to node H, node K connected to node I, node L connected to node J, nodes M and N connected to node K, and node O connected to node L. The third user's role permissions include operation permissions on nodes H, I, K, and N. Therefore, nodes H, I, K, and N are assigned permission values ​​of 1, and nodes J, L, N, and O are assigned permission values ​​of 0. Nodes H, I, K, and N with permission values ​​of 1 are retained, while nodes J, L, N, and O with permission values ​​of 0 are deleted, resulting in the third user's second sub-menu tree. This is essentially obtaining the corresponding first menu tree based on the user's role permissions. When a user's role permissions change, the permission values ​​assigned to each section of the second initial menu tree also change accordingly, thus obtaining multiple first menu trees corresponding one-to-one with multiple user roles. The above data is for illustrative purposes only and can be adjusted according to actual circumstances; this invention does not impose specific limitations.

[0066] The method further includes: the front-end performs optimization processing on the first sub-menu tree and the second sub-menu tree, including obtaining the number of times the second user performs selection operations on each node in the first sub-menu tree and comparing it with a preset number of operations, and shrinking the menu tree nodes corresponding to the preset number of operations to hidden nodes under the parent node corresponding to the first sub-menu tree node; it also includes obtaining the number of times the third user performs selection operations on each node in the second sub-menu tree and comparing it with the preset number of operations, and shrinking the menu tree nodes corresponding to the preset number of operations to hidden nodes under the parent node corresponding to the second sub-menu tree node. For example, the first sub-menu tree includes 7 levels of menus. When a user searches for a node in the nth level menu, n-1 operations are required. The preset number of operations is set to 3. If a user needs to search for a node in the 7th level menu, hidden nodes need to be set starting from the 5th level menu. Nodes in the 5th, 6th, and 7th level menus that do not require operation are shrunk to their corresponding hidden nodes to avoid occupying a large amount of display space due to menu tree expansion. The above data is only for illustrative purposes and can be adjusted according to actual needs. This invention does not impose specific limitations.

[0067] The method further includes: the front-end rendering the optimized first and second sub-menu trees to obtain the corresponding dynamic menu. Page rendering is the process of parsing data and displaying it on the page. For example, in a browser, from entering an address to displaying the page, the general steps are as follows: First, HTML (Hypertext Markup Language) is obtained. After downloading, it is parsed. During the HTML parsing process, if external resources such as CSS and JS are encountered, the browser will immediately download these resources. Then, the browser will convert the parsed HTML into DOM objects and assemble the DOM tree (the same applies to CSS, which is parsed into CSS objects and assembled into a CSSOM tree). After the DOM tree and CSSOM tree are built, the browser will build a rendering tree based on the DOM tree and CSSOM tree. After building the rendering tree, the position and style of all elements are determined. The browser then calculates the position, style, and size of all elements and finally presents the page to the user. Similarly, the front-end renders the optimized first and second sub-menu trees to obtain a dynamic menu view and presents it to the user.

[0068] In this embodiment of the invention, user login data is first obtained to obtain user role data. The preset role data includes administrator and general user. When a user's role data is that of a guest user, the user's role data fails to match the preset role data. Therefore, a complete initial menu tree is constructed through the front-end. The guest user only possesses a subset of the current initial menu tree. The menu permission identifier array for the guest user is obtained through the back-end and returned to the front-end. The front-end then adds filter identifiers to the data in the initial menu tree based on the returned menu permission identifier array. Based on the added filter identifiers, the data in the initial menu tree is recursively filtered to obtain the guest user's sub-menu tree. Finally, the front-end renders this sub-menu tree to obtain a dynamic menu. Using this method to obtain the guest user's sub-menu tree only requires... The front-end controls the generation and filtering of the menu tree, while the back-end only needs to return the corresponding menu permission identifier array. The back-end does not need to construct the menu tree (if the back-end were to handle this, the request would need to return the complete menu tree structure, which the front-end would then retrieve and display), reducing data request complexity. When the user's role data is administrator, and the user's role data matches the preset role data successfully, the front-end constructs both the administrator's and regular user's menu trees. Since the user's role data is administrator, the front-end directly retrieves the already constructed administrator's menu tree and renders it to obtain the administrator's dynamic menu. Using this method, the front-end controls the user's menu permissions, eliminating the need for back-end API requests and reducing dependence on back-end APIs.

[0069] Example 2

[0070] Please refer to Figure 2 The diagram below illustrates the components of a dynamic menu implementation system according to the present invention. The system includes:

[0071] The first acquisition unit is used to acquire the login data of the first user;

[0072] The second acquisition unit is used to acquire the role data of the first user based on the login data of the first user;

[0073] The matching unit is used to match the role data of the first user with preset role data. If the matching fails, the process proceeds to the first construction unit; if the matching succeeds, the process proceeds to the second construction unit.

[0074] The first construction unit is used to construct a first initial menu tree through the front end. The user whose role data fails to match the preset role data is the second user. The second user has a non-empty proper subset of the first initial menu tree.

[0075] The third acquisition unit is used to acquire the menu permission identifier array corresponding to the second user and return it to the front end based on the fact that the second user owns a non-empty proper subset of the first initial menu tree;

[0076] The filtering unit is used to filter the first initial menu tree to obtain a first sub-menu tree based on the menu permission identifier array corresponding to the second user;

[0077] The second construction unit is used to construct multiple first menu trees through the front end. The multiple first menu trees form a one-to-one mapping relationship with multiple user roles. The user whose role data matches the preset role data is the third user.

[0078] The fourth acquisition unit is used to acquire the second sub-menu tree corresponding to the third user based on the mapping relationship between multiple first menu trees and multiple preset roles.

[0079] Example 3

[0080] Embodiment 3 of the present invention provides a device for implementing a dynamic menu, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the method for implementing the dynamic menu.

[0081] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0082] The memory can be used to store the computer program and / or modules. The processor implements various functions of the dynamic menu implementation device in the invention by running or executing the data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.). In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart memory card, secure digital card, flash memory card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0083] Example 4

[0084] Embodiment 4 of the present invention provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the method for implementing the dynamic menu.

[0085] If the device for implementing the dynamic menu is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program that can be stored in a computer-readable storage medium. When executed by a processor, this computer program can implement the steps of the various method embodiments described above. The computer program includes computer program code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory, random access memory, dot carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction.

[0086] The basic concepts of this invention have been described. It is obvious to those skilled in the art that the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0087] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Moreover, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

[0088] Furthermore, those skilled in the art will understand that various aspects of this specification can be described and illustrated in several patentable ways or situations, including any new and useful combination of processes, machines, products, or substances, or any new and useful improvements thereof. Accordingly, various aspects of this specification can be implemented entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. All of the above hardware or software may be referred to as a “data block,” “module,” “engine,” “unit,” “component,” or “system.” Furthermore, various aspects of this specification may be represented as a computer product located on one or more computer-readable media, including computer-readable program code.

[0089] Computer storage media may contain a propagated data signal containing computer program code, for example, on baseband or as part of a carrier wave. This propagated signal may take various forms, including electromagnetic, optical, and suitable combinations thereof. Computer storage media can be any computer-readable medium other than a computer-readable storage medium, which can be connected to an instruction execution system, apparatus, or device to enable communication, propagation, or transmission of a program for use. The program code located on the computer storage medium can be propagated through any suitable medium, including radio, cable, fiber optic cable, RF, or similar media, or any combination of the above media.

[0090] The computer program code required for the operation of each part of this manual can be written in any one or more programming languages, including object-oriented programming languages ​​such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET, Python, etc.; conventional procedural programming languages ​​such as C, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP; dynamic programming languages ​​such as Python, Ruby, and Groovy; or other programming languages. This program code can run entirely on the user's computer, or as a standalone software package on the user's computer, or partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any network, such as a local area network (LAN) or wide area network (WAN), or connected to an external computer (e.g., via the Internet), or in a cloud computing environment, or used as a service such as Software as a Service (SaaS).

[0091] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.

[0092] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0093] For each patent, patent application, patent application publication, and other material, such as articles, books, specifications, publications, and documents, referenced in this specification, the entire contents of which are incorporated herein by reference. This excludes historical application documents that are inconsistent with or conflict with the content of this specification, as well as documents that limit the broadest scope of the claims in this specification (currently or subsequently appended to this specification). It should be noted that in the event of any inconsistency or conflict between the descriptions, definitions, and / or terminology used in the supplementary materials to this specification and the content of this specification, the descriptions, definitions, and / or terminology used in this specification shall prevail.

[0094] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.

[0095] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0096] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for implementing a dynamic menu, characterized in that, The method includes the following steps: S1. Obtain the login data of the first user; S2. Based on the login data of the first user, obtain the role data of the first user; S3. Match the first user's role data with preset role data. If the match fails, proceed to step S4. If the match succeeds, proceed to step S7. S4. Construct a first initial menu tree through the front end. The user whose role data fails to match the preset role data in the first user's role data is the second user. The second user has a non-empty proper subset of the first initial menu tree. S5. Based on the fact that the second user owns a non-empty proper subset of the first initial menu tree, the backend obtains the menu permission identifier array corresponding to the second user and returns it to the frontend; S6. Based on the menu permission identifier array corresponding to the second user, the front end filters the first initial menu tree to obtain the first sub-menu tree; S7. Multiple first menu trees are constructed through the front end. The multiple first menu trees form a one-to-one mapping relationship with multiple user roles. The user whose role data of the first user is successfully matched with the preset role data is the third user. S8. Based on the mapping relationship between multiple first menu trees and multiple user roles, the front end obtains the second sub-menu tree corresponding to the third user; The process of constructing the first initial menu tree via the front end includes: hierarchically placing data from the menu database into N arrays, where N is a positive integer ≥ 2; obtaining the first data in the first-level array; obtaining the second data in the second-level array and concatenating it with the corresponding data in the first data; continuously obtaining data from the N arrays until the Nth data in the Nth-level array is obtained and concatenating it with the corresponding data in the (N-1)th data. The method further includes: the front end performs optimization processing on the first sub-menu tree and the second sub-menu tree, including obtaining the number of times the second user performs selection operations on each node in the first sub-menu tree and comparing it with a preset number of operations, and shrinking the menu tree nodes corresponding to the preset number of operations to hidden nodes under the parent node corresponding to the first sub-menu tree node; it also includes obtaining the number of times the third user performs selection operations on each node in the second sub-menu tree and comparing it with the preset number of operations, and shrinking the menu tree nodes corresponding to the preset number of operations to hidden nodes under the parent node corresponding to the second sub-menu tree node; The front-end filters the first initial menu tree to obtain the first sub-menu tree by: adding filter identifiers to all data in the first initial menu tree based on the menu permission identifier array corresponding to the second user; and recursively filtering the first initial menu tree based on the filter identifiers. The recursive filtering of the first initial menu tree includes: the filter identifier includes a first filter identifier and a second filter identifier; matching the filter identifier of the data in the first initial menu tree with the first filter identifier and the second filter identifier; when the filter identifier of the data in the first initial menu tree matches the first filter identifier successfully, the first initial menu tree data corresponding to the successful match of the first filter identifier is retained; when the filter identifier of the data in the menu tree matches the second filter identifier successfully, the first initial menu tree data corresponding to the successful match of the second filter identifier is deleted. Building multiple first menu trees via the front end includes: a1. Construct a second initial menu tree using the aforementioned front-end; a2. Assign permission values ​​to each node of the second initial menu tree based on the role permissions of the third user, wherein the permission value of each node is 0 or 1; a3. Determine the permission value of each node in the second initial menu tree, delete the node with a permission value of 0 from the second initial menu tree, and keep the node with a permission value of 1. a4. Repeat steps a2 to a3 to obtain multiple first menu trees corresponding to multiple users; The method further includes: the front end renders the optimized first sub-menu tree and the second sub-menu tree to obtain the corresponding dynamic menu.

2. A system for implementing dynamic menus, characterized in that, The system includes: The first acquisition unit is used to acquire the login data of the first user; The second acquisition unit is used to acquire the role data of the first user based on the login data of the first user; The matching unit is used to match the role data of the first user with preset role data. If the matching fails, the process proceeds to the first construction unit; if the matching succeeds, the process proceeds to the second construction unit. The first construction unit is used to construct a first initial menu tree through the front end. The user whose role data fails to match the preset role data is the second user. The second user has a non-empty proper subset of the first initial menu tree. The third acquisition unit is used to acquire the menu permission identifier array corresponding to the second user and return it to the front end based on the fact that the second user owns a non-empty proper subset of the first initial menu tree; The filtering unit is used to filter the first initial menu tree to obtain a first sub-menu tree based on the menu permission identifier array corresponding to the second user; The second construction unit is used to construct multiple first menu trees through the front end. The multiple first menu trees form a one-to-one mapping relationship with multiple user roles. The user whose role data matches the preset role data is the third user. The fourth acquisition unit is used to acquire the second sub-menu tree corresponding to the third user based on the mapping relationship between multiple first menu trees and multiple preset roles. The process of constructing the first initial menu tree via the front end includes: hierarchically placing data from the menu database into N arrays, where N is a positive integer ≥ 2; obtaining the first data in the first-level array; obtaining the second data in the second-level array and concatenating it with the corresponding data in the first data; continuously obtaining data from the N arrays until the Nth data in the Nth-level array is obtained and concatenating it with the corresponding data in the (N-1)th data. The front-end performs optimization processing on the first sub-menu tree and the second sub-menu tree, including obtaining the number of times the second user performs selection operations on each node in the first sub-menu tree and comparing it with a preset number of operations, and shrinking the menu tree nodes that exceed the preset number of operations to hidden nodes under the parent node corresponding to the first sub-menu tree node; it also includes obtaining the number of times the third user performs selection operations on each node in the second sub-menu tree and comparing it with the preset number of operations, and shrinking the menu tree nodes that exceed the preset number of operations to hidden nodes under the parent node corresponding to the second sub-menu tree node; The front-end filters the first initial menu tree to obtain the first sub-menu tree by: adding filter identifiers to all data in the first initial menu tree based on the menu permission identifier array corresponding to the second user; and recursively filtering the first initial menu tree based on the filter identifiers. The recursive filtering of the first initial menu tree includes: the filter identifier includes a first filter identifier and a second filter identifier; matching the filter identifier of the data in the first initial menu tree with the first filter identifier and the second filter identifier; when the filter identifier of the data in the first initial menu tree matches the first filter identifier successfully, the first initial menu tree data corresponding to the successful match of the first filter identifier is retained; when the filter identifier of the data in the menu tree matches the second filter identifier successfully, the first initial menu tree data corresponding to the successful match of the second filter identifier is deleted. Building multiple first menu trees via the front end includes: a1. Construct a second initial menu tree using the aforementioned front-end; a2. Assign permission values ​​to each node of the second initial menu tree based on the role permissions of the third user, wherein the permission value of each node is 0 or 1; a3. Determine the permission value of each node in the second initial menu tree, delete the node with a permission value of 0 from the second initial menu tree, and keep the node with a permission value of 1. a4. Repeat steps a2 to a3 to obtain multiple first menu trees corresponding to multiple users; The system further includes: the front end renders the optimized first sub-menu tree and the second sub-menu tree to obtain the corresponding dynamic menu.

3. An apparatus for implementing a dynamic menu, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method for implementing the dynamic menu as described in claim 1.

4. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for implementing the dynamic menu as described in claim 1.

Images