Page access method and device and page construction method and device

Abstract

The embodiment of the invention provides a page access method and device and a page construction method and device.The page access method comprises the steps that in response to a page access request sent by a client, a target page identifier in the page access request is obtained; determining a target page template, the page configuration data and a page object version mapping table corresponding to the target page template according to the target page identifier, wherein the page object version mapping table is updated under the condition of performing version updating on the page object; determining a target version of the page object according to the page object version mapping table, and generating page data of the target page according to the page object of the target version and the page configuration data; sending the page data to the client, so as to generate a target page at the client through visual rendering; through the mode of maintaining the page object version mapping table, the operation and maintenance burden and the version compatibility risk are reduced, the rendering load of the client side is reduced, and the high-stability and low-delay page access requirement is supported.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a page access method. One or more embodiments of this specification also relate to a page access apparatus. A page construction method, a page construction apparatus, a computing device, a computer-readable storage medium, and a computer program product are also included. Background Technology

[0002] In advertising, merchants typically use a builder to construct ad placement landing pages. The builder constructs ad placement landing pages through decentralized modules. When the decentralized modules are updated, merchants need to manually upgrade the updated modules in their ad placement landing pages one by one.

[0003] As the scale of the system expands, the number of ad placement landing pages exceeds tens of thousands, leading to an exponential increase in maintenance costs and compatibility risks caused by version inconsistencies, which severely restricts the operational efficiency and stability of large-scale deployment scenarios. Furthermore, ad placement landing pages are usually rendered on the client side, which results in high page loading latency and increased user churn. Summary of the Invention

[0004] In view of the above, embodiments of this specification provide a page access method, and one or more embodiments of this specification also relate to a page access apparatus. A page construction method, a page construction apparatus, a computing device, a computer-readable storage medium, and a computer program product are also included.

[0005] According to a first aspect of the embodiments of this specification, a page access method is provided, including: In response to a page access request sent by the client, obtain the target page identifier in the page access request; The target page template, page configuration data, and page object version mapping table corresponding to the target page template are determined based on the target page identifier. The page object version mapping table will be updated when the page object is updated. The target version of each page object in the target page template is determined according to the page object version mapping table, and the page data of the target page is generated according to the page objects of each target version and the page configuration data. The page data is sent to the client so that the target page can be generated on the client through visual rendering.

[0006] According to a second aspect of the embodiments of this specification, a page access device is provided, comprising: The request-response module is configured to respond to a page access request sent by the client and obtain the target page identifier in the page access request; The template determination module is configured to determine a target page template, page configuration data, and a page object version mapping table corresponding to the target page template based on the target page identifier, wherein the page object version mapping table will be updated when the page object is updated. The version determination module is configured to determine the target version of each page object in the target page template according to the page object version mapping table, and generate page data of the target page according to the page objects of each target version and the page configuration data. The data sending module is configured to send the page data to the client so that the client can generate the target page through visual rendering.

[0007] According to a third aspect of the embodiments of this specification, a page construction method is provided, comprising: In response to a page editing request for the current page, obtain the target page template corresponding to the current page; Determine the current version of the page object in the current page and the target version of the page object in the target page template; If the current version is inconsistent with the target version, the current version is updated to the target version to obtain the updated current page, wherein the page access method described above is applied to access the updated current page.

[0008] According to a fourth aspect of the embodiments of this specification, a page building apparatus is provided, comprising: The request-response module is configured to respond to a page editing request for the current page and obtain the target page template corresponding to the current page; The version determination module is configured to determine the current version of the page object in the current page and the target version of the page object in the target page template. The page update module is configured to update the current version to the target version when the current version is inconsistent with the target version, thereby obtaining the updated current page, wherein the page access method described above is applied to access the updated current page.

[0009] According to a fifth aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the above method.

[0010] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0011] According to a seventh aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0012] The page access method provided in one embodiment of this specification, upon receiving a page access request, can accurately determine the corresponding target page template and page configuration data based on the target page identifier in the page access request. Based on the page object version mapping table corresponding to the target page template, the page object of the target version in the target page template can be obtained. If the page object is updated, the page object version mapping table is updated. That is, by maintaining the page object version mapping table, the operational burden of manual upgrades and the risk of version compatibility are reduced. By combining the target version page object and page configuration data, complete page data is generated on the server side, realizing the front-end of page rendering logic. The page data is then sent to the client, allowing visual rendering to be completed on the client side, reducing the client's rendering load, significantly improving page loading speed and user experience, thereby supporting the requirements for highly stable and low-latency page access. Attached Figure Description

[0013] Figure 1 This is a schematic diagram illustrating a scenario of a page access method provided in one embodiment of this specification; Figure 2 This is a flowchart illustrating a page access method provided in one embodiment of this specification; Figure 3 This is a flowchart illustrating a page construction method provided in one embodiment of this specification; Figure 4 This is a schematic diagram illustrating the processing of a page access method provided in one embodiment of this specification; Figure 5 This is a schematic diagram illustrating the processing of each stage in a page access method provided in one embodiment of this specification; Figure 6 This is a flowchart illustrating the process of a page construction method provided in one embodiment of this specification. Figure 7 This is a schematic diagram of the structure of a page access device provided in one embodiment of this specification; Figure 8 This is a schematic diagram of the structure of a page building apparatus provided in one embodiment of this specification; Figure 9This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0014] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0015] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0016] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0017] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0018] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0019] Builder: A visual building editor, a tool or platform that allows users to quickly build and generate applications, web pages, interfaces or functional modules through a visual, drag-and-drop or configurable graphical interface without writing or with minimal coding.

[0020] Module: An abstraction of the smallest buildable unit in an operational scenario, including the module's own functions, logic, style, and data description.

[0021] UPR: Uniform Page Render, defines a set of page modules and their corresponding versions, and is a set of page rendering templates.

[0022] MoCut: An efficient tool for quickly creating personalized web pages based on images.

[0023] Hot Zone: A custom area selected on an image using the Magic Cut editor, which is then given specific interactive functionality.

[0024] This specification provides a page access method, and also relates to a page access device, a page construction method, a page construction device, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0025] See Figure 1 , Figure 1 A schematic diagram of a page access method according to an embodiment of this specification is shown.

[0026] Specifically, this page access method is applied to a page access system, which includes a client 102 and a server 104. The client 102 is used to send a page access request for a target page to the server 104.

[0027] Server 104 responds to a page access request sent by client 102 by obtaining a target page identifier from the request; determining a target page template, page configuration data, and a page object version mapping table corresponding to the target page template based on the target page identifier, wherein the page object version mapping table will be updated when the page object is updated; determining the target version of the page object based on the page object version mapping table, and generating page data for the target page based on the target version of the page object and the page configuration data; and sending the page data to client 102. Client 102 generates the target page through visual rendering based on the page data.

[0028] Client 102 may include a browser, an app (application), or a web application such as an H5 (Hypertext Markup Language 5) application, a lightweight application (also known as a mini-program), or a cloud application. The client device can be developed based on the software development kit (SDK) provided by the server, such as a Real-Time Communication (RTC) SDK. The client device can be deployed in an electronic device and depends on the device's operation or certain apps running on the device. The electronic device may have a display screen and support information browsing, such as a personal mobile terminal like a mobile phone, tablet, or personal computer. Various other types of applications can also be configured in the electronic device, such as human-computer interaction applications, model training applications, text processing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, and social media platform software.

[0029] Server 104 can be understood as a server providing various services, including physical servers and cloud servers. Examples include servers providing communication services to multiple clients, servers supporting backend training of models used on clients, and servers processing data sent by clients. It's important to note that Server 104 can be implemented as a distributed server cluster composed of multiple servers, or as a single server. Server 104 can also be a server in a distributed system, or a server integrated with blockchain. Server 104 can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology.

[0030] See Figure 2 , Figure 2 A flowchart of a page access method provided in one embodiment of this specification is shown, which specifically includes the following steps.

[0031] Step 202: In response to the page access request sent by the client, obtain the target page identifier in the page access request.

[0032] Here, the client can be understood as the terminal device that initiates a request to the server. For example, the client can be a browser or a mobile application, etc., without limitation. The page access request can be understood as the network request sent by the client to the server in order to obtain the content of a specific page. The page identifier can be understood as the information used to uniquely identify the specific page that the client wants to access. For example, the page identifier can be the page access address, page number, etc.

[0033] When a user accesses a page through a client, the client sends a page access request containing the target page identifier to the server. Upon receiving the page access request, the server parses the page access request and extracts the target page identifier to determine which specific page resource the user wants to access.

[0034] For example, when a user enters a page access address A (i.e., the target page identifier) ​​in a browser (i.e., the client), the browser sends a page access request to the server, enabling the server to obtain the page access address A from the page access request. Subsequently, the server generates the corresponding page data based on the page access address A and returns it to the user's browser.

[0035] Step 204: Determine the target page template, page configuration data, and page object version mapping table corresponding to the target page template based on the target page identifier. The page object version mapping table will be updated when the page object is updated.

[0036] In this context, a page template can be understood as the basic framework used to render and generate a page. It typically includes a fixed structural layout and replaceable placeholders. A page template can contain multiple page objects, such as page modules and hotspots. Page configuration data can be understood as dynamic content or personalized data related to the page, used to populate the page template. A page object version mapping table can be understood as a record table or index table that records the correspondence between each page object and its current version. Updating a page object refers to the process of assigning a new version number to a page object when its functionality is modified or defects are fixed.

[0037] Specifically, when the target page identifier is obtained from the page access request, the target page template (the target page is built based on the target page template) and page configuration data (the specific content data in the target page) corresponding to the target page are determined based on the target page identifier. When the page object version mapping table is used to record the version information of each page object (such as navigation bar, cards, bottom information bar, etc.) in the page, obtaining the page object version mapping table can ensure that the page objects in the target page template are the latest or the specified correct version (i.e., the target version).

[0038] For example, if the target page is product detail page 'a', the page template for the target page is determined to be the detail page template (i.e., the target page template) based on the target page identifier. This detail page template can be a page template containing multiple modules such as a title area, image display area, price information area, and recommended product area. The page configuration data determined by the target page identifier can be specific information retrieved from the database, such as product name, price, and description. If the detail page template contains an image carousel component and a user review component, the target version of the image carousel component can be determined to be v2.1 and the target version of the user review component to be v1.2 through the page object version mapping table. It should be noted that when the development team optimizes the user review component (i.e., updates the version), the version number of the user review component in the page object version mapping table needs to be updated to v1.3. Therefore, when requesting access to the page of the user review component, the v1.3 version of the user review component will be automatically loaded according to the page object version mapping table.

[0039] In one or more embodiments of this specification, the target page identifier includes a template identifier and page parameters. The template identifier is used to determine the target page template corresponding to the target page, and the page parameters are used to determine the content data corresponding to the target page. Specific implementation methods are described below: Based on the target page identifier, the target page template, page configuration data, and the page object version mapping table corresponding to the target page template are determined, including: The target page template is determined based on the template identifier in the target page identifier, and the page configuration data is determined based on the page parameters in the target page identifier; Determine the page object version mapping table corresponding to the target page template.

[0040] In this embodiment, the target page identifier is represented by a link address; the template identifier can be understood as the part parsed from the link address that indicates the page template; and the page parameters can be understood as the part parsed from the link address that specifies the specific instance or personalized content of the page.

[0041] Specifically, the target page identifier consists of two parts: a template identifier with different functions and page parameters. The template identifier is used to determine the target page template corresponding to the target page that the user wants to access, while the page parameters are used to determine which specific data is filled in based on the target page template to generate the target page.

[0042] By parsing the target page identifier, the template identifier and page parameters can be extracted. The target page template can be determined based on the template identifier, and the page configuration data can be determined based on the page parameters. Furthermore, the page object version mapping table corresponding to the determined target page template can be obtained.

[0043] It should be noted that each page template is created by the platform developers. By creating and publishing page templates, merchants, enterprises and other users can build instantiated pages based on the published page templates. Each page template corresponds to a template identifier. In the embodiments of this specification, the template identifier corresponding to the page template is represented by the page template address (i.e., UPR address).

[0044] In one or more embodiments of this specification, the page access request also includes grayscale information. In fact, each page template corresponds to a grayscale release rule, which defines how specific user traffic can be directed to different versions of the page object. Specific implementation methods are described below: In response to a page access request sent by the client, obtain the target page identifier from the page access request, including: In response to the page access request sent by the client, obtain the target page identifier and grayscale information in the page access request; Based on the target page identifier, the target page template, page configuration data, and the page object version mapping table corresponding to the target page template are determined, including: The target page template and the page configuration data are determined based on the target page identifier; Based on the gray-scale release rules corresponding to the target page template and the gray-scale information, determine the page object version mapping table corresponding to the target page template.

[0045] Grayscale information can be understood as data attached to page access requests to identify client or user characteristics (such as user ID, device type, geographical location, etc.); grayscale release rules can be understood as a pre-configured set of logical strategies. Grayscale release rules define how to direct specific user traffic to a new version or a different version of the page object based on different grayscale information. For example, the grayscale release rules define that page access requests corresponding to device type A will generate the page using the test version of the page object, while page access requests for other device types will generate the page using the target version of the page object.

[0046] Specifically, when the server receives a page access request, the request includes not only the target page identifier but also grayscale information. The system determines the corresponding target page template and page configuration data based on the target page identifier. Crucially, the target page template does not correspond to a unified page object version mapping table. Instead, based on the grayscale release rules, a target page template can correspond to multiple page object version mapping tables, with different versions of page objects in each table. Alternatively, the target page template may correspond to a unified page object version mapping table, but the page objects within those tables may have multiple different versions. The visibility of these different versions is determined by the grayscale release rules. Therefore, by matching the grayscale information with the grayscale release rules, the system dynamically determines the page object version mapping table corresponding to the page access request. This means that when different users access the same page, the system can load different versions of the page object for them.

[0047] For example, when platform maintenance personnel upgrade the "Comments" module in a product details page template, they can configure a canary release rule for this module: users with user IDs ending in 1 will use the new v2.0 version of the comments module, while other users will continue to use the stable v1.5 version. When user A (user ID ending in 1) accesses product details page a (which is built based on the product details page template), their user ID will be carried as canary information in the page access request. Based on this canary information and the aforementioned canary release rule, version mapping table a1 of the v2.0 comments module will be selected to render the page; while when user B (user ID ending in 2) accesses the same product details page a, the default version mapping table a2 will be selected for them, thus loading the v1.5 comments module.

[0048] The page access method provided in the embodiments of this specification dynamically associates the canary release rules with the page object version mapping table, allowing new versions of page objects to be smoothly and securely pushed to specific user groups through configuration rules, greatly reducing the risk of full updates.

[0049] In one or more embodiments of this specification, canary release rules are typically used to implement phased version releases. That is, when a page object is upgraded to a new version, not all pages are immediately updated. Instead, a small group of users are allowed to access the new version (which can be considered a test version). This allows for testing the stability of the version update on a small scale. Once the risk-free process is ensured, a full release is then conducted. Therefore, different versions of the page object are determined based on the different canary release information carried in the page access requests. Specific implementation methods are described below: Based on the canary release strategy corresponding to the target page template and the canary information, determine the page object version mapping table corresponding to the target page template, including: If the grayscale information matches the grayscale release rule corresponding to the target page template, the first version mapping table is determined as the page object version mapping table corresponding to the target page template; otherwise, the second version mapping table is determined as the page object version mapping table corresponding to the target page template. The first version mapping table contains the page object of the test version, and the second version mapping table contains the page object of the current version. The test version is obtained by updating based on the current version.

[0050] In this context, the page objects in the first version mapping table may correspond to new versions in the testing phase, while the page objects in the second version mapping table correspond to stable versions in the application phase. That is, the second version mapping table can be understood as a page object version mapping table that has been tested and is stable. It guides the system to load page objects of the stable versions that are currently widely used online. The test version can be understood as a version that has been upgraded compared to the current version but has not yet been fully released. The current version can be understood as the stable version that is currently widely used online.

[0051] Specifically, the grayscale information in the page access request is compared with the preset grayscale release rules. If the grayscale information matches the grayscale release rules, the first version mapping table corresponding to the target page template is selected, meaning that the page access request is included in the grayscale test scope and will experience the new version page containing the test version page object. If the grayscale information does not match the grayscale release rules, the second version mapping table corresponding to the target page template is selected, meaning that the page access request will continue to see the stable version page composed of the current version page object, thus achieving precise traffic classification.

[0052] Continuing with the previous example, when upgrading the "Comments" module in the product details page template, a canary release rule can be configured for this module: users with a user ID ending in 1 will use the new version v2.0 (i.e., the test version) of the comments module, while other users will continue to use the stable version v1.5 (i.e., the current version) of the comments module. When user A accesses product details page a built based on the product details page template, it is determined that user A's user ID ends in 1, meaning that user A's canary release information conforms to the canary release rule corresponding to the product details page template. Therefore, the first version mapping table containing the test version of the comments module is determined to be the page object version mapping table. When user B accesses product details page a built based on the product details page template, it is determined that user B's user ID ends in 2, meaning that user B's canary release information does not conform to the canary release rule corresponding to the product details page template. Therefore, the second version mapping table containing the current version of the comments module is determined to be the page object version mapping table.

[0053] In practical applications, a target page template can correspond to a page object version mapping table. However, the page object version mapping table can contain multiple versions of page objects. Based on the grayscale information and the grayscale release rules of each page object, the version corresponding to each page object can be determined. For example, the grayscale release rule of page object a in the target page template is related to the user identifier, the grayscale release rule of page object b is related to the device type, and the grayscale release rule of page object c is related to the geographical location. This method can achieve traffic allocation at the page object level. That is, for a page access request, the grayscale information it carries includes three types of information: user identifier, device type, and geographical location. Based on this grayscale information, it can be determined that page object a is the test version, page object b is the current version, page object c is the test version, etc., without further limitation.

[0054] The page access method provided in the embodiments of this specification allows for the safe rollout of the test version to a small group of specific users for real-world testing through a canary release rule, while the vast majority of users continue to use the risk-free stable version (i.e., the current version). This significantly reduces the risk of systemic problems that may arise from a direct full release, ensuring a smoother and more scientific feature iteration process.

[0055] Step 206: Determine the target version of each page object in the target page template according to the page object version mapping table, and generate the page data of the target page according to the page objects of each target version and the page configuration data.

[0056] Here, a page object can be understood as an independent, reusable functional module, hotspot, or other object that constitutes a page; a target version can be understood as the version corresponding to each page object (such as a button, navigation bar, or product card) retrieved from the page object version mapping table; and page data can be understood as the final assembled complete data package containing all the structure, style, content, and logical information of the page. For example, the page data can be the HTML (Hyper Text Markup Language) document corresponding to the page.

[0057] Specifically, the target page template and page configuration data corresponding to the page access request have been determined through the above embodiments. The target version corresponding to each page object in the target page template has been determined through the canary release rules. Therefore, the version code of the target version corresponding to each page object can be loaded. The server combines each page object of the target version with the specific content provided by the page configuration data, and finally outputs complete page data that can be parsed and rendered by the client.

[0058] In practical applications, when generating page data for a product details page, the page object version mapping table determines that the image carousel component uses version 2.1, the buy button uses version 1.5, and the user review component uses version 3.2. Then, the page configuration data such as product name, price, and description are retrieved from the database. The image carousel code (version 2.1), the buy button code (version 1.5), and the review code (version 3.2), along with the product's specific information, are integrated into the product details page template. A complete HTML document is then generated through logical rendering and returned to the user's browser.

[0059] In one or more embodiments of this specification, the version corresponding to each page object in the target page template is determined based on the page object version mapping table selected through grayscale information and grayscale release rules. Specific implementation methods are described below: The target version of each page object in the target page template is determined according to the page object version mapping table, including: If the page object version mapping table is the first version mapping table, the target version of each page object in the target page template is determined according to the first version mapping table; When the page object version mapping table is the second version mapping table, the target version of each page object in the target page template is determined according to the second version mapping table, wherein the target version of the page object is a test version or the current version.

[0060] Specifically, each page object version mapping table contains the identifier of the page object and the version information corresponding to each page object. When the page object version mapping table corresponding to the target page template is selected, the target version corresponding to each page object can be determined according to the version information of the page objects in the page object version mapping table.

[0061] In practice, if the first version mapping table is selected based on the grayscale information matching the grayscale release rules, the target version of the page object is determined according to the version information of each page object in the first version mapping table. If a page object with a corresponding test version exists in the first version mapping table, a new version page containing the test version page object can be rendered, allowing users to experience the new version page. If the second version mapping table is selected, the target version of the page object is determined according to the version information of each page object in the second version mapping table. If a page object with a corresponding stable version exists in the second version mapping table, a stable version page containing the current version page object can be rendered, ensuring that most users receive a consistent and risk-free experience.

[0062] In one or more embodiments of this specification, when multiple page objects and page configuration data are determined, page data for a personalized, version-controlled target page can be generated by injecting the page configuration data into the corresponding page objects. Specific implementation methods are described below: Based on the page objects of each target version and the page configuration data, generate the page data for the target page, including: Obtain multiple page objects and the page configuration data, wherein the page objects contain modules and / or hot zones, and each page object is an object of the target version; Replace the target fields in the multiple page objects with the page configuration data to generate object data in the target format; Based on the target structure of the target page template, the object data is concatenated to obtain the page data of the target page.

[0063] In this context, the target field can be understood as a placeholder or variable reserved in the page object for populating dynamic content; the object data can be understood as an independent data block (such as a piece of HTML or a JSON object) formed after a single page object (such as a navigation bar or a product card) has been populated with specific configuration data. In the embodiments of this specification, the target format is HTML, that is, by replacing the target field, a piece of HTML code corresponding to each page object is obtained; the target structure can be understood as a predefined structural layout of the page object; and splicing can be understood as the process of combining the object data that has been populated with data into a complete page data according to the predefined layout of the target page template.

[0064] Specifically, based on the target versions of each page object determined above, the page object code and corresponding page configuration data of the target version are obtained; the placeholders (i.e., target fields) in the page object code are replaced with the actual values ​​(such as product titles and image links) in the page configuration data, thereby obtaining the HTML code (i.e., object data) containing real content for each page object; and according to the target structure in the target page template (e.g., the top is the navigation module, the middle is the product information module, and the bottom is the recommendation hotspot), the obtained object data is concatenated in sequence to finally output the complete page data (HTML document).

[0065] For example, given the image carousel module and its corresponding image list configuration data in version 2.1, the target field {"images to be carouseled"} in the image carousel module is replaced with the image data from the image list configuration data, generating HTML code containing real image data (e.g., carousel object data). Similarly, the purchase button and its corresponding price configuration data in version 1.5 can be obtained, and the same replacement operation is performed to obtain the button object data. By customizing the data configuration of each page object in the product details page template, the target format object data corresponding to each page object in the product details page template is obtained. Then, according to the structure and layout of the product details page template, the processed carousel object data, button object data, and object data of other modules (such as title and description) are concatenated to finally generate a complete and usable product details page HTML document.

[0066] The page access method provided in the embodiments of this specification achieves a high degree of decoupling and flexible reuse of content and style by splitting the page into versioned objects and configurable data. This not only allows page objects (modules / hotspots) to be developed, tested, and version-managed as independent units and reused in different pages, improving development efficiency, but also allows a large number of personalized pages to be quickly generated without modifying the code by replacing target fields, greatly improving operational flexibility.

[0067] In one or more embodiments of this specification, to improve client rendering efficiency and loading performance, alleviate user anxiety about blank screens, and enhance user experience, the first screen's page data is first obtained, and the second screen's data corresponding to the target page is loaded asynchronously. Specific implementation methods are described below: After obtaining the target page identifier from the page access request, the method further includes: Based on the target page identifier, the secondary screen data corresponding to the target page is asynchronously obtained, wherein the secondary screen data is used for visual rendering of the non-first screen portion of the target page on the client.

[0068] Asynchronous retrieval can be understood as a non-blocking data loading method, that is, while the main content of the page (such as the first screen) begins to load or render, requests for additional data are initiated concurrently in the background without waiting for the data to be returned before subsequent processing; secondary screen data can be understood as the data required to generate and render the part of the page that the user needs to scroll down to see (i.e., non-first screen); non-first screen can be understood as the content area below the initial visible window (i.e., the first screen) on the page that the user needs to scroll down to see.

[0069] Specifically, after parsing the target page identifier (i.e., determining which page the user wants to access), the server obtains the page data for the first screen according to the steps described above, ensuring that the user can see the core information of the page as quickly as possible. It then asynchronously initiates a request for the second screen data. When the page data for the first screen is returned to the browser, and the browser displays the content of the first screen through visual rendering, the server has also asynchronously loaded the page data corresponding to the second screen (i.e., the second screen data) and sent it to the browser. When the user scrolls through the target page, the browser displays the content of the second screen through visual rendering, thus achieving a seamless browsing experience and effectively reducing the time the user waits for the entire page to fully load.

[0070] For example, on a product details page, the first screen typically includes a carousel of product images, product prices, and a buy button. When the server receives a page access request, it synchronously processes and returns page data containing this first screen content. Simultaneously, based on the target page identifier, the server asynchronously retrieves page data such as the "Related Product Recommendations" list and "Product Details" data (i.e., secondary screen data). When a user opens a product details page, they instantly see the first screen content, while the secondary screen data is asynchronously loaded during their browsing. Therefore, when the user scrolls to the bottom of the page after viewing the last part of the first screen, the recommended related products are immediately rendered, reducing the loading delay of the first screen.

[0071] The page access method provided in the embodiments of this specification, based on the server returning a complete HTML document to the client to improve the first screen loading speed, adopts an asynchronous method to obtain secondary screen data, which can reduce the amount of data loaded at one time, further accelerate the first screen loading speed, reduce users' anxiety about blank screens, thereby improving user experience and reducing user churn rate.

[0072] Step 208: Send the page data to the client to generate the target page through visual rendering on the client.

[0073] Visual rendering can be understood as the process by which the client receives page data and then draws a visible and interactive visual interface on the screen.

[0074] Specifically, the server generates the page data (HTML document) of the target page through logical rendering and returns this page data to the client as a response to the page access request. Upon receiving the page data, the client transforms the page data into a graphical page that is perceived by the user through visual rendering, thus completing the process from page access request to target page presentation.

[0075] In practical applications, when a user visits a product details page, the server generates an HTML document (i.e., page data) containing product information, image links, styles, etc., based on the page access request, and then sends this HTML document to the user's browser (client). After receiving the page data, the browser renders the elements in the page onto the screen pixels and displays an interactive product details page by binding interactive logic.

[0076] The page access method provided in the embodiments of this specification realizes isomorphic rendering on the server side and the client side (combining server-side rendering and client-side rendering). Specifically, the complex page generation logic is completed on the server side, and the display and interaction are implemented on the client side. That is, the server pre-generates the first screen HTML document and hands it over to the client to bind subsequent interactions, thereby improving the loading performance of the client's first screen page and reducing the user's anxiety about a blank screen.

[0077] The page access method provided in the embodiments of this specification constructs a centralized version module management system, establishes a mapping relationship between page templates and instantiated pages, and when the page object in the page template is updated, the system can automatically detect the version change and realize the ability to hot replace the corresponding page object in the instantiated page, thereby solving the problems of low efficiency and error-proneness caused by traditional manual updates; and through isomorphic rendering of the server and client, it effectively improves the loading performance of the client's first screen page and alleviates the user's anxiety about the white screen during the waiting process.

[0078] See Figure 3 , Figure 3 A flowchart of a page construction method provided in one embodiment of this specification is shown, which specifically includes the following steps.

[0079] Step 302: In response to a page editing request for the current page, obtain the target page template corresponding to the current page.

[0080] In this context, a page editing request can be understood as an operation command triggered by the user in the builder to edit an existing page; the current page can be understood as a page that has already been built, and the user can edit the current page.

[0081] Specifically, when a user edits the current page using the builder, the target page template corresponding to the current page will be determined first to ensure that when there is a version upgrade of the page object in the target page template, the page object of the upgraded version in the current page will be updated synchronously.

[0082] In practice, upon receiving a page editing request, the page group corresponding to the current page is determined. Each page group corresponds to a unified page template, and the target page template for the current page is determined based on the management page address corresponding to the page group. The specific implementation method is as follows: In response to a page editing request for the current page, the target page template corresponding to the current page is obtained, including: In response to a page editing request for the current page, obtain the page group corresponding to the current page and the management page address corresponding to the page group; Based on the management page address, obtain the target page template corresponding to the current page.

[0083] Page grouping can be understood as a page management strategy that categorizes pages using the same page template into a logical group for easy batch management; the management page address can be understood as the storage location or access link address of the page template that the page group depends on.

[0084] Specifically, upon receiving a page editing request, the system queries the page group to which the current page belongs, determines the address of the management page that manages the resources of that page group, and then retrieves the latest target page template based on the management page address.

[0085] In practical applications, when a merchant wants to change the background color of a marketing campaign page in their store, the merchant can click the "Edit" button for that marketing campaign page in the builder, which triggers a page editing request. Based on this page editing request, the builder first finds out that the marketing campaign page belongs to the "Marketing Page" page group. The management page address corresponding to this page group is a link address that points to a store of marketing campaign templates. Based on this link address, the latest marketing campaign template is obtained.

[0086] The page construction method provided in the embodiments of this specification achieves centralized and standardized management of page templates through a group management mechanism. It ensures that the target page template corresponding to the page group can be determined through the management page address corresponding to the page group, so that subsequent page editing operations are based on a unified and up-to-date template. This avoids inconsistencies in page style or function caused by template version chaos, and improves the efficiency and reliability of large-scale page management.

[0087] Step 304: Determine the current version of the page object in the current page and the target version of the page object in the target page template.

[0088] Here, the current version can be understood as the version number currently being used by each page object in the current page instance; the target version can be understood as the version number that the target page template currently requires the page objects to reach, as parsed from the latest target page template.

[0089] Specifically, the system retrieves page objects from the currently running online page and records the version number (current version) of each page object (such as navigation bar, buttons, and product cards). From the retrieved target page template, it parses out the version number (target version) that each page object in the target page template should have, thereby accurately identifying the version differences between the page objects in the current page and the target page template through comparison.

[0090] In practical applications, in a centralized console, the operations personnel responsible for creating or managing page templates can update the versions of page objects within the templates. When a page object is updated, the page template containing that object will update its corresponding page object version mapping table. As mentioned in the above embodiment of the page access method, when a user accesses a page, the target version of the page object can be determined based on the page object version mapping table corresponding to the target page template. Similarly, in this embodiment, when a merchant edits the current page built based on a page template, it is also necessary to determine the target page template corresponding to the current page and, based on the page object version mapping table corresponding to the target page template, determine the target version of the page object.

[0091] By obtaining the target version of the page object and the current version of the page object in the instantiated current page, the two versions can be compared to determine whether the page object in the target page template has been updated compared to the current version.

[0092] The page construction method provided in the embodiments of this specification can accurately and efficiently discover the differences between the current page and the latest page template by obtaining the current version of the page object in the current page and the target version of the page object in the target page template. This provides a clear basis for subsequent targeted updates and ensures the accuracy of page iteration.

[0093] Step 306: If the current version is inconsistent with the target version, update the current version to the target version to obtain the updated current page, wherein the updated current page is accessed using the page access method described above.

[0094] Inconsistency can be understood as the version number of a certain page object in the current page being lower than the corresponding target version number in the target page template; update can be understood as the process of upgrading a page object from the old current version to the new target version.

[0095] Specifically, the process iterates through the page objects of the current page. If the current version of a page object is inconsistent with the target version in the target page template (usually the current version is older), the update process is triggered to upgrade the version of the page object to the target version. Once the iteration is complete, an updated page that is consistent with the version in the target page template is obtained, thus ensuring that any editing of the current page is based on the latest version of the updated page. Based on the user's edits and the updated page, the updated current page is obtained.

[0096] In practical applications, when the page objects in the target page template undergo version upgrades, the current page built based on the target page template has the ability to automatically detect version changes. That is, when accessing or editing the current page, the target version of the page objects in the current page is determined through the page object version mapping table corresponding to the target page template. Based on the target version of the page objects, a target page is generated for users to access or an updated page is generated for users to edit. This hot-replacement capability of page objects in instantiated pages solves the problem of fragmented version maintenance.

[0097] Of course, in reality, when there is a version upgrade of the page object in the target page template, the target page template is released through the gray release rule. Therefore, similar to the above embodiment, the gray information in the page editing request is determined, and the target version of the page object visible to the user is determined according to the gray information and the gray release rule. Specifically, when the gray information conforms to the gray release rule, the target version visible to the user can be the test version, while when the gray information does not conform to the gray release rule, the target version visible to the user can be the stable version.

[0098] The page building method provided in the embodiments of this specification achieves automated synchronization and updating of page object versions through version comparison and automatic updates, which greatly improves the efficiency and reliability of page maintenance. It ensures that when editing existing, already built pages, the already built pages can also quickly keep up with the version updates of the corresponding target page template, while maintaining fine control capabilities such as gray-scale releases, effectively reducing the cost of manual updates.

[0099] In one or more embodiments of this specification, merchants or enterprises can also create new instantiated pages in the builder, in which case the target page will be generated directly based on the latest version of the target page template. Specific implementation methods are described below: In response to a page creation request, retrieve and display multiple preset page templates; In response to a page selection request, the target page template is determined from the plurality of preset page templates; In response to a page building request, a target page based on the target page template is generated according to the target page object of the target version in the target page template and the configuration data of the target page object.

[0100] Here, a page creation request can be understood as a request triggered by a user clicking a button such as "New Page" in the builder, indicating an intention to create a new page; preset page templates can be understood as multiple page templates pre-designed by the platform, with different templates corresponding to different scenarios, allowing users to choose the appropriate template based on their application scenario; a page selection request can be understood as an instruction from a user, after browsing multiple preset page templates, to confirm the selection of a target page template through clicks, drags, or other operations; and a page building request can be understood as various personalized configuration operations performed by the user on the target page template (such as modifying text, uploading images, etc.) to build a complete instantiated page.

[0101] Specifically, when a user clicks the "New Page" button in the builder to attempt to build a page, the builder interface displays multiple pre-developed and available preset page templates in an intuitive form (such as a list). After browsing multiple preset page templates, the user can select a target page template according to their own needs. That is, the new page created by the user will be built based on the overall structure and layout, available component types, etc. of the target page template.

[0102] Each page object in the target page template corresponds to a target version. When a user personalizes the selected target page template, they are actually generating or editing the configuration data corresponding to each page object. Based on the target page objects of the target version in the target page template and the configuration data corresponding to each target page object configured by the user, the final, accessible target page is generated and can be published for customers to browse.

[0103] In practical applications, the builder interface can include a real-time preview area, allowing users to preview the generated target page in real time during the personalized configuration process, thereby improving the user's page building experience.

[0104] The page building method provided in this specification provides preset page templates, allowing users to quickly start editing or creating pages without professional development skills. This simplifies complex development work into intuitive content configuration. Furthermore, by determining the target version of the page object, it ensures the stability and consistency of the generated pages, avoiding version confusion and achieving efficient, standardized, and flexible page building. Real-time preview provides instant feedback, greatly improving the efficiency of page creation and user experience.

[0105] See Figure 4 , Figure 4 This diagram illustrates the processing steps of a page access method provided in one embodiment of this specification.

[0106] Upon receiving a page access request, if the target page to be accessed by the user is determined to belong to "Group 1" based on the target page identifier in the page access request, the unified rendering page of Group 1 is loaded. This unified rendering page can be understood as the target page template in the above embodiment. If the target page to be accessed by the user is determined to belong to "Group 2", the unified rendering page of Group 2 is loaded.

[0107] Specifically, the page configuration information includes page information (i.e., basic page attribute information, such as page identifier, page type, etc.), object data, object order, etc.; based on the page objects contained in the target page, the object data corresponding to each page object is retrieved and the object version corresponding to each page object (i.e., the target version) is confirmed.

[0108] The unified rendering page includes custom configurations (such as page style, theme color, etc.), object version, and Aladdin configuration. The Aladdin configuration is a structured data object that defines what content to display, in what style, and what interactive behaviors a specific area on the page (usually dynamic content, promotional activities, or advertising space) needs to display.

[0109] The rendering engine, based on the configured rendering scheme, collects, integrates, and verifies data from the information in the unified rendering page and page configuration information, and loads the event tracking configuration for subsequent user behavior data collection. Combining object version data, custom configurations, Aladdin configurations, and other data, it performs server-side rendering (SSR) according to object order, generates an HTML document, and returns the complete HTML to the client to improve the first screen loading speed. If server-side rendering times out or fails, a client-side rendering (CSR) degradation mechanism is triggered, and rendering is then performed by the client.

[0110] The page access method provided in the embodiments of this specification renders a page composed of multiple independent page objects. Each page object has an independent object version, and the object data is separated from the object version, thus decoupling the content from the framework. When upgrading the version of a page object, the object version of the page object in the instantiated page can be automatically and hot-swapped. Combined with unified management of groups, batch updates of pages are achieved. Furthermore, the CSR degradation mechanism ensures the availability of the page under abnormal conditions.

[0111] See Figure 5 , Figure 5 This document illustrates a schematic diagram of the processing stages in a page access method provided in one embodiment of this specification.

[0112] Upon receiving a page access request, the system first initializes and verifies the request, then acquires dynamic data in parallel, integrates data resources before rendering, and finally generates complete page data during the rendering and splicing stages, injecting it into the root container to complete the output of the page data.

[0113] During the initialization phase, upon receiving a page access request (UPR path? wh_pid=receiving page path), the system checks if an external receiving page identifier (i.e., wh_pid) exists in the request. This external receiving page identifier indicates that the page is not a regular independent page, but rather an entry page used to receive traffic on an external platform. If so, a dynamic link redirection is performed. Based on the external receiving page identifier, a current page link (i.e., the target page identifier in the above embodiment) is generated to access the current page. This current page link contains the UPR address (i.e., the template identifier in the above embodiment) and page parameters (used to identify page configuration data).

[0114] The system requests the page objects contained in the current page based on the current page link, and compares the obtained page objects with the page objects in the unified rendering page. If a version mismatch is found, the object version is automatically updated and the data is replaced to obtain the updated target version page object. In other words, by comparing and updating versions, it can ensure that the current page uses the latest and most stable object version for rendering, thereby ensuring functional consistency and reducing errors.

[0115] During the dynamic data source processing phase, in order to prioritize the loading speed of the first screen, the first screen data (i.e. the configuration data required for the first screen) needed to render the content of the first screen of the current page is obtained. In parallel, the link address of the second screen is generated based on the external landing page identifier, and the page data corresponding to the second screen is requested and obtained, that is, the specific configuration data corresponding to the second screen is obtained.

[0116] In the pre-rendering stage, the dynamic data obtained in the dynamic data source processing stage is formatted, cleaned, and standardized, thereby transforming it into static data suitable for use by the server-side rendering engine.

[0117] During the rendering and splicing phase, the version-controlled page objects prepared in the initialization phase are combined with the static data formatted in the pre-rendering phase. Each page object's HTML fragment (i.e., the object data in the above embodiment) is rendered one by one. All these rendered HTML fragments are then spliced ​​together according to the structure of a unified rendered page to form a complete HTML document. In practical applications, the external landing page can be displayed in the native application or in other applications outside the native application. When a user interacts with the external landing page through other applications, to guide the user to jump to the native application, this embodiment inserts a piece of client-initiating JavaScript code (referred to as script) into the HTML document. Client-initiating refers to initiating the native client application. Its core function is to attempt to invoke the native application corresponding to the external landing page. If the initiation fails, the user is guided to perform subsequent operations (such as jumping to the app store to download).

[0118] The complete HTML document is injected into the root wrapper. The root wrapper can be understood as the root node in the HTML document or the root component of the server-side rendering framework. In fact, the server-side rendering engine will start from the root wrapper and recursively render the entire component tree, eventually generating a complete HTML string. In this process, the root wrapper ensures that all child components can obtain the necessary context and global functionality. In isomorphic rendering, it is a key architectural design that coordinates the rendering results between the server and the client and ensures the consistency of the initial state.

[0119] In this embodiment, an HTML document containing complete content is sent to the client browser, which can render it quickly, greatly reducing the white screen time. Meanwhile, the client-side JavaScript takes over the interaction logic to achieve isomorphic rendering.

[0120] In practical applications, the root container has asynchronous permission control under preview mode. This is a security check for preview mode. If the current request is a page preview from the management backend, the system will asynchronously verify whether the user has permission to view the page to prevent unauthorized content from being leaked.

[0121] See Figure 6 , Figure 6 A flowchart illustrating the processing steps of a page construction method provided in one embodiment of this specification is shown.

[0122] Specifically, this page building method can automatically detect and synchronize existing and completed pages in the builder, thereby building the updated page. Its main purpose is to ensure that when the page object or dynamic content area (magic hot zone) used by the current page is updated, the page object of the current page can be automatically synchronized to the target version, thereby solving the problems of inconsistent page styles, missing functions or disordered content caused by template iteration.

[0123] In practice, after a user enters the builder interface and completes user identity verification, the system retrieves the page group corresponding to the current page and the address of the management page under that group. Based on this management page address, it obtains the configuration information of the page template, specifically the version information of the page objects within the template. The system compares the versions of the page objects in the template with the versions currently used on the page, automatically extracting any changed page objects (mainly page modules). The system then updates the versions of these objects to match those in the template. Furthermore, the process includes a check for "magic cutting hotspots." If a change in the magic cutting hotspot configuration is detected, the system modifies the configuration accordingly and updates the hotspot version; otherwise, the process terminates. This automated detection and update process effectively ensures the standardization and consistency of page objects and dynamic content areas.

[0124] In fact, the embodiments of this specification provide a three-level rendering system. At the UPR layer, UPR templates are created or edited through a centralized module console, defining the version baseline of page objects and configuring grayscale strategies (i.e., grayscale release rules). Visual version switching of customized content on template pages can be achieved through visualization. When publishing page templates, a version mapping table containing information such as module identifier, module version, hotspot identifier, module version, and UPR address can be generated, and a grayscale release strategy based on traffic levels is supported.

[0125] In the visual building layer, merchants or enterprises can access the page builder and use it to visually construct personalized pages based on preset page templates. When editing an existing page, the builder retrieves the unified rendering page corresponding to the page group where the current page is located and compares the module and hotspot information in the unified rendering page with the module and hotspot information in the current page. This updates the modules and magic-cutting hotspots in the current page, and the updated modules and magic-cutting hotspots can be previewed in real time in the builder's preview area.

[0126] In practical applications, the embodiments in this manual abstract the builder into a software development kit (SDK) by modifying the builder's domain name and interface, enabling zero-cost access to third-party platforms. With a portion of merchants managed by the third-party platform, operating costs can be greatly reduced, further increasing the upper limit of serviceable merchants and promoting the rapid development and growth of the project.

[0127] At the rendering execution layer, version mapping and SSR isomorphic rendering are implemented through the rendering method provided in this embodiment. Specifically, when a page is accessed, its corresponding unified rendering page is obtained. Page objects are centrally managed through the unified rendering page. The unified rendering page has a corresponding page object version mapping table (containing module and hot zone version information). Thus, the version information of the page objects mapped to the page can be obtained through the page object version mapping table. When the page is generated based on the corresponding version, batch hot updates of client pages can be realized. Moreover, this embodiment implements a high-performance SSR rendering solution while centrally managing the page, improving the smoothness of the projected page, and solving the defect that the general SSR framework does not provide a centralized version management rendering solution and cannot realize dynamic module version replacement and isomorphic rendering on the server side.

[0128] The method provided in the embodiments of this specification solves the problems of low upgrade efficiency and poor loading performance of the external page projection module based on a three-level rendering system.

[0129] Corresponding to the above method embodiments, this specification also provides embodiments of a page access device. Figure 7 A schematic diagram of a page access device according to one embodiment of this specification is shown. Figure 7 As shown, the device includes: The request-response module 702 is configured to respond to a page access request sent by the client and obtain the target page identifier in the page access request; The template determination module 704 is configured to determine a target page template, page configuration data, and a page object version mapping table corresponding to the target page template based on the target page identifier, wherein the page object version mapping table will be updated when the page object is updated. Version determination module 706 is configured to determine the target version of each page object in the target page template according to the page object version mapping table, and generate page data of the target page according to the page objects of each target version and the page configuration data. The data sending module 708 is configured to send the page data to the client to generate the target page through visual rendering on the client.

[0130] Optionally, the template determining module 704 is further configured to: The target page template is determined based on the template identifier in the target page identifier, and the page configuration data is determined based on the page parameters in the target page identifier; Determine the page object version mapping table corresponding to the target page template.

[0131] Optionally, the version determination module 706 is further configured to: Obtain multiple page objects and the page configuration data, wherein the page objects contain modules and / or hot zones, and each page object is an object of the target version; Replace the target fields in the multiple page objects with the page configuration data to generate object data in the target format; Based on the target structure of the target page template, the object data is concatenated to obtain the page data of the target page.

[0132] Optionally, the request-response module 702 is further configured to: In response to the page access request sent by the client, the target page identifier and grayscale information in the page access request are obtained.

[0133] Optionally, the template determining module 704 is further configured to: The target page template and the page configuration data are determined based on the target page identifier; Based on the gray-scale release rules corresponding to the target page template and the gray-scale information, determine the page object version mapping table corresponding to the target page template.

[0134] Optionally, the template determining module 704 is further configured to: If the grayscale information matches the grayscale release rule corresponding to the target page template, the first version mapping table is determined as the page object version mapping table corresponding to the target page template; otherwise, the second version mapping table is determined as the page object version mapping table corresponding to the target page template. The first version mapping table contains the page object of the test version, and the second version mapping table contains the page object of the current version. The test version is obtained by updating based on the current version.

[0135] Optionally, the version determination module 706 is further configured to: If the page object version mapping table is the first version mapping table, the target version of each page object in the target page template is determined according to the first version mapping table; When the page object version mapping table is the second version mapping table, the target version of each page object in the target page template is determined according to the second version mapping table, wherein the target version of the page object is a test version or the current version.

[0136] The device further includes: The secondary screen acquisition module is configured to asynchronously acquire secondary screen data corresponding to the target page based on the target page identifier, wherein the secondary screen data is used for visual rendering of the non-first screen portion of the target page on the client.

[0137] The above is an illustrative scheme of a page access device according to this embodiment. It should be noted that the technical solution of this page access device and the technical solution of the page access method described above belong to the same concept. For details not described in detail in the technical solution of the page access device, please refer to the description of the technical solution of the page access method described above.

[0138] Corresponding to the above method embodiments, this specification also provides embodiments of a page building apparatus. Figure 8 A schematic diagram of a page building apparatus according to one embodiment of this specification is shown. Figure 8 As shown, the device includes: The request-response module 802 is configured to respond to a page editing request for the current page and obtain the target page template corresponding to the current page; Version determination module 804 is configured to determine the current version of the page object in the current page and the target version of the page object in the target page template; The page update module 806 is configured to update the current version to the target version when the current version is inconsistent with the target version, thereby obtaining the updated current page, wherein the page access method described above is applied to access the updated current page.

[0139] Optionally, the request-response module 802 is further configured to: In response to a page editing request for the current page, obtain the page group corresponding to the current page and the management page address corresponding to the page group; Based on the management page address, obtain the target page template corresponding to the current page.

[0140] The device further includes: The page building module is configured to, in response to a page creation request, obtain and display multiple preset page templates; in response to a page selection request, determine a target page template from the multiple preset page templates; and in response to a page building request, generate a target page based on the target page template according to the target version of the target page object in the target page template and the configuration data of the target page object.

[0141] The above is an illustrative scheme of a page building apparatus according to this embodiment. It should be noted that the technical solution of this page building apparatus and the technical solution of the page building method described above belong to the same concept. For details not described in detail in the technical solution of the page building apparatus, please refer to the description of the technical solution of the page building method described above.

[0142] Figure 9 A structural block diagram of a computing device 900 according to one embodiment of this specification is shown. The components of the computing device 900 include, but are not limited to, a memory 910 and a processor 920. The processor 920 is connected to the memory 910 via a bus 930, and a database 950 is used to store data.

[0143] The computing device 900 also includes an access device 940, which enables the computing device 900 to communicate via one or more networks 960. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 960 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0144] In one embodiment of this specification, the above-described components of the computing device 900 and Figure 9Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 9 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0145] The computing device 900 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 900 can also be a mobile or stationary server.

[0146] The processor 920 is used to execute the following computer program / instruction, which, when executed by the processor, implements the steps of the above-mentioned page access method and page construction method.

[0147] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the computing device embodiments are basically similar to the page access method and page construction method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the page access method and page construction method embodiments.

[0148] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described page access method and page construction method.

[0149] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the computer-readable storage medium embodiments are basically similar to the page access method and page construction method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the page access method and page construction method embodiments.

[0150] An embodiment of this specification also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described page access method and page construction method.

[0151] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product belongs to the same concept as the technical solutions of the page access method and page construction method described above. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solutions of the page access method and page construction method described above.

[0152] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0153] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0154] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0155] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0156] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A page access method, comprising: obtaining a target page identifier in a page access request sent by a client in response to the page access request; determining a target page template, page configuration data and a page object version mapping table corresponding to the target page template according to the target page identifier, wherein the page object version mapping table is updated in case of version update of a page object; determining target versions of page objects in the target page template according to the page object version mapping table, and generating page data of a target page according to the page objects of the target versions and the page configuration data; sending the page data to the client to generate the target page through visual rendering at the client. 2.The method of claim 1, wherein determining the target page template, the page configuration data and the page object version mapping table corresponding to the target page template according to the target page identifier comprises: determining the target page template according to a template identifier in the target page identifier, and determining the page configuration data according to page parameters in the target page identifier; and determining the page object version mapping table corresponding to the target page template. 3.The method of claim 1, wherein generating the page data of the target page according to the page objects of the target versions and the page configuration data comprises: obtaining a plurality of page objects and the page configuration data, wherein a page object contains a module and / or a hot area, and each page object is an object of a target version; replacing target fields in the plurality of page objects with the page configuration data to generate object data in a target format; and splicing the object data according to a target structure of the target page template to obtain the page data of the target page. 4.The method of claim 1, wherein obtaining the target page identifier in the page access request sent by the client in response to the page access request comprises: obtaining the target page identifier and gray scale information in the page access request sent by the client in response to the page access request; and determining the target page template, the page configuration data and the page object version mapping table corresponding to the target page template according to the target page identifier comprises: determining the target page template and the page configuration data according to the target page identifier; and determining the page object version mapping table corresponding to the target page template according to a gray scale release rule corresponding to the target page template and the gray scale information. 5.The method of claim 4, wherein determining the page object version mapping table corresponding to the target page template according to a gray scale release strategy corresponding to the target page template and the gray scale information comprises: determining a first version mapping table as the page object version mapping table corresponding to the target page template in case that the gray scale information matches a gray scale release rule corresponding to the target page template. Otherwise, the second version mapping table is determined as the page object version mapping table corresponding to the target page template, wherein the first version mapping table contains page objects of a test version, and the second version mapping table contains page objects of a current version, and the test version is obtained based on updating the current version. 6.The method of claim 5, wherein determining target versions of page objects in the target page template according to the page object version mapping table comprises: in a case where the page object version mapping table is the first version mapping table, determining target versions of page objects in the target page template according to the first version mapping table; in a case where the page object version mapping table is the second version mapping table, determining target versions of page objects in the target page template according to the second version mapping table, wherein the target versions of the page objects are test versions or current versions. 7.The method of any one of claims 1-6, wherein after obtaining the target page identifier in the page access request, the method further comprises: asynchronously obtaining secondary screen data corresponding to the target page according to the target page identifier, wherein the secondary screen data is used for visually rendering a part of the target page other than a primary screen on the client. 8.A page construction method, comprising: in response to a page editing request for a current page, obtaining a target page template corresponding to the current page; determining a current version of a page object in the current page and a target version of a page object in the target page template; in a case where the current version is inconsistent with the target version, updating the current version to the target version to obtain an updated current page, wherein the page access method of any one of claims 1-7 is applied to access the updated current page. 9.The method of claim 8, wherein obtaining the target page template corresponding to the current page in response to the page editing request for the current page comprises: in response to the page editing request for the current page, obtaining a page group corresponding to the current page and a management page address corresponding to the page group; obtaining the target page template corresponding to the current page according to the management page address. 10.The method of claim 8, further comprising: in response to a page creation request, obtaining and displaying a plurality of preset page templates; in response to a page selection request, determining the target page template from the plurality of preset page templates; in response to a page building request, generating a target page based on the target page template, target page objects of the target version in the target page template, and configuration data of the target page objects. 11.A page access apparatus, comprising: a request response module configured to obtain a target page identifier in a page access request sent by a client in response to the page access request; The template determining module is configured to determine a target page template, page configuration data and a page object version mapping table corresponding to the target page template according to the target page identifier, wherein the page object version mapping table is updated in case of version update of a page object; The version determining module is configured to determine target versions of page objects in the target page template according to the page object version mapping table, and generate page data of the target page according to page objects of the target versions and the page configuration data; The data sending module is configured to send the page data to the client to generate the target page through visual rendering by the client.

12. A page building apparatus, comprising: A request response module configured to acquire a target page template corresponding to a current page in response to a page editing request for the current page; A version determining module configured to determine a current version of a page object in the current page and a target version of a page object in the target page template; A page updating module configured to update the current version to the target version in case that the current version is inconsistent with the target version, and obtain an updated current page, wherein the page access method of any one of claims 1-7 is applied to access the updated current page.

13. A computing device, comprising: A memory and a processor; The memory is configured to store computer programs / instructions, and the processor is configured to execute the computer programs / instructions, which realize the steps of the method of any one of claims 1-10 when executed by the processor.

14. A computer readable storage medium storing computer programs / instructions, which realize the steps of the method of any one of claims 1-10 when executed by a processor.

15. A computer program product comprising computer programs / instructions, which realize the steps of the method of any one of claims 1-10 when executed by a processor.

Images