Webpage development method, device, equipment and program product

Abstract

The application discloses a webpage development method, device, equipment and program product, and aims to solve the problem of insufficient page flexibility and difficulty in adapting to high-frequency dynamic changes of page style and operation content caused by customized development or dependence on fixed templates in the prior webpage development technology. The scheme comprises the following steps: determining at least one to-be-operated position in a target page, and registering a corresponding touch for each to-be-operated position. Through a visual configuration interface, a component library containing a plurality of reusable operation element components is provided to a user, and at least one target operation element component selected from the component library is associated with the touch in response to a user operation. A preview script of the target page is generated, and the preview script defines a layout rule of the target operation element component based on the to-be-operated position. Through the visual configuration interface, a configuration interface of the preview script is provided to the user, and the target operation element component in the preview script is configured through the configuration interface in response to a user operation.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a web page development, apparatus, device, and program product. Background Technology

[0002] With the rapid development of the mobile internet, various application service providers need to frequently build and adjust their page content to adapt to diverse user needs and market changes. Traditional web page development and operation configuration methods often rely on customized development or fixed templates, making it difficult to flexibly cope with the complex needs of diverse page styles and dynamically changing operational content. Summary of the Invention

[0003] This application proposes a web page development device, apparatus, equipment, and program product, aiming to solve the problems of insufficient page flexibility, long development iteration cycles, and difficulty in adapting to frequent dynamic changes in page style and operational content caused by the use of customized development or reliance on fixed templates in existing web page development technologies. Accordingly, the technical solution of this application is as follows: In a first aspect, embodiments of this application provide a web page development method, including: Identify at least one location to be operated on the target page, and register a corresponding touchpoint for each location to be operated; wherein, the location to be operated refers to the logical area on the target page used to display operational content; Through a visual configuration interface, a component library containing multiple reusable operational element components is provided to the user, and in response to user operations, at least one target operational element component selected from the component library is associated with the touchpoint. Generate a preview script for the target page, wherein the preview script defines the layout rules for the target operational element components based on the location to be operated; The visual configuration interface provides users with a configuration interface for the preview script and, in response to user operations, allows for content configuration of the target operational element components in the preview script through the configuration interface, thereby completing the development of the target page.

[0004] Secondly, embodiments of this application provide a web page development apparatus, comprising: The touchpoint configuration module is used to determine at least one location to be operated in the target page and register a corresponding touchpoint for each location to be operated; wherein, the location to be operated refers to the logical area in the target page used to display operational content; The component configuration module is used to provide users with a component library containing multiple reusable operational element components through a visual configuration interface, and in response to user operations, associate at least one target operational element component selected from the component library with the touchpoint. The script configuration module is used to generate a preview script for the target page, wherein the preview script defines the layout rules of the target operation element components based on the location to be operated; The content configuration module is used to provide users with a configuration interface for the preview script through the visual configuration interface, and in response to user operations, configure the content of the target operational element components in the preview script through the configuration interface to complete the development of the target page.

[0005] Thirdly, embodiments of this application provide an electronic device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to perform the method described in the first aspect.

[0006] Fourthly, embodiments of this application provide a computer program product, the computer program product including a computer-readable storage medium storing a computer program operable to cause a computer to perform the method described in the first aspect.

[0007] The solution in this application embodiment is implemented through the following technical means: First, at least one operational location is planned on the target page, and a corresponding touchpoint is registered for each operational location, thereby structuring and localizing the page's operational capabilities. Second, a component library containing multiple standardized and reusable operational element components is provided to the user through a visual configuration interface; then, in response to user operations, the target operational element component selected from the component library is dynamically associated with the aforementioned touchpoint. This design encapsulates various common operational content such as text, images, and links into standardized operational element components and manages them in a unified component library, enabling these components to be repeatedly called and combined in different pages and different operational scenarios, thereby avoiding the hassle of repeatedly developing the same or similar operational functions. Next, based on the associated touchpoints and components, a preview script for the target page is generated, which essentially defines the layout rules of each target operational element component on the corresponding operational location. Finally, a configuration interface for the preview script is provided to the user through the same visual configuration interface, allowing the user to configure the specific content of the target operational element components within the script. The above process transforms page development into a series of visual configuration operations, enabling efficient and flexible development and deployment of the target page without writing underlying code. Attached Figure Description

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

[0009] Figure 1 This is a schematic diagram of the first process of a web page development method according to an embodiment of this application.

[0010] Figure 2 This is a schematic diagram illustrating the division of target pages in the web page development method of this application embodiment.

[0011] Figure 3 This is a schematic diagram of data association relationships in the web page development method of this application embodiment.

[0012] Figure 4 This is a schematic diagram of a second process for a web page development method according to an embodiment of this application.

[0013] Figure 5 This is a schematic diagram illustrating the "setting and previewing simultaneously" implementation of the web page development method in this application embodiment.

[0014] Figure 6 This is a schematic diagram of the third process of the web page development method according to an embodiment of this application.

[0015] Figure 7 This is a schematic diagram of the web page development apparatus according to an embodiment of this application.

[0016] Figure 8 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0018] With the rapid development of the mobile internet, application service providers need to frequently build and adjust webpage content to achieve precise operations. Current mainstream technical solutions mainly include page-level custom development, element type abstraction and reuse, template or region-level pre-set development, and third-party component integration. Page-level custom development requires writing dedicated code for each webpage; element type abstraction and reuse categorizes common page elements to achieve unified management of similar elements; template-level development pre-sets operational functions based on fixed layouts for front-end integration; and third-party integration relies on external standardized components. While these solutions can achieve basic operational functions, they generally rely on pre-set structures or repetitive coding.

[0019] Existing technical solutions have significant shortcomings when dealing with complex needs such as diverse page styles and dynamically changing operational content. For example, page-level development lacks reusability, leading to low development efficiency; template-level solutions are limited by fixed layouts and cannot flexibly adapt to multiple terminals or irregularly shaped pages; while abstract reuse mechanisms have limited support for element combination and real-time adjustment, failing to efficiently respond to frequent content updates and diverse design requirements, thus increasing development and maintenance costs.

[0020] In view of this, this application proposes a web page development, device, equipment, and program product, which aims to solve the problems of insufficient page flexibility, long development iteration cycle, and difficulty in adapting to the high-frequency dynamic changes in page style and operational content caused by the use of customized development or reliance on fixed templates in existing web page development technologies.

[0021] The technical solutions provided by the various embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0022] One embodiment of this application provides a web page development method. Wherein, Figure 1 This is a flowchart illustrating web page development methods, including: S101, determine at least one location to be operated in the target page, and register a corresponding touchpoint for each location to be operated; wherein, the location to be operated refers to the logical area in the target page used to display the operation content.

[0023] The significance of this step is to structurally and positionally identify and define the various areas on the target page where dynamic operational deployments are planned, thus laying the foundation for subsequent visual configuration based on standardized components. By clearly defining the locations to be operated and registering unique touchpoints for them, the scattered operational capabilities on the page that originally required customized front-end code are essentially transformed into a series of standardized "configuration anchors" that can be uniformly managed, configured, and invoked. For example, on an app's homepage, the carousel at the top, the activity zone in the middle, and the promotional entry at the bottom can all be planned as independent locations to be operated; and the touchpoint registered for each such location serves as its unique identifier and configuration entry point in the subsequent operational configuration process.

[0024] Page touchpoint planning and registration is the first step in structuring page operation capabilities. It involves dividing the target page according to a logical regional division and creating and registering a unique touchpoint as its identifier for each region to be operated. Page touchpoint planning, based on the analysis of page layout and operational needs, divides the page into different logical regions, each corresponding to a location to be operated, and uniquely identifies and manages these touchpoints within the system. In practice, touchpoint registration is performed in the backend management system based on the analysis of the target page layout and operational needs. Touchpoint creation must be completed through a dedicated touchpoint registration function. Successfully registered touchpoints will serve as the basis for subsequent content delivery and location association in operational work orders.

[0025] During touchpoint registration, relevant attribute information needs to be entered. This information typically includes, but is not limited to, the page it belongs to, the channel, the touchpoint type, the touchpoint name, and the province where it is deployed. After submitting this information, the system will automatically generate a globally unique touchpoint code for that touchpoint. This code becomes the core identifier for that touchpoint throughout the entire system process. To adapt to operational needs in different scenarios, the touchpoint registration function offers flexible registration modes. For example, the number of frames and the frame sequence number of a touchpoint can be automatically generated by the system according to preset rules, or operators can manually specify them. For scenarios requiring the creation of a large number of touchpoints, the system supports batch registration via attachment upload, thereby significantly improving operational efficiency. In addition, the system also supports adding and editing frames to registered touchpoints, as well as enabling or disabling touchpoints. After registration is completed, each successfully registered operational location and its corresponding touchpoint are incorporated into the system's management system, enabling them to be associated with subsequent operational element components and accept visual configuration.

[0026] After registration, each touchpoint will form a complete record in the system. Its core information structure includes several key fields, such as touchpoint type (contactor_type) to distinguish different types of touchpoints, primary and secondary channel codes and names (channel_code, channel_name) to identify the channel it belongs to, a field indicating the touchpoint status (make_del), the associated system code (application_system_code), specific page information (operation_code, operation_name, operation_url), delivery range information (province_code, province_name), touchpoint position number (index_no), a globally unique touchpoint code (position_code), and touchpoint name (contact_name). This structured information system lays a solid data foundation for touchpoints to be linked with subsequent floor-level zone planning, operational element components, and precise delivery.

[0027] Furthermore, to further enhance the granularity of page area division and the flexibility of operational element configuration, this embodiment supports hierarchical planning of the target page. Specifically, the entire page can be divided into multiple floor areas according to a hierarchical relationship, and each floor area can be further divided into sub-areas to form dedicated zones. Under this model, the location to be operated is specifically represented by two types of logical areas: one is the floor area as a whole, and the other is the dedicated zone further subdivided within the floor. This means that a floor can be used as a complete touchpoint associated with a location to be operated; at the same time, any dedicated zone within it can also be used as an independent touchpoint associated with a location to be operated. The core concept of this hierarchical planning is to decouple the complex page structure into clearly hierarchical and clearly defined configuration units by defining and managing the macro-level floors and micro-level dedicated zones separately. Its significance lies in realizing modular management of page layout and precise deployment of operational capabilities, enabling operators to independently configure and combine areas of different levels and granularities, thereby greatly enhancing the flexibility of operational strategies and the granular control capability of page construction.

[0028] To solidify and efficiently manage the logical relationships among the aforementioned pages, floors, zones, and touchpoints, this embodiment maps them to a structured data table design. (Reference) Figure 3 As shown, this data table design constitutes a complete data link of "page → floor → zone → touchpoint" or "page → floor → touchpoint", providing underlying data support for refined operations. The core definitions and relationships of each table are as follows: Page Floor Association Table: Establishes the context to which a page belongs, records information such as the application system and distribution channel to which it belongs, and connects it to the floor table through association fields to realize "page association with floor".

[0029] Floor table: Defines floor entities, records floor name, code, display attributes and sorting number, and associates them with the zone table through their primary key to realize "floor associated with zone".

[0030] Zone Table: Manages sub-zones within a floor, recording the zone name, number, and its sequence number within the floor, and closely linked to the corresponding floor through a foreign key (the table ID of the floor to which the zone belongs).

[0031] Touchpoint Information Table: Stores core information for all registered touchpoints, including unique codes, names, frame settings, and statuses. Whether it's a floor or a zone, data association can point to a specific touchpoint record in this table.

[0032] It should be understood that through this table structure that clearly defines the subordinate and referential relationships of each dimension, the system can accurately map and manage the operational configuration of any logical area (floor, zone, or directly related touchpoint) on the page, thereby providing a data foundation for the modular deployment of page operations.

[0033] S102 provides users with a component library containing multiple reusable operational element components through a visual configuration interface, and in response to user operations, associates at least one target operational element component selected from the component library with a touchpoint.

[0034] The significance of this step is to standardize and componentize the basic functional units that constitute the page's operational content, and to achieve rapid binding of operational capabilities to page locations through a visual interactive method. Its significance lies in transforming the traditional code-dependent development of page functions into an intuitive, block-building-like configuration operation. Operations personnel can freely associate the required functional modules (i.e., operational element components) with pre-planned operational locations (i.e., touchpoints) on the page, thereby significantly lowering the barrier to entry for building page operational functions and shortening configuration time. The operational element components are abstract encapsulations of various operational content and interactive functions. The component library typically includes various types such as text components, image components, link components, and badge components. Each operational element component has well-defined attributes and behaviors. These attributes are standardized and stored using a JSON structure (e.g., recording component type, English parameter names, format or size constraints), thereby ensuring the component's independence, configurability, and stable reuse across multiple scenarios.

[0035] In practical implementation, a clearly categorized operational element component library panel can be displayed to users in the visual configuration interface. When a user needs to configure a registered touchpoint, they simply browse and select the desired target operational element component (such as a text component for displaying the main title) from the component library and drag and drop it into the configuration area associated with that touchpoint. The system responds to this operation in real time, automatically establishing the association between the selected target operational element component and the specific touchpoint. The backend system records and stores this association in a structured data format (such as an ordered JSON array), which fully records the type, order, and key attribute identifiers of all operational element components associated with that touchpoint. Through this drag-and-drop association, operations personnel can flexibly configure multiple different types of operational element components for a single touchpoint, quickly building complex solutions without needing to worry about the underlying code implementation.

[0036] To support the aforementioned visual configuration and cross-terminal reuse capabilities, this embodiment systematically designs and encapsulates the operational element components. The components are encapsulated through a unified technology adaptation layer, possessing cross-terminal type and implementation adaptability. They are applicable to various native application environments, HTML5 pages, personal computer browsers, and mainstream mini-program ecosystems, truly achieving "develop once, reuse across multiple platforms." In terms of component organization and management, they can be categorized into common, basic, and supplementary types based on their function and usage frequency. The attributes of each operational element component are standardized and stored using a JSON structure, for example, {"elementType": "time", "param_name": "time"}. For touchpoints that need to be associated with multiple operational element components of the same type, the system distinguishes them using a unique English parameter name (param_name). This parameter can be automatically generated according to the "type + number" rule to ensure uniqueness, or it can be matched using a pre-defined English parameter enumeration table to improve configuration efficiency and consistency. For complex operational element components with multi-dimensional business constraints (such as image components involving format and size limitations), their attribute encapsulation includes a related identifier (tableId) for linking to a dedicated element constraint record table in the backend, thereby achieving centralized management of complex attributes. Components with simple attributes only need to be defined through type tags. Taking the image component as an example, its attributes can be encapsulated as {"elementType": "image", "tableId": "123456"}. The image element design table linked through tableId defines detailed attribute constraints such as display name, element type, English parameter name, upload method, image format, size limit, size limit, whether it is required, and whether it is previewable. The English parameter name is also stored synchronously in this table, ensuring the consistency between parameter identifiers and business constraints. This hierarchical management mechanism for components of different complexities effectively controls the complexity of the system architecture while ensuring configuration flexibility and scalability.

[0037] Furthermore, to flexibly manage the relationships between touchpoints and components and support dynamic expansion, this embodiment uses a JSON structure to store these relationships. The JSON format naturally supports combination and order adjustment; when adding or deleting related components, only the corresponding JSON data needs to be edited. A hierarchical storage strategy is adopted: the configuration of simple components is directly written to JSON; complex components record the tableId in the JSON and query the backend constraint table, thus balancing the lightweight structure with the completeness of constraints. Finally, the relationships are persistently stored as an ordered JSON array, which records the information nodes of each related component (including fields such as elementType, param_name, or tableId) in sequence, precisely corresponding to the order in the configuration interface, and can be easily expanded by adding nodes.

[0038] S103, Generate a preview script for the target page. The preview script defines the layout rules of the target operation element components based on the location to be operated.

[0039] The significance of this step is to transform the previously planned page structure (the location to be operated) and associated operational element components into a dynamically rendered, proportionally scaled visual model that mirrors the final user-end page. Generating a preview script essentially creates a copy of the target page for interactive preview during the configuration phase. It predefines the precise positions, styles, and hierarchical relationships of each operational element component within the page, providing the technical foundation for subsequent "configure-while-previewing" visualization operations. The preview script itself is a structured collection of data and instructions. It doesn't contain specific operational content data, but it does include a complete framework of how content should be placed and displayed. For example, a preview script might record the coordinates and size of an image component within its associated touchpoint area, as well as the font, size, and color information that a text component should use. This information collectively constitutes the blueprint for the page layout.

[0040] In practical implementation, the process of generating preview scripts can be further broken down into several key operations. First, for each location to be operated, a matching base map is configured for its corresponding touchpoint. This base map serves as a visual reference canvas for subsequent layout operations. Next, on the base map, detailed configuration information is set for each target operational element component associated with that touchpoint. This configuration information includes at least its position coordinates and visual style parameters on the base map. For example, operators can drag and drop an image component to a specific area of ​​the base map and set its size; or drag a text component to a specified position and select its font and color. All configuration information for touchpoints and their associated components, including touchpoint identifiers, component types, coordinates, styles, etc., is aggregated and generated into a structured data object (e.g., a multi-level nested JSON structure). This structured data fully describes the hierarchical relationship from page, floor (i.e., the floor area mentioned above) / zone to touchpoint, component, and its layout rules. Finally, the parsing engine converts this structured data into code that the browser or rendering engine can recognize (e.g., an HTML fragment containing DIV containers and CSS style definitions), generating a preview script for defining layout rules. It should be understood that the preview script is designed to transform abstract layout intentions into precise, executable visual instructions. This allows the system to automatically fill in the content in the correct positions and render the actual styles when configuring specific operational content, achieving a WYSIWYG (What You See Is What You Get) configuration process. This greatly improves the accuracy and efficiency of configuration and avoids repeated modifications caused by misunderstandings or insufficient testing in traditional methods.

[0041] S104 provides users with a configuration interface for previewing scripts through a visual configuration interface. In response to user operations, users can configure the content of the target operational element components in the preview script through the configuration interface to complete the development of the target page.

[0042] The significance of this step is to finally bind and integrate the page layout rules defined by the preview script (i.e., the page's "skeleton") constructed in the previous steps with the specific operational content (i.e., actual text, image links, redirect addresses, etc., which can be regarded as the page's "flesh and blood") that the operations personnel are preparing to use. This process is achieved by providing users with a configuration interface for the preview script. This interface serves as a low-barrier, high-efficiency final configuration entry point, allowing operations personnel without coding skills to simply fill in or select specific content in intuitive forms, input boxes, or selectors. This drives the system to automatically fill the content into the corresponding positions and render a display effect consistent with the end user, based on the established rules in the preview script. This signifies that the entire process from page structure planning and layout definition to content configuration is completed within a visual interface, truly achieving a one-stop closed loop from operational configuration to the page's publishable state, thereby efficiently and error-free completing the development of the target page.

[0043] In practical implementation, the system loads the generated preview script in the visual configuration interface, parses and maps it into a visual configuration form area, i.e., the configuration interface. For example, for a touchpoint associated with a "main title text component" and an "activity image component," the configuration interface will render a text input box (for filling in the title content) and an image upload control (for uploading the activity image). Every content entry or selection operation performed by the operations personnel in this interface will be captured by the system in real time and bound to the corresponding target operational element component in the preview script. All configuration content will be structured and saved as a publishable "work order" data. Its technical effect lies in decoupling the complex page development process into two relatively independent stages: "layout definition" and "content filling," and fully graphicallyizing and formalizing the latter. This allows operations personnel without a technical background to independently and accurately complete the deployment of the final page content, greatly shortening the path from operational ideas to page launch and improving business response speed.

[0044] During the page development and configuration process, this embodiment further integrates the content of the target operational element components configured by the user with the layout rules in the preview script in real time, so as to synchronously render the target page in a dedicated preview area of ​​the visual configuration interface. To achieve clearer visualization of the configuration process, this embodiment records the association order of all touchpoints with the target operational element components. Based on this, the system can gradually combine the content configured by the user with the layout rules in the preview script according to this association order, thereby dynamically rendering the evolution process of the target page from scratch and filling in content in sequence in the preview area. The significance of doing so is that it provides a progressive, configuration-logic visual feedback, which not only shows the final effect, but also clearly presents the logical steps of page composition, helping the configurer to understand the page structure and verify the completeness of the configuration. For example, if the operator first configures the touchpoint content of floor one, the preview area will first fully render floor one; when configuring the content of floor two, the preview area will dynamically stitch together and render floor two below the already rendered floor one.

[0045] Furthermore, the preview area can visually highlight the target operational element component that the user is currently configuring. For example, when a user edits a link to an image component in the configuration form on the right, the corresponding image location in the preview area will display a highlighted flashing border or a background color change. This establishes a strong spatial connection and immediate feedback between the configuration operation and the visual effect, helping users quickly locate the specific position of the currently edited item on the page, effectively avoiding configuration misalignment, and greatly improving the accuracy of configuration operations and the user experience.

[0046] Specifically, the rendering and display of the preview script is achieved through a structured process that transforms the visual configuration into an interactive simulation preview effect. The specific steps are as follows: Figure 4 As shown, it includes: 1) Systematically categorize and preview elements First, the basic units that make up the preview—the preview elements—are systematically categorized into text, images, and badges (badges can be further divided into text badges, image badges, and red dot badges). Simultaneously, configurable style attributes are defined for each type of element. For example, text elements support setting font, font size, and color; images require setting width and height; and badges follow corresponding style rules based on their type. This step provides a structured foundation for subsequent fine-grained configuration.

[0047] 2) Set the overall size of the preview area For touchpoints that support multi-frame display, the overall boundary of their preview area needs to be defined. For each frame, its position coordinates on the canvas (e.g., based on the x / y values ​​of the top-left corner) and size parameters (width and height) should be set, and a matching background image should be uploaded as the visual reference for that frame. This ensures that the layout of the preview area remains consistent with the actual front-end page.

[0048] 3) Set a preview element on the canvas. Within each frame of the pre-defined base map, operators can use the canvas tool to visually drag and drop preview elements such as text and images to place them at the target location, and dynamically set their coordinates, dimensions (such as image width and height), and style details (such as text color and font size). The system responds to operations in real time, providing a WYSIWYG configuration experience.

[0049] 4) Encapsulate configuration parameters as JSON objects After completing the visualization configuration, the system automatically encapsulates all element parameters (including frame position identifiers, element types, coordinates, styles, etc.) into a structured JSON object, categorized by page, floor / zone, touchpoint / frame position, and element. This JSON object is uploaded to the backend via an interface, serving as the complete data source for generating the preview script.

[0050] 5) The backend generates a preview script file. After receiving the JSON data, the backend service parses its hierarchical relationships and attribute definitions, and generates a preview file based on this information (such as an HTML fragment containing DIV layout and CSS style definitions). This file constitutes the "skeleton" of the page display, clarifying the arrangement rules and style framework of each element, but has not yet been filled with specific operational content.

[0051] 6) Parse the data and create HTML tags The system further parses the element data in the preview file and automatically creates an HTML tag with a unique ID for each element (such as text corresponding to...). Image Correspondence Tag IDs are typically generated based on a rule of "frame identifier + feature parameter name (paramName)" (e.g., 01vSubject) to ensure their uniqueness and associativity.

[0052] 7) Match work order data with tag ID In the operations configuration interface, the system loads a preview script and uses a data binding mechanism to associate and match the configuration content entered in the work order with the IDs of HTML tags. For example, the text in the work order is assigned to the corresponding page element using document.getElementById("01vSubject").textContent.

[0053] 8) Dynamically fill content into the preview area The system iterates through all bound tags, retrieves the corresponding configuration data (such as text, image links, etc.) from the work orders in batches, and replaces the placeholder content in the preview script. Subsequently, the preview area renders a simulation effect in real time, consistent with the final user page, based on the layout and style rules defined in the script.

[0054] 9) Complete the data-driven rendering closed loop. Through the above steps, the system achieves a complete closed loop from visual configuration to data-driven rendering. When operators modify content on the right side of the configuration interface, the preview area on the left updates the effect simultaneously, truly achieving a "configure and preview at the same time" experience. This improves configuration accuracy, reduces debugging costs, and ensures that the final page presentation matches expectations.

[0055] also, Figure 5 This example demonstrates a typical scenario of "configuring and previewing simultaneously" during the operational configuration of a target page. As shown in the figure, the page is structurally planned as multiple floor areas arranged from top to bottom, such as "Coupon Center" and "Hot Activities" as independent floors. Furthermore, some floors are further divided into sub-areas such as "Zone 1" and "Zone 2". The figure clearly marks the touchpoint numbers associated with each zone (e.g., Touchpoint 1, Touchpoint 2), indicating that these areas have been registered in the system as independent locations awaiting operation. During actual configuration, if the operator modifies the content of the operational element components bound to a certain touchpoint (e.g., touchpoint 1 associated with "Zone 1" in the figure) (e.g., updating text or replacing images), the preview area on the left side of the configuration interface will render the new content to the location of that zone in real time according to the corresponding preview script, thus intuitively demonstrating the "configuring and previewing simultaneously" working mode where configuration operations and visual feedback are synchronized.

[0056] also, Figure 6 This example demonstrates a complete implementation process for web page development. First, page operation planning is conducted based on operational needs. Then, touchpoints are registered on the target page to identify the locations to be operated. After touchpoint registration, reusable operational element components are associated with the corresponding touchpoints via drag-and-drop. Based on this, the page is hierarchically planned with floors and zones to organize operational areas in a structured manner. Next, the preview setup phase is initiated, generating a preview script that defines the layout rules. The core components are operational configuration and real-time preview. Operational personnel configure specific content through a visual interface and simultaneously view the simulation effects. After configuration, the operational interface integrates a preview function for synchronized display. Finally, work order data is integrated into the user terminal and displayed on the front end, thus forming an end-to-end closed-loop process from planning and configuration to release and display.

[0057] In summary, this embodiment first plans at least one operational location on the target page and registers a corresponding touchpoint for each operational location, thereby structuring and localizing the page's operational capabilities. Secondly, a component library containing multiple standardized and reusable operational element components is provided to the user through a visual configuration interface. Then, in response to user actions, the target operational element component selected from the component library is dynamically associated with the aforementioned touchpoint. This design encapsulates various common operational content such as text, images, and links into standardized operational element components and manages them in a unified component library, allowing these components to be repeatedly called and combined in different pages and operational scenarios, thus avoiding the hassle of repetitive development for the same or similar operational functions. Next, based on the associated touchpoints and components, a preview script for the target page is generated. This preview script essentially defines the layout rules for each target operational element component at its corresponding operational location. Finally, a configuration interface for this preview script is provided to the user through the same visual configuration interface, allowing the user to configure the specific content of the target operational element components within the script. The above process transforms page development into a series of visual configuration operations, enabling efficient and flexible development and deployment of the target page without writing underlying code.

[0058] In addition, corresponding to Figure 1 In addition to the method shown, another embodiment of this example also provides a web page development apparatus. Figure 7 This is a structural diagram of the web development device 700, including: The touchpoint configuration module 710 is used to determine at least one location to be operated in the target page and register a corresponding touchpoint for each location to be operated; wherein, the location to be operated refers to a logical area in the target page used to display operational content.

[0059] The component configuration module 720 is used to provide users with a component library containing multiple reusable operational element components through a visual configuration interface, and in response to user operations, associate at least one target operational element component selected from the component library with the touchpoint.

[0060] The script configuration module 730 is used to generate a preview script for the target page, wherein the preview script defines the layout rules of the target operation element components based on the location to be operated.

[0061] The content configuration module 740 is used to provide the user with a configuration interface for the preview script through the visual configuration interface, and in response to user operations, configure the content of the target operational element component in the preview script through the configuration interface to complete the development of the target page.

[0062] Optionally, the apparatus in this embodiment further includes: The page preview module is used to combine the content of the target operational element component configured by the user with the layout rules in the preview script, so as to synchronously render the target page in the preview area of ​​the visualization configuration interface.

[0063] Optionally, the page preview module is specifically used to: record the association order of all the touchpoints with the target operational element component; and, according to the association order, combine the content of the target operational element component configured by the user with the layout rules in the preview script to dynamically render the evolution process of the target page in the preview area of ​​the visual configuration interface.

[0064] Optionally, the page preview module is also used to: visually highlight the target operational element component that the user is currently configuring in the preview area.

[0065] Optionally, the script configuration module 730 generates a preview script for the target page, including: configuring a base map for the corresponding touchpoint based on the location to be operated; setting configuration information for each associated target operation element component on the base map, the configuration information including at least one of position coordinates and style parameters; generating structured data for each location to be operated based on the corresponding touchpoint, the target operation element component, and the configuration information of the target operation element component; and parsing the structured data into the preview script for defining layout rules.

[0066] Optionally, the location to be operated includes at least one of the following: a floor area formed by dividing the page into upper and lower levels; or a special zone formed by further dividing the floor area into sub-areas.

[0067] Optionally, the operational element components in the component library include at least one of text components, image components, link components, and badge components, and the attributes of each component are defined through a JSON structure.

[0068] This embodiment of the device first plans at least one operational location on the target page and registers a corresponding touchpoint for each operational location, thereby structuring and localizing the page's operational capabilities. Secondly, through a visual configuration interface, it provides users with a component library containing multiple standardized and reusable operational element components. Then, in response to user actions, it dynamically associates the target operational element component selected from the component library with the aforementioned touchpoint. This design encapsulates various common operational content such as text, images, and links into standardized operational element components and manages them within a unified component library. This allows these components to be repeatedly called and combined in different pages and different operational scenarios, thus avoiding the hassle of repeatedly developing the same or similar operational functions. Next, based on the associated touchpoints and components, a preview script for the target page is generated. This preview script essentially defines the layout rules for each target operational element component at its corresponding operational location. Finally, through the same visual configuration interface, it provides users with a configuration interface for this preview script, allowing users to configure the specific content of the target operational element components within the script. The above process transforms page development into a series of visual configuration operations, enabling efficient and flexible development and deployment of the target page without writing underlying code.

[0069] It should be noted that the web page development device in this embodiment can be used as... Figure 1 The execution body of the method shown is therefore able to achieve... Figure 1 The steps and functions of the method shown are illustrated.

[0070] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Please refer to it. Figure 8 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0071] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0072] Memory is used to store computer programs. Specifically, a computer program may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides the computer program to the processor.

[0073] Specifically, the processor reads the corresponding computer program from non-volatile memory into memory and then runs it, forming the above-mentioned logical structure. Figure 7 The web page development apparatus shown. Correspondingly, the processor executes the program stored in the memory, and specifically performs the following operations: Identify at least one location to be operated on the target page, and register a corresponding touchpoint for each location to be operated; wherein, the location to be operated refers to the logical area on the target page used to display operational content.

[0074] Through a visual configuration interface, a component library containing multiple reusable operational element components is provided to the user, and in response to user operations, at least one target operational element component selected from the component library is associated with the touchpoint.

[0075] Generate a preview script for the target page, wherein the preview script defines the layout rules of the target operational element components based on the location to be operated.

[0076] The visual configuration interface provides users with a configuration interface for the preview script and, in response to user operations, allows for content configuration of the target operational element components in the preview script through the configuration interface, thereby completing the development of the target page.

[0077] The above is as described in this instruction manual. Figure 1 The web page development method disclosed in the illustrated embodiments can be applied to a processor and implemented by the processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit in the processor or by instructions in the form of software. The processor mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0078] Of course, in addition to software implementation, the electronic device described in this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0079] Furthermore, embodiments of this application also propose a computer program product, including a computer-readable storage medium storing one or more computer programs, the one or more computer programs including instructions.

[0080] When the aforementioned instructions are executed by a portable electronic device that includes multiple applications, they enable the portable electronic device to perform... Figure 1 The steps in the method shown include: Identify at least one location to be operated on the target page, and register a corresponding touchpoint for each location to be operated; wherein, the location to be operated refers to the logical area on the target page used to display operational content.

[0081] Through a visual configuration interface, a component library containing multiple reusable operational element components is provided to the user, and in response to user operations, at least one target operational element component selected from the component library is associated with the touchpoint.

[0082] Generate a preview script for the target page, wherein the preview script defines the layout rules of the target operational element components based on the location to be operated.

[0083] The visual configuration interface provides users with a configuration interface for the preview script and, in response to user operations, allows for content configuration of the target operational element components in the preview script through the configuration interface, thereby completing the development of the target page.

[0084] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

[0086] The above are merely embodiments of this specification and are not intended to limit the scope of this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification. Furthermore, all other embodiments obtained by those skilled in the art without inventive effort should fall within the protection scope of this document.

Claims

1. A webpage development method, characterized in that, include: Identify at least one location to be operated on the target page, and register a corresponding touchpoint for each location to be operated; wherein, the location to be operated refers to the logical area on the target page used to display operational content; Through a visual configuration interface, a component library containing multiple reusable operational element components is provided to the user, and in response to user operations, at least one target operational element component selected from the component library is associated with the touchpoint. Generate a preview script for the target page, wherein the preview script defines the layout rules for the target operational element components based on the location to be operated; The visual configuration interface provides users with a configuration interface for the preview script and, in response to user operations, allows for content configuration of the target operational element components in the preview script through the configuration interface, thereby completing the development of the target page.

2. The method according to claim 1, characterized in that, Also includes: The content of the target operational element component configured by the user is combined with the layout rules in the preview script to synchronously render the target page in the preview area of ​​the visualization configuration interface.

3. The method according to claim 2, characterized in that, Also includes: Record the association order of all the aforementioned touchpoints with respect to the target operational element component; Combining the content of the target operational element component configured by the user with the layout rules in the preview script to synchronously render the target page in the preview area of ​​the visual configuration interface includes: According to the association order, the content of the target operational element component configured by the user is combined with the layout rules in the preview script to dynamically render the evolution process of the target page in the preview area of ​​the visualization configuration interface.

4. The method according to claim 2, characterized in that, Also includes: In the preview area, the target operational element component that the user is currently configuring is visually highlighted.

5. The method according to claim 1, characterized in that, Generate a preview script for the target page, including: Based on the location to be operated, configure a base map for its corresponding touchpoint; On the base map, configuration information is set for each of the associated target operational element components, the configuration information including at least one of location coordinates and style parameters; For each of the locations to be operated, structured data is generated based on the corresponding touchpoint, the target operation element component, and the configuration information of the target operation element component; The structured data is parsed into a preview script used to define layout rules.

6. The method according to claim 1, characterized in that, The locations to be operated include at least one of the following: Floor areas formed by dividing a page into upper and lower levels; The floor area is further divided into sub-areas to form special zones.

7. The method according to any one of claims 1 to 6, characterized in that, The operational element components in the component library include at least one of text components, image components, link components, and badge components, and the attributes of each component are defined using a JSON structure.

8. A web page development device, characterized in that, include: The touchpoint configuration module is used to determine at least one location to be operated in the target page and register a corresponding touchpoint for each location to be operated; wherein, the location to be operated refers to the logical area in the target page used to display operational content; The component configuration module is used to provide users with a component library containing multiple reusable operational element components through a visual configuration interface, and in response to user operations, associate at least one target operational element component selected from the component library with the touchpoint. The script configuration module is used to generate a preview script for the target page, wherein the preview script defines the layout rules of the target operation element components based on the location to be operated; The content configuration module is used to provide users with a configuration interface for the preview script through the visual configuration interface, and in response to user operations, configure the content of the target operational element components in the preview script through the configuration interface to complete the development of the target page.

9. An electronic device, comprising: processor; And a memory arranged to store computer-executable instructions, characterized in that, when executed, the executable instructions cause the processor to perform the method as described in any one of claims 1 to 7.

10. A computer program product, the computer program product comprising a computer-readable storage medium storing a computer program, characterized in that, The computer program is operable to cause the computer to perform the method as described in any one of claims 1 to 7.

Images