Resource reuse method, apparatus, device, and storage medium

Abstract

The application discloses a resource reuse method and device, equipment and storage medium, and relates to the technical field of computers, which comprises the following steps: in response to a control configuration request triggered by a user based on a form configuration interface of a form platform, adding a to-be-referenced card control in the form configuration interface according to the control configuration request; determining a target card resource from a list of referable card resources in a portal platform according to user demand; establishing and saving a resource reference relationship between the to-be-referenced card control and the target card resource; and loading portal card content corresponding to the target card resource according to the resource reference relationship in the case that a form page corresponding to the form configuration interface is in a running state. According to the application, the reference relationship between the form control and the portal card is established, the form page can directly load the portal card content, repeated development is not needed, one-time configuration and multi-reuse are realized, and the problem of high cost caused by the development and maintenance of business columns of the portal and the form is solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to resource reuse methods, apparatus, devices and storage media. Background Technology

[0002] As enterprises deepen their digital transformation, the construction of enterprise information systems has evolved from single business systems to platform-based and integrated approaches. Portal platforms and form platforms, as two fundamental capabilities in enterprise digital transformation, play crucial roles in the construction of various business applications. Portal platforms serve as a unified information access point for the enterprise, aggregating various business sections through configuration, such as application navigation, to-do list centers, message notifications, data dashboards, quick operations, and resource centers. Form platforms, on the other hand, support the collection, filling, approval, and transfer of business data, serving as a key carrier for the digital implementation of business processes. Currently, portal platforms and form platforms typically exist as independent functional modules, each with its own independent designer, runtime engine, and data system.

[0003] However, during business processing, forms also need to display data lists, application entry points, approval information, or other form-related data. For example, users may need to refer to a real-time data list when filling out an application form, or view an overview of pending tasks when processing an approval form. Faced with such cross-scenario display needs, existing solutions typically involve redeveloping corresponding controls or reconfiguring display content in the form designer. This results in the same business section often needing to be developed and maintained independently on both the portal and form sides, leading to high costs. Summary of the Invention

[0004] The main purpose of this application is to provide a resource reuse method, apparatus, device and storage medium, which aims to solve the technical problem that existing portal platforms and form platforms require separate development and maintenance of business sections, resulting in high costs.

[0005] To achieve the above objectives, this application proposes a resource reuse method, the method comprising: In response to a control configuration request triggered by a user's form configuration interface on a form platform, add a card control to be referenced in the form configuration interface according to the control configuration request; The target card resource is determined from the list of referenceable card resources in the portal platform based on user needs; Establish and save the resource reference relationship between the card control to be referenced and the target card resource; When the form page corresponding to the form configuration interface is running, the portal card content corresponding to the target card resource is loaded according to the resource reference relationship.

[0006] In one embodiment, the step of loading the portal card content corresponding to the target card resource according to the resource reference relationship includes: In response to a page access request triggered by the form page, obtain the user identity information of the currently accessing user; Determine the form access control rules corresponding to the form page and the card access control rules corresponding to the card control to be referenced; The permissions of the current user are verified based on the user identity information, the form access control rules, and the card access control rules. If the permission verification passes, the portal card content corresponding to the target card resource is loaded according to the resource reference relationship.

[0007] In one embodiment, the step of verifying the permissions of the current user based on the user identity information, the form access control rules, and the card access control rules includes: According to the form access control rules, the system verifies whether the current user has form access permissions for the form page based on the user identity information, and whether the card control to be referenced has visual permissions on the form page, and obtains the form-side permission verification result. According to the card access control rules, the system verifies whether the current user has access permissions to the target card resource based on the user identity information, and obtains the portal-side permission verification result. The step of loading the portal card content corresponding to the target card resource according to the resource reference relationship when the permission verification is passed includes: If both the form-side permission verification result and the portal-side permission verification result indicate that they have passed, the portal card content corresponding to the target card resource is loaded according to the resource reference relationship.

[0008] In one embodiment, the step of loading the portal card content corresponding to the target card resource according to the resource reference relationship includes: Obtain the form context information of the form page; Based on the resource reference relationship, the form context information is passed to the card rendering module corresponding to the target card resource; The system receives the portal card content obtained from the target card resource by the card rendering module based on the form context information, and renders and displays the portal card content.

[0009] In one embodiment, the step of rendering and displaying the portal card content includes: Determine the width and height configurations of the card control to be referenced; The display area of ​​the portal card corresponding to the target card resource in the form page is determined based on the control width configuration and the control height configuration. The content of the portal card is rendered and displayed within the display area.

[0010] In one embodiment, the step of establishing and saving the resource reference relationship between the card control to be referenced and the target card resource includes: Obtain the control identifier of the card control to be referenced and the card identifier of the target card resource; Obtain the display configuration information of the card control to be referenced in the form configuration interface based on the control identifier; The control identifier, the card identifier, and the display configuration information are associated and stored to form a resource reference relationship between the card control to be referenced and the target card resource.

[0011] In one embodiment, before the step of determining the target card resource from the list of referable card resources in the portal platform according to user needs, the method further includes: Retrieve resource metadata for all card resources in the portal platform; Based on the resource metadata, check whether the corresponding card resource meets the preset reference conditions; Based on the detection results, card resources that meet the preset referencing conditions are configured as referable card resources, and a list of referable card resources is generated based on the referable card resources.

[0012] Furthermore, to achieve the above objectives, this application also proposes a resource reuse device, the device comprising: The request and response module is used to respond to the control configuration request triggered by the user based on the form configuration interface of the form platform, and add the card control to be referenced in the form configuration interface according to the control configuration request; The card determination module is used to determine the target card resource from the list of referenceable card resources in the portal platform according to user requirements; The reference establishment module is used to establish and save the resource reference relationship between the card control to be referenced and the target card resource; The resource referencing module is used to load the portal card content corresponding to the target card resource according to the resource referencing relationship when the form page corresponding to the form configuration interface is running.

[0013] In addition, to achieve the above objectives, this application also proposes a resource reuse 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 resource reuse method as described above.

[0014] 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 resource reuse method described above.

[0015] This application provides a resource reuse method. It discloses a method that, in response to a user's control configuration request triggered by the form configuration interface of a form platform, adds a card control to be referenced in the form configuration interface according to the control configuration request; determines a target card resource from the list of referenceable card resources in the portal platform according to user needs; establishes and saves the resource reference relationship between the card control to be referenced and the target card resource; and loads the portal card content corresponding to the target card resource based on the resource reference relationship when the form page corresponding to the form configuration interface is running. Compared to the existing method where portal platforms and form platforms independently develop and maintain similar business sections, requiring simultaneous modifications in multiple places for any change to a section, this application, by adding a card control to be referenced in the form configuration interface and establishing a reference relationship between the control and existing card resources in the portal platform, allows the form page to directly load portal card content when running, eliminating the need to redevelop similar functional controls for form scenarios. This achieves one-time configuration and multiple reuse of portal card resources in form scenarios, thus solving the technical problem of high costs associated with the separate development and maintenance of business sections by existing portal platforms and form platforms. Attached Figure Description

[0016] 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.

[0017] 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.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the resource reuse method of this application. Figure 2 The system architecture diagram provided for the resource reuse method of this application; Figure 3This is a flowchart illustrating Embodiment 2 of the resource reuse method of this application; Figure 4 This is a flowchart illustrating Embodiment 3 of the resource reuse method of this application; Figure 5 An overall flowchart is provided for the resource reuse method of this application; Figure 6 This is a schematic diagram of the module structure of the resource reuse device according to an embodiment of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the resource reuse method in the embodiments of this application.

[0019] 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

[0020] 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.

[0021] 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.

[0022] The main solution of this application embodiment is as follows: In response to a control configuration request triggered by a user based on the form configuration interface of the form platform, add a card control to be referenced in the form configuration interface according to the control configuration request; determine the target card resource from the list of referenceable card resources in the portal platform according to the user's needs; establish and save the resource reference relationship between the card control to be referenced and the target card resource; when the form page corresponding to the form configuration interface is in a running state, load the portal card content corresponding to the target card resource according to the resource reference relationship.

[0023] Because the existing portal platform and form platform are independent of each other, and there is no unified interoperability mechanism between portal cards and form controls, the card columns configured in the portal cannot be directly reused in the form scenario. As a result, the same business column needs to be developed and maintained separately on both the portal and the form, which is costly.

[0024] This application provides a solution that adds a card control to be referenced in the form configuration interface and establishes a reference relationship between the control and existing card resources in the portal platform. This allows the form page to directly load portal card content when it is running, without having to redevelop similar functional controls for the form scenario. This achieves one-time configuration and multiple reuse of portal card resources in the form scenario, thereby solving the technical problem that the existing portal platform and form platform need to develop and maintain business columns separately, which is costly.

[0025] 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, terminal device, or resource reuse device capable of performing the above functions. The following description uses a resource reuse device (hereinafter referred to as "device") as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Based on this, embodiments of this application provide a resource reuse method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the resource reuse method of this application.

[0027] In this embodiment, the resource reuse method includes steps S10 to S40: Step S10: In response to a control configuration request triggered by the user's form configuration interface based on the form platform, add the card control to be referenced in the form configuration interface according to the control configuration request.

[0028] It should be noted that a form platform can be a software system used to support business data collection, entry, approval, and workflow. In practical applications, form platforms typically provide a visual form designer and a form execution engine. Users can use the form designer to complete the layout and configuration of form pages and controls, while the form execution engine is responsible for rendering the designed form configuration into a running page that can be accessed and operated by end users.

[0029] It should also be noted that the form platform can be deployed independently or as a functional module of an enterprise-level low-code development platform or business process management platform. Furthermore, in this embodiment, the form platform can interact with the portal platform to reference card resources within the portal platform.

[0030] It should be understood that the form configuration interface is an operational interface provided by the form platform for users to design and configure form pages, i.e., the working interface of the form designer. In the form configuration interface, users can add various controls to the form page through drag-and-drop, clicking, or other interactive methods, and configure the controls' properties, layout, data binding, validation rules, etc. The form configuration interface typically includes three main areas: a control toolbar, a canvas area, and a properties panel. The control toolbar lists various form control types available for user selection; the canvas area displays the layout structure of the currently edited form page and the added controls; the properties panel displays the configurable attribute parameters corresponding to the currently selected control, allowing users to set the control's display style, data source, event behavior, etc. In this embodiment, the form configuration interface is the entry point for users to add card controls to be referenced and select target card resources.

[0031] It should also be understood that a control configuration request can be an instruction triggered by a user through interactive operations to add or configure controls in the form configuration interface. This can include various triggering methods, such as a drag-and-drop operation where the user drags a control of a certain type from the control toolbar to the canvas area, a click operation where the user clicks on an existing control in the canvas area to edit its properties, or a menu operation where the user selects "Add Control" via the right-click menu. This embodiment does not limit this. In this embodiment, the control configuration request may carry a control type identifier, which indicates the specific control type to be added or configured.

[0032] It should be noted that the card control to be referenced can be a predefined extended type of form control in the form platform. It can be displayed as a control icon in the control toolbar in the form configuration interface, allowing users to add it to the form's canvas area by dragging or clicking. In practical applications, unlike common input controls such as text input boxes, number input boxes, and dropdown selection boxes, as well as display controls such as buttons and labels, the card control to be referenced does not carry specific business data or display content. Instead, it serves as a placeholder container on the form page, used to load and display portal card content referenced from the portal platform when the form is running.

[0033] In its implementation, the device can provide a form platform that includes a form configuration interface. When a user triggers a control configuration request in the form configuration interface of the form platform, the device can receive the request and, based on the control type identifier in the request, determine that the control the user needs to add is a card control to be referenced. Subsequently, it creates an instance of the card control to be referenced in the canvas area of ​​the form configuration interface and displays a visual placeholder identifier for the control at a specified location in the canvas area. This specified location can be the position of the mouse cursor in the canvas area when the user triggers the control configuration request, or it can be a preset default insertion position in the form configuration interface.

[0034] Step S20: Determine the target card resource from the list of referenceable card resources in the portal platform according to user requirements.

[0035] Understandably, user needs can be the subjective intent and selection preferences expressed by the user during the form configuration process regarding the portal card sections to be referenced on the form page. In this embodiment, user needs can be reflected through the user's selection operation in the list of referenceable card resources. The device does not need to identify or infer the user's subjective intent; it only needs to determine the corresponding target card resource based on the user's selection operation.

[0036] It's important to note that a portal platform can be a software system used to build a unified information access point for an enterprise. It can aggregate various business sections through configuration, such as application entry navigation, to-do list center, message notifications, data dashboards, quick operations, and resource center, providing users with a one-stop information access and business processing portal. In practical applications, portal platforms typically adopt a card-based design pattern, encapsulating different types of business content into independent functional cards, such as application entry cards, data list cards, approval center cards, quick access cards, personal message cards, and resource center cards. Furthermore, the portal platform can have card management capabilities, allowing administrators to quickly configure and expand various portal cards according to business needs, and some card resources can be made available to other platforms (such as form platforms) for reference.

[0037] It should be noted that the list of referenceable card resources can be a list of card resources that are pre-maintained by the portal platform and made available to the form platform, and that can be referenced by form controls. In this embodiment, each entry in the list of referenceable card resources can correspond to an existing card category in the portal platform. Each entry contains at least the card identifier information and card name information for that card category. In addition, each entry can further contain metadata information such as card type, authorization scope, display parameters, and data source summary. In practical applications, the list of referenceable card resources can be obtained through the interface between the portal platform and the form platform, and the form platform can display this list to the user for selection in the form configuration interface.

[0038] It should also be noted that the target card resource can be a specific card resource selected from the list of referenceable card resources that needs to be reused in the current form page. This card resource corresponds to an existing card instance in the portal platform, which has been configured and published and has defined display content and data sources. When referencing the target card resource in the form page, the form page does not recreate the card instance; instead, it loads the portal card content corresponding to the card instance while the form is running by establishing a reference relationship. In practical applications, the device can select a suitable card resource from the list of referenceable card resources as the target card resource based on user needs. For example, when a user needs to design a training application form, the device can select the "Training Course Data List" card in the portal platform as the target card resource; when a user needs to design an approval form, the device can select the "Approval Center" card in the portal platform as the target card resource.

[0039] In the implementation, after the card control to be referenced is added to the form configuration interface, the device can send a resource list retrieval request to the portal platform. Upon receiving the request, the portal platform can return a list of card resources currently referenced by the form platform to the device. The device can then display the received list of referenceable card resources in the property panel or pop-up window of the form configuration interface, awaiting user selection. After receiving a selection operation triggered by the user based on the list of referenceable card resources, the device can determine the target card resource based on the user's selection.

[0040] Furthermore, prior to step S20, the procedure also includes: Step S21: Obtain resource metadata for all card resources in the portal platform.

[0041] It should be understood that resource metadata can be descriptive information corresponding to each card resource in the portal platform. It can be used to characterize the basic attributes, functional characteristics, and referencing constraints of the card resource. For example, resource metadata can include information such as card identifier, card name, card type, authorization scope, display parameters, data source summary, card status, creation time, and category. Specifically, the card identifier uniquely identifies the card instance within the portal platform and in cross-platform references; the card name provides a readable name for the card resource displayed to the user in the form configuration interface; the card type characterizes the business category to which the card belongs, such as application entry type, data list type, approval center type, quick entry type, personal message type, or resource center type; the authorization scope describes the roles, departments, or users allowed to access the card; display parameters describe the rendering configurations required for the card to be displayed, such as width, height, and style template; and the data source summary describes the data table, interface, or business system from which the card's data originates. In practical applications, resource metadata can be stored in the portal platform's configuration database in the form of structured data and can be read by external systems through the interfaces provided by the portal platform.

[0042] Step S22: Detect whether the corresponding card resource meets the preset reference conditions based on the resource metadata.

[0043] It should be noted that the preset referencing conditions can be pre-defined rules used to determine whether card resources in the portal platform can be referenced by the form platform. In this embodiment, the preset referencing conditions can be a set of rules pre-configured in the portal platform or form platform. Only card resources that meet the rules are allowed to be provided to the form side as referenceable card resources. For example, preset referencing conditions may include the card status being "published," the card type belonging to the set of allowed reference types, and the card authorization scope including the access source identifier of the form platform. In addition, preset referencing conditions may also include whether the card resource has completed the necessary configuration, such as whether the data source has been correctly configured and whether the display template has been fully set. In practical applications, the specific content of the preset referencing conditions can be pre-configured by the administrator according to actual business needs, or can be dynamically adjusted by the portal platform according to the system's operating status.

[0044] Step S23: Based on the detection results, configure the card resources that meet the preset referencing conditions as referable card resources, and generate a list of referable card resources based on the referable card resources.

[0045] It should be understood that a referable card resource can be a card resource in the portal platform that meets all referencing conditions and can be referenced by the form platform. In this embodiment, a referable card resource can be a subset of all card resources in the portal platform, wherein the card resources in this subset have completed the necessary configuration and publication in the portal platform, and meet the referencing requirements of the form platform in terms of authorization scope, card type, and data integrity.

[0046] It should also be understood that before being referenced by the form platform, the original card instance of the referenceable card resource in the portal platform remains unchanged. The form platform does not modify or copy the card instance, but loads the display content corresponding to the card instance in the form page by establishing a reference relationship.

[0047] In its implementation, the device first calls the metadata query interface provided by the portal platform to read the resource metadata of all card resources in the portal platform from the card management database, or obtains the resource metadata of all card resources in the portal platform through metadata synchronization messages sent by the portal platform. Then, the device reads preset referencing conditions and compares the resource metadata of each card resource with the preset referencing conditions to determine whether the card resource meets the requirements for being referenced. Specifically, if the preset referencing condition is a permission condition, the device can obtain the current user's identity information and determine whether the user has the permission to reference the card resource in the form; if the preset referencing condition is a status condition, the device can read the status attribute of the card resource and determine whether the card resource is in a published and available valid state; if the preset referencing condition is a type condition, the device can read the type attribute of the card resource and determine whether the type of the card resource belongs to the types allowed to be referenced by the form. Then, the device can synthesize the judgment results from each dimension. If the card resource meets all preset referencing conditions, it is determined that the card resource meets the preset referencing conditions. Next, the device can configure card resources that meet the preset referencing conditions as referable card resources, read the metadata of all referable card resources from the referable resource library, organize the metadata according to the preset list format, and finally generate a list of referable card resources.

[0048] In this embodiment, by acquiring the resource metadata of all card resources in the portal platform and detecting whether each card resource meets preset referencing conditions based on the resource metadata, the card resources that meet the conditions are then configured as referable card resources, and a list of referable card resources is generated. This achieves automatic identification and dynamic maintenance of referable card resources on the form platform side. Furthermore, because this embodiment uniformly determines the referability of card resources through preset referencing conditions, the list of referable card resources obtained by the form platform side is consistent and compliant. This effectively prevents the form platform from referencing unpublished, mismatched, or unauthorized card resources, thus ensuring the security and reliability of cross-platform referencing operations.

[0049] Step S30: Establish and save the resource reference relationship between the card control to be referenced and the target card resource.

[0050] It should be noted that the resource reference relationship can be a correspondence between the card control to be referenced in the form and the target card resource in the portal platform. This correspondence can be used to instruct the form execution engine on which portal card content to load during the form page execution phase. In this embodiment, the resource reference relationship can be stored in the form of structured data, which includes at least the control identifier of the card control to be referenced and the card identifier of the target card resource. Furthermore, the resource reference relationship can also include form identifiers, the width configuration, height configuration, and style configuration of the control in the form. In practical applications, the resource reference relationship can be persistently saved as part of the form configuration data and read and parsed by the device during the form execution phase to determine which portal card category's card content the card control to be referenced in the current form page needs to load.

[0051] In practical implementation, the device can obtain the control identifier of the card control to be referenced and the card identifier of the target card resource, and associate the control identifier and the card identifier to form a resource reference relationship between the card control to be referenced and the target card resource.

[0052] Further, step S30 includes: Step S31: Obtain the control identifier of the card control to be referenced and the card identifier of the target card resource.

[0053] Understandably, the control identifier can be a unique identifier generated for the card control instance to be referenced when it is created in the form configuration interface. It remains unchanged throughout the lifecycle of the form page and is used to uniquely identify the card control instance to be referenced in form configuration data, runtime data, and various internal operations. In this embodiment, the control identifier can be a string composed of numbers, letters, or underscores, such as "ctrl_20260826_001," or it can be a unique serial number generated according to preset encoding rules, such as a string generated based on a combination of timestamps and random numbers. This embodiment does not impose any restrictions on this.

[0054] It is also understood that the card identifier can be a unique identifier for the target card resource within the portal platform. This identifier can be generated and maintained by the portal platform when the card resource is created, and is used to uniquely refer to the card resource instance within the portal platform and in cross-platform references. In this embodiment, the card identifier can be a string consisting of numbers, letters, or underscores, such as "card_10001", or it can be a unique serial number generated by the portal platform according to its own encoding rules.

[0055] Step S32: Obtain the display configuration information of the card control to be referenced in the form configuration interface based on the control identifier.

[0056] It should be understood that the display configuration information can be the various display-related parameter data configured in the form configuration interface for the card control to be referenced. This information can be used to determine how the content of the referenced portal card is displayed on the form page during the form execution phase. In practical applications, the display configuration information can include control width configuration, control height configuration, control style configuration, control margin configuration, and control alignment configuration. Specifically, the control width configuration specifies the width occupied by the control on the form page, which can be a fixed pixel value (e.g., "600 pixels") or a relative proportion value (e.g., "occupies 100% of the form width"); the control height configuration specifies the height occupied by the control on the form page, which can be a fixed pixel value (e.g., "400 pixels") or an adaptive height mode; the control style configuration specifies the control's background color, border style, font style, and other visual attributes; the control margin configuration specifies the spacing between the control and other form elements; and the control alignment configuration specifies the horizontal alignment of the control on the form page (e.g., left-aligned, center-aligned, or right-aligned).

[0057] It should also be understood that the display configuration information can be stored in the form of key-value pairs, such as "{width:600,height:400,align:center}", which can be set by the user in the form configuration interface, or the device can automatically assign default values ​​according to the overall layout of the form page.

[0058] Step S33: Associate and store the control identifier, the card identifier, and the display configuration information to form a resource reference relationship between the card control to be referenced and the target card resource.

[0059] In its implementation, when a device adds a card control to be referenced in the form configuration interface, it can assign a unique control identifier within the form scope to the control and store this identifier, along with the control instance, in the form's control collection. After determining the target card resource, the device can read the control identifier of the card control to be referenced from the control collection and extract the card identifier of the target card resource from the resource information returned by the portal platform. Then, the device can store the control identifier, card identifier, and display configuration information as an association record in the form's configuration file to establish a resource reference relationship between the card control to be referenced and the target card resource. Furthermore, this association record can also contain a form identifier to indicate the form page to which the reference relationship belongs.

[0060] In this embodiment, by obtaining the control identifier of the card control to be referenced and the card identifier of the target card resource, and obtaining the display configuration information of the control in the form configuration interface based on the control identifier, the control identifier, card identifier, and display configuration information are associated and stored to form a configurable resource reference relationship. This achieves structured recording and persistent storage of the reference relationship between form controls and portal cards, ensuring that the reference relationship established in the form design state can be accurately read and restored in the form runtime state. Simultaneously, because the display configuration information is associated with the control identifier and card identifier, the form runtime state can simultaneously obtain the display size and style parameters of the card when loading the portal card content. This ensures the consistency between the display effect of the portal card on the form page and the overall form layout, avoiding layout errors caused by missing display parameters or configuration mistakes.

[0061] Step S40: When the form page corresponding to the form configuration interface is in running state, load the portal card content corresponding to the target card resource according to the resource reference relationship.

[0062] Understandably, the running state can be the page state where the form page corresponding to the form configuration interface has been configured and published, and is accessible and operable by end users. In this embodiment, the lifecycle of a form page includes at least a design state and a running state. In the design state, the form page is configured and laid out by the user in the form configuration interface and has not yet been published; in the running state, the form page has been published, and end users can access the form page through a browser or other clients to fill in data, approve applications, or process business. Switching a form page from the design state to the running state usually requires a publishing operation; after publishing, the form page is in the running state.

[0063] It is also understood that the portal card content can be the specific business information originally displayed on the portal page corresponding to the target card resource. For example, when the target card resource is a data list card, the portal card content is the data rows of the data list; when the target card resource is an approval center card, the portal card content is the current user's to-do list; when the target card resource is an application entry card, the portal card content is the application icon and the corresponding access link; when the target card resource is a quick access card, the portal card content is a collection of quick operation buttons or links. In this embodiment, the portal card content can be generated by the card rendering module on the portal platform side according to the card configuration and data source, and can subsequently be loaded into the display area corresponding to the card control to be referenced on the form page for rendering and display.

[0064] It should be noted that, referring to Figure 2 , Figure 2 A system architecture diagram provided for the resource reuse method of this application. (e.g.) Figure 2 As shown, the reuse process of portal card resources in a form scenario can be as follows: The portal platform can pre-register the configured card resources as referenceable resources, filter them according to preset reference conditions, and generate a list of referenceable card resources. Subsequently, the device can select the target card resource from the list of referenceable card resources through the card control to be referenced in the form designer, and then establish and save the resource reference relationship between the card control to be referenced and the target card resource. During the form execution phase, the device can obtain the identity information of the current user, and then perform dual permission verification according to the access control rules on the form side and the card access control rules on the portal side. The card content is only allowed to be loaded when both verifications pass. After that, the device can obtain the form context information of the form page and pass the form context information to the card rendering module corresponding to the target card resource. The card rendering module then renders and displays the portal card content on the form page, thereby achieving secure adaptation and display of the portal card on the form page.

[0065] This embodiment provides a resource reuse method. The method discloses a process that, in response to a user's control configuration request triggered by the form configuration interface of a form platform, adds a card control to be referenced in the form configuration interface according to the control configuration request; determines a target card resource from the list of referenceable card resources in the portal platform according to user needs; establishes and saves the resource reference relationship between the card control to be referenced and the target card resource; and, when the form page corresponding to the form configuration interface is running, loads the portal card content corresponding to the target card resource according to the resource reference relationship. Compared to existing methods where portal platforms and form platforms independently develop and maintain similar business sections, requiring simultaneous modifications in multiple places for any change to a section, this embodiment, by adding a card control to be referenced in the form configuration interface and establishing a reference relationship between the control and existing card resources in the portal platform, allows the form page to directly load portal card content while running, eliminating the need to redevelop similar functional controls for the form scenario. This achieves one-time configuration and multiple reuse of portal card resources in the form scenario, thus solving the technical problem of high costs associated with the separate development and maintenance of business sections by existing portal platforms and form platforms.

[0066] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the resource reuse method in this application.

[0067] In this embodiment, the step of loading the portal card content corresponding to the target card resource according to the resource reference relationship includes steps S41 to S44: Step S41: In response to a page access request triggered based on the form page, obtain the user identity information of the currently accessing user.

[0068] It is understood that a page access request can be an instruction sent by a user to a device through a client to request access to a form page. It can be triggered when the user performs an operation to open the form page in a browser or other client program, such as clicking a link on the form page, entering the form page's Uniform Resource Locator in the address bar, or triggering it through interactive methods such as scanning a QR code or clicking a menu button in the application. This embodiment does not limit this.

[0069] It should be understood that the current user can be the one who initiates the page access request and intends to access the form page, and can be identified by the login credentials (such as username and password, digital certificate, biometrics, etc.) used by the user when logging into the enterprise digital system.

[0070] It should also be understood that user identity information can be a data set used to characterize the identity attributes of the currently accessing user. This can include the user's unique user identifier in the user management system, the user's role identifier, department identifier, user group identifier, job title information, or position information. For example, user identity information may include the user identifier "user_001", the role identifier "role_approver", and the department identifier "dept_finance". In this embodiment, user identity information can be generated and maintained by the device after the user successfully logs into the enterprise digital system. When the user initiates a page access request, this user identity information is transmitted to the device along with the page access request.

[0071] Step S42: Determine the form access control rules corresponding to the form page and the card access control rules corresponding to the card control to be referenced.

[0072] It should be noted that form access control rules can be a set of rules used to determine whether a user has the permission to access a form page and specific controls within the form page. These rules can include form page-level access control rules and control-level visual control rules. Form page-level access control rules determine the users or roles that can access the current form page, typically represented as an access control list, such as "Role A, Role B, and Role C have access permissions." Control-level visual control rules determine the users or roles that can see specific controls on the form page, such as "Visible only to users in the finance department" or "Visible only to users with approval permissions."

[0073] It should also be noted that card access control rules can be a set of pre-defined rules set by the portal platform to determine whether a user has permission to access the target card resource. In practical applications, card access control rules correspond one-to-one with each card resource in the portal platform, controlling the users or roles that can view and access the content of that card in the portal platform. In this embodiment, card access control rules can include rule types such as role whitelists, department whitelists, and user blacklists. For example, the access control rule for a certain data list card can be set to "only members of the R&D department have access rights".

[0074] Step S43: Perform permission verification on the current accessing user based on the user identity information, the form access control rules, and the card access control rules.

[0075] In this embodiment, the device can perform permission verification on the current user based on user identity information, form access control rules, and card access control rules. This permission verification can include form-side permission verification and portal-side permission verification. In practical applications, the device can perform form-side permission verification and portal-side permission verification on the current user separately to obtain the permission verification result. Form-side permission verification refers to the device determining whether the current user meets the access conditions stipulated by the form access control rules based on the user identity information; portal-side permission verification refers to the device determining whether the current user meets the access conditions stipulated by the card access control rules based on the user identity information.

[0076] Step S44: If the permission verification passes, load the portal card content corresponding to the target card resource according to the resource reference relationship.

[0077] In its implementation, after receiving a page access request triggered by a user through a client, the device can parse the request and extract the user's identity information from the session credentials. Subsequently, the device can determine the form access control rules corresponding to the form page based on its page identifier. Simultaneously, the device can read the card identifier of the target card resource from the resource reference relationship and use this card identifier to query the corresponding card access control rules from the portal platform. Next, the device can perform form-side permission verification and portal-side permission verification on the current user based on the user's identity information, the form access control rules, and the card access control rules, respectively, obtaining the permission verification results. When the permission verification passes—that is, when the current user simultaneously meets the access conditions stipulated by both the form access control rules and the card access control rules—the device can load the portal card content corresponding to the target card resource according to the resource reference relationship. When the permission verification fails, the device can refuse to load the portal card content or display a permission denied message to the current user.

[0078] Further, step S43 includes: Step S431: According to the form access control rules, verify whether the current user has form access permissions for the form page based on the user identity information, and whether the card control to be referenced has visual permissions on the form page, and obtain the form-side permission verification result.

[0079] It should be understood that form access permissions refer to whether a current user is allowed to access the form page and view or perform operations. This is determined by the page-level access control rules set by the form platform during the form configuration phase. In practice, if the current user's identity information meets the access conditions set by the form page (e.g., the current user's role is in the form page's access whitelist), then the current user has form access permissions; otherwise, the current user does not have form access permissions.

[0080] It should also be understood that visibility permissions refer to whether the currently accessing user is allowed to view the card control to be referenced on the form page. This can be determined by the control-level visibility control rules set by the form platform during the form configuration phase. These control-level visibility control rules can be set based on user roles, department, job title, or other user attributes. For example, the visibility permission of a card control to be referenced can be set to "visible only to department managers," meaning that even if ordinary employees have form access permissions, they will not be able to see that control area.

[0081] Understandably, the form-side permission verification result can be the judgment result obtained after verifying the permissions of the current accessing user according to the form access control rules. It can be used to indicate whether the current accessing user has both form access permission and visual permission. In practical applications, if the current accessing user has both form access permission and visual permission, the form-side permission verification result is passed; if the current accessing user does not have either form access permission or visual permission, the form-side permission verification result is failed.

[0082] Step S432: According to the card access control rules, verify whether the current accessing user has resource access permissions for the target card resource based on the user identity information, and obtain the portal-side permission verification result.

[0083] It should be understood that resource access permissions refer to whether a current user is allowed to access the content of the portal card corresponding to the target card resource. This access permission can be determined by the card access control rules set by the portal platform during the card configuration phase. These rules can be set based on user roles, user departments, user identifiers, or other user attributes. For example, the access control rule for a data list card could be set to "only members of the R&D department have resource access permissions," meaning that users outside the R&D department would not be able to view the card content even through a form page.

[0084] Understandably, the portal-side permission verification result can be the judgment result obtained after verifying the permissions of the current accessing user according to the card access control rules. It can be used to indicate whether the current accessing user has resource access permissions. In practical applications, if the current accessing user has resource access permissions, the portal-side permission verification result is passed; if the current accessing user does not have resource access permissions, the portal-side permission verification result is failed.

[0085] Accordingly, step S44 includes: Step S441: If both the form-side permission verification result and the portal-side permission verification result indicate that they have passed, load the portal card content corresponding to the target card resource according to the resource reference relationship.

[0086] In this embodiment, the form-side permission verification result is obtained by verifying whether the current user has form access permission and visual permission according to the form access control rules, and the portal-side permission verification result is obtained by verifying whether the current user has resource access permission according to the card access control rules. The portal card content is loaded only when both the form-side permission verification result and the portal-side permission verification result indicate that they have passed. This achieves dual independent verification and superimposed control of form platform-side permissions and portal platform-side permissions, effectively avoiding the risk of permission bypass caused by a single permission verification dimension, thereby improving the security of resource reference and the reliability of access control.

[0087] In its implementation, the device first performs form-side permission verification on the current user based on their identity information according to form access control rules. This form-side permission verification can include form access permission verification and visual permission verification. In form access permission verification, the device reads the access permission configuration of the form page from the form access control rules and compares the role identifier or user identifier in the user's identity information with the role list or user list in the access permission configuration to determine if the current user belongs to the permitted user group. If the current user's role identifier or user identifier exists in the access permission configuration, the current user is deemed to have form access permission; otherwise, the current user is deemed not to have form access permission. In visual permission verification, the device reads the visual permission configuration of the card control to be referenced from the form access control rules and compares the current user's role identifier or user identifier with the role list or user list in the visual permission configuration to determine if the current user belongs to the user group allowed to view the control. If the current user's role identifier or user identifier is in the visual permission configuration, then the current user can be determined to have visual permissions; if it is not in the visual permission configuration, then the current user cannot be determined to have visual permissions. When both the form access permission verification result and the visual permission verification result are positive, the device can determine that the form-side permission verification result is positive.

[0088] Next, the device can obtain the card access control rules for the target card resource from the portal platform. These rules include a list of user roles, user departments, or user identifiers with resource access permissions. The device then compares the role identifier, department identifier, or user identifier in the user's identity information with the list of roles, departments, or identifiers in the card access control rules to determine if the current user belongs to the user group permitted to access the card resource. If the current user's role identifier, department identifier, or user identifier meets at least one condition in the card access control rules, the current user is deemed to have resource access permissions, and the portal-side permission verification result is set to "pass." If none of the current user's role identifier, department identifier, or user identifier meets any of the conditions in the card access control rules, the current user is deemed not to have resource access permissions, and the portal-side permission verification result is set to "fail." If both the form-side and portal-side permission verification results indicate "pass," the device can determine that the current user has passed the complete permission verification and load the portal card content corresponding to the target card resource according to the resource reference relationship. Furthermore, if either the form-side permission verification result or the portal-side permission verification result fails, the device can determine that the current user has not passed the complete permission verification. In this case, the portal card content will not be loaded, or a permission-unavailable message will be displayed to the current user.

[0089] In this embodiment, by obtaining the user identity information of the current user, form access control rules and card access control rules are determined. Based on the identity information, form access control rules, and card access control rules, the current user's permissions are verified. This ensures that portal card content is loaded only when the permission verification passes, according to the resource reference relationship. This achieves dual permission verification on both the form side and the portal side, ensuring that users cannot bypass the original access control rules of the portal card by accessing the form page. This effectively avoids the risk of data leakage caused by permission bypass and improves the security and compliance of cross-platform resource reference.

[0090] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart illustrating Embodiment 3 of the resource reuse method of this application.

[0091] In this embodiment, the step of loading the portal card content corresponding to the target card resource according to the resource reference relationship includes steps S45-S46: Step S45: Obtain the form context information of the form page.

[0092] It should be noted that the form context information can be a set of business environment data in which the form page is running. This set of data describes the page environment, page state, and related data of the current form page, and can provide the referenced portal card with the background data required for its adaptive display in the form scenario. In this embodiment, the form context information may specifically include the current form identifier, form page state, user identity information of the current user, business primary key value, process instance identifier, current tenant identifier, and the page area where the card control to be referenced is located. Among them, the current form identifier is used to uniquely identify the form page instance that is currently running; the form page state is used to characterize the current operation stage of the form, such as new state, edit state, read-only view state, or approval state; the business primary key value can refer to the unique identifier of the business data record corresponding to the current form, such as the application form number in the training application form; the process instance identifier can refer to the unique identifier of the process instance corresponding to the current form when the form is associated with a business process; the current tenant identifier is used to determine the tenant to which the current user belongs in a multi-tenant system; the page area where the card control to be referenced is located is used to determine the display position of the card on the form page, and this area information can be represented as the row number, column number, hierarchical coordinates, or offset relative to the parent container of the control on the form page.

[0093] Step S46: Pass the form context information to the card rendering module corresponding to the target card resource according to the resource reference relationship.

[0094] It should be noted that the card rendering module can be a program module or component used to render portal card content. In this embodiment, the card rendering module can be deployed as an independent service or as a built-in functional module of the portal platform. In practical applications, the card rendering module has a data path with each card resource in the portal platform and can read the configuration information (including data source configuration, display template configuration, style configuration, etc.) of the corresponding card based on the card identifier. In addition, the card rendering module also has data acquisition capabilities, and can generate data query conditions based on the data source information (such as database table name, API interface address or data view name) and form context information (such as business primary key value, current user identifier) ​​in the card configuration, and obtain the corresponding card data from the data source.

[0095] Step S47: Receive the portal card content obtained by the card rendering module from the target card resource based on the form context information, and render and display the portal card content.

[0096] In its implementation, after the current user passes permission verification, the device extracts the current form identifier, form page state, and user identity information from the running instance of the form page. It then reads the configuration location of the card control to be referenced in the form configuration interface from the form page's configuration data. Based on this configuration location, it determines the actual page area of ​​the card control to be referenced on the form page. Next, it extracts the business primary key value and the current field values ​​of each field from the current data model of the form page. Finally, it aggregates this information into form context information. Subsequently, the device reads the card identifier of the target card resource from the resource reference relationship and determines the corresponding card rendering module, as well as the access address or interface information of the card rendering module corresponding to the target card resource, based on the card identifier. Then, the device encapsulates the form context information according to the data format required by the card rendering module corresponding to the target card resource and transmits the encapsulated form context information to the card rendering module through the corresponding address or interface information. After receiving the form context information, the card rendering module can read the data source configuration and display template configuration of the target card resource based on the card identifier. It then generates data query conditions based on the data source configuration and form context information and executes a data query to retrieve the corresponding card data from the target card resource's data source. The retrieved card data is then populated into the display template to generate the portal card content. Finally, the device can receive the portal card content returned by the card rendering module and render and display the received portal card content according to the display configuration information of the card control to be referenced on the form page.

[0097] Furthermore, the step of rendering and displaying the content of the portal card includes: Step S471: Determine the control width configuration and control height configuration of the card control to be referenced.

[0098] It should be understood that the control width configuration can be a parameter setting of the width occupied by the referenced card control on the form page. This can be a fixed pixel value (e.g., "600 pixels" or "800 pixels") or a relative proportion value (e.g., "occupies 50% of the total width of the form page" or "occupies 100% of the total width of the form page"). Similarly, the control height configuration can be a parameter setting of the height occupied by the referenced card control on the form page. This can be a fixed pixel value (e.g., "300 pixels" or "400 pixels") or an adaptive indicator (e.g., "adapts to content"). In this embodiment, the control width and height configurations can be set by the form designer through the property panel in the form configuration interface during the form configuration stage, or the device can automatically assign default values ​​based on the overall layout of the form page and responsive design rules. This embodiment does not impose any restrictions on this.

[0099] Step S472: Determine the display area of ​​the portal card corresponding to the target card resource in the form page based on the control width configuration and the control height configuration.

[0100] Understandably, the display area can be the control area occupied by the card control to be referenced on the form page for displaying the portal card content. It can consist of two parts: the area position and the area size. The area position can be determined by the position of the card control to be referenced in the form page layout, and the area size can be determined by the control width configuration and the control height configuration.

[0101] Step S473: Render and display the content of the portal card within the display area.

[0102] In its implementation, after acquiring the portal card content, the device can read the display configuration information of the card control to be referenced from the form page's configuration information. This display configuration information stores the set values ​​for the control's width and height. Subsequently, the device can obtain the position information of the card control to be referenced within the form page layout. This position information can include the control's starting horizontal and vertical coordinates. Then, the device can use the position information of the card control to be referenced as the starting point of the display area, define the control's width configuration as the horizontal extension range of the display area, and the control's height configuration as the vertical extension range of the display area, thereby determining the specific range of the display area of ​​the card control to be referenced within the form page. Finally, the device can fill the display area with the portal card content and render the portal card content according to the portal card's preset style rules. During rendering, the device can adaptively layout the portal card content based on the width and height of the display area. If the original size of the portal card content is inconsistent with the size of the display area, the portal card content can be scaled, cropped, or rearranged to fit the size of the display area. Once rendering is complete, the portal card content will be displayed in the corresponding display area of ​​the card control to be referenced on the form page, allowing the current user to view and interact with it.

[0103] In this embodiment, by determining the width and height configurations of the card control to be referenced, and based on these configurations, determining the display area of ​​the portal card corresponding to the target card resource on the form page, the portal card content is then rendered and displayed within the determined display area. This ensures that the referenced portal card is displayed within the specified area of ​​the form page according to the size parameters preset during the form design phase. Consequently, the display effect of the portal card in the form scenario is coordinated with the overall layout of the form page, thereby improving the display quality and user experience of cross-platform resource referencing.

[0104] It should be noted that, referring to Figure 5 , Figure 5 This provides an overall flowchart for the resource reuse method described in this application. Figure 5 As shown, in actual use, the portal platform can pre-maintain referable card resources and register the configured card resources as resource objects that can be referenced by the form platform, while providing the form platform with metadata information of the referable card resources. When the form platform needs to reuse portal card resources, the device can obtain a custom card control based on the control configuration request triggered by the user, and simultaneously create and display an instance of the custom card control in the canvas area of ​​the form configuration interface. Then, it loads the list of referable card resources provided by the portal platform through the communication interface between the form platform and the portal platform, and displays this list in the property panel or pop-up window of the form configuration interface for the user to select. Subsequently, the device can determine the card selected by the user as the target card resource and establish a mapping relationship between the form context parameters and the parameters required by the target card resource. This allows the context information of the form page (such as the current form identifier, business primary key value, process instance identifier, and the user identity information of the currently accessing user) to be passed to the portal card based on this mapping relationship during the form execution phase, enabling the portal card to obtain and display the corresponding data content according to the form scenario. Next, the device can obtain the display configuration information (including width, height, and style configurations) of the custom card control in the form configuration interface, and associate and store the control identifier of the custom card control, the card identifier of the target card resource, and the display configuration information to form a configurable resource reference relationship. After the form page enters the running state, the device can determine the target portal card content that the current custom card control needs to load based on the resource reference relationship in the control configuration, and perform form permission and portal card permission verification to check whether the current accessing user has form access permission, control visibility permission, and target card resource resource access permission. If all verifications pass, the device can load the target portal card content and render and display it on the form page; if any verification fails, the device does not load the portal card content, or displays a "no permission" prompt in the display area corresponding to the custom card control.

[0105] In this embodiment, by obtaining the form context information of the form page and passing it to the card rendering module corresponding to the target card resource according to the resource reference relationship, the card rendering module can obtain the portal card content from the target card resource based on the form context information. Finally, the device receives and renders the portal card content, thereby realizing the context awareness and dynamic adaptation of the portal card in the form scenario. This allows the referenced portal card to automatically match and display relevant card data according to the business scenario of the current form, avoiding the portal card displaying content unrelated to the current form business in the form scenario. This improves the content accuracy and scenario adaptation capability of the portal card when reused across platforms.

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

[0107] This application also provides a resource reuse device, please refer to... Figure 6 The resource reuse device includes: The request and response module 10 is used to respond to a control configuration request triggered by the user's form configuration interface based on the form platform, and add a card control to be referenced in the form configuration interface according to the control configuration request; Card determination module 20 is used to determine the target card resource from the list of referenceable card resources in the portal platform according to user requirements; Reference establishment module 30 is used to establish and save the resource reference relationship between the card control to be referenced and the target card resource; The resource referencing module 40 is used to load the portal card content corresponding to the target card resource according to the resource referencing relationship when the form page corresponding to the form configuration interface is in running state.

[0108] The resource reuse device provided in this application, employing the resource reuse method in the above embodiments, can solve the technical problem that existing portal platforms and form platforms require separate development and maintenance of business sections, resulting in high costs. Compared with the prior art, the beneficial effects of the resource reuse device provided in this application are the same as those of the resource reuse method provided in the above embodiments, and other technical features in the resource reuse device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0109] This application provides a resource reuse 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, and the instructions are executed by the at least one processor to enable the at least one processor to perform the resource reuse method in Embodiment 1 above.

[0110] The following is for reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing resource multiplexing devices in the embodiments of this application. The resource multiplexing devices in the embodiments of this application may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (PADs), portable media players (PMPs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 7 The resource reuse device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0111] like Figure 7 As shown, the resource multiplexing 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 the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the resource multiplexing device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the resource multiplexing device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows resource multiplexing devices with various systems, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

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

[0113] The resource reuse device provided in this application, employing the resource reuse method in the above embodiments, can solve the technical problem of resource reuse. Compared with the prior art, the beneficial effects of the resource reuse device provided in this application are the same as those of the resource reuse method provided in the above embodiments, and other technical features in this resource reuse device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0114] 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.

[0115] 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.

[0116] 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 resource reuse method in the above embodiments.

[0117] 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 fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0118] The aforementioned computer-readable storage medium may be included in the resource multiplexing device; or it may exist independently and not assembled into the resource multiplexing device.

[0119] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the resource reuse device, the resource reuse device: responds to a control configuration request triggered by a user's form configuration interface on a form platform, adds a card control to be referenced in the form configuration interface according to the control configuration request; determines a target card resource from the list of referenceable card resources in the portal platform according to user requirements; establishes and saves a resource reference relationship between the card control to be referenced and the target card resource; and, when the form page corresponding to the form configuration interface is in a running state, loads the portal card content corresponding to the target card resource according to the resource reference relationship.

[0120] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" 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).

[0121] 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.

[0122] 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.

[0123] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described resource reuse method. This solves the technical problem that existing portal platforms and form platforms require separate development and maintenance of business sections, resulting in high costs. 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 resource reuse method provided in the above embodiments, and will not be elaborated upon here.

[0124] 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.

[0125] All user-related data involved in this application (such as user needs, user identity information, etc.) were obtained with the user's permission or consent; that is, when this application is used in a specific product or technology, user permission is required to obtain and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.

[0126] For example, when it is necessary to obtain a user's identity information, a prompt to obtain identity information can be displayed on the user's terminal. After receiving confirmation from the user regarding the prompt to obtain identity information, the terminal can obtain the user's identity information.

Claims

1. A resource reuse method, characterized in that, The method includes: In response to a control configuration request triggered by a user's form configuration interface on a form platform, add a card control to be referenced in the form configuration interface according to the control configuration request; The target card resource is determined from the list of referenceable card resources in the portal platform based on user needs; Establish and save the resource reference relationship between the card control to be referenced and the target card resource; When the form page corresponding to the form configuration interface is running, the portal card content corresponding to the target card resource is loaded according to the resource reference relationship.

2. The method as described in claim 1, characterized in that, The step of loading the portal card content corresponding to the target card resource according to the resource reference relationship includes: In response to a page access request triggered by the form page, obtain the user identity information of the currently accessing user; Determine the form access control rules corresponding to the form page and the card access control rules corresponding to the card control to be referenced; The permissions of the current user are verified based on the user identity information, the form access control rules, and the card access control rules. If the permission verification passes, the portal card content corresponding to the target card resource is loaded according to the resource reference relationship.

3. The method as described in claim 2, characterized in that, The step of verifying the permissions of the current user based on the user identity information, the form access control rules, and the card access control rules includes: According to the form access control rules, the system verifies whether the current user has form access permissions for the form page based on the user identity information, and whether the card control to be referenced has visual permissions on the form page, and obtains the form-side permission verification result. According to the card access control rules, the system verifies whether the current user has access permissions to the target card resource based on the user identity information, and obtains the portal-side permission verification result. The step of loading the portal card content corresponding to the target card resource according to the resource reference relationship when the permission verification is passed includes: If both the form-side permission verification result and the portal-side permission verification result indicate that they have passed, the portal card content corresponding to the target card resource is loaded according to the resource reference relationship.

4. The method as described in claim 1, characterized in that, The step of loading the portal card content corresponding to the target card resource according to the resource reference relationship includes: Obtain the form context information of the form page; Based on the resource reference relationship, the form context information is passed to the card rendering module corresponding to the target card resource; The system receives the portal card content obtained from the target card resource by the card rendering module based on the form context information, and renders and displays the portal card content.

5. The method as described in claim 4, characterized in that, The step of rendering and displaying the content of the portal card includes: Determine the width and height configurations of the card control to be referenced; The display area of ​​the portal card corresponding to the target card resource in the form page is determined based on the control width configuration and the control height configuration. The content of the portal card is rendered and displayed within the display area.

6. The method as described in claim 1, characterized in that, The step of establishing and saving the resource reference relationship between the card control to be referenced and the target card resource includes: Obtain the control identifier of the card control to be referenced and the card identifier of the target card resource; Obtain the display configuration information of the card control to be referenced in the form configuration interface based on the control identifier; The control identifier, the card identifier, and the display configuration information are associated and stored to form a resource reference relationship between the card control to be referenced and the target card resource.

7. The method as described in claim 1, characterized in that, Before the step of determining the target card resource from the list of referenceable card resources in the portal platform according to user needs, the method further includes: Retrieve resource metadata for all card resources in the portal platform; Based on the resource metadata, check whether the corresponding card resource meets the preset reference conditions; Based on the detection results, card resources that meet the preset referencing conditions are configured as referable card resources, and a list of referable card resources is generated based on the referable card resources.

8. A resource reuse device, characterized in that, The device includes: The request and response module is used to respond to the control configuration request triggered by the user based on the form configuration interface of the form platform, and add the card control to be referenced in the form configuration interface according to the control configuration request; The card determination module is used to determine the target card resource from the list of referenceable card resources in the portal platform according to user requirements; The reference establishment module is used to establish and save the resource reference relationship between the card control to be referenced and the target card resource; The resource referencing module is used to load the portal card content corresponding to the target card resource according to the resource referencing relationship when the form page corresponding to the form configuration interface is running.

9. A resource reuse 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 resource reuse method as described in any one of claims 1 to 7.

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

Images