Conversation card generation method and device, equipment, storage medium and program product

Abstract

The application discloses a dialogue card generation method and device, equipment, storage medium and program product, relates to the technical field of intelligent dialogue, and specifically comprises the following steps: according to the business request of a user, the card template corresponding to the business request is matched, and the business data and the calling information of the target component associated with the card template are obtained; the card template, the business data and the calling information of the target component are fused to generate a template string; the target component is dynamically loaded and rendered based on the template string to generate a dialogue card that can be cross-platform displayed. This way of dynamically loading the target component required by the card template on demand can effectively reduce the code size of the dialogue card generation, reduce the network transmission burden, does not need to depend on a specific front-end framework or running environment, greatly improves the compatibility of the dialogue card between different technology stack platforms, and combines a business data fusion mechanism to better meet the personalized interaction demand of a user.

Description

Technical Field

[0001] This application relates to the field of intelligent dialogue technology, and in particular to a method, apparatus, device, storage medium and program product for generating dialogue cards. Background Technology

[0002] With the rapid development of artificial intelligence technology, card-based chatbots have been widely applied in various digital interaction scenarios, becoming an important medium for improving the efficiency of human-computer dialogue. As a structured information presentation method, the reusability and cross-platform capability of conversational cards are key. For example, online customer service in various software applications has achieved a leapfrog upgrade from traditional human dialogue to automated intelligent service through highly intelligent dialogue interaction. As an important structured and visual information presentation medium in dialogue scenarios, conversational cards possess high interactivity, aesthetics, and scalability, making them the preferred choice for intelligent interaction in dialogue systems.

[0003] However, existing solutions for generating conversational cards, which use UI component libraries based on specific frameworks such as React or Vue, typically result in large component sizes. Furthermore, rendering cards across platforms with different technology stacks requires importing the entire framework library, increasing network transmission overhead, easily leading to version conflicts with existing platform libraries, and necessitating repeated development of the same functionality across different systems.

[0004] By using server-side rendering, data and components are combined to generate cards at runtime. When the cards contain complex functions such as list rendering, the size of the code generated by the server may increase dramatically or even become unpredictable, posing a risk of transmission failure.

[0005] Using low-code platforms to generate pages or components through drag-and-drop methods can lead to limitations. The component libraries provided by low-code platforms are often fixed in style and interaction, making it difficult to meet the personalized needs of visual design and complex interactions in dialogue scenarios. Furthermore, the generated components may behave inconsistently on different terminals.

[0006] Therefore, existing methods for generating dialogue cards generally suffer from problems such as bulky component sizes leading to heavy network transmission burdens, poor compatibility, and difficulty in meeting the personalized interaction needs in dialogue scenarios.

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

[0008] The main objective of this application is to provide a method, apparatus, device, storage medium, and program product for generating dialogue cards, aiming to solve the technical problems of existing dialogue card generation methods, such as bulky components leading to heavy network transmission burden, poor compatibility, and difficulty in meeting personalized interaction needs.

[0009] To achieve the above objectives, this application proposes a method for generating dialogue cards, the method comprising: The corresponding card template is determined based on the user's business request, and the business data associated with the card template and the call information of the target component are obtained. The card template, the business data, and the call information of the target component are merged to generate a template string; The target component is dynamically loaded and rendered based on the template string to generate a conversational card for cross-platform display.

[0010] In one embodiment, the step of determining the corresponding card template based on the user's business request includes: Perform intent parsing on the user's business request to determine the user's intent corresponding to the business request; The rules engine maps the user intent to business nodes under the target topic. The card template corresponding to the business request is determined based on the business node.

[0011] In one embodiment, the step of obtaining business data associated with the card template and call information of the target component includes: The corresponding data interface and the calling information of the target components required by the card template are determined based on the configuration information of the card template. The business data associated with the card template is accessed through the data interface.

[0012] In one embodiment, the card template has a data slot corresponding to the target component; the step of fusing the card template, the business data, and the call information of the target component to generate a template string includes: Based on the call information of the target component, select the target data required by the target component from the business data; The target data is used to fill the corresponding data slot of the target component in the card template to obtain the template string.

[0013] In one embodiment, the step of dynamically loading and rendering the target component based on the template string to generate a conversational card for cross-platform display includes: The template string is used to identify the first registered component and the second unregistered component in the target component; the first component is a core component that is preloaded and registered during idle time, and the core component is a high-frequency used component selected based on the usage frequency of each component. Based on the calling information of the custom component, the component code of the second component is retrieved from the content delivery network, and the component code of the second component is bound to the corresponding component tag to complete the global registration of the second component; Using a pre-loaded rendering plugin, the first component and the registered second component are rendered to generate conversational cards for cross-platform display.

[0014] In one embodiment, the step of rendering the first component and the registered second component using a pre-loaded rendering plugin to generate a conversational card for cross-platform display includes: Using a pre-loaded rendering plugin, the template string is inserted into the document object model, and the first component and the registered second component are instantiated and rendered to obtain multiple component instances; Shadow nodes are created for each component instance in the document object model. The structure and style of the component instance are isolated and encapsulated in the shadow nodes to generate conversational cards for cross-platform display.

[0015] Furthermore, to achieve the above objectives, this application also proposes a dialogue card generation apparatus, the dialogue card generation apparatus comprising: The data acquisition module is used to determine the corresponding card template based on the user's business request, and to acquire the business data associated with the card template and the call information of the target component; The data orchestration module is used to integrate the card template, the business data, and the call information of the target component to generate a template string; The card rendering module is used to dynamically load the target component based on the template string and render it to generate conversational cards for cross-platform display.

[0016] In addition, to achieve the above objectives, this application also proposes a dialog card generation device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the dialog card generation method as described above.

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

[0018] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the dialog card generation method described above.

[0019] One or more technical solutions proposed in this application have at least the following technical effects: By determining the corresponding card template based on the user's business request and obtaining the business data and target component call information associated with the card template, on-demand association of card generation resources is achieved. This avoids pre-packaging or embedding all potentially used components during card generation, effectively reducing the size of component code to be transmitted during initial loading and alleviating network transmission burden. By integrating the card template, business data, and target component call information to generate a template string, the separation and dynamic integration of template, data, and component logic are achieved. This makes the construction of card content no longer dependent on hard coding for a specific platform, providing a foundation for cross-platform display and helping to improve the compatibility of conversational cards. Finally, the required target components are dynamically loaded and rendered based on the template string to generate conversational cards for cross-platform display. This achieves on-demand loading of components, avoiding the problem of excessive data volume caused by loading or generating a large amount of unnecessary component code at once, significantly reducing the amount of data transmitted over the network and lowering network bandwidth consumption.

[0020] By abstracting and fusing card content into card templates, business data, and target component call information, a descriptive template string is generated, decoupling the card's specific implementation from its logical structure and data. Based on this decoupled architecture, as long as the rendering environment supports parsing the template string and dynamically loads the target component according to its information, the card can be rendered and displayed without being forced to depend on a specific front-end framework or runtime environment. This enhances the adaptability of dialog cards across different technology stacks or platforms, improving their compatibility. Furthermore, the mechanism of fusing business data with component call information provides a foundation for implementing richer data-driven interaction logic. Calling corresponding business data as card content based on the user's business requests helps meet the user's personalized interaction needs. Attached Figure Description

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

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

[0023] Figure 1 This is a flowchart illustrating an embodiment of the dialog card generation method of this application. Figure 2 This is a schematic diagram of the system structure of the dialog card system provided in the embodiments of this application; Figure 3 This is a flowchart illustrating Embodiment 2 of the dialog card generation method of this application; Figure 4 This is a schematic diagram of the module structure of the dialog card generation device according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the dialog card generation method in this application embodiment.

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

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

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

[0027] Current methods for generating conversational cards have the following main drawbacks: The solution based on UI (User Interface) component library: generates large component size, increases network transmission burden, requires the introduction of large framework library when dialog cards are cross-platform, which may lead to version conflicts, and cannot achieve component reuse between systems with different technology stacks, resulting in redundant development.

[0028] Server-side rendering-based solutions: For dialog cards that contain complex logic such as list rendering, the code size generated by server-side rendering is uncontrollable, which may lead to transmission failures. Furthermore, the styles between cards cannot be isolated, posing a risk of style pollution.

[0029] Low-code platform solutions: The component libraries provided by the platform have fixed styles and interactions, making it difficult to meet personalized interaction needs. Furthermore, the generated components behave inconsistently on different terminals, resulting in a poor interactive experience.

[0030] This application provides a method for generating conversational cards, which can solve or at least partially solve the shortcomings of existing conversational card generation schemes. The conversational card generation method provided in this application requires fewer component template updates and can be stored in a Content Delivery Network (CDN). Components are loaded on demand during front-end rendering, reducing the amount of data transmitted. Card generation can run independently without relying on a UI component library; only a lightweight rendering plugin needs to be introduced into the card rendering platform.

[0031] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or a dialog card generation device capable of performing the above functions. The following description uses a dialog card generation device as an example to illustrate this embodiment and the subsequent embodiments.

[0032] Based on this, embodiments of this application provide a method for generating dialogue cards, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the dialog card generation method of this application.

[0033] In this embodiment, the dialog card generation method includes steps S10 to S30: Step S10: Determine the corresponding card template based on the user's business request, and obtain the business data and target component call information associated with the card template; Step S20: Merge the card template, the business data, and the call information of the target component to generate a template string; Step S30: Dynamically load the target component according to the template string and render it to generate a conversational card for cross-platform display.

[0034] Based on the user's business request, the corresponding card template is determined, and the business data associated with the card template and the call information of the target component are obtained, mapping the abstract user request to specific rendering resources and data. The target component is the component required by the card template. It should be noted that the user's business request can be a request triggered by a natural language dialogue.

[0035] In one feasible implementation, based on the user's business request, at least one of the user's business scenario and dialogue scenario is identified, and a corresponding card template is determined based on the business scenario and / or dialogue scenario corresponding to the business request. For example, for a user's business request corresponding to the business scenario of querying an order list, there may be a corresponding order card-list format card template.

[0036] When obtaining the business data associated with the card template and the call information of the target component, firstly, determine the target component required by the card template, and then obtain the business data required by the card template and the call information of the target component.

[0037] As one embodiment, a method of associating a data configuration table with a component list is used to obtain the business data and component call information associated with the card template. Specifically, each card template is associated with a data source configuration table and a component dependency list in the database. The data source configuration table defines the various data fields required to populate the card template and their corresponding remote API interface addresses, request parameters, and response data mapping paths; while the component dependency list defines all the target components required to render the card template.

[0038] After determining the card template, the system queries the data source configuration table and component dependency list associated with the card template. On one hand, it calls multiple service API interfaces based on the data source configuration table to aggregate business data; on the other hand, it reads the component dependency list to obtain precise component call information. This component call information includes at least the component's name and version.

[0039] The card template, the acquired business data, and the call information of the target component are combined to generate a template string. This template string is a rich text string and is an intermediate representation containing all rendering instructions.

[0040] Understandably, a card template is a string containing special markers, including but not limited to placeholders. Each component call within the card template corresponds to a placeholder. For the acquired business data and component call information, feature values ​​are first extracted. Then, by iterating through the original string of the card template, all placeholders are replaced with their corresponding feature values, ultimately generating the template string.

[0041] Finally, the target component is loaded and rendered based on the generated template string, generating a conversational card for cross-platform display. Loading the target component can be achieved by maintaining a global component registry, which records the mapping between component names and their loader functions. After generating the template string, a parser is used to traverse the template string, identify all custom element tags, and for each custom element tag, check the component registry to determine if the corresponding custom element is a registered component.

[0042] For registered components, they can be loaded and used directly using the loader in the component registry. For unregistered components, they must be registered first, and then loaded and used after registration.

[0043] As an example, after dynamically loading all the required target components, the template string and target components are stored in a container element for rendering. Finally, the container element presents the rendered complete conversational card.

[0044] In one embodiment, for a container element with an injected template string, the browser parses the string and creates the corresponding element node. When a registered custom element (i.e., part or all of the target component) is parsed, the browser automatically calls its constructor and executes its lifecycle callbacks. To handle the uncertainty of component loading and rendering completion time, a rendering queue can be introduced to ensure that all custom elements have been upgraded before notifying the external card that rendering is complete. Ultimately, the complete conversational card is presented within the container. Since the component is implemented based on Web standards (such as CustomElements), as long as the host environment (such as a browser, WebView, or a WeChat Mini Program framework that supports Web Components) supports these standards, the card can be rendered correctly, thus achieving cross-platform display.

[0045] It should be understood that for the final generated dialogue cards, the business data is the raw material, belonging to dynamic structured information, containing data requested in the user's business request. The card template defines the visual structure of the dialogue content, that is, the visual layout, static text, component positions, and overall structure of the dialogue card ultimately presented to the user. Rendering the card template involves injecting the business data into the card template and arranging it according to the visual structure defined by the card template, so that the dynamic business data is perfectly integrated with the static template layout and interactive components, resulting in a visual dialogue card for user interaction.

[0046] In one embodiment, the dialog card generation method provided in this application is applied to a dialog card system, with reference to... Figure 2 The system structure shown is based on programming languages ​​such as JavaScript or Java to complete the development, deployment, and application of dialog cards and components, specifically including a base layer, a middleware layer, an application layer, and a presentation layer.

[0047] The base layer is primarily used for the development and testing of card templates and components. Developable components include Web Components components created using WebComponents technology, and developable card templates include interactive cards. In WebComponents, Custom Elements define custom element classes that can be used to create multiple component classes; Shadow DOM encapsulates styles and structure to isolate style pollution and interaction effects; and HTML Templates enable template reuse. During card development, Web Components components are called, and development and test data are passed in for debugging. After development is complete, an API is called to store the card template in the database and the components on a CDN server.

[0048] The middle platform layer is used for data acquisition, data processing, and data communication. For data acquisition, it specifically includes obtaining user business requests, determining the corresponding card template based on the user's business requests, and then obtaining the corresponding business data and component call information. For data processing, it includes the fusion processing of card templates, business data, and component call information to generate the corresponding template string. For data communication, it is specifically used for data interaction, including but not limited to sending the template string to the application layer.

[0049] The application layer is the terminal execution layer of the dialogue card, responsible for receiving template strings from the middleware layer and completing component-based rendering. Specifically, this includes plugin loading, component downloading and registration, and exception handling. Plugin loading specifically loads the plugins required for rendering; component downloading and registration specifically downloads the target components needed for the card template and registers any unregistered components; exception handling specifically addresses rendering failures, such as component download failures, by using fallback cards and corresponding fallback phrases to ensure the dialogue is handled without the user's awareness.

[0050] The presentation layer is mainly used for multi-terminal display of dialogue cards, including applications (APP), PCs, and other terminals such as large screens.

[0051] In this embodiment, by determining the corresponding card template based on the user's business request and obtaining the business data and target component call information associated with the card template, on-demand association of card generation resources is achieved. This avoids pre-packaging or embedding all potentially used components during card generation, effectively reducing the size of component code to be transmitted during initial loading and alleviating network transmission burden. By integrating the card template, business data, and target component call information to generate a template string, the separation and dynamic integration of template, data, and component logic are achieved. This makes the construction of card content no longer dependent on hard coding for a specific platform, providing a foundation for cross-platform display and helping to improve the compatibility of conversational cards. Finally, the required target components are dynamically loaded and rendered according to the template string to generate conversational cards for cross-platform display. This achieves on-demand loading of components, avoiding the problem of excessive data volume caused by loading or generating a large amount of unnecessary component code at once, significantly reducing the amount of data transmitted over the network and lowering network bandwidth consumption.

[0052] By abstracting and fusing card content into card templates, business data, and target component call information, a descriptive template string is generated, decoupling the card's specific implementation from its logical structure and data. Based on this decoupled architecture, as long as the rendering environment supports parsing the template string and dynamically loads the target component according to its information, the card can be rendered and displayed without being forced to depend on a specific front-end framework or runtime environment. This enhances the adaptability of dialog cards across different technology stacks or platforms, improving their compatibility. Furthermore, the mechanism of fusing business data with component call information provides a foundation for implementing richer data-driven interaction logic. Calling corresponding business data based on user business requests helps meet users' personalized interaction needs.

[0053] In one implementation, step S10 involves determining the corresponding card template based on the user's business request. Specifically, this is achieved by parsing the user's business request intent. Therefore, step S10 includes steps S101 to S103: Step S101: Perform intent parsing on the user's business request to determine the user intent corresponding to the business request; Step S102: Map the user intent to a business node under the target topic using the rule engine; Step S103: Determine the card template corresponding to the service request based on the service node.

[0054] The system performs intent parsing on user business requests to determine the user intent corresponding to the business request. The aim is to understand the business requests generated by users through chatbots, search boxes, or directly triggered events, and to transform them into structured intents that can be recognized and processed by machines.

[0055] The rule engine maps user intents to business nodes under the target topic, and determines the card template corresponding to the business request based on the business node. In this embodiment, the rule engine maintains an intent-template mapping relationship. By parsing the user intent and utilizing the rule engine's mapping, the card template corresponding to the business request is determined.

[0056] In this context, a topic represents a relatively independent and highly cohesive business area, such as account management, order services, or after-sales support. A business node, on the other hand, can be a specific business step or service touchpoint under a topic. An intent can be mapped to a specific business node, and a topic is the primary category of business nodes.

[0057] Based on the parsed user intent, the rule engine first determines which topic the user intent belongs to, and then further identifies a specific business node under that topic. For example, for the intent "order query," the rule engine's mapping first determines the "order service" topic, and then the "query order list" business node under the "order service" topic. This mapping process of user intent by the rule engine ensures that the user's business request is guided to the correct business context, thereby obtaining the correct business data to respond to the user's business request or answer the user's dialogue, ensuring the accuracy of the dialogue interaction.

[0058] Furthermore, the card template corresponding to the business request is determined based on the business node. There is an association between the business node and the card template. As an example, multiple candidate response contents can be configured on a business node. Therefore, in some complex business scenarios, a business node can also be configured with one or more card templates to respond to different interaction scenarios of the same business request.

[0059] When multiple card templates are configured on a business node, a secondary decision can be made on the card template based on additional contextual information, such as user profiles and user operation history, to select the most suitable card template from the multiple alternative templates configured on the business node.

[0060] Card templates are determined based on intent parsing, topic / business routing, and template decision-making. This decouples business logic from the card presentation layer, enabling more flexible responses to user needs and assigning appropriate interactive interfaces to each business scenario, thus improving the user experience.

[0061] In one implementation, the acquisition of business data and component call information is achieved through interface calls. Based on this, step S10 may further include steps S104-S105: Step S104: Determine the corresponding data interface and the calling information of the target components required by the card template based on the configuration information of the card template; Step S105: Call the business data associated with the card template through the data interface.

[0062] First, the corresponding data interface and the calling information of the target components required by the card template are determined based on the card template configuration information. It can be understood that each card template will be pre-configured with the dynamic data to be filled and where this data is obtained when it is defined. After the corresponding card template is determined, the corresponding data interface is determined based on the card template configuration information, and the business data required by the card template is obtained through the data interface configured in the card template.

[0063] In practice, the configuration information for a card template can be represented by declaring one or more data source configuration objects in the card template's metadata. Each object contains the following information: Interface address: The URL address of the remote API; Request parameters: These include fixed parameters and parameters dynamically obtained from user requests, session context, etc., such as user identifiers; Response data mapping path: Defines how to extract the specific fields required by the card template from the complex JSON / XML response body returned by the interface. For example, the placeholders in the card template contain a data object corresponding to all the data required by a component. The data object corresponding to the placeholder {userName} in the card template should be obtained from the data.user.profile.name path in the interface response.

[0064] It's important to note that the card template defines not only the content and data requirements but also its UI structure. The target component's invocation information refers to the detailed information of the custom elements and components necessary for rendering the card template. As one example, all custom element tags appearing in the card template can be statically analyzed to form a component dependency list. As another example, all components potentially used in the business scenario can be read from the business configuration level (theme or node). Component invocation information includes at least the component tag name and a possible version number, serving as key identifiers for subsequent dynamic loading and registration of components.

[0065] After determining the data interface configuration, real-time business data is obtained by initiating actual network requests. Specifically, the configured interface address and parameters are converted into one or more real API call instances to obtain the dynamic content needed to populate the card template.

[0066] In practical implementation, the data interface determined based on the card template's configuration information is a third-party data interface. One or more third-party data interfaces can be called in parallel or sequentially to obtain the business data required by the card template. For example, a dialog card for user order details may need to simultaneously call the "User Information Service" interface to obtain basic user information and the "Order Details Service" interface to obtain order data.

[0067] If the API calls for retrieving business data are asynchronous, then it is also necessary to manage these asynchronous operations, wait for all APIs to return data, and parse and extract the returned data according to the preset response data mapping path, and finally aggregate them into a unified data object, or data context. This data object will contain the specific values ​​required for all placeholders in the card template.

[0068] By configuring the card template, the key resource requirements for the two types of cards—dynamic data (business data) acquisition and UI building unit (target call information)—are specified. Real-time retrieval of business data is achieved by calling the data interface, enabling the card content to be linked with the real-time business system, ensuring the timeliness of information, and also providing a foundation for the front-end to load UI components on demand.

[0069] In one feasible implementation, the placeholder is a data slot. The card template has a data slot corresponding to the target component. The fusion of the card template, business data, and component call information is achieved by filling the data slot with data. Therefore, step S20 may include steps S201~S202: Step S201: Based on the calling information of the target component, select the target data required by the target component from the business data; Step S202: Use the target data to fill the corresponding data slot of the target component in the card template to obtain the template string.

[0070] In static card templates, data slots, or data interfaces, are reserved for dynamic target components. These data slots are structured and identifiable placeholders. In practice, these data slots can take various forms, but their core function is to act as the data entry point for the target component within the template. Specific forms include, but are not limited to, the following: Custom element attribute slots: In the HTML fragment of a card template, the target component is usually invoked as a custom tag (such as...). <my-order-card>Its data slots can be designed as attributes of the custom tag.

[0071] Slot content slot: If the target component defines a slot internally... <slot>If an element receives projected content, then a child element with a specific identifier (such as a slot attribute) placed inside the component tag in the card template can be considered a content slot.

[0072] Template variables or placeholders: In a more advanced template engine, data slots can also be represented as special template syntax variables and bound to instances of specific components.

[0073] The existence of data slots separates the structure of the card template from the specific data or values, creating conditions for subsequent accurate data injection.

[0074] The business data obtained through the data interface is typically a complex JSON object, which may contain various types of data such as user information, order lists, and product details. It is necessary to extract the corresponding subsets from this data based on the specific needs of each target component. Specifically, based on the call information of the target component, the target data required by the target component is selected from the business data, and then the obtained business data is distributed to different target components.

[0075] In specific implementations, for example, the call information of the target component contains the mapping rules of the corresponding data slots. By traversing all the data slots in the card template and according to the mapping rules corresponding to each data slot, the corresponding target data is located and extracted from the massive aggregated business data.

[0076] The mapping rules for data slots are defined by the data requirements of the target component. These definitions can be built into the component declaration or placed externally in the configuration information of the card template.

[0077] Furthermore, the extracted, discrete target data is precisely filled into the corresponding data slots preset in the card template, thereby generating a template string for a data-ready card template.

[0078] The specific implementation methods for inserting target data into the corresponding data slot include, but are not limited to: String replacement: If the data slot is a placeholder string in the template (such as {orderId}), then the string search and replace operation is performed directly to replace the placeholder with the actual data or value.

[0079] Attribute value population: If the data slot is an attribute of a custom element, the target data is set to the value of that attribute by manipulating the template's abstract syntax tree (AST) or by string manipulation.

[0080] DOM (Document Object Model) operations: In more complex scenarios, the card template can be parsed into a lightweight DOM tree in memory first, then the specific elements and attribute nodes can be located through the JavaScript DOM API, their values ​​can be set, and finally the initial format of the card template can be restored through serialization.

[0081] By filling data slots with data, fresh business data is injected into the static template that originally only had structure and placeholders, generating a data-ready card template, laying the foundation for subsequent rendering of conversational cards containing specific content.

[0082] By using data slots, target data is selected from business data to fill the data slots, ensuring that business data can be passed to the target component in a structured and unambiguous manner. This is the key to realizing the dynamic processing of complex card content and maintaining the relationship between templates and data.

[0083] It is understandable that the card template filled with business data in the data slot is a data-ready template string, that is, a template string containing dynamic data. In some embodiments, to reduce communication overhead or ensure data security, for example, to reduce the internal communication overhead of the middle platform layer sending template strings to the application layer, further data post-processing can be performed on the template string after it is generated. This data post-processing includes, but is not limited to, data desensitization, data compression, and data fragmentation. Based on the template string obtained from the post-processing, the target component is dynamically loaded and rendered to generate a conversational card for cross-platform display.

[0084] It should be understood that the application layer of the conversation card system receives a post-processed template string from the middle platform layer, and can load and render the target component based on the received template string to finally generate a conversational card for cross-platform display.

[0085] In one feasible implementation, step S30 may include steps S301 to S303: Step S301: Identify the first registered component and the second unregistered component in the target component according to the template string; the first component is a core component that is preloaded and registered during idle time, and the core component is a high-frequency used component selected based on the usage frequency of each component; Step S302: Based on the calling information of the custom component, retrieve the component code of the second component from the content delivery network, bind the component code of the second component with the corresponding component tag, and complete the global registration of the second component; Step S303: Using a pre-loaded rendering plugin, render the first component and the registered second component to generate a conversational card for cross-platform display.

[0086] The target component is identified based on the template string. Each category of component includes at least a registered first component and an unregistered second component. The registered first component is a core component that is preloaded and registered during idle time. This core component is a high-frequency component selected based on the usage frequency of each component.

[0087] The first registered component refers to a custom element that already exists in the global registry. This means that the component's code has been successfully loaded and registered. Once this type of component is identified, there is no need to download and register it again. It can be used directly for rendering, thus saving network request and initialization time.

[0088] Unregistered custom components are those declared in the template string but not present in the global registry; they are components that need to be dynamically loaded on demand during the rendering process.

[0089] The first component preloaded during idle time is the frequently used component identified by analyzing the historical usage data of each component. During idle time, the core components with high usage frequency are preloaded and registered, which can avoid loading too many components during rendering.

[0090] It's important to note that the global registry is a list of registered custom elements. By querying the global registry, you can determine whether each target component declared in the template string has been registered. If a target component already exists in the global registry, it is considered registered; otherwise, it is not. The first registered component and the second component pre-loaded during idle periods both already exist in the global registry and do not require repeated downloading and registration.

[0091] For unregistered second components, based on their call information, their component code is retrieved from the Content Delivery Network (CDN). The retrieved component code is then bound to its corresponding component tag to complete the global registration of the second component. The component tag for the second component can be randomly generated.

[0092] Understandably, the component's invocation information includes the component name or identifier, version number, and runtime environment. Based on this information and following predetermined rules—such as the base address, environment variables, component name, and component version—the complete URL address of the component code on the content delivery network is dynamically constructed. Subsequently, by creating component tags or other methods, a network request is initiated to asynchronously fetch the component code of the custom component.

[0093] The fetched component code is a script module, which can export a class. After the component code is loaded, the script class (such as a JavaScript class) defined in the script module is called and the corresponding function is executed to bind the component code with the component tag, thereby associating the custom component with the component tag and completing global registration.

[0094] In one embodiment, if an error occurs while fetching the component code, it can be retried a preset number of times, such as 5 times. If the fetch still fails after 5 retries, a fallback card or fallback dialogue is used to provide a fallback dialogue to avoid the user being unaware of any abnormal card display.

[0095] Using pre-loaded rendering plugins, the registered first component and the registered second component are rendered to generate conversational cards for cross-platform display. For example, the rendering plugins include two plugins: Polyfill and Lit. Polyfill is used to simulate native APIs such as customElements and Shadow DOM in older browsers, while the Lit library provides an efficient template system and base classes to simplify the development and rendering of custom components. The rendering plugins provide a unified and compatible runtime foundation for the rendering of all subsequent custom components. Based on this foundation, the components required by the card template are rendered to generate conversational cards for cross-platform display.

[0096] In the specific rendering process, once all necessary components, namely the first and second components, have been globally registered and the template string containing business data is ready, the front end inserts the template string into the specified container element on the page through innerHTML, insertAdjacentHTML, or DOM manipulation.

[0097] The browser, or through the Polyfill plugin, automatically parses the template string. If it encounters native HTML tags, it processes them in the standard way. If it encounters registered custom element tags (i.e., the first and second components), the browser automatically calls their constructors, creates element instances, mounts their Shadow DOM, and executes their lifecycle callbacks. The component instance initializes its state and UI based on the attributes bound to its tag, i.e., the data slots to be filled, ultimately generating conversational cards.

[0098] After the above rendering process is completed, what is presented within the container element is a complete, interactive, conversational card. Since all components are implemented based on Web standards (Custom Elements, Shadow DOM), as long as the host environment (browser, WebView, mini-program framework that supports the standard, etc.) supports these standards, the card can be displayed with a consistent style and behavior, thus achieving cross-platform display.

[0099] In one feasible implementation, step S303 may further include steps S3031 to S3032: Step S3031: Using the pre-loaded rendering plugin, insert the template string into the document object model, and instantiate and render the first component and the registered second component to obtain multiple component instances; Step S3032: Create shadow nodes corresponding to each component instance in the document object model, and isolate and encapsulate the structure and style of the component instance in the shadow nodes to generate conversational cards for cross-platform display.

[0100] Preloaded rendering plugins mainly refer to environments or libraries that provide support for Web Components. Utilizing preloaded rendering plugins specifically means performing subsequent DOM operations in an environment that has the ability to run Web Components (either natively or through Polyfill simulation).

[0101] Inserting the template string into the Document Object Model (DOM) is the physical operation that triggers browser parsing and rendering. The front-end can call the DOM API to parse the template string, which contains all data, component tag declarations, and HTML structure, as a whole, transforming it into an actual DOM node tree in memory, and then mounting it under the specified container element on the page. At this point, custom element tags exist as element nodes in the DOM tree.

[0102] When a DOM node containing a custom element tag is added to the document, the browser's custom element reactor kicks in, checking whether these tags are already globally registered—that is, whether they are the target components required by the card template. For each registered custom element node, the browser automatically calls its constructor, creating a concrete object of that component class, and uses this object to upgrade the corresponding DOM element; this process is called instantiation rendering. Ultimately, each custom element tag in the DOM tree corresponds to an active script object instance with internal state and methods—that is, a component instance.

[0103] Furthermore, shadow nodes are created for each component instance within the Document Object Model. These shadow nodes are known as the Shadow DOM. In practice, the creation of shadow nodes typically occurs during the component class's constructor or when it first connects to the DOM. The component code calls the browser's native API, which creates and mounts an independent shadow root (ShadowRoot) for the component instance. This ShadowRoot is the root node of its internal, encapsulated DOM subtree (i.e., the shadow node).

[0104] It should be noted that calling the same component on multiple card templates will generate multiple ShadowDOMs, each of which is independent.

[0105] The structure and styles of component instances are isolated and encapsulated within the shadow node. Specifically, after creating the ShadowRoot, the rendering logic of the component instance clones its internal HTML template (usually generated by the html template string from the Lit library or innerHTML) and appends it to this ShadowRoot. At the same time, the styles defined inside the component are also applied to this ShadowRoot subtree.

[0106] The strong encapsulation of the Shadow DOM is reflected in: Style isolation: CSS selectors defined inside shadow nodes have their scope strictly limited to the shadow tree and will not leak into the main document, thus not affecting other parts of the page. Conversely, style rules in the main document are also largely unable to affect the components through the shadow tree, thereby avoiding style pollution problems. DOM isolation: DOM nodes inside the shadow tree are hidden from queries of the script module of the main document, and vice versa, thus providing good encapsulation.

[0107] In the specific implementation of generating conversational cards for cross-platform display, once all component instances on the page have been instantiated, each with its own independent Shadow DOM, and each rendering its internal structure and styles within its Shadow DOM, the entire container element presents a complete conversational card. Because the styles and behaviors of each component are encapsulated within its own Shadow DOM, when multiple cards are displayed side-by-side on the page, their styles and interaction logic do not interfere with each other.

[0108] Understandably, multiple card templates can be configured under the same theme. Taking a dialogue card system as an example, in one implementation, high-frequency components are selected based on the usage frequency of each component, configured in the middle platform layer, and associated with the card templates under the corresponding theme. Subsequently, the middle platform layer can determine the core components to be distributed based on the theme corresponding to the parsed user intent, and distribute them to the application layer during off-peak hours, where the application layer completes the loading and registration during off-peak hours.

[0109] In practice, the user's business request is first parsed to clarify the user's intent and the corresponding target topic. Then, the middle platform layer determines the core components associated with the target topic based on the configured core component list and sends them to the application layer. The application layer then preloads and globally registers these core components during system idle time.

[0110] In another implementation, the core components can be dynamically determined by the middle platform layer based on the theme corresponding to the parsed user intent, and distributed during system idle time. Specifically, the middle platform layer will obtain all the components required by the card templates under the theme corresponding to the user intent, and distribute these components as core components that may be used later to the application layer. The application layer will also complete preloading and global registration during idle time. It should be noted that the core components distributed by the middle platform layer to the application layer are components that are likely to be used currently or in the future under the target theme. These components may include some or all of the target components required by the card template, or may not include them at all.

[0111] In one embodiment, reference is made to Figure 3 , Figure 3 This is another flowchart illustrating the dialog card generation method provided in the embodiments of this application. Figure 3 In the process of generating dialogue cards, the main stages include card and component development, data processing and transmission, and card rendering.

[0112] Specifically, during the card and component development phase, components are created using Web Components technology. Card development calls these Web Components components and inputs development test data for debugging. Components and cards that pass debugging are stored in versions. The version-based storage is implemented as follows: after development is complete, an interface is called to store the card template in the database and the component in a CDN server. The component's CDN address consists of a base address, environment variables, the component name, and the component's version number. If a component is updated and compatible with the older version, the original version of the component is modified, while the address remains unchanged. If incompatible, a new version number is added, and the new component is stored in the new version address. Both old and new versions coexist, and cards can freely choose which version of the component to use.

[0113] During the data processing and transmission phase, the main task is to parse the user's intent based on their business request, thereby determining the topic corresponding to the business request and the business nodes under that topic, and then determining the corresponding card template. Based on the card template's configuration information, the corresponding data interface is determined, and business data is obtained through interface calls. The card template, business data, and the call information for the components required by the card template are integrated to form a template string. This template string is then compressed, de-identified, and fragmented before being transmitted to the front end.

[0114] Furthermore, after identifying the theme corresponding to the user's business request, other components associated with that theme can be transmitted to the front end during off-peak hours for preloading and registration. It should be noted that these other components associated with the theme are high-frequency core components selected based on their usage frequency, which may include the target components required by the card template. Therefore, when the template string arrives at the front end, some of the target components required by the card template may already be registered; only the unregistered components need to be loaded and registered.

[0115] In some embodiments, other components associated with a theme may also refer to components required by other card templates under the same theme. It is understood that once a user uses a particular card template, they are highly likely to use other card templates under the same theme subsequently. Therefore, preloading and registering these potentially used components (especially core components) during idle periods can reduce the number of components that need to be loaded during the rendering phase and improve resource utilization.

[0116] During the card rendering process, the template string is received by the front end, the rendering plugin is downloaded, and the global registry is used to determine whether each component required by the card template has been registered. If there are unregistered components, they are downloaded and registered. If all components are registered, card rendering is performed.

[0117] In this embodiment, by dynamically loading required components on demand when generating dialogue cards, and only fetching the corresponding target component code from the CDN when a specific card needs to be rendered, the problem of having to load the entire large framework library or render a large code package on the server at once, as in traditional solutions, is avoided. This effectively reduces the network transmission burden and speeds up the initial response time. Furthermore, by using an optimization strategy of preloading frequently used core components during idle periods, potentially needed core components are preloaded and registered, greatly improving the rendering performance of the first or second screen of subsequent cards, achieving intelligent scheduling of resource loading and a smooth improvement in user experience.

[0118] Furthermore, based on browser native standards such as Web Components, components become standard custom elements after global registration. They can be used directly in any host environment that supports the same standard without relying on specific front-end frameworks such as React or Vue. This avoids version conflicts and redundant development issues caused by differences in technology stacks, enabling template reuse that allows for one-time development and multi-platform operation, and significantly reducing the cost of multi-platform adaptation and maintenance.

[0119] By leveraging the shadow property of the Document Object Model (DOM), an independent shadow node is created for each component instance, strictly encapsulating and isolating the component's DOM structure and CSS styles. This ensures that internal component styles do not affect the global page, and external styles cannot intrude into the component's internal structure. This allows multiple cards, or even multiple instances of the same card, to be rendered in parallel without interfering with each other, avoiding the style conflict risks of traditional web development and providing a reliable sandbox environment for building complex and personalized interactive interfaces.

[0120] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the dialogue card generation method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0121] This application also provides a dialog card generation device, please refer to... Figure 4 The dialogue card generation device includes: The data acquisition module 10 is used to determine the corresponding card template according to the user's business request, and to acquire business data and target component call information associated with the card template; The data orchestration module 20 is used to integrate the card template, the business data, and the call information of the target component to generate a template string; The card rendering module 30 is used to dynamically load the target component according to the template string and render it to generate a conversational card for cross-platform display.

[0122] In one embodiment, the data acquisition module 10 is further configured to: Perform intent parsing on the user's business request to determine the user's intent corresponding to the business request; The rules engine maps the user intent to business nodes under the target topic. The card template corresponding to the business request is determined based on the business node.

[0123] In one embodiment, the data acquisition module 10 is further configured to: The corresponding data interface and the calling information of the target components required by the card template are determined based on the configuration information of the card template. The business data associated with the card template is accessed through the data interface.

[0124] In one embodiment, the card template has a data slot corresponding to the target component; the data arrangement module 20 is further configured to: Based on the call information of the target component, select the target data required by the target component from the business data; The target data is used to fill the corresponding data slot of the target component in the card template to obtain the template string.

[0125] In one embodiment, the card rendering module 30 is further configured to: The template string is used to identify the first registered component and the second unregistered component in the target component; the first component is a core component that is preloaded and registered during idle time, and the core component is a high-frequency used component selected based on the usage frequency of each component. Based on the calling information of the custom component, the component code of the second component is retrieved from the content delivery network, and the component code of the second component is bound to the corresponding component tag to complete the global registration of the second component; Using a pre-loaded rendering plugin, the first component and the registered second component are rendered to generate conversational cards for cross-platform display.

[0126] In one embodiment, the card rendering module 30 is further configured to: Using a pre-loaded rendering plugin, the template string is inserted into the document object model, and the first component and the registered second component are instantiated and rendered to obtain multiple component instances; Shadow nodes are created for each component instance in the document object model. The structure and style of the component instance are isolated and encapsulated in the shadow nodes to generate conversational cards for cross-platform display.

[0127] The dialogue card generation apparatus provided in this application, employing the dialogue card generation method described in the above embodiments, can solve the technical problems of existing dialogue card generation methods, such as bloated component size leading to heavy network transmission burden, poor compatibility, and difficulty in meeting personalized interaction needs. Compared with the prior art, the beneficial effects of the dialogue card generation apparatus provided in this application are the same as those of the dialogue card generation method provided in the above embodiments, and other technical features in the dialogue card generation apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0128] This application provides a dialog card generation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the dialog card generation method in Embodiment 1 above.

[0129] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a conversation card generation device suitable for implementing embodiments of this application. The conversation card generation device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The illustrated dialog card generation device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0130] like Figure 5 As shown, the dialog card generation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the dialog card generation device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the card-generating device to communicate wirelessly or wiredly with other devices to exchange data. Although card-generating devices with various systems are shown in the figures, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

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

[0132] The dialogue card generation device provided in this application, employing the dialogue card generation method described in the above embodiments, solves the technical problems of existing dialogue card generation methods, such as bloated component size leading to heavy network transmission burden, poor compatibility, and difficulty in meeting personalized interaction needs. Compared with the prior art, the beneficial effects of the dialogue card generation device provided in this application are the same as those of the dialogue card generation method provided in the above embodiments, and other technical features in this dialogue card generation device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

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

[0135] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the dialog card generation method in the above embodiments.

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

[0137] The aforementioned computer-readable storage medium may be included in the dialog card generation device; or it may exist independently and not be assembled into the dialog card generation device.

[0138] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the dialog card generating device, cause the dialog card generating device to: The corresponding card template is determined based on the user's business request, and the business data associated with the card template and the call information of the target component are obtained. The card template, the business data, and the call information of the target component are merged to generate a template string; The target component is dynamically loaded and rendered based on the template string to generate a conversational card for cross-platform display.

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

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

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

[0142] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described dialog card generation method. This solves the technical problems of existing dialog card generation methods, such as bloated component sizes leading to heavy network transmission burdens, poor compatibility, and difficulty in meeting personalized interaction needs. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the dialog card generation method provided in the above embodiments, and will not be repeated here.

[0143] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the dialog card generation method described above.

[0144] The computer program product provided in this application can solve the technical problems of existing dialog card generation methods, such as bloated component size leading to heavy network transmission burden, poor compatibility, and difficulty in meeting personalized interaction needs. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the dialog card generation method provided in the above embodiments, and will not be repeated here.

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

Claims

1. A method for generating dialogue cards, characterized in that, The method for generating dialogue cards includes: The corresponding card template is determined based on the user's business request, and the business data associated with the card template and the call information of the target component are obtained. The card template, the business data, and the call information of the target component are merged to generate a template string; The target component is dynamically loaded and rendered based on the template string to generate a conversational card for cross-platform display.

2. The dialog card generation method as described in claim 1, characterized in that, The step of determining the corresponding card template based on the user's business request includes: Perform intent parsing on the user's business request to determine the user's intent corresponding to the business request; The rules engine maps the user intent to business nodes under the target topic. The card template corresponding to the business request is determined based on the business node.

3. The dialog card generation method as described in claim 1, characterized in that, The step of obtaining business data and target component call information associated with the card template includes: The corresponding data interface and the calling information of the target components required by the card template are determined based on the configuration information of the card template. The business data associated with the card template is accessed through the data interface.

4. The dialog card generation method as described in claim 1, characterized in that, The card template has a data slot corresponding to the target component; the step of integrating the card template, the business data, and the call information of the target component to generate a template string includes: Based on the call information of the target component, select the target data required by the target component from the business data; The target data is used to fill the corresponding data slot of the target component in the card template to obtain the template string.

5. The dialog card generation method according to any one of claims 1 to 4, characterized in that, The step of dynamically loading and rendering the target component based on the template string to generate a conversational card for cross-platform display includes: The template string is used to identify the first registered component and the second unregistered component in the target component; the first component is a core component that is preloaded and registered during idle time, and the core component is a high-frequency used component selected based on the usage frequency of each component. Based on the calling information of the custom component, the component code of the second component is retrieved from the content delivery network, and the component code of the second component is bound to the corresponding component tag to complete the global registration of the second component; Using a pre-loaded rendering plugin, the first component and the registered second component are rendered to generate conversational cards for cross-platform display.

6. The dialog card generation method as described in claim 5, characterized in that, The step of rendering the first component and the registered second component using a pre-loaded rendering plugin to generate a conversational card for cross-platform display includes: Using a pre-loaded rendering plugin, the template string is inserted into the document object model, and the first component and the registered second component are instantiated and rendered to obtain multiple component instances; Shadow nodes are created for each component instance in the document object model. The structure and style of the component instance are isolated and encapsulated in the shadow nodes to generate conversational cards for cross-platform display.

7. A dialog card generating device, characterized in that, The dialogue card generation device includes: The data acquisition module is used to determine the corresponding card template based on the user's business request, and to acquire the business data associated with the card template and the call information of the target component; The data orchestration module is used to integrate the card template, the business data, and the call information of the target component to generate a template string; The card rendering module is used to dynamically load the target component based on the template string and render it to generate conversational cards for cross-platform display.

8. A dialog card generation device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the dialog card generation method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the dialog card generation method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the dialog card generation method as described in any one of claims 1 to 6.

Images