CN111125098B - Access method of application front end containing multiple modules, module registration method and device - Google Patents
Access method of application front end containing multiple modules, module registration method and device Download PDFInfo
- Publication number
- CN111125098B CN111125098B CN201911254293.5A CN201911254293A CN111125098B CN 111125098 B CN111125098 B CN 111125098B CN 201911254293 A CN201911254293 A CN 201911254293A CN 111125098 B CN111125098 B CN 111125098B
- Authority
- CN
- China
- Prior art keywords
- module
- information
- accessible
- standard
- definition table
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2282—Tablespace storage structures; Management thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Software Systems (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computational Linguistics (AREA)
- Stored Programmes (AREA)
Abstract
The application front end receives request information of user login, and determines an accessible module with access authority according to the request information of the user. And then calling a standard module definition table of the module according to the determined accessible module, reading module configuration information in the standard module definition table, and confirming the module type. And finally, calling the running environment of the module or the loader of the module to run or load the accessible module according to the type of the module. The method adopts the unified standard to standardize the modules with different architectures, so that the modules can be unified on line and cooperated with each other to achieve unified user experience. The application also provides a method for calling the module by the module scheduling engine, an access device of the application front end comprising multiple modules, a module registration method, a module registration system, a module calling method and a system for accessing the application front end by the multiple modules.
Description
Technical Field
The present application relates to an access method for an application front end, and more particularly, to an access method for an application front end including multiple modules, and a device including a multi-module access application front end, a method for calling a module through a module scheduling engine, a module registration method, a module registration device, a module calling method, and a system including a multi-module access application front end.
Background
An application front end comprising multiple modules means that a plurality of modules of different technical frameworks can be run on one application front end, for example, various programs written in different languages or different types of modules are uniformly run on one application front end. The application front end integrates a plurality of modules capable of running independently, and service items with rich functions are provided through the modules capable of running independently.
In the prior art, the implementation method of the application front end including multiple modules is usually implemented by simple superposition, and a general method is to first select a functional module, for example, an APP corresponds to a functional module, and add other functional modules on the basis of the functional module, for example, add other functional modules in the APP.
In the above technical solutions, since the functional modules are implemented by different technical architectures, there are many defects that are difficult to overcome. The functional modules can only run independently and are independent of each other, functions can be overlapped, and the access path in the modules is long, so that uniform user experience cannot be achieved. Secondly, because the functional modules run independently and are independent of each other, each functional module forms a larger volume, and the problem of one functional point can cause that other functions can not work normally. Thirdly, because each functional module has different operators, the global management of the functions can not be realized, the coordination difficulty is high, and the online standards are not uniform.
Disclosure of Invention
In order to solve the above problem, the present application provides an access method for an application front end including multiple modules, which includes the steps of:
receiving request information of user login, and inquiring an accessible module with access authority of a client according to the request information of user login;
calling standard module definition tables corresponding to the accessible modules from a database according to the accessible modules with access rights of clients;
inquiring module configuration information in the standard module definition table corresponding to each accessible module, and judging the type of the accessible module according to the module configuration information;
and according to the type of the accessible module, corresponding to each accessible module, calling a respective running environment or jumping to a loader of the accessible module, and loading or running the accessible module.
Optionally, the modules are independent from each other, and each module may adopt different technical architectures, where the different technical architectures include offline H5, online H5, fact Native, Native Android, Native ios, and applet.
Optionally, the method comprises a public component for providing services for each module, wherein the public component is at least encapsulated with module management, version management and statistical analysis functions, and the modules are accessed through a native interface and a JS interface provided by the public component.
Optionally, the module configuration information in the standard module definition table at least includes module type information, module address information, module name information, and module icon information.
Optionally, the standard module definition table is generated when a module is registered, where the registration refers to a process of inserting the module defined by the standard module definition table into a database and enabling the module to be accessed.
Optionally, the loader comprises native code, a built-in H5 browser.
Optionally, the reading of data from the memory by the application front end adopts a third-level cache policy with preset data priority, and the method includes:
making a network data version request, and loading preset data into a memory if the network data version is less than or equal to the local preset data version or the request returns an error;
and if the network data version is larger than the local preset data version, adopting the network data.
Optionally, in the case of using network data, a third-level cache policy with network data priority is used; preferentially making a network data request, and if the network data is correctly returned, locally storing the data and loading the data to a memory;
if the network data returns an error, reading the cache data from the local storage and loading the cache data to the memory;
and if the local storage data is empty, loading the application preset data to the memory.
The application also provides a method for calling the module through the module scheduling engine, which comprises the following steps:
receiving a module calling request;
inquiring configuration information of the accessible module requested to be called according to the module calling request;
judging the type of the accessible module requested to be called according to the configuration information of the accessible module requested to be called:
calling a running environment of the accessible module requested to be called or jumping to a loader of the accessible module requested to be called according to the type of the accessible module requested to be called;
and loading or running the accessible module requested to be called.
Optionally, after the accessible module requested to be called is loaded or executed, recording an execution result of the accessible module requested to be called;
and returning the operation result to the module.
The application also provides an access device of the application front end containing multiple modules, which is characterized by comprising an information receiving unit, a data calling unit, a configuration information inquiry unit and a calling or loading unit,
the information receiving unit is used for inquiring the accessible module with the access right of the client according to the client information
The data calling unit is used for accessing the database, inquiring a standard module definition table of the accessible module and reading module configuration information of the accessible module from the standard module definition table;
the configuration information query unit is used for judging the type of the module according to the module configuration information;
the calling or loading unit is used for calling the running environment of the module or jumping to a loader of the module according to the type of the module, and loading or running the module.
Optionally, the system further comprises a public component unit, wherein the public component unit is packaged with module management, version management and statistical analysis functions, and also provides a native and JS interface.
Optionally, the public component unit further provides native and JS interfaces, and the module provides native interface and JS interface access through the public component.
Optionally, the module configuration information at least includes module type information, module address information, module name information, and module icon information.
Optionally, the module accesses the server and can be accessed on the requirements of the standard module definition table.
Optionally, the module scheduling unit may receive a call request of the module to call another module, where the calling another module includes querying configuration information of the another module, determining a type of the another module, calling a running environment of the another module, jumping to a loader of the another module, and loading or running the another module.
Optionally, the loader comprises native code, a built-in H5 browser.
The application also provides a module registration method, which comprises the following steps:
inputting module configuration information into a standard module definition table, and storing the standard module definition table in a database;
judging the module type according to the module configuration information;
and setting the running environment of the module or establishing the access connection of the module according to the type of the module.
The application also provides a module registration system, which comprises a configuration information input unit and a database,
the configuration information input unit is used for inputting module configuration information into a standard module definition table and storing the standard module definition table in a database;
the database is: used for storing the standard module definition table;
the application also provides a module calling method, which comprises the following steps:
receiving module information and extra information of an application module;
inquiring the module information of the target module which is applied and called by the application module according to the module information and the extra information of the application module;
judging the type of the target module according to the module information of the target module;
and calling the running environment of the target module or jumping to a loader of the target module according to the type of the target module, and loading or running the target module.
The application also provides a device system with multiple modules accessed to the application front end, which is characterized by comprising a configuration information input unit, a database and environment setting unit, a module configuration information query unit, a module type judgment unit and a module scheduling unit,
the configuration information input unit is used for inputting module configuration information into a standard module definition table and storing the standard module definition table into a database;
the database is used for storing the standard module definition table;
the environment setting unit is used for setting the running environment of the module or the access connection of the module according to the module configuration information;
the module configuration information query unit is used for accessing the database, querying a standard module definition table of the accessible module and reading the module configuration information of the accessible module;
the module type judging sheet is used for judging the type of the module according to the module configuration information;
the module scheduling unit is used for calling the running environment of the module or jumping to a loader of the module according to the type of the module, and loading or running the module.
The method comprises the steps of inquiring client information, determining an accessible module with access authority according to the client information, calling a standard module definition table of the accessible module according to the accessible module of the client, and reading configuration information of the module through the standard module definition table to call each module. The modules with different types of architectures are subjected to unified standardization standards through the standard module definition table, so that the modules are more independent, the research and development of each service can be not interfered with each other, and the modules can be integrated quickly. The modules are mutually independent, so that more accurate authority control is facilitated, and mutual cooperation is facilitated.
The method and the device adopt the unified common module to provide support for the operation of each module, reduce the workload of repeated development and maintenance, reduce the phenomenon of service coupling and easily realize global management.
Drawings
Fig. 1 shows a flow chart of an access method of an application front end including multiple modules in the present application.
Fig. 2 shows a flow chart of a preset data priority caching method in the present application.
Fig. 3 is a flowchart illustrating a network data priority caching method according to the present application.
FIG. 4 illustrates a workflow diagram for invoking a module by the module scheduler engine in the present application.
Fig. 5 shows a block diagram of an access device of an application front end containing multiple modules in the present application.
Fig. 6 shows a flow chart of a module registration method in the present application.
FIG. 7 shows a diagram of a module registration system in the present application.
FIG. 8 shows a flow chart of a module calling method in the present application.
Detailed Description
The application provides an access method of an application front end containing multiple modules, a method for calling the modules through a module scheduling engine, an access device of the application front end containing the multiple modules, a module registration method, a module registration device, a module calling method and a system for accessing the application front end through the multiple modules. It should be noted that the present application includes, but is not limited to, the technical solutions shown in the following embodiments, and also includes the technical solutions of the same principle as the present application or the technical solutions given in the technical teaching of the present application.
In order to realize the unified and ordered management of each module of different technical frameworks and realize the unified technical access specification, the application provides an access method of an application front end containing a plurality of modules, which comprises the following steps,
receiving request information of user login, and inquiring an accessible module with access authority of a user according to the request information of user login;
calling a standard module definition table corresponding to each accessible module from a database according to the accessible module with access authority of a user;
inquiring module configuration information in the standard module definition table corresponding to each accessible module, and judging the type of the accessible module according to the module configuration information;
and according to the type of the accessible module, corresponding to each accessible module, calling a respective running environment or jumping to a loader of the accessible module, and loading or running the accessible module.
In order to explain the access method of the application front end including multiple modules and the technical details included therein in more detail, the present application is explained in detail with reference to 6 implementations.
Fig. 1 shows a flow chart of the operation of the first embodiment.
The first embodiment will be described in detail with reference to fig. 1.
Step S101, receiving request information of user login, and inquiring an accessible module with access right of the user according to the request information of user login.
The user information refers to various information including identity information used by a user in application front-end operation or login, and information capable of inquiring access authority of an accessible module of the user is the user information referred to in this embodiment. The user information may come from a variety of sources, such as direct input by the user, input through other devices or means, obtained over a network, and so forth. In this embodiment, the receiving of the user information is performed under the precondition that the user is notified and the user authorization is obtained.
In step S101, the user logs in, and then queries the accessible module having the access right according to the user information on the premise of user authorization. The accessible module for querying the access right of the user can be in various manners, and in this embodiment, the following manner is adopted, that is, firstly, the service that the user has opened is judged through the user information, and then, the accessible module that the user has the access right is judged according to the service that the user has opened.
Step S102, according to the accessible modules with access authority, the standard module definition table corresponding to each accessible module is called from the database.
The database may be a local database or a non-local database. The calling may be from a local database, from a non-local database, or from a non-local database, and cached in the local database.
The database stores standard module definition tables of the modules built by the technical frameworks, and the standard module definition tables standardize the modules built by the technical frameworks according to a uniform technical standard so as to meet the integration requirement of the modules at the application front end. The standard module definition table contains module information of the module on the basis of technical standard unification, including module type information, module address information, module name information, module icon information and the like.
The standard module definition table is generated when the module is registered, and in this embodiment, the standard module definition table is a table for setting parameters according to a specified standard, and includes not only a format table, but also files, data or other types of carriers with specified standards unified by all setting modules. The registration refers to a process that a module defined by a standard module definition table is inserted into a database and can be accessed, and during registration, the standard module definition table can be generated by a plurality of methods, such as filling or automatic generation.
In step S102, the accessible module with access right of the user is already known, and on the basis, the standard module definition table of each accessible module with access right of the user and the data in the table are called from the database.
Step S103, module configuration information in the standard module definition table corresponding to each accessible module is inquired, and the type of the accessible module is judged according to the module configuration information.
The configuration information is recorded on a standard module definition table, the configuration information comprises technical parameters, operating parameters, access parameters, module types, module storage addresses and the like of the modules, and the types of the accessible modules are obtained according to the configuration information.
The types of accessible modules refer to separate modules using different technical architectures including H5, online H5, read Native, Native Android, Native ios, applets, and the like. In step S103, determining the type of the accessible module means determining which type of the accessible module includes H5, online H5, read Native, Native Android, Native ios, applet, and the like.
Step S104, according to the type of the accessible module, corresponding to each accessible module, calling the respective running environment or jumping to a loader of the accessible module, and loading or running the accessible module.
In step S104, the type of the accessible module is already determined, and the calling mode of the accessible module can be determined according to the type of the accessible module.
The loader in one case comprises native code, a built-in H5 browser, such as a module calling technical architecture H5. And after judging that the module type is H5, calling a loader of H5 according to the operating parameters of H5, and loading the H5. The loader is preset to the application front end and is called according to the calling request.
The H5 may be data stored at different addresses that are recorded in the standard module definition table and read at the time of H5 load. It is also possible that the H5 is preset data, and is directly loaded locally when the H5 is judged to be preset data.
In another case, for example, a module with native Android as the technical architecture is called. And after judging that the type of the module is the native Android, calling the running environment of the native Android to run the module according to the running parameters of the native Android, wherein the running environment is preset and is started according to a calling request. And after the module operating environment starts to operate, operating the module in the operating environment. The modules may be stored at different addresses and loaded before running according to the module addresses recorded in the standard module information table.
In this embodiment, the modules adopt a unified technical standard architecture, and can use a unified common component for providing services for each module, where the common component is at least encapsulated with module management, version management, and statistical analysis functions, for example, the service function provided by the common component may be a message push function, a version detection function, a log feedback function, a behavior analysis function, a hot repair function, a hot update function, a communication function, and the like. The module accesses the common component through a native interface and a JS interface provided by the common component.
In the embodiment, a plurality of data caching methods can be provided in the actual operation process, and the application provides a preferable data caching method.
Fig. 2 and 3 show a preferred data caching method of the present embodiment.
The data caching method in the present embodiment is described in detail below with reference to fig. 2 and 3 in conjunction with the present embodiment.
Referring to fig. 2, in this embodiment, the application front end reads data from the memory, and the data read from the memory adopts a third-level cache policy with a priority of preset data.
S211 first requests a network data version, and in a specific operation process, the result of network interruption may be caused due to uncertainty of a network environment, or the data version may be smaller than or equal to the local preset data version due to other reasons. And if the network data version is less than or equal to the local preset data version or the request returns an error, loading the preset data into the memory.
S212, if the network data version is greater than the local preset data version, the network data is used. In fact, the local preset data version is relatively general, for example, after the network data version is checked to be larger than the local preset data version for the first time, the network data version is updated to the memory for the first time, after the network data version is checked to be larger than the local preset data version for the second time, the network data version is updated to the memory for the second time, if the network data version is checked to be smaller than or equal to the local preset data version for the second time, the network data version updated for the first time is the preset data, and the preset data is the data included in the application front end itself in the initialization stage.
Referring to fig. 3, in the case of using network data, a third-level caching policy with network data priority is used.
S221 preferentially requests network data, and if the network data is returned correctly, stores the data locally and loads the data to the memory.
S222, if the network data returns an error, reading the cache data from the local storage and loading the cache data to the memory.
And S223, if the local storage data is empty, loading the application preset data to the memory.
In the application, the modules can be called mutually, and the application provides a method for calling the modules through a module scheduling engine.
FIG. 4 illustrates a workflow diagram for invoking a module by the module scheduler engine.
The second embodiment will be described in detail with reference to fig. 4.
Step S301 receives a module call request.
In step S301, the module scheduling engine receives a module invoking request, where the request includes information of an application invoking module and related information of a requested invoking module, and the related information refers to information that the module scheduling engine can query or access configuration information of the requested invoking module according to the related information.
Step S302 queries configuration information of the accessible module requested to be called according to the module calling request. The configuration information includes technical parameters, operating parameters, access parameters, module types, module storage addresses and the like of the modules.
Step S303 determines the type of the accessible module requested to be called according to the configuration information of the accessible module requested to be called. The types of accessible modules refer to separate modules using different technical architectures including H5, online H5, read Native, Native Android, Native ios, applets, and the like.
Step S304 calls the execution environment of the accessible module requested to be called or jumps to the loader of the accessible module requested to be called according to the type of the accessible module requested to be called.
The loader in one case comprises native code, a built-in H5 browser, such as a module calling technical architecture H5. And after judging that the module type is H5, calling a loader of H5 according to the operating parameters of H5, and loading the H5. The loader is preset to the application front end and is called according to the calling request.
The H5 may be data stored at different addresses that are recorded in the standard module definition table and read at the time of H5 load. It is also possible that the H5 is preset data, and is directly loaded locally when the H5 is judged to be preset data.
In another case, for example, a module with native Android as the technical architecture is called. And after judging that the type of the module is the native Android, calling the running environment of the native Android to run the module according to the running parameters of the native Android, wherein the running environment is preset and is started according to a calling request. And after the module operating environment starts to operate, operating the module in the operating environment. The modules may be stored at different addresses and downloaded before operation according to the module addresses recorded in the standard module information table.
Step S305 loads or runs the accessible module requested to be called.
After the accessible module requested to be called is loaded or executed while the accessible module requested to be called provides a technical or data support only for the accessible module requesting to be called, the module scheduling engine records the execution result of the accessible module requested to be called and returns the execution result to the module.
In the method, the application front end may include a plurality of separate modules, and each module is independent from each other in different architectures and runs or loads on a unified application front end.
Fig. 5 shows a block diagram of an access device comprising a multi-module application front-end.
A third embodiment of the present application will be described in detail below with reference to fig. 5.
The information receiving unit 401 receives request information of user login, and queries an accessible module having access right according to the request information of user login.
The request information for user login refers to various information including identity information used by the user in application front-end operation or login, and the information capable of querying the access authority of the accessible module possessed by the user is the user information referred to in this embodiment. The user information may come from a variety of sources, such as direct input by the user, input through other devices or means, obtained over a network, and so forth. In this embodiment, the receiving of the user information is performed under the precondition that the user is notified and the user authorization is obtained.
In the information receiving unit 401, first, request information for user login is received, and then, under the precondition that the user is authorized, an accessible module having an access right of the user is queried according to the request information for user login. The accessible module for querying the access right of the user can be in various manners, and in this embodiment, the following manner is adopted, that is, firstly, the service that the user has opened is judged through the user information, and then, the accessible module that the user has the access right is judged according to the service that the user has opened.
The data retrieving unit 402 retrieves standard module definition tables corresponding to the accessible modules from the database according to the accessible modules to which the user has access rights.
The database may be a local database or a non-local database. The calling may be from a local database, from a non-local database, or from a non-local database, and cached in the local database.
The database stores standard module definition tables of the modules built by the technical frameworks, and the standard module definition tables standardize the modules built by the technical frameworks according to a uniform technical standard so as to meet the integration requirement of the modules at the application front end. The standard module definition table contains module information of the module on the basis of technical standard unification, including module type information, module address information, module name information, module icon information and the like.
The standard module definition table is generated when a module is registered, the registration refers to a process that the module defined by the standard module definition table is accessed into a database and can be accessed, and the standard module definition table can be generated in various generation methods, such as filling and automatic generation.
In the data retrieving unit 402, the accessible module to which the user has access right is already known, and on the basis of this, the standard module definition data of each accessible module to which the user is known to have access right is retrieved from the database.
The configuration information query unit 403 queries the module configuration information in the standard module definition table corresponding to each accessible module, and determines the type of the accessible module according to the module configuration information.
The configuration information is recorded on a standard module definition table, the configuration information comprises technical parameters, operating parameters, access parameters, module types, module storage addresses and the like of the modules, and the types of the accessible modules are obtained according to the configuration information.
The types of accessible modules refer to separate modules using different technical architectures including H5, online H5, read Native, Native Android, Native ios, applets, and the like. In the configuration information query unit 403, determining the type of the accessible module means determining which type of the accessible module includes H5, online H5, fact Native, Native Android, Native ios, applet, and the like.
The calling or loading unit 404 calls the respective running environments or jumps to the loader of the accessible modules corresponding to the accessible modules according to the types of the accessible modules, and loads or runs the accessible modules.
In the calling or loading unit 404, the type of the accessible module is already determined, and the calling mode of the accessible module can be determined according to the type of the accessible module.
The loader in one case comprises native code, a built-in H5 browser, such as a module calling technical architecture H5. And after judging that the module type is H5, calling a loader of H5 according to the operating parameters of H5, and loading the H5. The loader is preset to the application front end and is called according to the calling request.
The H5 may be data stored at different addresses that are recorded in the standard module definition table and read at the time of H5 load. It is also possible that the H5 is preset data, and is directly loaded locally when the H5 is judged to be preset data.
In another case, for example, a module with native Android as the technical architecture is called. And after judging that the type of the module is the native Android, calling the running environment of the native Android to run the module according to the running parameters of the native Android, wherein the running environment is preset and is started according to a calling request. And after the module operating environment starts to operate, operating the module in the operating environment. The modules may be stored at different addresses and downloaded before operation according to the module addresses recorded in the standard module information table.
The common component unit 405, where the modules adopt a unified technical standard architecture, can use a unified common component that provides services for each module, and the common component is at least encapsulated with module management, version management, and statistical analysis functions, for example, the service function provided by the common component may be message pushing, version detection, log feedback, behavior analysis, thermal remediation function, thermal update function, communication function, and the like. The module accesses the common component through a native interface and a JS interface provided by the common component.
In this embodiment, the application front end reads data from the memory, and the data read from the memory adopts a third-level cache policy with preset data priority.
Please refer to the data caching method shown in fig. 2 and 3.
Referring to fig. 2, in this embodiment, the application front end reads data from the memory, and the data read from the memory adopts a third-level cache policy with a priority of preset data.
S210, judging the size of the network data and the preset data version, wherein the network data refers to data acquired from a server through a network. The preset data refers to locally built-in version data.
S211 first requests a network data version, and in a specific operation process, the result of network interruption may be caused due to uncertainty of a network environment, or the data version may be smaller than or equal to the local preset data version due to other reasons. And if the network data version is less than or equal to the local preset data version or the request returns an error, loading the preset data into the memory.
S212, if the network data version is greater than the local preset data version, the network data is used. In fact, the local preset data version is relatively general, for example, after the network data version is checked to be larger than the local preset data version for the first time, the network data version is updated to the memory for the first time, after the network data version is checked to be larger than the local preset data version for the second time, the network data version is updated to the memory for the second time, if the network data version is checked to be smaller than or equal to the local preset data version for the second time, the network data version updated for the first time is the preset data, and the preset data is the data included in the application front end itself in the initialization stage.
Referring to fig. 3, in the case of using network data, a third-level caching policy with network data priority is used.
S221 determines the network data return result, and the following processing steps are performed to determine the network data return result.
S221 preferentially requests network data, and if the network data is returned correctly, stores the data locally and loads the data to the memory.
S222, if the network data returns an error, reading the cache data from the local storage and loading the cache data to the memory.
And S223, if the local storage data is empty, loading the application preset data to the memory.
Fig. 6 shows a flow chart of a module registration method.
A fourth embodiment of the present invention will be described in detail with reference to fig. 6.
Step S501 inputs the module configuration information into a standard module definition table, and stores the standard module definition table in a database.
In step S501, the module is of a technical standard architecture specified by an installation standard module definition table, and in a specific registration process, information specified by the module installation standard module definition table is written into information of the module.
Step S502 judges the module type according to the module configuration information.
In step S502, the configuration information is recorded in a standard module definition table, and the configuration information includes technical parameters, operating parameters, access parameters, a module type, a module storage address, and the like of a module, and the type of the accessible module is obtained according to the configuration information.
Step S503 sets the operating environment of the module or establishes the access connection of the module according to the module type.
In step S503, according to the read configuration information, the technical parameters, the operating parameters, the access parameters, the module type, the module storage address, and the like of the module may be obtained, and the operating environment or the access connection of the module may be set according to the parameters recorded in the configuration information.
In the application, the module registration method provides an operation basis for the access method of the application front end comprising multiple modules, and the access of the application front end comprising the multiple modules can be realized only by registering the modules in advance. The application also provides a module registration device corresponding to the module registration method.
Fig. 7 shows a block diagram of the module registration system of the present application.
The embodiment 5 of the present application will be described in detail with reference to fig. 7.
The configuration information entry unit will 601, enter the module configuration information into the standard module definition table, store the standard module definition table in the database.
The module is installed according to a technical standard framework specified in a standard module definition table, and in a specific registration process, information specified in the module installation standard module definition table is written into the information of the module.
The database 602 is used for storing the standard module definition table.
The database may be a local database or a non-local database. The calling may be from a local database, from a non-local database, or from a non-local database, and cached in the local database.
And setting the environment, namely setting the running environment of the module or the access connection of the module according to the module configuration information.
According to the read configuration information, the technical parameters, the operating parameters, the access parameters, the module type, the module storage address and the like of the module can be obtained, and the operating environment or the access connection of the module is set according to the parameters recorded by the configuration information.
According to the access method and device and the module registration method and device for the application front end comprising the multiple modules, the application also provides an access system for the application front end comprising the multiple modules, and the access method and device and the module registration method and system for the application front end comprising the multiple modules.
The module registration process is as follows:
and inputting the module configuration information into a standard module definition table, and storing the standard module definition table in a database. And writing the information specified by the module installation standard module definition table into the information of the module.
And setting the environment, namely acquiring the technical parameters, the operating parameters, the access parameters, the module type, the module storage address and the like of the module according to the read configuration information, and setting the operating environment or the access connection of the module according to the parameters recorded by the configuration information.
The module calling process is as follows:
firstly, receiving request information of user login, and then inquiring an accessible module with access authority of a user according to the request information of user login under the precondition of user authorization. The accessible module for querying the access right of the user can be in various manners, and in this embodiment, the following manner is adopted, that is, firstly, the service that the user has opened is judged through the user information, and then, the accessible module that the user has the access right is judged according to the service that the user has opened.
The accessible modules with the access rights of the users are known, and on the basis, the standard module definition data of each accessible module with the access rights of the known users are called from the database.
And inquiring module configuration information in the standard module definition table corresponding to each accessible module, and judging the type of the accessible module according to the module configuration information.
The configuration information is recorded on a standard module definition table, the configuration information comprises technical parameters, operating parameters, access parameters, module types, module storage addresses and the like of the modules, and the types of the accessible modules are obtained according to the configuration information.
And according to the type of the accessible module, corresponding to each accessible module, calling a respective running environment or jumping to a loader of the accessible module, and loading or running the accessible module.
The method and the device have the advantages that the modules can be mutually called in the actual operation process, the information among the modules is transferred and extracted on the basis of mutual calling, and according to the requirement, the method for calling the modules is further provided.
FIG. 8 shows a flow chart of a module invocation method.
The 6 th embodiment of the present application will be described in detail with reference to fig. 8.
Step S701 receives module information and additional information of the application module.
During compiling, the called target module firstly needs to be registered in the platform router, specifically: the package target class, b.class, is generated by APT technique. And the target module sends the B.class to the platform router and registers the B.class into the platform router in a Key-value mode.
When calling, firstly, an application module applying for a calling target module generates a packaging target class, namely a.class, from own information through an APT technology. And the platform router receives the A.class transmitted to the data storage module in the platform router by the application module through the Key and stores the A.class.
Step S702 inquires the module information of the target module which is applied and called by the application module according to the module information and the extra information of the application module.
After the data storage module of the platform router receives the A.class, the platform router transmits the transmitted Key and the additional information into the platform router according to the A.class transmitted into the data storage module, and acquires the module information of the target module.
Step S703 determines the type of the target module according to the module information of the target module.
The types of accessible modules refer to separate modules using different technical architectures including H5, online H5, read Native, Native Android, Native ios, applets, and the like. Determining the type of the accessible module means determining which type of the accessible module includes H5, online H5, real Native, Native Android, Native ios, and applet.
Step S704 calls the running environment of the target module or jumps to the loader of the target module, and loads or runs the target module according to the type of the target module.
The type of the accessible module is determined, and the calling mode of the accessible module can be judged according to the type of the accessible module.
The loader in one case comprises native code, a built-in H5 browser, such as a module calling technical architecture H5. And after judging that the module type is H5, calling a loader of H5 according to the operating parameters of H5, and loading the H5. The loader is preset to the application front end and is called according to the calling request.
The H5 may be data stored at different addresses that are recorded in the standard module definition table and read at the time of H5 load. It is also possible that the H5 is preset data, and is directly loaded locally when the H5 is judged to be preset data.
In another case, for example, a module with native Android as the technical architecture is called. And after judging that the type of the module is the native Android, calling the running environment of the native Android to run the module according to the running parameters of the native Android, wherein the running environment is preset and is started according to a calling request. And after the module operating environment starts to operate, operating the module in the operating environment. The modules may be stored at different addresses and loaded before running according to the module addresses recorded in the standard module information table.
The present application has been explained in detail through the above six examples, but the present application is not limited to only the above three embodiments. Variations may also be made within the knowledge of those skilled in the art without departing from the spirit of the present application.
Claims (13)
1. An access method of an application front end containing multiple modules comprises the following steps:
receiving request information of user login, and inquiring an accessible module with access authority of a user according to the request information of user login;
calling a standard module definition table corresponding to each accessible module from a database according to the accessible module with access authority of a user;
inquiring module configuration information in the standard module definition table corresponding to each accessible module, and judging the type of the accessible module according to the module configuration information;
according to the type of the accessible module, corresponding to each accessible module, calling respective running environments or jumping to a loader of the accessible module, and loading or running the accessible module;
wherein the standard module definition table is generated at module registration, and the module accesses the server and can be accessed on the requirement of the standard module definition table; the modules are independent, and each module can adopt different technical frameworks; the module configuration information includes at least: module type information, module address information, module name information, and module icon information.
2. The method of claim 1, comprising a common component for providing services to each module, wherein the common component encapsulates at least module management, version management, and statistical analysis functions, and the modules are accessed through a native interface and a JS interface provided by the common component.
3. The method according to claim 1, wherein the application front-end reads data from a memory, and the reading of data from the memory employs a three-level cache policy with preset data priority, and the method comprises:
making a network data version request, and loading preset data into a memory if the network data version is less than or equal to the local preset data version or the request returns an error;
and if the network data version is larger than the local preset data version, adopting the network data.
4. The access method of application front-end containing multiple modules according to claim 3, characterized in that, in case of network data, a third-level caching strategy with network data priority is used; preferentially making a network data request, and if the network data is correctly returned, locally storing the data and loading the data to a memory;
if the network data returns an error, reading the cache data from the local storage and loading the cache data to the memory;
and if the local storage data is empty, loading the application preset data to the memory.
5. A method for invoking a module by a module scheduling engine, comprising the steps of:
receiving a module calling request;
according to the module calling request, inquiring the configuration information of the accessible module requested to be called, wherein the configuration information of the module at least comprises: module type information, module address information, module name information and module icon information;
judging the type of the accessible module requested to be called according to the configuration information of the accessible module requested to be called;
calling a running environment of the accessible module requested to be called or jumping to a loader of the accessible module requested to be called according to the type of the accessible module requested to be called;
loading or running the accessible module requested to be called;
the module type information, the module address information, the module name information and the module icon information are module configuration information in a standard module definition table;
wherein the modules access the server and can be accessed on the requirements of a standard module definition table; the modules are independent, and each module can adopt different technical frameworks; the standard module definition table is generated at module registration time.
6. An access device of application front end containing multiple modules is characterized in that the access device comprises an information receiving unit, a data calling unit, a configuration information inquiry unit and a calling or loading unit,
the information receiving unit is used for receiving request information of user login and inquiring the accessible module with access right of the user according to the request information of user login
The data calling unit is used for accessing the database and inquiring a standard module definition table of the accessible module, and reading module configuration information of the accessible module from the standard module definition table, wherein the standard module definition table is generated when the module is registered, and the module accesses the server and can be accessed according to the requirements of the standard module definition table;
the configuration information query unit is used for judging the type of the module according to the module configuration information, and the module configuration information at least comprises: module type information, module address information, module name information and module icon information;
the calling or loading unit is used for calling the running environment of the module or jumping to a loader of the module according to the type of the module, and loading or running the module, the modules are independent, and each module can adopt different technical frameworks.
7. The access device of claim 6, comprising a common component that services each module, said common component encapsulating at least module management, version management, statistical analysis functions, said modules being accessed through a native interface and a JS interface provided by the common component.
8. The access device of claim 6, wherein the front-end reads data from the memory, and the reading of data from the memory employs a three-level caching policy with preset data priority, and the access device comprises:
making a network data version request, and loading preset data into a memory if the network data version is less than or equal to the local preset data version or the request returns an error;
and if the network data version is larger than the local preset data version, adopting the network data.
9. The access device of claim 8, wherein when network data is used, a third-level caching strategy is used for network data priority; preferentially making a network data request, and if the network data is correctly returned, locally storing the data and loading the data to a memory;
if the network data returns an error, reading the cache data from the local storage and loading the cache data to the memory;
and if the local storage data is empty, loading the application preset data to the memory.
10. A method for registering a module, comprising the steps of:
inputting module configuration information into a standard module definition table, and storing the standard module definition table in a database;
judging the module type according to the module configuration information;
setting the running environment of the module or establishing the access connection of the module according to the type of the module;
wherein the module configuration information at least includes: module type information, module address information, module name information and module icon information;
wherein the modules access the server and can be accessed on the requirements of a standard module definition table; the modules are independent, and each module can adopt different technical frameworks; the standard module definition table is generated when the module is registered;
the module type information, the module address information, the module name information and the module icon information are module configuration information in the standard module definition table.
11. A module registration system comprises a configuration information entry unit and a database,
the configuration information input unit is used for inputting module configuration information into a standard module definition table and storing the standard module definition table in a database;
the standard module definition table is generated when a module is registered, and the module accesses the server and can be accessed according to the requirements of the standard module definition table;
the database is used for storing the standard module definition table;
the modules are independent, and each module can adopt different technical frameworks;
the configuration information of the module at least comprises: module type information, module address information, module name information and module icon information;
the module type information, the module address information, the module name information and the module icon information are module configuration information in the standard module definition table.
12. A module calling method, comprising the steps of:
receiving module information and extra information of an application module;
inquiring the module information of the target module which is applied and called by the application module according to the module information and the extra information of the application module;
judging the type of the target module according to the module information of the target module;
calling the running environment of the target module or jumping to a loader of the target module according to the type of the target module, and loading or running the target module;
the modules are independent, and each module can adopt different technical frameworks.
13. A system for multi-module access application front end is characterized in that the system comprises a configuration information input unit, a database and environment setting unit, a module configuration information query unit, a module type judgment unit and a module scheduling unit,
the configuration information input unit is used for inputting module configuration information into a standard module definition table, and the standard module definition table is stored in a database;
the database is used for storing the standard module definition table;
the environment setting unit is used for setting the running environment of the module or the access connection of the module according to the module configuration information;
the module configuration information query unit is used for accessing the database, querying a standard module definition table of the accessible module and reading the module configuration information of the accessible module;
the module type judging unit is used for judging the type of the module according to the module configuration information;
the module scheduling unit is used for calling the running environment of the module or jumping to a loader of the module according to the type of the module, and loading or running the module;
wherein the standard module definition table is generated at module registration, and the module accesses the server and can be accessed on the requirement of the standard module definition table; the modules are independent, and each module can adopt different technical frameworks; the module configuration information includes at least: module type information, module address information, module name information, and module icon information.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911254293.5A CN111125098B (en) | 2019-12-06 | 2019-12-06 | Access method of application front end containing multiple modules, module registration method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911254293.5A CN111125098B (en) | 2019-12-06 | 2019-12-06 | Access method of application front end containing multiple modules, module registration method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111125098A CN111125098A (en) | 2020-05-08 |
| CN111125098B true CN111125098B (en) | 2021-02-05 |
Family
ID=70496285
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911254293.5A Active CN111125098B (en) | 2019-12-06 | 2019-12-06 | Access method of application front end containing multiple modules, module registration method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111125098B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104965742A (en) * | 2015-06-30 | 2015-10-07 | 努比亚技术有限公司 | Automated script and apparatus for processing front-end tasks |
| US9595061B1 (en) * | 2015-07-24 | 2017-03-14 | Accenture Global Services Limited | Cloud-based platform integrating point of sale devices of different types and/or formats |
| CN108319827A (en) * | 2018-01-25 | 2018-07-24 | 烽火通信科技股份有限公司 | A kind of API rights managements plug-in unit and method based on OSGI frames |
| CN108494582A (en) * | 2018-02-13 | 2018-09-04 | 国网浙江省电力有限公司信息通信分公司 | A kind of lower coupling automation operational system and method |
| CN108595223A (en) * | 2018-04-27 | 2018-09-28 | 上海达梦数据库有限公司 | A kind of configuration method of application program, device, equipment and storage medium |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105138602B (en) * | 2015-08-06 | 2019-07-19 | 中国电力科学研究院 | A kind of construction system and its application method of three-dimensional collaborative platform |
| CN106873972A (en) * | 2016-12-30 | 2017-06-20 | 中国电力科学研究院 | Electric Power Network Planning emulation platform computing module cut-in method and system based on plug-in unit |
-
2019
- 2019-12-06 CN CN201911254293.5A patent/CN111125098B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104965742A (en) * | 2015-06-30 | 2015-10-07 | 努比亚技术有限公司 | Automated script and apparatus for processing front-end tasks |
| US9595061B1 (en) * | 2015-07-24 | 2017-03-14 | Accenture Global Services Limited | Cloud-based platform integrating point of sale devices of different types and/or formats |
| CN108319827A (en) * | 2018-01-25 | 2018-07-24 | 烽火通信科技股份有限公司 | A kind of API rights managements plug-in unit and method based on OSGI frames |
| CN108494582A (en) * | 2018-02-13 | 2018-09-04 | 国网浙江省电力有限公司信息通信分公司 | A kind of lower coupling automation operational system and method |
| CN108595223A (en) * | 2018-04-27 | 2018-09-28 | 上海达梦数据库有限公司 | A kind of configuration method of application program, device, equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111125098A (en) | 2020-05-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1894667B (en) | System and method for allocating server resources | |
| CN102185900B (en) | Application service platform system and method for developing application services | |
| CN101034990B (en) | Right management method and device | |
| CN103064960B (en) | Data base query method and equipment | |
| CN110532025B (en) | Data processing method, device and equipment based on micro-service architecture and storage medium | |
| CN107948203A (en) | A kind of container login method, application server, system and storage medium | |
| WO2012041388A1 (en) | Generation of a query plan for accessing a database | |
| CN114205342B (en) | Service debugging routing method, electronic equipment and medium | |
| CN101727475B (en) | Method, device and system for acquiring database access process | |
| CN112860507B (en) | Control method and device for sampling rate of distributed link tracking system | |
| CN113381866B (en) | Gateway-based service calling method, device, equipment and storage medium | |
| CN115867891A (en) | Method for dynamically integrating application programs, software system and machine thereof | |
| US7721278B2 (en) | Modular server architecture for multi-environment HTTP request processing | |
| CN106776706A (en) | Method for managing user right and device based on caching | |
| CN114661580A (en) | Flow recording playback method and device, computer equipment and storage medium | |
| US20100332582A1 (en) | Method and System for Service Contract Discovery | |
| CN110267077B (en) | Offline caching method, device, terminal and readable storage medium | |
| CN107943504A (en) | The dynamic update method of software module in a kind of embedded system | |
| JP2007527562A5 (en) | ||
| CN117076473B (en) | Metadata operation method, system, equipment and medium for SaaS multi-tenant | |
| CN111125098B (en) | Access method of application front end containing multiple modules, module registration method and device | |
| CN109388770B (en) | Web page generation method and device | |
| CN111683091A (en) | Method, device, equipment and storage medium for accessing cloud host console | |
| CN113608831B (en) | Plug-in instance management method, system, storage medium and equipment | |
| CN108563514A (en) | Access method, application and the electronic equipment of application configuration service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |