Component management-based page upgrade method and computing device

Abstract

This application provides a page upgrade method and computing device based on component management, comprising: acquiring a multi-version component library, wherein the multi-version component library includes at least one component library, each component library corresponding to a component library version number, the component library including components for building a page, each component corresponding to a component version number, and the component libraries of different versions being logically isolated; responding to a page upgrade command, calling the page metadata corresponding to the page to be upgraded, the page metadata including at least the page identifier of the page to be upgraded, the target component library version number of the target component library corresponding to the page to be upgraded, and the target component version number of the target component; searching in the multi-version component library based on the page metadata to obtain the corresponding target component, and using the target component to upgrade the page to be upgraded. The above method solves the risk faced by upgrades due to the coupling of component attributes and page configuration.

Description

Technical Field

[0001] This application relates to the field of computing device technology, and in particular to a page upgrade method and computing device based on component management. Background Technology

[0002] Currently, with the widespread application of front-end engineering and low-code platforms, front-end component libraries, as basic page building units, are extensively reused in different application pages. During the long-term evolution and development of front-end components, their attribute structure, interactive behavior, and resource forms continuously change. The development of system business is often accompanied by the continuous iteration of component library versions, and component upgrades have become a crucial technical aspect affecting the overall stability of the system.

[0003] Currently, existing front-end component library upgrade solutions typically adopt a "global one-size-fits-all" approach. This means that when a new component library version is released, the underlying component package is directly replaced in the main project's dependencies, forcing all historical page environments to be uniformly updated to the latest system component library. When resolving configuration inconsistencies, the deep coupling between component attributes and page configurations leads to significant collateral risks during system upgrades. Each component version evolution not only easily triggers unpredictable rendering crashes and behavioral anomalies on numerous historical pages, but also causes users' original page configurations to be forcibly overwritten and rendered invalid. Ultimately, the system is forced to rely on inefficient and error-prone manual page-by-page repairs to maintain stability, severely restricting the platform's iteration efficiency, engineering security, and development efficiency. Summary of the Invention

[0004] This application provides a page upgrade method and computing device based on component management, which can solve the problem that the system faces huge associated risks during upgrades due to the deep coupling between component attributes and page configuration.

[0005] Firstly, embodiments of this application provide a page upgrade method based on component management. The method includes: acquiring a multi-version component library, wherein the multi-version component library includes at least one component library, each component library corresponding to a component library version number, each component library including components for building a page, each component corresponding to a component version number, and component libraries of different versions being logically isolated; responding to a page upgrade instruction, calling the page metadata corresponding to the page to be upgraded, the page metadata including at least the page identifier of the page to be upgraded, the target component library version number of the target component library corresponding to the page to be upgraded, and the target component version number of the target component; searching in the multi-version component library based on the page metadata to obtain the corresponding target component, and using the target component to upgrade the page to be upgraded. The above steps avoid the problem of simultaneous adaptation of all pages caused by traditional global forced upgrades. Upgrading a single page will not affect the operation of other historical pages, the pages corresponding to each component library do not interfere with each other, and different applications use different component libraries during upgrades, effectively reducing the compatibility risks caused by component version iterations and improving system stability.

[0006] In one possible implementation, before obtaining the multi-version component library, the method further includes: obtaining a version object set, wherein the version object set includes at least one version object, and the version object includes a deployed component library and a corresponding component library version number; creating a corresponding library directory for each version object in the version object set to obtain a version directory set, wherein the storage locations corresponding to the library directories in the version directory set are logically isolated; and configuring the version objects in the version object set to the corresponding library directories in the version directory set to obtain the multi-version component library. The above steps establish a standardized multi-version component library deployment mechanism, achieving logical isolation between versions and avoiding resource overlap and conflicts between versions at the storage level.

[0007] In one possible implementation, after responding to the page upgrade instruction and calling the page metadata corresponding to the page to be upgraded, the method further includes: extracting the target component library version number and the target component version number from the page metadata; configuring a mapping relationship between the target component library version number and the target component version number based on version number rule information, wherein the naming rule of the target component version number is associated with the corresponding target component library version number. The above steps establish an association mapping between component library versions and component versions. Through a standardized version mapping mechanism, version addressing errors are avoided, and the accuracy of component resource loading is improved.

[0008] In one possible implementation, the step of searching the multi-version component library based on the page metadata to obtain the corresponding target component includes: generating a resource loading path based on the target component library version number and the target component version number in the page metadata; and searching the multi-version component library according to the resource loading path to obtain the target component. These steps achieve precise location of component resources through path generation and retrieval, realizing automated resource addressing based on version numbers, and improving the automation level of the upgrade process and resource loading efficiency.

[0009] In one possible implementation, the method further includes: generating difference attributes by comparing the first resource file and the second resource file; generating a first configuration file based on the difference attributes; and upgrading the page to be upgraded using the target component includes: upgrading the page to be upgraded based on the first configuration file. The above steps automatically generate an adaptation configuration through resource file difference comparison, eliminating the need for manual page-by-page modification, improving upgrade efficiency, reducing configuration errors caused by manual modification, and ensuring the integrity of the user's original configuration.

[0010] In one possible implementation, generating the first configuration file based on the difference attributes includes: generating a component skeleton based on the configuration scenario of the target component and the second resource file, wherein the component skeleton includes at least the newly added field structure corresponding to the updated target component; and generating the first configuration file based on the difference attributes and the standardized skeleton. The above steps unify the configuration structure through the component skeleton, ensuring the standardization of configuration migration, avoiding missing fields or structural errors in the generated configuration file, guaranteeing compatibility between the upgraded configuration and the new version of the component, and improving the structural consistency of the configuration file.

[0011] In one possible implementation, upgrading the page to be upgraded based on the first configuration file includes: comparing the first configuration file and the target component library to obtain an updated component set, the updated component set including component intersections, newly added component sets, removed component sets, and specification attributes; merging the updated component set into the specification skeleton strategy, and upgrading the page to be upgraded based on intersection inheritance rules, blind spot completion rules, and obsolescence removal rules to obtain the upgraded page. The above steps achieve precise configuration updates through categorized merging rules, ensuring both the integrity of the configuration data and compatibility with new version components, thus realizing automated and refined configuration upgrades.

[0012] In one possible implementation, generating the first configuration file based on the difference attributes and the specification skeleton includes: performing attribute semantic recognition on the difference attributes to obtain the attribute category corresponding to the difference attributes, wherein the attribute category includes one of core attributes, auxiliary attributes, and dynamic attributes; obtaining the corresponding difference merging strategy based on the attribute category; and generating the first configuration file based on the difference merging strategy and the specification skeleton. The above steps refine the merging strategy through attribute semantic classification, improving the accuracy of configuration migration.

[0013] In one possible implementation, at least one attribute category corresponds to multiple difference merging strategies. The method further includes: predicting the priority of the difference merging strategies based on a pre-trained model, wherein the pre-trained model is trained based on a first training sample, the first training sample including attribute conflict logs and attribute configuration history records; and determining the target difference merging strategy for the attribute category based on the priority. These steps dynamically optimize the merging strategy priority through machine learning, improving the intelligence of configuration upgrades. Simultaneously, the prediction accuracy is continuously optimized with the accumulation of historical data, resulting in iterative improvements in upgrade adaptation.

[0014] Secondly, embodiments of this application provide a page upgrade device based on component management, applied to a first computing device, the device comprising:

[0015] The acquisition module is used to acquire multiple versions of the component library;

[0016] The calling module is used to respond to page upgrade commands and call the page metadata corresponding to the page to be upgraded;

[0017] The search module is used to search in the multi-version component library based on the page metadata to obtain the corresponding target component, and to upgrade the page to be upgraded using the target component.

[0018] In one possible implementation, before acquiring the multi-version component library, the acquisition module is further configured to: acquire a set of version objects, the set of version objects including at least one version object, the version object including a deployed component library and a corresponding component library version number; create a corresponding library directory for each version object in the set of version objects to obtain a set of version directories, wherein the storage locations corresponding to each library directory in the set of version directories are logically isolated; and configure the version objects in the set of version objects to the corresponding library directories in the set of version directories to obtain the multi-version component library.

[0019] In one possible implementation, after the calling module invokes the page metadata corresponding to the page to be upgraded in response to the page upgrade instruction, it is further configured to: extract the target component library version number and the target component version number from the page metadata; and configure the mapping relationship between the target component library version number and the target component version number based on version number rule information, wherein the naming rule of the target component version number is associated with the corresponding target component library version number.

[0020] In one possible implementation, when the search module searches the multi-version component library based on the page metadata to obtain the corresponding target component, it is specifically used to: generate a resource loading path based on the target component library version number and the target component version number in the page metadata; and search the multi-version component library according to the resource loading path to obtain the target component.

[0021] In one possible implementation, the search module is further configured to: generate difference attributes by comparing the first resource file and the second resource file; generate a first configuration file based on the difference attributes; and when the target component is used to upgrade the page to be upgraded, the search module is specifically configured to: upgrade the page to be upgraded based on the first configuration file.

[0022] In one possible implementation, when the search module generates the first configuration file based on the difference attributes, it is specifically used to: generate a component skeleton based on the configuration scenario of the target component and the second resource file, wherein the component skeleton includes at least the newly added field structure corresponding to the updated target component; and generate the first configuration file based on the difference attributes and the specification skeleton.

[0023] In one possible implementation, when the search module upgrades the page to be upgraded based on the first configuration file, it is specifically used to: compare the first configuration file and the target component library to obtain an updated component set, the updated component set including component intersection, newly added component set, removed component set and specification attributes; merge the updated component set into the specification skeleton strategy, and upgrade the page to be upgraded based on intersection inheritance rules, blind spot completion rules and invalidation removal rules to obtain the upgraded page.

[0024] In one possible implementation, when the search module generates the first configuration file based on the difference attributes and the specification skeleton, it is specifically used to: obtain the attribute category corresponding to the difference attributes by performing attribute semantic recognition on the difference attributes, wherein the attribute category includes one of core attributes, auxiliary attributes, and dynamic attributes; obtain the corresponding difference merging strategy based on the attribute category; and generate the first configuration file based on the difference merging strategy and the specification skeleton.

[0025] In one possible implementation, at least one attribute category corresponds to multiple difference merging strategies, and the method is further used to: predict the priority of the difference merging strategy based on a pre-trained model, wherein the pre-trained model is trained based on a first training sample, the first training sample including attribute conflict logs and attribute configuration history; and determine the target difference merging strategy for the attribute category based on the priority.

[0026] Thirdly, embodiments of this application provide a computing device, including: a memory and a processor;

[0027] The memory is coupled to the processor; the memory is used to store program instructions; the processor is used to invoke the program instructions to cause the computing device to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0028] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0029] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect. Attached Figure Description

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

[0031] Figure 1 A schematic diagram illustrating a page upgrade method based on component management provided in an embodiment of this application;

[0032] Figure 2 A flowchart illustrating a page upgrade method based on component management provided in this application embodiment. Figure 1 ;

[0033] Figure 3 A flowchart illustrating a page upgrade method based on component management provided in this application embodiment. Figure 2 ;

[0034] Figure 4A flowchart illustrating a page upgrade method based on component management provided in this application embodiment. Figure 3 ;

[0035] Figure 5 A flowchart illustrating a page upgrade method based on component management provided in this application embodiment. Figure 4 ;

[0036] Figure 6 A schematic diagram of the architecture of a page upgrade method based on component management provided in an embodiment of this application;

[0037] Figure 7 A flowchart illustrating an embodiment of this application;

[0038] Figure 8 The overall system architecture diagram provided for the embodiments of this application;

[0039] Figure 9 A schematic diagram of a page upgrade device based on component management provided in this embodiment;

[0040] Figure 10 This is a schematic diagram of the structure of the computing device provided in this embodiment.

[0041] The accompanying drawings illustrate specific embodiments of this invention, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the present invention in any way, but rather to illustrate the concepts of this invention to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0042] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0043] The following is combined Figure 1 The application scenarios involved in the embodiments of this application will be described.

[0044] Figure 1 This is a schematic diagram illustrating a scenario for a page upgrade method based on component management, provided as an embodiment of this application. For example... Figure 1As shown, when a user creates a website page using a low-code platform, they first open the web design page to enter the low-code platform's entry page. Then, they find the multi-version component library dropdown menu in the upper right corner and select the first component library. Simultaneously, selectable components from the first component library appear on the right, including backgrounds. Figure 1 ,background Figure 2 The website includes a drop-down menu, a playback plugin, an input box, a payment button, and another drop-down menu. Users can then drag and drop the required components to the blank space in the middle. After creating the desired website page, users can click "Create Complete" to lock the page and the selected components. After creation, some parts still have preview and trial runs available. The rightmost part is the "Publish" button. When users click the "Publish" button, the created website page will be simultaneously published on the preset page path.

[0045] In the above application scenarios, when the components in the first component library are upgraded or updated, the components called in the first component library when the terminal device opens the corresponding page will also be updated. In traditional scenarios, multiple pages are often created using a single version of the component library. If one version of the component library fails, the entire system is affected. Storing different versions of the component library in different system directories ensures logical isolation and independent coexistence between the component libraries, eliminating the risk of the entire system being affected if one version of the component library fails. This also reduces the coupling between pages and component libraries and facilitates future upgrades.

[0046] The technical solution of this embodiment and how the technical solution of this embodiment solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this embodiment will be described below with reference to the accompanying drawings.

[0047] Figure 2 A flowchart illustrating a page upgrade method based on component management provided in this application embodiment. Figure 1 ,like Figure 2 As shown, the method includes:

[0048] Step S101: Obtain a multi-version component library. The multi-version component library includes at least one component library. Each component library corresponds to a component library version number. The component library includes components used to build the page. Each component corresponds to a component version number. Component libraries of different versions are logically isolated.

[0049] Step S102: In response to the page upgrade command, call the page metadata corresponding to the page to be upgraded. The page metadata includes at least the page identifier of the page to be upgraded, the target component library version number of the target component library corresponding to the page to be upgraded, and the target component version number of the target component.

[0050] Step S103: Search the multi-version component library based on page metadata to obtain the corresponding target component, and use the target component to upgrade the page to be upgraded.

[0051] For example, the device pre-deploys and stores multiple versions of component libraries. First, it reads the resource files and version numbers of each version of the component library, confirms that the storage paths of each version are independent, and completes the resource initialization of the multiple version component libraries, ensuring that component resources of different versions will not overwrite each other. When an upgrade command for a specified page is received, the device retrieves the page metadata corresponding to the page from the database or configuration file according to the page identifier in the command, and parses out the target component library version number and the target component version number, providing a basis for subsequent resource addressing. Finally, based on the version information in the page metadata, the device locates the corresponding version of the component resource in the multiple version component library, completes resource loading and page configuration adaptation, and ultimately realizes the component version upgrade of the page. In one possible implementation, a local pre-deployment approach is adopted. Platform operations and maintenance personnel pre-deploy all available versions of the component library to a local file server, assigning an independent storage directory to each version. When the system starts, it directly scans the local directory to complete the loading and registration of all versions of the component library. In another possible implementation, a remote on-demand retrieval approach is adopted. The system only stores commonly used versions of the component library locally. When it receives an upgrade request for a specified version and there is no corresponding resource locally, it automatically retrieves the corresponding version of the component library resource from the remote component repository, caches it in a local independent directory, and then completes the registration.

[0052] The above steps avoid the problem of all pages needing to be adapted simultaneously due to traditional global forced upgrades. Upgrading a single page will not affect the operation of other historical pages. Pages corresponding to different component libraries do not interfere with each other. Different applications use different component libraries when upgrading, which effectively reduces the compatibility risks brought about by component version iteration and improves system stability.

[0053] Figure 3 A flowchart illustrating a page upgrade method based on component management provided in this application embodiment. Figure 2 ;like Figure 3 As shown, the method includes:

[0054] Step S201: Obtain a set of version objects. The set of version objects includes at least one version object, which includes the deployed component library and the corresponding component library version number.

[0055] Step S202: Create a corresponding library directory for each version object in the version object set to obtain a version directory set, wherein the storage locations corresponding to each library directory in the version directory set are logically isolated.

[0056] Step S203: Configure the version objects in the version object set to the corresponding library directory in the version directory set to obtain the multi-version component library.

[0057] Step S204: Obtain a multi-version component library. The multi-version component library includes at least one component library. Each component library corresponds to a component library version number. The component library includes components used to build the page. Each component corresponds to a component version number. Component libraries of different versions are logically isolated.

[0058] Step S205: In response to the page upgrade command, call the page metadata corresponding to the page to be upgraded. The page metadata includes at least the page identifier of the page to be upgraded, the target component library version number of the target component library corresponding to the page to be upgraded, and the target component version number of the target component.

[0059] Step S206: Search the multi-version component library based on page metadata to obtain the corresponding target component.

[0060] For example, firstly, all completed and deployable component library versions are collected. The component library resources for each version are packaged with their version number into independent version objects, forming a set of version objects that serves as the foundation for building a multi-version component library. Next, each version object in the set is traversed, and an independent file storage directory is created for each version object. The directory name corresponds one-to-one with the version number, and the storage paths of all directories are independent, achieving physical resource isolation and forming a set of version directories. Then, the component library resource files in each version object are written to the corresponding version's storage directory, completing resource deployment and archiving, forming a logically isolated multi-version component library. Next, the component library resources and version identifiers in all deployed directories are read to load and register the multi-version component library for subsequent page upgrades. After receiving a page upgrade command, the device retrieves the corresponding page's metadata based on the page identifier to obtain the target component library version and target component version information. Finally, the target component resource is located based on the version information in the metadata, completing the page's component version upgrade. One possible implementation uses file system directory isolation, which means that logical isolation is achieved based on file system directories. Another possible implementation uses containerized isolation, which means that each version of the component library is deployed with an independent static resource container. Each container has an independent runtime environment and resource path, and the network and storage between containers are isolated from each other.

[0061] The above steps establish a standardized multi-version component library deployment mechanism, achieving logical isolation between versions and avoiding resource overlap and conflicts between versions from the storage level.

[0062] Figure 4A flowchart illustrating a page upgrade method based on component management provided in this application embodiment. Figure 3 ;like Figure 4 As shown, the method includes:

[0063] Step S301: Obtain a multi-version component library. The multi-version component library includes at least one component library. Each component library corresponds to a component library version number. The component library includes components used to build the page. Each component corresponds to a component version number. Component libraries of different versions are logically isolated.

[0064] Step S302: In response to the page upgrade command, call the page metadata corresponding to the page to be upgraded. The page metadata includes at least the page identifier of the page to be upgraded, the target component library version number of the target component library corresponding to the page to be upgraded, and the target component version number of the target component.

[0065] Step S303: Extract the target component library version number and the target component version number from the page metadata; based on the version number rule information, configure the mapping relationship between the target component library version number and the target component version number, wherein the naming rule of the target component version number is associated with the corresponding target component library version number.

[0066] Step S304: Search the multi-version component library based on page metadata to obtain the corresponding target component, and use the target component to upgrade the page to be upgraded.

[0067] Steps S301 to S303 have been explained previously and will not be repeated here.

[0068] For example, in one possible implementation, a full search is performed based on the target component library version number and the target component version number in the page metadata to find the target component. Then, the service is stopped, the existing component is deleted, relevant resources are remotely invoked for updating, and finally the service is started to complete the update. In another possible implementation, a pre-configured mapping table is used. A version mapping table file is pre-generated for each version of the component library, recording all components contained in the library and their version numbers. When the system loads the component library, it directly reads the mapping table to quickly establish version correspondences. Based on the version mappings, the target component is located in multiple version component libraries to complete the page upgrade.

[0069] The above steps establish an association mapping between component library versions and component versions. Through a standardized version mapping mechanism, version addressing errors are avoided, and the accuracy of component resource loading is improved.

[0070] Furthermore, in one possible implementation, step S303 in this embodiment is specifically implemented as follows: step S303 includes:

[0071] Step S303-1: Generate the resource loading path based on the target component library version number and target component version number in the page metadata.

[0072] Step S303-2: Search the multi-version component library according to the resource loading path to obtain the target component.

[0073] Step S303-3: Upgrade the page to be upgraded based on the component.

[0074] For example, firstly, the root path of the component library is determined based on the target component library version number in the page metadata. Combining the target component version number and component identifier, a complete resource loading path for the target component is generated according to preset path concatenation rules. Secondly, the storage directory of the multi-version component library is searched according to the generated resource loading path to match the corresponding version of the component resource file. Finally, the matched component resource is loaded, replacing the original page component and completing the page upgrade rendering. For the generated resource loading path, one possible implementation uses static path concatenation, with a preset fixed resource directory structure, such as the format "base path / component library version number / component name / component version number / resource file," directly concatenating to generate the complete file access path. Another possible implementation uses dynamic route resolution, where version information and component identifiers are received through a unified resource gateway. The gateway dynamically resolves the corresponding resource storage address using routing rules and returns it to the front end for loading.

[0075] The above steps achieve precise location of component resources through path generation and retrieval, realize automated resource addressing based on version number, and improve the automation level of the upgrade process and resource loading efficiency.

[0076] Figure 5 A flowchart illustrating a page upgrade method based on component management provided in this application embodiment. Figure 4 ,like Figure 5 As shown, the method includes:

[0077] Step S401: Obtain a multi-version component library. The multi-version component library includes at least one component library. Each component library corresponds to a component library version number. The component library includes components used to build the page. Each component corresponds to a component version number. Component libraries of different versions are logically isolated.

[0078] Step S402: In response to the page upgrade command, call the page metadata corresponding to the page to be upgraded. The page metadata includes at least the page identifier of the page to be upgraded, the target component library version number of the target component library corresponding to the page to be upgraded, and the target component version number of the target component.

[0079] Step S403: Search the multi-version component library based on page metadata to obtain the corresponding target component.

[0080] Step S404: Generate difference attributes by comparing the first resource file and the second resource file.

[0081] Step S405: Generate the first configuration file based on the difference attributes.

[0082] Step S406: Based on the first configuration file, upgrade the page to be upgraded.

[0083] Steps S401 to S403 have been explained previously, so they will not be repeated here. We will begin the explanation from step S404.

[0084] For example, the first resource file here refers to the file describing the component resources in the old version before the update, and the second resource file here refers to the file describing the component resource information in the new version after the update. First, the first resource file corresponding to the old version and the second resource file corresponding to the new version are read, and the attribute structure is compared field by field to extract the added, deleted and modified information of the attributes and generate a set of differences. The first resource file refers to the component specification file of the target component before the update, which records the attribute definitions, configuration rules and other information of the old version. The second resource file refers to the component specification file of the target component after the update, which records the attribute structure and configuration rules of the new version. Second, based on the difference attribute information, where the difference attributes refer to the results obtained by directly comparing the differences in the attributes describing the component in the first resource file and the second resource file, the original configuration of the page is adapted to generate a first configuration file compatible with the new version of the component. Finally, the original page configuration is replaced with the first configuration file, the new version of the component is loaded and the page upgrade is completed. For comparing the first and second resource files, one possible implementation is to use a static field comparison method: parse the JSON structure of the two resource files, traverse the attribute fields layer by layer, and determine the addition, deletion, and value change of attributes by matching field names, directly generating a structured difference report; another possible implementation is to use a semantic comparison method: based on field name comparison, combine the attribute description text and type information to perform semantic matching on renamed attributes, identify the semantic changes of fields with the same name and the semantic equivalence of fields with different names, and generate more accurate difference attributes.

[0085] The above steps automatically generate adaptive configurations by comparing resource file differences, eliminating the need for manual page-by-page modifications, thus improving upgrade efficiency, reducing configuration errors caused by manual modifications, and ensuring the integrity of the user's original configuration.

[0086] Furthermore, in one possible implementation, step S405 in this embodiment is specifically implemented as follows: step S405 includes:

[0087] Step S405-1: Based on the configuration scenario and second resource file of the target component, generate a component skeleton, which includes at least the newly added field structure corresponding to the updated target component.

[0088] Step S405-2: Generate the first configuration file based on the difference attributes and the specification skeleton.

[0089] For example, firstly, based on the business configuration scenario of the target component, the attribute definitions in the second resource file are read, the complete attribute structure of the new version component is extracted, and a component skeleton containing only the field framework and default values ​​is generated as the basic template for configuration migration. Secondly, the difference attributes and the original configuration information are filled into the component skeleton according to preset rules to complete the migration and adaptation of the old configuration and generate a complete first configuration file.

[0090] The above steps ensure the standardization of configuration migration by unifying the configuration structure through the component skeleton, avoid missing fields or structural errors in the generated configuration files, guarantee the compatibility of the upgraded configuration with the new version of the component, and improve the structural consistency of the configuration files.

[0091] Furthermore, in one possible implementation, step S406 in this embodiment is specifically implemented as follows: step S406 includes:

[0092] Step S406-1: Compare the first configuration file and the target component library to obtain the updated component set. The updated component set includes component intersection, newly added component set, removed component set, and standardized attributes.

[0093] Step S406-2: Merge the updated component set into the standardized skeleton strategy, and upgrade the page to be upgraded based on the intersection inheritance rule, blind spot completion rule and invalidation removal rule to obtain the upgraded page.

[0094] For example, firstly, the component list in the first configuration file is compared with the component list in the target component library. Components are categorized according to their current status, generating an updated component set containing three categories: intersection, addition, and removal. Simultaneously, the corresponding specification attribute information is extracted. Secondly, the various components in the updated component set are backflowed into the specification skeleton according to the corresponding merging rules. The configuration is strategically merged using three rules: inheritance, completion, and removal, ultimately generating the upgraded page configuration and completing the page upgrade. For backflow merging, one possible implementation is an automatic full merging method. The system automatically merges all component configurations according to the three preset rules, generating the final upgraded configuration. Another possible implementation is a manual confirmation merging method. After the system completes the initial merging, configuration items with potential change risks are marked as pending confirmation, and a preview page is generated for developers to verify. Only after confirmation are the final configuration merge performed.

[0095] The above steps achieve precise configuration updates through categorized merging rules, ensuring both the integrity of configuration data and compatibility with new version components, thus realizing automated and refined configuration upgrades.

[0096] Furthermore, in one possible implementation, step S405-2 in this embodiment is specifically implemented as follows: step S405-2 includes:

[0097] Step S405-2-1: By performing attribute semantic recognition on the differential attributes, obtain the attribute category corresponding to the differential attributes. The attribute category includes one of the following: core attribute, auxiliary attribute, and dynamic attribute.

[0098] Step S405-2-2: Based on the attribute category, obtain the corresponding difference merging strategy.

[0099] Step S405-2-3: Generate the first configuration file based on the difference merging strategy and specification skeleton.

[0100] For example, firstly, semantic recognition is performed on each attribute in the difference attributes. By analyzing information such as attribute name, description text, and field type, it is classified into one of the following categories: core attributes, auxiliary attributes, and dynamic attributes. Secondly, based on the category to which the attribute belongs, a preset difference merging strategy is matched. For example, core attributes are preferentially retained based on their old values, while auxiliary attributes are preferentially adopted based on their new default values. Finally, according to the matched difference merging strategy, the attribute configuration is populated into the specification skeleton to generate the first configuration file.

[0101] The above steps refine the merging strategy through attribute semantic classification, thereby improving the accuracy of configuration migration.

[0102] Furthermore, in one possible implementation, step S405-2-2 in this embodiment is specifically implemented as follows: step S405-2-2 includes:

[0103] Step S405-2-2-1: Based on the pre-trained model, predict the priority of the difference merging strategy, wherein the pre-trained model is trained based on the first training sample, which includes attribute conflict logs and attribute configuration history.

[0104] Step S405-2-2-2: Determine the target difference merging strategy for attribute categories based on priority.

[0105] For example, firstly, a pre-trained model is invoked, inputting information such as the category, change type, and historical conflict records of the current difference attribute. The model outputs the risk score and suitability of each candidate merging strategy, thereby generating a strategy priority ranking. Then, based on the priority ranking, the strategy with the highest priority is selected as the target difference merging strategy for that attribute category, for subsequent configuration merging. For the pre-trained model, two methods can be used: decision tree model prediction or deep neural network model prediction. Decision tree model prediction involves training a classification decision tree model based on historical upgrade data, using attribute category, change magnitude, and historical conflict count as feature nodes to output the risk level of each strategy. Deep neural network model prediction involves training a deep neural network based on a large amount of historical upgrade logs and user behavior data to automatically extract the correlation between attribute features and strategy effectiveness, outputting a more accurate priority score.

[0106] The above steps use machine learning to dynamically optimize the priority of merging strategies, thereby improving the intelligence of configuration upgrades. At the same time, the prediction accuracy is continuously optimized as historical data accumulates, so that the upgrade adaptation effect is continuously improved through iteration.

[0107] Figure 6 A schematic diagram of the architecture of a page upgrade method based on component management provided in this application embodiment is shown below. Figure 3 As shown, this includes a page layer, a two-factor dynamic addressing gateway, a multi-version component library layer, and a rendering executor below. The page layer contains page identifier A and its bound component version number V1, page identifier B and its bound component version number V2, and page identifier C and its bound component version number V3. When a page is opened, the page identifier and component version are first sent to the two-factor dynamic addressing gateway. Then, the two-factor dynamic addressing gateway uses the page identifier and component version number as parameters to search and redirect to the multi-version component library layer to find the corresponding component library, such as component library V1, component library V2, and component library V3. Next, the resources from the found component library are returned to the two-factor dynamic addressing gateway. Finally, the rendering executor retrieves the component library resources from the two-factor dynamic addressing gateway and performs page rendering.

[0108] Figure 7 The flowchart provided for the embodiments of this application is as follows: Figure 7 As shown, firstly, the project build tool is used to upgrade to the new version online, triggering on-demand component upgrades. The project build tool reads the core metadata files of the old and new versions. The differential comparison engine in the project build tool compares the core metadata files of the old and new versions and outputs the added attributes, changed attributes, and obsolete attributes. At the same time, a new runtime attribute skeleton is generated based on the new version of the core metadata file, and valid attributes are extracted from the old version of the core metadata file. Then, based on the above output, a safe backflow and merging is performed to generate the component intersection, the new component set, and the removed component set. Finally, the upgraded configuration and compass are output.

[0109] Figure 8 The overall system architecture diagram provided for the embodiments of this application is as follows: Figure 8 As shown, the system architecture diagram includes a three-layer structure: hardware server layer, system architecture layer, and component resource layer. The hardware server layer consists of application server, database server, and file and resource server, which respectively provide page rendering and backend services, page metadata storage, and multi-version component library resource hosting capabilities. Each hardware device is deployed independently and works collaboratively.

[0110] The system architecture layer comprises a page layer, a page metadata layer, a two-factor dynamic addressing gateway, a multi-version component library layer, and an upgrade engine layer. Through the processing units within this system architecture layer, the entire process of page creation, version binding, dynamic addressing, component loading, and automatic upgrades is controlled.

[0111] The component resource layer stores multiple isolated versions of component libraries (such as component library a, component library b, and component library c shown in the diagram). Each version corresponds to an independent file set, supporting on-demand loading and upgrades. Key hardware structure relationships: The application server is responsible for page rendering and interaction, the database server persistently stores page metadata, and the file server logically isolates and stores multiple versions of the component library. The hardware communicates with each other through the network to collaboratively complete page rendering and component upgrades.

[0112] Figure 9 This embodiment provides a schematic diagram of the structure of a page upgrade device based on component management, as shown below. Figure 9 As shown, the page upgrade device 40 based on component management provided in this embodiment includes:

[0113] Module 401 is used to retrieve multi-version component libraries;

[0114] Module 402 is invoked in response to a page upgrade command to retrieve the page metadata corresponding to the page to be upgraded.

[0115] Search module 402 is used to search in the multi-version component library based on page metadata to obtain the corresponding target component and use the target component to upgrade the page to be upgraded.

[0116] In one possible implementation, before acquiring the multi-version component library, the acquisition module 401 is further configured to: acquire a version object set, the version object set including at least one version object, the version object including the deployed component library and the corresponding component library version number; create a corresponding library directory for each version object in the version object set to obtain a version directory set, wherein the storage locations corresponding to each library directory in the version directory set are logically isolated; and configure the version objects in the version object set to the corresponding library directories in the version directory set to obtain the multi-version component library.

[0117] In one possible implementation, after the calling module 402 calls the page metadata corresponding to the page to be upgraded in response to the page upgrade instruction, it is further configured to: extract the target component library version number and the target component version number from the page metadata; and configure the mapping relationship between the target component library version number and the target component version number based on the version number rule information, wherein the naming rule of the target component version number is associated with the corresponding target component library version number.

[0118] In one possible implementation, when the search module 402 searches in the multi-version component library based on page metadata to obtain the corresponding target component, it specifically performs the following steps: generating a resource loading path based on the target component library version number and the target component version number in the page metadata; and searching the multi-version component library according to the resource loading path to obtain the target component.

[0119] In one possible implementation, the search module 402 is further configured to: generate difference attributes by comparing the first resource file and the second resource file; generate a first configuration file based on the difference attributes; and when the search module upgrades the page to be upgraded using the target component, it is specifically configured to: upgrade the page to be upgraded based on the first configuration file.

[0120] In one possible implementation, when the search module 402 generates the first configuration file based on the difference attributes, it is specifically used to: generate a component skeleton based on the configuration scenario of the target component and the second resource file, wherein the component skeleton includes at least the newly added field structure corresponding to the updated target component; and generate the first configuration file based on the difference attributes and the specification skeleton.

[0121] In one possible implementation, when the search module 402 upgrades the page to be upgraded based on the first configuration file, it specifically performs the following steps: compares the first configuration file and the target component library to obtain an updated component set, which includes component intersections, newly added component sets, removed component sets, and specification attributes; merges the updated component set into the specification skeleton strategy; and upgrades the page to be upgraded based on intersection inheritance rules, blind spot completion rules, and invalidation removal rules to obtain the upgraded page.

[0122] In one possible implementation, when the search module 402 generates the first configuration file based on the difference attributes and the specification skeleton, it is specifically used to: obtain the attribute category corresponding to the difference attributes by performing attribute semantic recognition on the difference attributes, the attribute category including one of core attributes, auxiliary attributes, and dynamic attributes; obtain the corresponding difference merging strategy based on the attribute category; and generate the first configuration file based on the difference merging strategy and the specification skeleton.

[0123] In one possible implementation, at least one attribute category corresponds to multiple difference merging strategies, and the method is further used to: predict the priority of the difference merging strategy based on a pre-trained model, wherein the pre-trained model is trained based on a first training sample, the first training sample including attribute conflict logs and attribute configuration history; and determine the target difference merging strategy for the attribute category based on the priority.

[0124] Figure 10 This is a schematic diagram of the computing device provided in this embodiment. Figure 10 As shown, the computing device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0125] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0126] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0127] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0128] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0129] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0130] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0131] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0132] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0133] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0134] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0135] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0136] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0137] If a function 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, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0138] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0139] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A page upgrade method based on component management, characterized in that, The method includes: Obtain a multi-version component library, which includes at least one component library, each component library corresponding to a component library version number, and the component library includes components for building pages, each component corresponding to a component version number, with logical isolation between different versions of the component library; In response to a page upgrade command, the page metadata corresponding to the page to be upgraded is invoked. The page metadata includes at least the page identifier of the page to be upgraded, the target component library version number of the target component library corresponding to the page to be upgraded, and the target component version number of the target component. The page metadata is used to search the multi-version component library to obtain the corresponding target component, and the target component is used to upgrade the page to be upgraded.

2. The method according to claim 1, characterized in that, Before obtaining the multi-version component library, the following is also included: Obtain a set of version objects, wherein the set of version objects includes at least one version object, and the version object includes a component library and a corresponding component library version number; For each version object in the version object set, a corresponding library directory is created to obtain a version directory set, wherein the storage locations corresponding to each library directory in the version directory set are logically isolated. Configure the version objects in the version object set to the corresponding library directory in the version directory set to obtain a multi-version component library.

3. The method according to claim 1, characterized in that, After responding to the page upgrade instruction and calling the page metadata corresponding to the page to be upgraded, the method further includes: Extract the target component library version number and the target component version number from the page metadata; configure the mapping relationship between the target component library version number and the target component version number based on version number rule information, wherein the naming rule of the target component version number is associated with the corresponding target component library version number.

4. The method according to claim 1, characterized in that, The step of searching in the multi-version component library based on the page metadata to obtain the corresponding target component includes: Based on the target component library version number and the target component version number in the page metadata, a resource loading path is generated; The target component is obtained by searching the multi-version component library according to the resource loading path.

5. The method according to claim 1, characterized in that, The page metadata includes a first resource file and a second resource file corresponding to the target component. The first resource file represents the component specification of the target component before the update, and the second resource file represents the component specification of the target component after the update. The method further includes: By comparing the first resource file and the second resource file, a difference attribute is generated, which represents the result obtained based on the differences in attributes between the first resource file and the second resource file; Based on the aforementioned differences, a first configuration file is generated; Upgrading the page to be upgraded using the target component includes: Based on the first configuration file, upgrade the page to be upgraded.

6. The method according to claim 5, characterized in that, The step of generating the first configuration file based on the difference attributes includes: Based on the configuration scenario of the target component and the second resource file, a component skeleton is generated, which includes at least the newly added field structure corresponding to the updated target component; Based on the aforementioned differences in attributes and the specification skeleton, the first configuration file is generated.

7. The method according to claim 5, characterized in that, The step of upgrading the page to be upgraded based on the first configuration file includes: The first configuration file and the target component library are compared to obtain an updated component set, which includes component intersection, newly added component set, removed component set and specification attributes; The updated component set is backflowed and merged into the standardized skeleton strategy. Based on the intersection inheritance rule, blind spot completion rule and invalidation removal rule, the page to be upgraded is upgraded to obtain the upgraded page.

8. The method according to claim 6, characterized in that, The process of generating the first configuration file based on the difference attributes and the specification skeleton includes: By performing attribute semantic recognition on the differential attributes, the attribute category corresponding to the differential attributes is obtained. The attribute category includes one of core attributes, auxiliary attributes, and dynamic attributes. Based on the attribute categories, the corresponding difference merging strategy is obtained; Based on the difference merging strategy and the specification skeleton, the first configuration file is generated.

9. The method according to claim 8, characterized in that, At least one of the attribute categories corresponds to multiple difference merging strategies, and the method further includes: Based on a pre-trained model, the priority corresponding to the difference merging strategy is predicted, wherein the pre-trained model is trained based on a first training sample, which includes attribute conflict logs and attribute configuration history. Based on the priority, the target difference merging strategy for the attribute category is determined.

10. A computing device, characterized in that, The computing device includes a memory and a processor; The memory and the processor are coupled; The memory is used to store program instructions; The processor is used to invoke the program instructions to cause the computing device to perform the method as described in any one of claims 1-9.

Images