Rendering method of client page, rendering equipment of client page and medium

Abstract

The invention discloses a client page rendering method, client page rendering equipment and a medium, and relates to the technical field of computers, the client page rendering method comprises the following steps: obtaining an equipment type of a to-be-rendered client, and obtaining a terminal row capacity and a root reference variable associated with a to-be-accessed terminal according to the equipment type; a preset page is loaded, the length-width percentage of each component in the preset page relative to the preset page is determined, and the preset page is constructed based on a client of a preset type; if the equipment type is a non-preset type, converting the length-width percentage into a root unit value based on the root reference variable and the resolution, and displaying the component on a preset page based on the root unit value; and constructing a component DOM tree of each component based on the terminal row capacity, and rendering a preset page according to the component DOM tree. On the basis, through a self-adaption mode, interface adaption of each terminal device can be completed only by developing a set of codes, so that the development efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to methods for rendering client-side pages, rendering devices for client-side pages, and media. Background Technology

[0002] With the rapid development of the digital age, various application functions not only need to be displayed on the computer, but also need to provide a consistent user experience on multiple terminals such as mobile phones and tablets.

[0003] However, traditional application development models require developers to write front-end code separately for each type of terminal. Multi-terminal independent development results in a lot of repetitive work. The same function requires writing multiple sets of code for different terminals, which prolongs the development cycle and leads to low development efficiency.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a rendering method, rendering device and medium for client-side pages, aiming to solve the technical problem that the current application development model requires writing a set of code for each type of client, resulting in low development efficiency.

[0006] To achieve the above objectives, this application proposes a method for rendering a client-side page, the method comprising:

[0007] Obtain the device type of the client to be rendered, and obtain the terminal row capacity and root reference variable associated with the terminal to be accessed based on the device type;

[0008] Load a preset page and determine the length and width percentages of each component in the preset page relative to the preset page. The preset page is constructed based on a preset type of client.

[0009] If the device type is not a preset type, the length and width percentages are converted into root unit values ​​based on the root reference variable and the resolution, and the component is displayed on the preset page based on the root unit value.

[0010] Based on the terminal row capacity, construct the component DOM tree for each component, and render the preset page according to the component DOM tree.

[0011] In one embodiment, the aspect ratio includes a length percentage and a width percentage. The step of converting the aspect ratio to a root unit value based on the root reference variable and the resolution of the client to be rendered, if the device type is not a preset type, includes:

[0012] If the device type is not a preset type, calculate the first product between the root reference variable, the length percentage and the horizontal pixels of the resolution, and the second product between the root reference variable, the width percentage and the vertical pixels of the resolution;

[0013] Set the first product and the second product to the length and width corresponding to the root unit value.

[0014] In one embodiment, the step of constructing a component DOM tree for each component based on the terminal line capacity, and rendering the preset page according to the component DOM tree, includes:

[0015] Based on the terminal line capacity, construct the component DOM nodes of the component, wherein the number of the component DOM nodes is equal to the terminal line capacity;

[0016] By associating the DOM nodes, the component DOM tree is obtained;

[0017] The preset interface is rendered based on the component arrangement position in the component DOM tree.

[0018] In one embodiment, before the steps of obtaining the device type and resolution of the client to be rendered, and obtaining the terminal line capacity and root reference variable of the terminal to be accessed based on the device type, the rendering method of the client page further includes:

[0019] Configure the occupancy percentage of each preset component in the component library, as well as the preset terminal line capacity and root reference variable for each device type;

[0020] Obtain the size and position parameters of the preset component configured in the preset page, and calculate the length and width percentages based on the size and position parameters;

[0021] Update the storage of the terminal row capacity, the root reference vector, the length and width percentages, and the preset page.

[0022] In one embodiment, after the steps of constructing a component DOM tree for each component based on the terminal line capacity and rendering the preset page according to the component DOM tree, the client page rendering method further includes:

[0023] Determine the preset occupancy percentage of the component;

[0024] The remaining space, excluding the stated placeholder percentage, is allocated based on the flexible box to update the current placeholder percentage of the component.

[0025] In one embodiment, after the steps of loading a preset page and determining the length percentage of components in the preset page, the client-side page rendering method further includes:

[0026] If the device type is the preset type, determine the length and width percentages and layout coordinate percentages of the component in the preset page;

[0027] Obtain the target resolution of the client to be rendered, and calculate the target length, width and layout coordinates of the component based on the product of the target resolution, the length and width percentages and the layout coordinate percentages.

[0028] Based on the target width and height and the layout coordinates, traverse and create the DOM tree corresponding to each component.

[0029] In one embodiment, the step of obtaining the device type of the client to be rendered, and obtaining the terminal row capacity and root reference variable associated with the terminal to be accessed based on the device type, includes:

[0030] Obtain the device type of the client to be rendered, and determine the resolution associated with the device type;

[0031] Based on the device type, query the terminal row capacity associated with the terminal to be accessed, and query the root reference variable associated with the resolution.

[0032] In one embodiment, after the steps of obtaining the device type of the client to be rendered and determining the resolution associated with the device type, the rendering method for the client interface further includes:

[0033] Obtain the target resolution and target terminal line capacity of the client of the preset type;

[0034] Calculate the ratio between the target resolution and the resolution, and calculate the terminal line capacity based on the ratio and the target terminal line capacity;

[0035] Query the root reference variable associated with the resolution.

[0036] In addition, to achieve the above objectives, this application also proposes a client page rendering device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the client page rendering method described above.

[0037] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the client page rendering method described above.

[0038] One or more technical solutions proposed in this application have at least the following technical effects:

[0039] First, the device type of the client to be rendered is obtained, and the terminal line capacity and root base variable are obtained accordingly. Then, the preset page is loaded and the relative width and height percentages of its components are determined. This page is built based on the preset type client. When the device type is not the preset type, the percentages are automatically converted to root unit values ​​using the root base variable and resolution, so that the components can be displayed adaptively on the preset page based on this value. Finally, the DOM tree of the components is built in combination with the terminal line capacity and the page is rendered. This effectively solves the problem of inconsistent display or performance of preset pages caused by differences in screen size, resolution or processing power in diverse device environments. Developers do not need to write multiple sets of different code to achieve the same effect on different operating devices or operating systems, reducing the development cycle of projects with multi-device display and improving development efficiency. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0042] Figure 1 This is a schematic diagram of the rendering method for the client side of this application.

[0043] Figure 2 A flowchart illustrating the rendering method for the client interface of this application in the first embodiment;

[0044] Figure 3 A flowchart illustrating the second embodiment of the rendering method for the client interface of this application;

[0045] Figure 4 A simplified flowchart illustrating the rendering method of the client interface provided in the second embodiment of this application;

[0046] Figure 5 This is a schematic diagram illustrating an embodiment of this application where the component has not undergone a flexible box transformation.

[0047] Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the rendering method of the client interface in this embodiment of the application.

[0048] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0049] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0050] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0051] The main solution of this application embodiment is: to obtain the device type of the client to be rendered, and to obtain the terminal row capacity and root reference variable associated with the terminal to be accessed based on the device type;

[0052] Load a preset page and determine the length and width percentages of each component in the preset page relative to the preset page. The preset page is constructed based on a preset type of client.

[0053] If the device type is not a preset type, the length and width percentages are converted into root unit values ​​based on the root reference variable and the resolution, and the component is displayed on the preset page based on the root unit value.

[0054] Based on the terminal row capacity, construct the component DOM tree for each component, and render the preset page according to the component DOM tree.

[0055] With the rapid development of the digital age, various application functions not only need to be displayed on PCs, but also need to provide a consistent user experience on multiple terminals such as mobile phones and tablets.

[0056] However, traditional application development models require developers to write front-end code separately for each type of terminal. Multi-terminal independent development results in a lot of repetitive work. The same function requires writing multiple sets of code for different terminals, which prolongs the development cycle and leads to low development efficiency.

[0057] Based on this, this application provides a solution that uses device interface adaptation to automatically adjust the application interface display to the current device. This allows the development of content to be displayed on multiple devices with different operating systems with only one set of code, eliminating the need to develop multiple sets of code, reducing the development cycle, and improving the development efficiency of multi-device display projects.

[0058] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or client-side page rendering device capable of the above functions. The following description uses a client-side page rendering device as an example to illustrate this embodiment and the subsequent embodiments. The application project in this embodiment is typically a web page project, which is usually developed on a PC (personal computer) and can be seamlessly implemented on mobile phones and tablets. Therefore, the following description uses a PC-based development project as an example.

[0059] The architecture of the client-side page rendering method in this application is as follows: Figure 1 As shown, the system comprises a client, an interaction layer, a configuration engine, and a data layer. The client typically includes PCs, mobile devices, and other terminals such as tablets. The interaction layer is used for data interaction parsing, including parameter parsing, a dynamic rendering engine, and dynamic strategy loading. Parameter parsing and dynamic rendering include parameter and page template data analysis, component calculation, and DOM (Document Object Model) tree generation. Dynamic loading strategies include loading CSS libraries (common frameworks used to simplify web development), JS libraries (common libraries), and event libraries. The configuration engine process involves generating a page configuration template based on component metadata, component adaptation parameters, and terminal characteristics from the configuration side. Subsequently, data is loaded into the configuration library using JS, CSS, and event libraries. This ensures that when the rendering project is loaded on a device other than the configuration side, the page configuration template is adapted to the current device, thus achieving adaptive processing.

[0060] Based on this, embodiments of this application provide a method for rendering a client-side page, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the rendering method for the client page of this application.

[0061] In this embodiment, the rendering method of the client page includes steps S10 to S40:

[0062] Step S10: Obtain the device type of the client to be rendered, and obtain the terminal row capacity and root reference variable associated with the terminal to be accessed based on the device type.

[0063] In this embodiment, device type refers to the client's hardware platform identifier, such as mobile, PC, and tablet. Device type can be obtained through browser navigator.userAgent parsing or the device API (Application Programming Interface). Terminal capacity is the number of DOM nodes that the client browser's rendering engine can process in parallel at a time; that is, the maximum amount of tasks or data that a terminal device or system can process per unit of time. Terminal line capacity is the number of DOM nodes that can be accommodated in each line of the terminal interface, defining the number of components that can be displayed per line for different terminals. The root base variable is rem (root em, a length unit in CSS), whose value is calculated based on the font-size of the root element. For projects developed on PC, the length unit is pixels (px), while for mobile devices, the length unit is em. Therefore, to display the project on a mobile device, unit conversion is required. Thus, a root base variable needs to be determined for parameter conversion, such as the conversion ratio of 1rem = 16px at a 1920×1080 resolution.

[0064] The terminal row capacity and root reference vector corresponding to a device type can be queried based on a mapping table. First, the device type is obtained via API. Then, the terminal row capacity corresponding to the device is queried through the device type mapping table, and the root reference variable corresponding to the device type is read from the preset configuration library. The root reference variable and terminal row capacity are preset parameters.

[0065] In another optional implementation of obtaining the terminal line capacity and root reference vector, the resolution corresponding to the device type can be read first, and the root reference variable can be calculated using the resolution. Specifically, after obtaining the device type of the client to be rendered, the resolution associated with that device type is queried using a query command. Then, the terminal line capacity corresponding to that device is queried according to the device type mapping table, and the root reference variable associated with the resolution is also queried. For example, the root reference vector is 1rem = 16px at a resolution of 1920×1080, and 1rem = 8px at a resolution of 2560×1440. It should be noted that the above parameters are for illustrative purposes only and are not intended to limit this application.

[0066] In another alternative implementation of obtaining the terminal row capacity and root reference vector, the target resolution and target terminal row capacity of a client of a preset type can be obtained first. Then, the ratio of the target resolution to the resolution of the current client to be rendered is calculated. This ratio includes the ratio of horizontal pixels and the ratio of vertical pixels. Based on this ratio and the target terminal row capacity, the terminal row capacity corresponding to the client to be rendered is calculated. For example, if the ratio is 2 and the target terminal row capacity is 4, then the terminal row capacity is 2. Simultaneously, the root reference vector associated with the resolution is queried. Therefore, by using the device resolution size ratio, the rendering parameters in the actual rendering process of the current client to be rendered are calculated, ensuring that the client adaptively adjusts the interface to be rendered.

[0067] It should be noted that the root reference vector and terminal row capacity are usually pre-configured by the developers and stored in the data area.

[0068] By obtaining the configuration parameters associated with the device type, the component size can be adaptively adjusted based on the configuration parameters when rendering the content of the preset page to the component. Therefore, only one set of code needs to be developed to realize the display of different devices, improving project development efficiency.

[0069] Step S20: Load a preset page and determine the length and width percentages of each component in the preset page relative to the preset page.

[0070] In this embodiment, the preset page is built based on a preset type of client. When the preset type is PC, the preset interface is an HTML / CSS template built based on a desktop browser. The width and height percentages are the proportions of the component size relative to the parent container, such as width:50% and length:50%.

[0071] By triggering events and traversing the CSS rule table of the preset page, the percentage of length and width of the component in the current row and column are determined by extracting the % unit style declarations of all components.

[0072] In another alternative implementation, when loading the preset page, the UI design system configuration file can be read directly, and the ratio between the component and the canvas size can be parsed to generate a percentage mapping table. Then, the percentage is injected into the CSS variables.

[0073] By determining the percentage of a component within a preset interface, the original layout information of the component can be understood, allowing for adaptive adjustment of the component size based on this original layout information and previously acquired configuration parameters.

[0074] Step S30: If the device type is not a preset type, convert the length and width percentages into root unit values ​​based on the root reference variable and the resolution of the client to be rendered.

[0075] It's understandable that the size of components in the preset page needs to be adjusted to fit the display interface of different devices only when the device type is not a preset type. Non-preset types refer to device types other than the preset types; for example, if the preset type is PC, non-preset types would be mobile phones and tablets. The root unit value is the rem unit value, which is the parameter value obtained after converting the component's length and width based on the rem baseline value.

[0076] When the device type is determined to be a non-preset type through type comparison, the current client resolution is obtained. Then, the rem unit value is calculated based on the rem value calculation formula: Rem unit value = percentage x resolution size x root reference vector. Here, resolution includes both horizontal and vertical pixel sizes, and the component's length and width percentages include both length and width percentages. Therefore, in the actual calculation process, it is necessary to calculate the first product between the root reference variable, the length percentage, and the horizontal pixels of the resolution, and the second product between the root reference variable, the width percentage, and the vertical pixels of the resolution. Then, the first and second products are set as the length and width corresponding to the rem unit value, respectively. After calculating the rem unit value, the component is displayed on the preset page based on the rem unit value, thus completing the adaptive adjustment of the component on different display interfaces and maintaining consistent proportions across any resolution.

[0077] Step S40: Construct a component DOM tree for each component based on the terminal line capacity, and render the preset page according to the component DOM tree.

[0078] In this embodiment, the DOM tree is a structured tree representation generated by the browser after parsing the document. It converts each element, attribute, and text in the document into programmable object nodes, forming a hierarchical relationship. The component DOM tree consists of programmable object nodes corresponding to each component. The rendering process is the process of compositing the DOM trees into a bitmap and outputting it.

[0079] The terminal row capacity defines the number of components that can be displayed per row on different terminals. Therefore, when constructing the component DOM tree based on the terminal row capacity, the number of component DOM nodes in that row is equal to the terminal row capacity. For example, if the device to be rendered is a mobile device such as a mobile phone, the terminal row capacity of the mobile phone is 1, meaning that at most one component can be displayed per row in the mobile phone's display interface. After constructing the component DOM nodes based on the terminal row capacity, all DOM nodes need to be associated to obtain the component DOM tree. Finally, during the rendering process, the preset interface is rendered according to the component arrangement position in the component DOM tree. For example, if component A was originally in the 3rd row of the preset page, after constructing the DOM tree, component A is located in the 6th row. At this time, the rendering adjustment of the component position is performed according to the actual row number of the component, so that after the component size transformation is completed in step S30, each component is adjusted to a position that is compatible with the current terminal to be rendered. Thus, component parsing and dynamic layout can be achieved through a single template, realizing one-time configuration and multi-terminal adaptation, significantly reducing the complexity and maintenance cost of multi-terminal development. In the implementation process, the component is cut into multiple subtrees according to the terminal row capacity, then node fragments are created in batches, and finally the display content is submitted to the rendering queue to complete the rendering.

[0080] For example, the default type is PC with a resolution of 1920×1080 and a terminal line size of 3. The non-default type is mobile phone with a resolution of 360×800, and the root base variable is 1rem = 16px with a terminal line size of 1. The default page has a row containing three components: name, gender, and phone number. However, since the terminal line size for mobile phones is 1 per row, after generating the name component DOM node in the current row, it is necessary to create a new line to generate the gender component and then another new line to generate the phone number component.

[0081] It should be noted that the above examples and the data used in the examples are for illustrative purposes only and are not intended to limit this application.

[0082] This embodiment provides a method for rendering client-side pages. It dynamically adapts the content of a configuration template based on the device parameter information of the client to be rendered and constructs the DOM tree of the components. This ensures that the layout ratio of the components in the preset page remains intact while controlling the display of components in separate lines. This effectively solves the problem of inconsistent display or performance issues in preset pages caused by differences in screen size, resolution, or processing power in diverse device environments. Based on a standardized component configuration template, cross-terminal size and position adaptation is achieved by defining component metadata and adaptation parameters. It avoids hard-coding logic on different clients, abstracting terminal characteristics such as line capacity and rem baseline into configurable variables. Combined with a dynamic calculation engine, it automatically generates an adapted layout, achieving "configuration once, adaptation for multiple platforms," ​​avoiding rewriting code on different clients and improving development efficiency.

[0083] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 After step S20, the rendering method of the client page further includes steps S50 to S70:

[0084] Step S50: If the device type is the preset type, determine the length and width percentages and layout coordinate percentages of the component in the preset page.

[0085] Step S60: Obtain the target resolution of the client to be rendered, and calculate the target length, width and layout coordinates of the component based on the product of the target resolution, the length and width percentages and the layout coordinate percentages.

[0086] In this embodiment, if the device type is a preset type, such as a PC as the terminal to be rendered, since the configuration is based on the PC, the actual component width, height, and layout coordinates can be directly calculated by multiplying the component's aspect ratio and layout coordinate percentage by the PC resolution. Therefore, it is necessary to first determine the component's aspect ratio and layout coordinate percentage, then obtain the target resolution of the client to be rendered, and calculate the component's target aspect ratio and layout coordinates relative to the current client to be rendered based on the product of the target resolution, aspect ratio, and layout coordinate percentage.

[0087] Specifically, the actual width of a component = width percentage × parent container width or screen width; the actual height of a component = height percentage × parent container height or screen height. In layout coordinates, the actual horizontal coordinate = horizontal percentage × parent container width; and the actual vertical coordinate = vertical percentage × parent container height. Therefore, by calculating the product of horizontal pixels and length percentage at the target resolution, we obtain the horizontal length; by calculating the product of vertical pixels and width percentage, we obtain the vertical width; and by calculating the horizontal pixels and horizontal coordinate percentage, we obtain the X-value of the layout coordinates. Similarly, we obtain the Y-value of the layout coordinates.

[0088] For example, the resolution of the client to be rendered is 1920×1080. The preset page contains a centered card component, whose width occupies 80% of the screen and its height occupies 60%. The button is positioned 40% horizontally from the left and 80% vertically from the top. Calculate the actual pixel values ​​of the card in this case:

[0089] Card width = 0.8 × 1920px = 1536px; Card height = 0.6 × 1080px = 648px;

[0090] Next, calculate the button coordinates: left side coordinates = 0.4 × 1920px = 768px; top coordinates = 0.8 × 1080px = 864px.

[0091] Step S70: Based on the target width and height and the layout coordinates, traverse and create the DOM tree corresponding to each component.

[0092] After obtaining the actual length, width, and coordinate information, the component list is looped through according to the calculated actual size and coordinates to generate DOM nodes. That is, each component is traversed, and DOM nodes are generated based on the actual position and size of the component to build the DOM tree.

[0093] For example, to help understand the implementation flow of the client page rendering method obtained by combining this embodiment with the first embodiment described above, please refer to... Figure 4 , Figure 4 This document provides a simplified flowchart of a client-side page rendering method, specifically, the default type is PC. Based on this, during the dynamic layout generation process, the current device type and resolution (i.e., the device type and resolution of the client to be rendered) are first read. Simultaneously, terminal parameters, including the terminal line size and rem baseline variable, are obtained. Then, a preset page template is loaded. After the template is loaded, the terminal type is determined. If the terminal type is PC, the actual width, height, and coordinates of the components in the page template on the current device are calculated. Based on these actual width, height, and coordinates, nodes are iterated and DOM nodes are created, thereby loading the page template onto devices of the same type and resolution, or devices with different resolutions.

[0094] After determining the terminal type, if the device type is not PC, the component's width and height are converted to rem values ​​to adjust the display size in the template. Then, the DOM nodes of each component are created in a loop according to the terminal's line capacity to complete the construction of the DOM tree. Finally, the component is rendered by setting the flex property.

[0095] This embodiment provides a method for rendering client-side pages. When the clients to be rendered are of the same type, the actual coordinate size and component dimensions are calculated based on the resolution of the same type of client, so as to achieve adaptive display adjustment of the template component on the current client.

[0096] Based on any of the above embodiments, in the third embodiment of this application, the content that is the same as or similar to any of the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, before step S10, the rendering method of the client page further includes steps S01 to S03:

[0097] Step S01: Configure the occupancy percentage of each preset component in the component library, as well as the preset terminal line capacity and root reference variable for each device type.

[0098] In this embodiment, please continue to refer to Figure 1 The configuration engine is used to configure components and define metadata, thereby achieving cross-platform page adaptation. Therefore, a unified component configuration system needs to be built to shield differences across multiple terminals, extract commonalities among components, and define standardized metadata, thus achieving a consistent experience across platforms.

[0099] The configuration process mainly includes defining component basic metadata and adaptation parameters, visual component configuration, and abstracting terminal characteristics, as well as defining dynamic adaptation parameters. Defining component basic metadata and adaptation parameters involves defining basic metadata for various components such as input boxes, buttons, and dropdown lists. This metadata includes component type, Chinese name, whether it is required, whether it is visible, and input validation rules. Simultaneously, to improve the flexibility of interface adaptation, a placeholder percentage parameter, such as `place=0.5`, needs to be configured for each component. This placeholder percentage is used to dynamically allocate remaining space in the Flexbox layout. If no placeholder percentage is defined, it is set to the default value of 1. This placeholder percentage parameter plays a crucial role in the subsequent rendering process, enabling more precise layout control through fine-tuning even after the overall layout is determined.

[0100] In addition to configuring the percentage of space allocated to the components, terminal parameters also need to be defined, abstracting the terminal's display characteristics into configurable variables. These configurable variables typically include the terminal line capacity and rem baseline variable, which are usually customized by developers based on the actual device conditions.

[0101] Step S02: Obtain the size and position parameters of the preset component configured on the preset page, and calculate the length and width percentages based on the size and position parameters.

[0102] In the component visual configuration, all configuration data can be personalized through the visual configuration interface to generate standardized page configuration templates. Developers can configure preset components onto preset pages via visual configuration. During the configuration process, the interface automatically obtains the component's size and position parameters and converts them into percentage values ​​based on the PC layout. The specific process of obtaining these parameters is standard for component visual configuration and is not limited to this application.

[0103] By obtaining size and position parameters, the component's length and width percentages after being configured on a preset page are calculated. Based on percentage design, the component configuration is decoupled from the hard-coded logic of a specific terminal, forming a reusable and portable configuration template, laying a solid foundation for subsequent cross-terminal adaptation.

[0104] Step S03: Update the storage of the terminal row capacity, the root reference vector, the length and width percentages, and the preset page.

[0105] After obtaining the above parameters, the preset parameters corresponding to each device type, as well as the preset page and all component information within the page, can be stored in the database so that the relevant parameters can be found through data query commands later.

[0106] Optionally, in this embodiment, please continue to refer to Figure 4 After rendering the preset page based on the component DOM tree, the page rendering is complete. However, this rendering method may result in adaptation errors. For example, if three components in one row of the preset page are distributed to three rows in the current client, the arrangement of the three components may be abnormal after rendering through the DOM tree. In this case, it is necessary to set the container display based on the component's place value and dynamically allocate the remaining space using flexbox, such as flex:0.5, which means allocating 50% of the remaining space. Therefore, after rendering the preset page based on the component DOM tree, it is also necessary to determine the component's preset place value and then allocate the remaining space other than the place value based on the flexbox to update the component's current place value.

[0107] For example, taking the product component as an example, in the original design (PC version), the product display row contains three equal-width components, arranged from left to right: main image, details, and purchase items. Each component's width occupies 33% of the entire row. However, when the page is loaded on a mobile device, because the row capacity is 1, the components are split into three rows. The lack of flexible layout causes display errors, resulting in the following: Figure 5 As shown, there are exceptions including text that is too short to be centered, left-aligned with white space on the right, and right-aligned buttons. In these cases, we can enable flexbox layout and inject CSS properties into each line container:

[0108]

[0109] flex-grow values ​​are allocated according to preset weighting proportions:

[0110] Flex allocation factor = (Component preset percentage ÷ Total preset percentage) × Remaining space percentage

[0111] At this point, the system can automatically update the current occupancy percentage, thus obtaining a page that meets the actual usage requirements.

[0112] This embodiment provides a method for rendering client-side pages. It configures components and defines metadata based on a configuration engine to achieve cross-terminal adaptation of the page. By using a flexible layout box to adjust the component parameters of the client to be rendered after loading the preset page based on the DOM tree, it reduces abnormal display of components and optimizes the display effect while adaptively adjusting the component layout information.

[0113] This application provides a rendering device for a client interface, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the rendering method for the client interface in the first embodiment described above.

[0114] The following is for reference. Figure 6 This document illustrates a schematic diagram of a rendering device suitable for implementing the client interface of the embodiments of this application. The rendering device for the client interface in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, personal digital assistants (PDAs), tablet computers (PADs), portable multimedia players (PMPs), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The rendering device for the client interface shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0115] like Figure 6As shown, the rendering device for the client interface may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the rendering device for the client interface. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the client interface rendering device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows client interface rendering devices with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0116] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0117] The client interface rendering device provided in this application, employing the client interface rendering method described in the above embodiments, can solve the technical problem of low development efficiency caused by the current application development model requiring the writing of a separate set of code for each type of client. Compared with the prior art, the beneficial effects of the client interface rendering device provided in this application are the same as those of the client interface rendering method provided in the above embodiments, and other technical features in this client interface rendering device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0118] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0119] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0120] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the client interface rendering method in the above embodiments.

[0121] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM, or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0122] The aforementioned computer-readable storage medium may be included in the rendering device of the client interface; or it may exist independently and not be mounted in the rendering device of the client interface.

[0123] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a rendering device of a client interface, cause the rendering device of the client interface to: obtain the device type of the client to be rendered, and obtain the terminal row capacity and root reference variable associated with the terminal to be accessed based on the device type;

[0124] Load a preset page and determine the length and width percentages of each component in the preset page relative to the preset page. The preset page is constructed based on a preset type of client.

[0125] If the device type is not a preset type, the length and width percentages are converted into root unit values ​​based on the root reference variable and the resolution, and the component is displayed on the preset page based on the root unit value.

[0126] Based on the terminal row capacity, construct the component DOM tree for each component, and render the preset page according to the component DOM tree.

[0127] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0128] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0129] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0130] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the rendering method of the client interface described above. This solves the technical problem of low development efficiency caused by the current application development model requiring a separate set of code for each type of client. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the client interface rendering method provided in the above embodiments, and will not be elaborated upon here.

[0131] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for rendering a client-side page, characterized in that, The rendering methods for the client-side page include: Obtain the device type of the client to be rendered, and obtain the terminal row capacity and root reference variable associated with the terminal to be accessed based on the device type; Load a preset page and determine the length and width percentages of each component in the preset page relative to the preset page. The preset page is constructed based on a preset type of client. If the device type is not a preset type, the aspect ratio is converted into a root unit value based on the root reference variable and the resolution of the client to be rendered, and the component is displayed on the preset page based on the root unit value; Based on the terminal row capacity, construct the component DOM tree for each component, and render the preset page according to the component DOM tree.

2. The client-side page rendering method as described in claim 1, characterized in that, The length and width percentages include length percentages and width percentages. If the device type is not a preset type, the step of converting the length and width percentages to root unit values ​​based on the root reference variable and the resolution of the client to be rendered includes: If the device type is not a preset type, calculate the first product between the root reference variable, the length percentage and the horizontal pixels of the resolution, and the second product between the root reference variable, the width percentage and the vertical pixels of the resolution; Set the first product and the second product to the length and width corresponding to the root unit value.

3. The client-side page rendering method as described in claim 1, characterized in that, The step of constructing a component DOM tree for each component based on the terminal row capacity, and rendering the preset page according to the component DOM tree, includes: Based on the terminal line capacity, construct the component DOM nodes of the component, wherein the number of the component DOM nodes is equal to the terminal line capacity; By associating the DOM nodes, the component DOM tree is obtained; The preset interface is rendered based on the component arrangement position in the component DOM tree.

4. The client-side page rendering method as described in claim 1, characterized in that, Before the steps of obtaining the device type and resolution of the client to be rendered, and obtaining the terminal line capacity and root reference variable of the terminal to be accessed based on the device type, the rendering method of the client page further includes: Configure the occupancy percentage of each preset component in the component library, as well as the preset terminal line capacity and root reference variable for each device type; Obtain the size and position parameters of the preset component configured in the preset page, and calculate the length and width percentages based on the size and position parameters; Update the storage of the terminal row capacity, the root reference vector, the length and width percentages, and the preset page.

5. The client-side page rendering method as described in claim 4, characterized in that, After the steps of constructing a component DOM tree for each component based on the terminal row capacity and rendering the preset page according to the component DOM tree, the rendering method of the client page further includes: Determine the preset occupancy percentage of the component; The remaining space, excluding the stated placeholder percentage, is allocated based on the flexible box to update the current placeholder percentage of the component.

6. The client-side page rendering method as described in claim 1, characterized in that, After the steps of loading the preset page and determining the length percentage of the components in the preset page, the client-side page rendering method further includes: If the device type is the preset type, determine the length and width percentages and layout coordinate percentages of the component in the preset page; Obtain the target resolution of the client to be rendered, and calculate the target length, width and layout coordinates of the component based on the product of the target resolution, the length and width percentages and the layout coordinate percentages. Based on the target width and height and the layout coordinates, traverse and create the DOM tree corresponding to each component.

7. The client-side page rendering method as described in claim 1, characterized in that, The steps of obtaining the device type of the client to be rendered, and obtaining the terminal row capacity and root reference variable associated with the terminal to be accessed based on the device type, include: Obtain the device type of the client to be rendered, and determine the resolution associated with the device type; Based on the device type, query the terminal row capacity associated with the terminal to be accessed, and query the root reference variable associated with the resolution.

8. The client interface rendering method as described in claim 7, characterized in that, After the steps of obtaining the device type of the client to be rendered and determining the resolution associated with the device type, the rendering method of the client interface further includes: Obtain the target resolution and target terminal line capacity of the client of the preset type; Calculate the ratio between the target resolution and the resolution, and calculate the terminal line capacity based on the ratio and the target terminal line capacity; Query the root reference variable associated with the resolution.

9. A rendering device for a client-side page, characterized in that, The rendering device for the client page includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the rendering method for the client page as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the client page rendering method as described in any one of claims 1 to 8.

Images