A web page generation method, device and storage medium

Abstract

The invention relates to the field of website construction and content management, and discloses a webpage generation method and device and a storage medium, and the method comprises the steps: obtaining first webpage design data in a draft data layer; in response to a data publishing instruction for the draft data layer, determining to-be-published target webpage design data in the first webpage design data of the draft data layer; and publishing the target webpage design data to the formal data layer, and rendering corresponding display webpages on different terminal devices based on the webpage design data in the formal data layer. According to the method and the device, the problems of difficulty in multi-terminal adaptation of the portal website and separation of publishing and rendering processes in the prior art are solved.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202512058274.7 (22) Application Date 2025.12.31 (71) Applicant CITIC International Telecommunications (Information Technology) Limited Address 20 / F, Lincoln Tower, Taikoo Place, 979 King's Road, Quarry Bay, Hong Kong Applicant China Enterprise Network Communication Technology Co., Ltd. (72) Inventor Li Chaoqun (74) Patent Agency Beijing Sanju Sunshine Intellectual Property Agency Co., Ltd. 11250 Patent Attorney Song Ruobing (51) Int.Cl. G06F 16 / 958 (2019.01) (54) Invention Title: A Webpage Generation Method, Apparatus, and Storage Medium (57) Abstract: This invention relates to the field of website construction and content management, and discloses a webpage generation method, apparatus, and storage medium. The method includes: acquiring first webpage design data in a draft data layer; responding to a data publishing instruction for the draft data layer, and determining target webpage design data to be published in the first webpage design data of the draft data layer; publishing the target webpage design data to the formal data layer, and rendering the corresponding display webpage on different terminal devices based on the webpage design data in the formal data layer. This invention solves the problems of difficulty in multi-terminal adaptation of portal websites and the fragmentation of the publishing and rendering processes in the prior art. Claims 2 pages, Description 14 pages, Drawings 4 pages, CN 122045536 A 2026.05.15 CN 1 22 04 55 36 A 1. A webpage generation method, characterized in that the method includes: acquiring first webpage design data in a draft data layer; responding to a data publishing instruction for the draft data layer, and determining target webpage design data to be published in the first webpage design data of the draft data layer; publishing the target webpage design data to a formal data layer, and rendering corresponding display webpages on different terminal devices based on the webpage design data in the formal data layer. 2. The method according to claim 1, characterized in that the method for constructing the first webpage design data includes: determining a control type of at least one control according to user requirements; acquiring a preset data model corresponding to the control type, and filling the preset data model with corresponding type fields, data content fields, and sorting fields to obtain at least one target control; generating first webpage design data in the draft data layer based on the target control.3. The method according to claim 2, characterized in that, after generating first webpage design data based on the target control in the draft data layer, it includes: in response to a drag-to-start operation for the first target control, obtaining a first target control identifier; in response to a drag-in operation to drag the first target control to a second target control trigger area, obtaining a second target control identifier; in response to a drag-to-end operation, exchanging the order of the first target control and the second target control in the first webpage design data according to the first target control identifier and the second target control identifier, to obtain the exchanged first webpage design data. 4. The method according to claim 1, characterized in that, determining the target webpage design data to be published in the first webpage design data in the draft data layer includes: identifying the publishing object corresponding to the data publishing instruction; obtaining the level type corresponding to the publishing object in the webpage data hierarchy; determining the target webpage design data to be published in the first webpage design data in the draft data layer according to the level type. 5. The method according to claim 4, characterized in that, determining the target webpage design data to be published from the first webpage design data in the draft data layer according to the hierarchical type includes: if the hierarchical type is a website level, then determining all the first webpage design data in the draft data layer as the target webpage design data to be published; or, if the hierarchical type is a webpage level, then extracting the webpage identifier in the data publishing command, and filtering out the first webpage design data associated with the webpage identifier in the draft data layer as the target webpage design data to be published; or, if the hierarchical type is a block level, then extracting the block identifier in the data publishing command, and filtering out the first webpage design data associated with the block level in the draft data layer as the target webpage design data to be published. 6. The method according to claim 1, characterized in that the method further comprises: responding to a data adjustment instruction, the data adjustment instruction including an adjustment object and an adjustment type; locating second webpage design data associated with the adjustment object in the draft data layer; modifying the second webpage design data according to the adjustment type to generate an updated second webpage design data, and storing the updated second webpage design data in the draft data layer; wherein, when the adjustment object is a published block and the adjustment type is a content adjustment type, it is allowed to initiate a publishing process independently for the published block or for the page to which the published block belongs; when the adjustment type is a published block and the adjustment type is a structural adjustment type, it is only allowed to initiate a publishing process for the page to which the published block belongs.7. The method according to claim 1, characterized in that the method further comprises: responding to a version rollback instruction, the version rollback instruction including at least a target version identifier; obtaining a historical webpage design data set associated with the target version identifier; copying the historical webpage design data set to the draft data layer to obtain rollback draft data. 8. The method according to claim 1, characterized in that rendering the corresponding display webpage on different terminal devices based on the second webpage design data in the formal data layer comprises: obtaining screen attribute information of the current terminal device; determining the corresponding device type according to the screen attribute information, and matching the corresponding target style rule using the device type; laying out the second webpage design data in the formal data layer based on the target style rule to generate a display webpage adapted to the current terminal device, and rendering the display webpage. 9. A webpage generation apparatus, characterized in that the apparatus comprises: an acquisition module, configured to acquire first webpage design data in a draft data layer; a determination module, configured to respond to a data publishing instruction for the draft data layer and determine target webpage design data to be published in the first webpage design data of the draft data layer; and a publishing module, configured to publish the target webpage design data to a formal data layer and render corresponding display webpages on different terminal devices based on the webpage design data in the formal data layer. 10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer instructions, the computer instructions being configured to cause a computer to execute the method of any one of claims 1 to 8. Claims 2 / 2 Page 3 CN 122045536 A Webpage Generation Method, Apparatus and Storage Medium Technical Field

[0001] This invention relates to the field of website construction and content management, specifically to a webpage generation method, apparatus and storage medium. Background Art

[0002] With the rapid development of Internet technology, corporate portal websites have become an important part of information technology construction. Portal websites not only carry corporate image and business display, but also need to support multi-terminal access, dynamic content updates and rapid iterations. In this process, enterprises usually need to design and develop separately for different devices (such as PC, mobile, and tablet), which leads to extended development cycles, increased maintenance costs, and difficulty in ensuring consistent cross-terminal experience. In addition, traditional portal websites often adopt a front-end and back-end coupled architecture, requiring developers to intervene in page content and style adjustments, making it difficult to quickly respond to business changes and achieve visual arrangement and real-time preview of content, thus restricting the overall website building efficiency.

[0003] In the prior art, portal website construction usually requires the development of independent front-end interfaces for different terminals, resulting in repetitive development workload, wasted resources, and difficulty in achieving adaptive rendering of a set of data across multiple terminals.Furthermore, although some systems support content management, they still lack a unified publishing mechanism and multi-terminal rendering support, making it impossible to automatically adapt to different device screens based on the same set of design data after publishing, affecting the consistency of content presentation and the smoothness of user experience. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a webpage generation method, apparatus, and storage medium to solve the problems of difficulty in multi-terminal adaptation of portal websites and the fragmentation of publishing and rendering processes in the prior art.

[0005] In a first aspect, embodiments of the present invention provide a webpage generation method, the method comprising: obtaining first webpage design data in a draft data layer; responding to a data publishing instruction for the draft data layer and determining target webpage design data to be published in the first webpage design data of the draft data layer; publishing the target webpage design data to a formal data layer, and rendering corresponding display webpages on different terminal devices based on the webpage design data in the formal data layer.

[0006] Further, the method for constructing the first webpage design data includes: determining the control type of at least one control according to user requirements; obtaining a preset data model corresponding to the control type, and filling the preset data model with the corresponding type field, data content field, and sorting field to obtain at least one target control; generating the first webpage design data based on the target control in the draft data layer.

[0007] Further, after generating the first webpage design data based on the target control in the draft data layer, the method includes: obtaining the first target control identifier in response to a drag start operation for the first target control; obtaining the second target control identifier in response to a drag enter operation for dragging the first target control to the trigger area of ​​the second target control; and exchanging the order of the first target control and the second target control in the first webpage design data according to the first target control identifier and the second target control identifier, in response to a drag end operation, to obtain the exchanged first webpage design data.

[0008] Further, determining the target webpage design data to be published in the first webpage design data of the draft data layer includes: identifying the publishing object corresponding to the data publishing instruction; obtaining the level type corresponding to the publishing object in the webpage data hierarchy structure; and determining the target webpage design data to be published in the first webpage design data of the draft data layer according to the level type.

[0009] Further, determining the target webpage design data to be published in the first webpage design data of the draft data layer according to the hierarchical type includes: if the hierarchical type is a website level, then all the first webpage design data in the draft data layer are determined as the target webpage design data to be published; or, if the hierarchical type is a webpage level, then the webpage identifier in the data publishing command is extracted, and the first webpage design data associated with the webpage identifier in the draft data layer is selected as the target webpage design data to be published; or, if the hierarchical type is a block level, then the block identifier in the data publishing command is extracted, and the first webpage design data associated with the block level in the draft data layer is selected as the target webpage design data to be published.

[0010] Further, the method further includes: responding to a data adjustment instruction, the data adjustment instruction including an adjustment object and an adjustment type; locating second webpage design data associated with the adjustment object in the draft data layer; modifying the second webpage design data according to the adjustment type to generate updated second webpage design data, and storing the updated second webpage design data in the draft data layer; wherein, when the adjustment object is a published block and the adjustment type is a content adjustment type, it is allowed to initiate a release process independently for the published block or for the page to which the published block belongs; when the adjustment type is a published block and the adjustment type is a structural adjustment type, it is only allowed to initiate a release process for the page to which the published block belongs.

[0011] Further, the method further includes: responding to a version rollback instruction, the version rollback instruction including at least a target version identifier; obtaining a historical webpage design data set associated with the target version identifier; copying the historical webpage design data set to the draft data layer to obtain rollback draft data.

[0012] Further, the step of rendering the corresponding display webpage on different terminal devices based on the second webpage design data in the formal data layer includes: obtaining the screen attribute information of the current terminal device; determining the corresponding device type according to the screen attribute information, and matching the corresponding target style rule using the device type; laying out the second webpage design data in the formal data layer based on the target style rule to generate a display webpage adapted to the current terminal device, and rendering the display webpage.

[0013] In a second aspect, embodiments of the present invention provide a webpage generation apparatus, the apparatus comprising: an acquisition module, configured to acquire first webpage design data in a draft data layer; a determination module, configured to respond to a data publishing instruction for the draft data layer and determine target webpage design data to be published in the first webpage design data of the draft data layer; and a publishing module, configured to publish the target webpage design data to a formal data layer and render corresponding display webpages on different terminal devices based on the webpage design data in the formal data layer.

[0014] In a third aspect, embodiments of the present invention provide a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method of the first aspect or any corresponding embodiment thereof.

[0015] In a fourth aspect, embodiments of the present invention provide a computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a computer to perform the method of the first aspect or any corresponding embodiment thereof.

[0016] The method provided in this application embodiment has the following beneficial effects: The method provided in this application embodiment achieves data isolation and secure storage during the design process by obtaining the first web page design data in the draft data layer, supports users to perform multiple non-destructive edits and save version drafts, and provides a reliable and repeatedly modifiable data source for subsequent release; responding to the data release instruction and determining the target web page design data to be released in the draft data, it can accurately control the scope of the released content, avoid irrelevant or incompletely modified data being accidentally disclosed, and at the same time, combined with the permission management mechanism, enhances the controllability and accuracy of the release process; by releasing the target web page design data to the formal data layer, and rendering the corresponding display web page on different terminal devices based on the data of this layer, it ensures the uniformity of the content after release and the multi-terminal adaptive capability, so that the same set of design data can automatically adapt to different screen sizes and device types, significantly improving the consistency of web page cross-terminal display and user experience.

[0017] Brief Description of the Drawings: In order to more clearly illustrate the technical solutions in the specific embodiments of the present invention or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 is a flowchart illustrating a webpage generation method according to an embodiment of the present invention; Figure 2 is a flowchart illustrating another webpage generation method according to an embodiment of the present invention; Figure 3 is a flowchart illustrating yet another webpage generation method according to an embodiment of the present invention; Figure 4 is a flowchart illustrating yet another webpage generation method according to an embodiment of the present invention; Figure 5 is an architectural diagram illustrating a webpage generation system according to an embodiment of the present invention; Figure 6 is a structural block diagram illustrating a webpage generation device according to an embodiment of the present invention; Figure 7 is a hardware structure diagram illustrating a computer device according to an embodiment of the present invention. Detailed Description

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Specification 3 / 14 Page 6 CN 122045536 A

[0020] According to an embodiment of the present invention, a webpage generation method, apparatus and storage medium are provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0021] In this embodiment, a webpage generation method is provided. FIG1 is a flowchart of a webpage generation method according to an embodiment of the present invention. As shown in FIG1, the process includes the following steps: Step S101, obtaining first webpage design data in the draft data layer.

[0022] In this embodiment of the application, in response to a user's request to enter the webpage design or editing mode, a data query request is initiated to the draft data layer (usually a database or distributed storage system isolated from the production environment) which is dedicated to storing unpublished data, based on the current operation context (such as user identity, page identifier to be edited, or website identifier). Through a pre-set data access interface, the corresponding first webpage design data in an editable state is retrieved from the draft data layer using the current user ID, page path, or unique website ID as query conditions. (i.e., the previously saved draft version containing a list of controls and its structured model data, whose data structure is usually JSON or a similar format, containing a collection of multiple fields). If a corresponding draft exists, it is loaded into memory or front-end state management for subsequent rendering and interaction by the visual designer. If it does not exist (e.g., for the first creation), an empty data structure can be initialized or initial data can be generated based on a template, which is still regarded as an acquisition behavior, thereby providing a clear data source for the subsequent editing and publishing process.For example, when a user clicks "Edit Homepage", the system queries the draft database for the draft record under the current user with the page path " / index", and parses the JSON design data stored therein into an object that the front end can process, thus completing the acquisition of the first webpage design data.

[0023] Step S102: In response to the data publishing instruction for the draft data layer, the system determines the target webpage design data to be published in the first webpage design data of the draft data layer.

[0024] In this embodiment, when a user triggers a publishing operation on the management interface (such as clicking the publish button or calling the publish API), a corresponding data publishing instruction is generated and responded to (this instruction is usually a structured request carrying information such as the publishing operation type, operator identity, timestamp, and target object identifier). First, it is verified whether the current user has publishing permission for this instruction (based on preset permission configuration). Then, the publishing object corresponding to the data publishing instruction (e.g., the entire website, a specific page, or a single block) is identified. Based on the type of the publishing object in the data hierarchy (e.g., website, page, or block), the target webpage design data to be published is located from the first webpage design data (i.e., the current set of design data for all draft versions) already existing in the draft data layer through conditional filtering: if the publishing object is the entire website, the target data is the complete set of all page and block data in the draft layer; if it is a specific page, all block data under that page are extracted according to the page identifier; if it is a single block, the model data of that block is accurately extracted according to the block identifier. This process ensures the controllability of the publishing scope and provides a data source for subsequent data synchronization to the formal environment.

[0025] Step S103: Publish the target webpage design data to the formal data layer, and render the corresponding display webpage on different terminal devices based on the webpage design data in the formal data layer.

[0026] In this embodiment, the determined target webpage design data to be published is completely migrated or overwritten from the draft data layer to the formal data layer (i.e., an independent data storage area that stores all externally visible and published content, physically or logically isolated from the draft layer) through atomic data copying and replacement operations. This publishing process usually generates a new data version and records publishing metadata (such as version number, publishing time, and publisher), while archiving the previously active formal version as a historical version, thereby completing the formal online launch of the data; subsequently, the rendering layer (i.e., the front-end display engine) will actively listen to or periodically poll the data update status of the formal data layer. When new data is detected, it will immediately obtain the latest webpage design data in the formal data layer, and combine it with the terminal device type of the current user (e.g., by obtaining screen attributes and matching CSS media query rules). Then, the corresponding responsive style rules are dynamically applied to calculate and render the layout of the data, and finally a display webpage adapted to the current terminal device is generated (e.g., a single-column layout on a mobile phone and a multi-column layout on a computer) and delivered to the user's browser for display, thereby achieving the effect of one-time release and multi-terminal adaptive presentation. For example, after the page containing a carousel and a news list is released, the data is stored in the official database; when a mobile user accesses it, the rendering engine will detect the small screen device, and then apply the mobile CSS rules to adjust the carousel to full screen width and the news list to a vertical stacked layout before rendering and outputting.

[0027] In the embodiments of this application, the target webpage design data to be released is determined in the first webpage design data of the draft data layer, including: Step A1, identifying the release object corresponding to the data release instruction.

[0028] Specifically, upon receiving a data publishing instruction from the user interface or API (usually a structured request, such as a JSON object containing the fields [Operation: Publish, Operator Identifier, Timestamp]), the payload of the instruction is first parsed to extract the explicitly specified publishing object information. This object is usually represented by specific fields in the instruction (such as target type and target identifier). The target type field is used to indicate the hierarchical range of the publishing operation (its value is "website", "page", or "block"), while the target identifier field is used to uniquely identify the specific operation target within the corresponding level (such as the website ID, the page path, or the block hash value). By reading and verifying these fields, the publishing object corresponding to the data publishing instruction can be accurately identified. For example, if the target type in the instruction is "page" and the target identifier is " / home", then the publishing object for this publishing is identified as a specific page with the path " / home", thus providing input basis for subsequently determining the data filtering range.

[0029] Step A2: Obtain the hierarchical type of the publishing object in the web page data hierarchy structure.

[0030] Specifically, based on the identified publishing object (such as a specific website, page, or block), the layer type corresponding to the publishing object is obtained by querying the predefined web page data hierarchy structure (a logical model describing the data hierarchy, usually defining the website as the highest level, which contains multiple pages, and each page is composed of multiple blocks). According to the identifier of the publishing object (such as ID or path), the search is performed in the hierarchy structure index, or the target type field carried in the data publishing instruction is directly parsed (if the field has explicitly specified the type), thereby determining the category of the object in the hierarchy structure, that is, the layer type (its value is one of "website level", "web page level" or "block level"); for example, if the publishing object is a page identified as " / home", its layer type can be determined as "web page level" through path matching or metadata query. This step provides a direct classification basis for the subsequent (step A3) filtering of the data to be published at different granularities.

[0031] Step A3, determine the target web page design data to be published in the first web page design data of the draft data layer according to the layer type.

[0032] Specifically, determining the target webpage design data to be published in the first webpage design data of the draft data layer according to the layer type includes: if the layer type is the website layer, then all the first webpage design data in the draft data layer are determined as the target webpage design data to be published; or, if the layer type is the webpage layer, then the webpage identifier in the data publishing command is extracted, and the first webpage design data associated with the webpage identifier in the draft data layer is selected as the target webpage design data to be published; or, if the layer type is the block layer, then the block identifier in the data publishing command is extracted, and the first webpage design data associated with the block layer in the draft data layer is selected as the target webpage design data to be published.

[0033] If the hierarchy type is website hierarchy (i.e., the publishing object is the entire portal website), the system directly determines all the first webpage design data stored in the draft data layer (i.e., the draft set of all pages and blocks under the website) as the target webpage design data to be published, without any filtering, and realizes one-time publishing of the entire site; if the hierarchy type is webpage hierarchy (i.e., the publishing object is a single page), the system parses the specific webpage identifier from the payload of the data publishing command (usually page 5 / 14 of the specification, 8 CN 122045536 A). The system uses the unique ID or path name of the page as a condition to query and filter all first webpage design data (usually referring to all block data belonging to the page) associated with this ID in the draft data layer, and uses it as the target of this release; if the level type is block level (i.e. the release object is a single block, such as a carousel or navigation bar), the system also extracts the specific block ID (i.e. the unique ID of the block) from the data release command, and then accurately locates and filters the first webpage design data (i.e. the model data of the specific block) directly associated with this ID in the draft data layer, thereby achieving independent release at the smallest granularity. The entire filtering process is based on the preset data association relationship (such as associating pages and blocks through foreign keys or nested attributes), and is implemented through database query or memory filtering technology to ensure the accuracy and completeness of the release target.

[0034] In the embodiments of this application, the corresponding display webpage is rendered on different terminal devices based on the second webpage design data in the formal data layer, including: Step B1, obtaining the screen attribute information of the current terminal device.

[0035] Specifically, when a user accesses a published webpage through a browser or other client, the rendering layer (i.e., the front-end display engine) actively calls the application programming interface (API) provided by the client environment (e.g., the JavaScript interface of window.screen object, window.innerWidth, or Cascading Style Sheets Media Queries in a web browser) to obtain the screen attribute information of the current terminal device during initial loading or page repainting. This attribute information typically includes, but is not limited to, key parameters such as screen width, height, pixel density, and viewport size. These raw attribute values ​​are collected and encapsulated into structured data objects (e.g., {width: 1024, height: 768, dpr: 2}) as the basic input for determining the device type and matching style rules. For example, when a user accesses a webpage in landscape mode on a tablet device, the rendering layer obtains that the current viewport width is 1024 pixels and records that the device pixel ratio is 2. This information together constitutes the set of screen attribute information of the current terminal device.

[0036] Step B2: Determine the corresponding device type based on the screen attribute information and use the device type to match the corresponding target style rules.

[0037] Specifically, after obtaining screen attribute information (especially screen width), the device type (i.e., "computer", "tablet", or "mobile") corresponding to the current access terminal is determined based on preset device resolution classification rules (e.g., screen width greater than 1024 pixels is computer, greater than 768 pixels and less than or equal to 1024 pixels is tablet, and less than or equal to 768 pixels is mobile). Subsequently, using the determined device type as the query keyword, the corresponding target style rule (i.e., a set of style instructions that defines the size, position, spacing, and display logic of controls under this device type) is matched from a predefined style rule library (this library usually contains a set of CSS styles pre-written for different device types, such as multi-column layout for computers, adaptive grid for tablets, and vertical flow layout for mobile). In addition, the screen orientation attribute (by determining whether it is landscape or portrait) can be combined to match more refined landscape and portrait-specific style rules for devices such as tablets, thereby achieving precise adaptation of styles to devices. For example, when the screen width is 800 pixels, the device type is determined to be "tablet", and further detected as portrait mode, thereby matching and applying the target style rule set specifically for "tablet portrait mode".

[0038] Step B3, based on the target style rules, the second webpage design data in the formal data layer is laid out to generate a display webpage adapted to the current terminal device, and the display webpage is rendered.

[0039] Specifically, the target style rules obtained by matching (i.e., the CSS style set predefined for the current device type, including the size, position, inner and outer margins and display logic of the controls) are used to perform visual layout calculations on the second webpage design data (i.e., the published, structured stored webpage content data, including the control list and its model information) obtained from the formal data layer (an independent storage area that stores all published and externally visible data). By using a template engine or dynamic style injection technology, each control instance (such as a carousel or card) in the second webpage design data is combined with its corresponding style specification (see page 6 / 14, CN 122045536 A) to generate an HTML structure and CSS style code that conforms to responsive design. This generates a display webpage adapted to the current terminal device (for example, arranging card controls vertically in a single column on mobile devices and using a multi-column grid layout on desktop devices). Simultaneously, responsive image processing mechanisms are applied (such as using CSS padding-top percentages and absolute positioning to achieve fixed aspect ratio scaling) to ensure that multimedia elements adapt to different screens. Finally, the generated webpage code is parsed and drawn onto the screen using a browser engine or native rendering components, completing the rendering of the display webpage and providing users with a consistent browsing experience across devices.

[0040] In this embodiment of the application, the method for constructing the first webpage design data, as shown in Figure 2, includes: Step S201, determining the control type of at least one control according to user requirements.

[0041] In this embodiment of the application, the system provides a visual control selection panel, which displays various predefined control types (such as carousels, navigation bars, video players, graphic cards, etc.) in categories. Each control type corresponds to a reusable page function module. Based on their page content and layout plan (i.e., user requirements), users select one or more required control types from the panel by clicking or searching. After receiving the user's selection operation, the unique type identifier of the selected control is recorded. This identifier will serve as the key basis for subsequent instantiation of the control, thereby transforming the abstract user requirements into a specific and operable set of data objects, laying the foundation for subsequent data model filling. For example, when a user needs to construct a homepage containing headline news and product displays, the news list and product cards can be determined as the control types to be used in this instance.

[0042] It should be noted that the control data is set through text input boxes, number input boxes, drop-down boxes, etc. The data structure of each control is as follows:

[0043] Step S202: Obtain the preset data model corresponding to the control type, and fill the corresponding type field, data content field and sorting field in the preset data model to obtain at least one target control.

[0044] In this embodiment of the application, according to the determined control type (such as a carousel, video player, etc.), a preset data model (i.e., a structured data template, such as a JSON object containing fixed fields such as id, type, model, and sortNo) corresponding to the control type is obtained from a predefined control template library. The model field conforms to the BlockModel data structure and contains specific content fields such as title, border, list, and desc. Then, the user is guided to fill in specific data for each field in the preset data model through a visual editing interface (such as a form input box, file upload component, or drop-down selector). The type field (i.e., the type field) is automatically set as the identifier of the current control type. The data content field (i.e., model and its nested fields) is dynamically filled according to the user input (e.g., filling the carousel control with an image list, title text, or video link). The sorting field is automatically generated according to the initial position of the control in the designer or the order manually specified by the user. After filling, all field data is integrated to generate an independently operable control instance, i.e., the target control. This control carries all the necessary rendering data and display configuration, providing a basic unit for subsequent web page assembly.

[0045] It should be noted that the preset data model structure of the rendering control is as follows: Manual 7 / 14 Page 10 CN 122045536 A

[0046] Wherein, the structure of the control list data (i.e., ListItemModel) is as follows:

[0047] The attachment item data structure (i.e., FileItem) is as follows: Manual 8 / 14 Page 11 CN 122045536 A

[0048] For example, when a user creates a "news card" control, the data model template corresponding to the card is loaded. The user then enters the news title, summary, and publication time in the form and uploads a cover image. These contents are automatically filled into the title, desc, publishTime, and imageObject fields of the model. At the same time, the type is set to "newsCard" and sortNo is set to 1, generating a news card target control that can be directly used for page layout.

[0049] Step S203: Generate the first web page design data in the draft data layer based on the target control.

[0050] In this embodiment of the application, each target control (i.e., an independent control instance that has been populated with data) is aggregated and assembled in the order defined by its sort field (sortNo) to form a data set that can describe the content and layout of a webpage or page area, i.e., the first webpage design data; this data is essentially a list or tree structure containing multiple control objects, each control object containing its complete id, type, model and sortNo attributes; subsequently, this structured data is persistently stored in a dedicated draft data layer (i.e., a database or storage area used to store all unpublished design data in the editing state, which is physically or logically isolated from the publicly visible formal data layer), and is usually associated with information such as the currently logged-in user, page identifier and timestamp, thereby generating a webpage design draft version that can be obtained, edited and previewed at any time, but has not yet been released to the public. For example, after a user creates a navigation bar control (sortNo: 1), a carousel control (sortNo: 2), and a news list control (sortNo: 3) in sequence, these target controls are grouped into an array in ascending order of their sortNo. Then, this array is used as the entire page data named "Homepage" and saved to a specific record in the draft database, thus completing the generation and storage of the first webpage design data in the draft layer.

[0051] In this embodiment of the application, after generating the first webpage design data in the draft data layer based on the target controls, the process includes: Step C1, in response to a drag-and-drop start operation on the first target control, obtaining the identifier of the first target control.

[0052] Specifically, when a user performs a drag-and-drop start operation on a rendered control (i.e., the first target control, such as a carousel or navigation bar instance) on the visual interface of the web page designer (this operation specifically refers to the initial action of the user pressing and holding the left mouse button on the control while moving the mouse, corresponding to the dragstart event in the HTML5 native drag-and-drop API), the event is immediately triggered and responded to; in the event handling function, event bubbling is first prevented to avoid interfering with the listening logic of other levels in the designer, and then the first target control identifier (i.e., the unique id value corresponding to the control in the data layer) is extracted from the HTML element bound to the event object (i.e., the outermost DOM element that wraps the control) and recorded in the global or module scope variable, and the flag variable that identifies the drag state is set to true, thereby locking the identity of the currently dragged control and providing key data basis for subsequent drag entry and sequential exchange. For example, when a user starts dragging a news card control with the id "newsCard_005", the data-control-id attribute value "newsCard_005" is read in the dragstart event and assigned to the startDragId variable, marking the official start of the drag-and-drop interaction process for that specific control.

[0053] Step C2, in response to the drag-and-drop operation of dragging the first target control to the trigger area of ​​the second target control, the identifier of the second target control is obtained.

[0054] Specifically, when the user moves the first target control being dragged (whose identifier has been recorded) into the interactive range of another control within the designer, a drag-in operation targeting that target area is triggered (this operation corresponds to the dragenter event in HTML5 drag events, which is triggered when the dragged element first enters the boundary area of ​​a valid placeable element); an event listener has been pre-bound to the wrapping HTML element of each control. When this event is triggered, the listener first prevents event bubbling, and then performs conditional judgment: checking whether the global state variable is true (confirming the existence of valid drag behavior), and whether it exists and is not equal to the identifier carried by the control element that triggered the event (to avoid recording itself as the target); if the conditions are met, then from the current event target element (i.e., the wrapping DOM of the second target control) Extract the identifier of the second target control from the data-* attribute of the element and assign it to another global variable. This records the identity of the target object to which the first target control is about to be placed or swapped, providing key target positioning information for subsequent drag-and-drop completion and sequence swapping.For example, when a user drags a news card with the id "newsCard_005" onto the carousel control, the dragenter event triggered by the carousel control element will record its own id (such as "carousel_002") in the endDragId variable, identifying the potential target position of this drag interaction.

[0055] Step C3: In response to the end of the drag operation, according to the first target control identifier and the second target control identifier, the order of the first target control and the second target control in the first webpage design data is swapped to obtain the swapped first webpage design data.

[0056] Specifically, when the user releases the left mouse button and ends the dragging behavior, a drag-end operation is triggered (bound to the container element of the web page designer). In the processing logic of this event, firstly, based on the previously recorded first target control identifier and second target control identifier, the array index positions corresponding to these two control objects are found in the current first web page design data (i.e., the control array stored in the draft data layer). Subsequently, by swapping the control objects at these two index positions (for example, by using the array's splice method to swap elements), and synchronously updating the values ​​of the sorting fields in the two controls to reflect their new display order, the position swap of the controls in the data layer is completed. After the swap is completed, the updated control array is re-persistently saved to the draft data layer as the swapped first web page design data, overwriting the original data, and realizing real-time synchronization of design state data. Finally, necessary state cleanup work is performed, the global drag state variable is reset to false, and temporary records are cleared to ensure the correct reset of the drag interaction state and avoid interference with subsequent operations.

[0057] In this embodiment of the application, as shown in FIG3, the method further includes: step S301, responding to a data adjustment instruction, wherein the data adjustment instruction includes an adjustment object and an adjustment type.

[0058] In this embodiment of the application, when a user performs operations such as editing, deleting, or structural adjustment on an existing page or block in the web page designer or content management interface (e.g., modifying the text content of a block, changing an image, or adding a new block to the page) and confirms saving, a data adjustment instruction is generated. This instruction is a data object carrying the operation intent and parameters, which clearly includes the adjustment object (i.e., the specific target identifier targeted by this operation, such as the ID of the published block "block_123", or the path of the page " / home") and the adjustment type (used to distinguish the essential category of the operation, usually a predefined enumeration value, such as only updating the content while keeping the block structure unchanged, or involving the addition, deletion, or hierarchical relationship change of blocks). Then, in response to this data adjustment instruction, the user receives the instruction through event listening or API call, parses the adjustment object and adjustment type information in it, and passes it to the subsequent processing logic to locate and change the specific data.

[0059] Step S302: Locate the second webpage design data associated with the adjustment object in the draft data layer.

[0060] In this embodiment, after receiving the parsed data adjustment instruction, based on the adjustment object specified in the instruction (such as the unique ID of the block "block_123" or the path of the page " / home"), a data query and location operation is performed in the draft data layer (an independent storage area that stores all unpublished design data in the editing state). Using the adjustment object as the query condition, the second webpage design data associated with the adjustment object in the data structure is found and located by using a database query statement (such as SELECT in SQL) or by traversing the data set in memory. (That is, the editable design data copy currently stored in the draft layer for the specific page or block, whose data structure is similar to the first webpage design data, including information such as control list, model and sorting.) For example, when the adjustment object is block ID "block_789", the record with id "block_789" is queried in the block table of the draft data layer, and its corresponding complete design data (including the block's type, model, etc.) is loaded into the processing context to provide a data target for subsequent change operations. If the object does not exist in the draft layer (for example, when editing a published block for the first time), a corresponding second web page design data copy can be initialized and generated in the draft layer based on the current version data of the block in the formal data layer for adjustment.

[0061] Step S303: Change the second web page design data according to the adjustment type, generate updated second web page design data, and store the updated second web page design data in the draft data layer.

[0062] In this embodiment of the application, based on the parsed adjustment type, the corresponding data change operation is performed on the located second web page design data. For content-related adjustments (such as modifying text or changing images), new data received via form input or API directly updates the relevant properties in the `model` field of the corresponding control. For structural adjustments (such as adding or deleting controls or rearranging their order), array operations or reassignment of fields are used to change the composition or arrangement of controls, and the property values ​​of all affected controls are updated synchronously to maintain the correct order. After the changes are completed, the updated data copy is integrated into the updated second webpage design data. Subsequently, it is persistently stored in the corresponding record of the draft data layer through a database UPDATE operation or overwrite, replacing the original draft. This ensures that all editing results are securely saved and in a ready-to-publish state. A unique version hash or timestamp can also be generated for this new draft to support subsequent traceability.For example, if a user changes the title of a block from "News" to "Latest News", after updating the model.title field in the located block data, the entire block data object is written back to the draft database to complete the saving of this content adjustment.

[0063] In this embodiment, when the adjustment object is a published block and the adjustment type is a content adjustment type, it is allowed to initiate a publishing process independently for the published block or to initiate a publishing process for the page to which the published block belongs; when the adjustment type is a published block and the adjustment type is a structural adjustment type, it is only allowed to initiate a publishing process for the page to which the published block belongs.

[0064] In this embodiment, as shown in FIG4, the method further includes: Step S401, responding to a version rollback instruction, the version rollback instruction includes at least a target version identifier.

[0065] In this embodiment, when a user selects a past release version and triggers a "rollback" operation in a portal website or block management interface (such as a historical version list), a version rollback instruction is generated and responded to. This instruction is usually a request data packet sent by the front-end interface or API call, which must contain the target version identifier specified by the user (i.e., a string that uniquely identifies a historical release version, such as version number V1 or hash value), and may also contain meta-information such as operator and timestamp. After receiving this instruction through event listening or interface call, the system first verifies whether the current user has the operation permission for version rollback, then parses the instruction payload, extracts the target version identifier, and thus confirms the specific historical version that the user wants to restore, providing a clear target for subsequent steps (acquiring historical data and copying it to the draft layer).

[0066] Step S402: Obtain the historical webpage design data set associated with the target version identifier.

[0067] In this embodiment, after parsing the target version identifier (such as version number V2.1), this identifier is used as a key query condition to initiate a query request to the version management database or storage system. By querying a data table or file index specifically used to store historical version snapshots, a complete set of historical web page design data that is precisely associated with the target version identifier is obtained. This set of data is a snapshot that is fully archived when the target version is released. It is usually stored in a structured form (such as JSON or serialized objects) and contains all page data, block data and their hierarchical relationships within the portal website or a specific release scope under this version.

[0068] Step S403: Copy the historical web page design data set to the draft data layer to obtain the rollback draft data.

[0069] In this embodiment of the application, the historical webpage design data set (i.e., a full data snapshot of the target historical version) is written into the draft data layer through a data copying operation (such as executing a database INSERT operation or a file storage system copy command), overwriting or replacing any old draft data currently existing on the page or website; at the same time, a new draft unique identifier is generated for this copy (e.g., a new version hash is generated by combining the timestamp), and this data is marked as rollback draft data (i.e., a draft copy from a historical version that is currently in an editable and republishable state), thus completing the operation of restoring the specified historical version to the current editable draft.

[0070] This embodiment also provides a webpage generation system, as shown in Figure 5. The architecture includes: a webpage designer, a draft data layer, a formal data layer, and a rendering layer. The webpage designer is connected to the draft data layer for data reading and writing. The draft data layer and the formal data layer synchronize data in one direction or two directions through a publish / rollback mechanism. The formal data layer is connected to the rendering layer. The webpage designer is used to edit and combine controls through a visual drag-and-drop method, build and generate draft data of webpages, blocks, and layouts based on user input, and store the data in the draft data layer. It supports real-time preview and multi-round editing. The draft data layer is used to store all webpage design data that is in the editing state and has not been published externally, including page data, block data, and their associated hierarchical structure. It also supports data filtering and management based on the publishing object (website, page, or block). The formal data layer is used to receive target webpage design data published from the draft data layer, store all published and publicly visible webpage content versions, and record historical version snapshots generated for each publication. It supports data retrieval and backtracking by version identifier. The rendering layer is used to obtain currently valid webpage design data from the formal data layer, match the corresponding responsive style rules with the screen attributes of the access terminal, perform layout calculations and multi-terminal adaptation rendering on the data, and finally generate and display the corresponding webpage on different devices.

[0071] In this embodiment, a webpage generation device is also provided, which is used to implement the above embodiments and preferred embodiments. Details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0072] This embodiment provides a webpage generation device, as shown in FIG6, including: an acquisition module 61, used to acquire first webpage design data in a draft data layer; a determination module 62, used to respond to a data publishing instruction for the draft data layer and determine the target webpage design data to be published in the first webpage design data in the draft data layer; and a publishing module 63, used to publish the target webpage design data to the formal data layer and render the corresponding display webpage on different terminal devices based on the webpage design data in the formal data layer.

[0073] In this embodiment, the device further includes: a construction module, used to determine the control type of at least one control according to user needs; acquire a preset data model corresponding to the control type, and fill the preset data model with the corresponding type field, data content field, and sorting field to obtain at least one target control; and generate first webpage design data in the draft data layer based on the target control.

[0074] In this embodiment, the construction module is further configured to: obtain the identifier of the first target control in response to a drag-to-start operation for the first target control; obtain the identifier of the second target control in response to a drag-in operation for dragging the first target control to the trigger area of ​​the second target control; and, in response to a drag-to-end operation, exchange the order of the first target control and the second target control in the first webpage design data according to the identifier of the first target control and the identifier of the second target control to obtain the exchanged first webpage design data.

[0075] In this embodiment, the determining module 62 is specifically configured to: identify the publishing object corresponding to the data publishing instruction; obtain the level type corresponding to the publishing object in the webpage data hierarchy structure; and determine the target webpage design data to be published in the first webpage design data of the draft data layer according to the level type.

[0076] In this embodiment of the application, the determining module 62 is specifically used to determine all the first webpage design data in the draft data layer as the target webpage design data to be published if the layer type is a website layer; or, if the layer type is a webpage layer, extract the webpage identifier in the data publishing command and filter out the first webpage design data associated with the webpage identifier in the draft data layer as the target webpage design data to be published; or, if the layer type is a block layer, extract the block identifier in the data publishing command and filter out the first webpage design data associated with the block layer in the draft data layer as the target webpage design data to be published.

[0077] In this embodiment, the apparatus further includes: an adjustment module, configured to respond to a data adjustment instruction, the data adjustment instruction including an adjustment object and an adjustment type; locate second webpage design data associated with the adjustment object in the draft data layer; modify the second webpage design data according to the adjustment type to generate updated second webpage design data, and store the updated second webpage design data in the draft data layer; wherein, when the adjustment object is a published block and the adjustment type is a content adjustment type, it is allowed to initiate a publishing process independently for the published block or for the page to which the published block belongs; when the adjustment type is a published block and the adjustment type is a structural adjustment type, it is only allowed to initiate a publishing process for the page to which the published block belongs.

[0078] In this embodiment, the apparatus further includes: a rollback module, configured to respond to a version rollback instruction, the version rollback instruction including at least a target version identifier; obtain a set of historical webpage design data associated with the target version identifier; copy the set of historical webpage design data to the draft data layer to obtain rollback draft data.

[0079] In this embodiment of the application, the publishing module 63 is specifically used to obtain the screen attribute information of the current terminal device; determine the corresponding device type according to the screen attribute information, and use the device type to match the corresponding target style rule; lay out the second webpage design data in the formal data layer based on the target style rule, generate a display webpage adapted to the current terminal device, and render the display webpage.

[0080] Please refer to FIG7. FIG7 is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention. As shown in FIG7, the computer device includes: one or more processors 10, memory 20, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components communicate with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, multiple processors and / or multiple buses can be used together with multiple memories and multiple memory units if needed. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0081] The processor 10 can be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device can be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GPRS), or any combination thereof.

[0082] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0083] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required for at least one function, and the data storage area may store data created by using the computer device according to the display of a small program landing page (page 13 / 14, CN 122045536 A). Furthermore, the memory 20 may include high-speed random access memory and may also include non-transient memory, such as at least one disk storage device, flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0084] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include combinations of the above types of memory.

[0085] The computer device also includes a communication interface 30 for the computer device to communicate with other devices or communication networks.

[0086] Embodiments of the present invention also provide a computer-readable storage medium in which the methods described above according to embodiments of the present invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and will be stored on a local storage medium, so that the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware. The storage medium may be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implement the methods shown in the above embodiments.

[0087] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.Description 14 / 14 pages 17 CN 122045536 A Figure 1 Figure 2 Description Drawings 1 / 4 pages 18 CN 122045536 A Figure 3 Figure 4 Description Drawings 2 / 4 pages 19 CN 122045536 A Figure 5 Figure 6 Description Drawings 3 / 4 pages 20 CN 122045536 A Figure 7 Description Drawings 4 / 4 pages 21 CN 122045536 A Abstract The invention relates to the field of website construction and content management, and discloses a web page generation method, device and storage medium. The method includes : obtaining first web page design data in a draft data layer; responsive to a data publishing instruction for the draft data layer and determining target web design data to be published in the first web design data of the draft data layer; publish the target web design data to the formal data layer, and render the corresponding display web pages on different terminal devices based on the web design data in the formal data layer. The invention solves the problems in the prior art that the multi-terminal adaptation of the portal website is difficult and the release and rendering processes are separated.。

Claims

1. A method for generating web pages, characterized in that, The method includes: Retrieve the first webpage design data from the draft data layer; In response to a data publishing instruction for the draft data layer, the target webpage design data to be published is determined in the first webpage design data of the draft data layer; The target webpage design data is published to the formal data layer, and the corresponding display webpage is rendered on different terminal devices based on the webpage design data in the formal data layer.

2. The method according to claim 1, characterized in that, The method for constructing the first webpage design data includes: Determine the control type of at least one control based on user requirements; Obtain the preset data model corresponding to the control type, and fill the preset data model with the corresponding type field, data content field and sorting field to obtain at least one target control; The first webpage design data is generated in the draft data layer based on the target control.

3. The method according to claim 2, characterized in that, After generating the first webpage design data based on the target control in the draft data layer, the process includes: In response to a drag-and-drop start operation targeting the first target control, obtain the identifier of the first target control; In response to a drag-in operation that drags the first target control to the trigger area of ​​the second target control, the identifier of the second target control is obtained; In response to the end of the drag-and-drop operation, the order of the first target control and the second target control in the first web page design data is swapped according to the first target control identifier and the second target control identifier, so as to obtain the swapped first web page design data.

4. The method according to claim 1, characterized in that, The step of determining the target webpage design data to be published from the first webpage design data in the draft data layer includes: Identify the publishing object corresponding to the data publishing instruction; Obtain the hierarchy type of the published object in the webpage data hierarchy structure; The target webpage design data to be published is determined from the first webpage design data in the draft data layer according to the level type.

5. The method according to claim 4, characterized in that, The step of determining the target webpage design data to be published in the first webpage design data of the draft data layer according to the hierarchy type includes: If the level type is a website level, then all the first webpage design data in the draft data layer will be determined as the target webpage design data to be published. Alternatively, if the level type is a web page level, the web page identifier in the data publishing command is extracted, and the first web page design data associated with the web page identifier is selected in the draft data layer as the target web page design data to be published. Alternatively, if the level type is a block level, the block identifier in the data publishing command is extracted, and the first web page design data associated with the block level is selected from the draft data layer as the target web page design data to be published.

6. The method according to claim 1, characterized in that, The method further includes: In response to a data adjustment instruction, the data adjustment instruction includes the adjustment object and the adjustment type; Locate the second webpage design data associated with the adjustment object in the draft data layer; The second webpage design data is modified according to the adjustment type to generate updated second webpage design data, and the updated second webpage design data is stored in the draft data layer. Specifically, when the adjustment object is a published block and the adjustment type is a content adjustment type, it is allowed to initiate a publishing process independently for the published block or for the page to which the published block belongs; when the adjustment type is a published block and the adjustment type is a structural adjustment type, it is only allowed to initiate a publishing process for the page to which the published block belongs.

7. The method according to claim 1, characterized in that, The method further includes: In response to a version rollback command, the version rollback command includes at least a target version identifier; Obtain the set of historical webpage design data associated with the target version identifier; The historical webpage design data set is copied to the draft data layer to obtain the rollback draft data.

8. The method according to claim 1, characterized in that, The rendering of the corresponding display webpage on different terminal devices based on the second webpage design data in the formal data layer includes: Obtain the screen attribute information of the current terminal device; The corresponding device type is determined based on the screen attribute information, and the corresponding target style rule is matched using the device type; Based on the target style rules, the second webpage design data in the formal data layer is laid out to generate a display webpage adapted to the current terminal device, and the display webpage is rendered.

9. A webpage generation device, characterized in that, The device includes: The acquisition module is used to acquire the first webpage design data in the draft data layer; A determination module is used to respond to a data publishing instruction for the draft data layer and determine the target webpage design data to be published in the first webpage design data of the draft data layer; The publishing module is used to publish the target webpage design data to the formal data layer, and render the corresponding display webpage on different terminal devices based on the webpage design data in the formal data layer.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the method of any one of claims 1 to 8.

Images