Content model construction and unification engine execution method, system and apparatus

Abstract

This invention relates to the field of B2B foreign trade website building technology, and in particular to a content model construction and unified engine execution method, system, and device. The method includes: the client configuring fields of the content model; the server constructing the fields into a tree-like field structure according to hierarchical relationships, storing the tree-like field structure as metadata, and assembling a model definition object based on the read metadata; the client recursively rendering the form interface based on the model definition object; the server generating data validation rules based on the configuration parameters in the metadata, and validating the form data submitted by the client based on the data validation rules; the server storing the validated form data according to the field attributes in the metadata, and performing state management, soft deletion, and sorting processing on the content data. This invention can solve the problems of high coupling between model and code, complex field nesting, difficulty in expansion, code redundancy, and difficulty in ensuring consistency of state across multiple modules in existing technologies.

Description

Technical Field

[0001] This invention relates to the field of business-to-business (B2B) foreign trade website building technology, and in particular to a content model construction and unified engine execution method, system and equipment. Background Technology

[0002] The B2B foreign trade website building field has now formed a mature content management system. Various types of content, such as products, news, solutions, and navigation, need to be efficiently configured and flexibly managed. The industry generally pursues a low-code, configurable, and easily scalable system architecture to adapt to the website building needs and business changes of different enterprises.

[0003] Most existing B2B foreign trade website building systems use hard-coded content management modules. The content structure is directly embedded in the database tables and business code. Each type of content requires independently developed form rendering, data validation, CRUD interfaces, and page templates. Common functions such as drafts, recycle bins, and sorting also need to be implemented module by module.

[0004] This implementation method has obvious technical defects: the model and code are highly coupled, and adding or modifying fields requires synchronous modification of the front-end and back-end code and storage structure; it does not support dynamically nested fields, making it difficult to expand complex structures; it has a large amount of redundant code, low reusability, and high maintenance costs; model changes depend on code releases, making it difficult to guarantee the consistency of state across multiple modules. Summary of the Invention

[0005] This invention provides a content model construction and unified engine execution method, system, and device to solve the problems of high coupling between models and code, complex field nesting, difficulty in expansion, code redundancy, and difficulty in ensuring the consistency of state across multiple modules in the prior art.

[0006] In a first aspect, embodiments of the present invention provide a content model construction and unified engine execution method, including: The client configures the fields of the content model through a visual interface, and the server constructs the fields into a tree field structure according to the hierarchical relationship, and stores the tree field structure as metadata in the database; The server reads the metadata and assembles a model definition object based on the metadata. The client recursively renders the form interface based on the model definition object. The server generates corresponding data validation rules based on the configuration parameters in the metadata, and validates the form data submitted by the client based on the data validation rules. The server stores the validated form data into the main content table or the extended content table according to the field attributes in the metadata, and performs status management, soft deletion and sorting processing on the content data.

[0007] One possible implementation also includes: When the content model changes, the server updates the metadata in the database. The server and the client load the corresponding model structure at runtime based on the updated metadata, thus achieving non-intrusive model evolution.

[0008] In one possible implementation, the client pre-configures atomic field types such as text, editor, image, select, and combination, where combination is a container field that supports nested subfields to implement a multi-level grouping structure. The visualization interface includes: a field tree display area on the left and a field type display area on the right; the field tree display area on the left displays clickable field node buttons, which are used to render all field nodes configured under the current model in the form of a recursive list; the field type display area on the right displays clickable field type buttons.

[0009] In one possible implementation, the client configures the fields of the content model through a visual interface, and the server constructs the fields into a tree-like field structure according to their hierarchical relationship, and stores the tree-like field structure as metadata in the database, including: Determine the context parent node based on the field node selected by the user or the default settings; Receive the field type clicked by the user, and generate a temporary field object through a pop-up configuration based on the context parent node and the field type; Upon receiving confirmation from the user, the client serializes the temporary field object into JSON data and submits it to the server. The server establishes a parent-child hierarchy mapping relationship for the fields based on the JSON data and writes the field records into the metadata table; After the client refreshes the page, the server reconstructs the tree field structure based on the metadata table and returns it to the client, which then recursively renders the tree field structure.

[0010] In one possible implementation, the client serializes the temporary field object into JSON data and submits it to the server, including: The client serializes the temporary field object into JSON data and submits it to the server along with the content model identifier model_id and the parent field identifier parent_id as a field configuration request; The server establishes a parent-child hierarchy mapping relationship for the fields based on the JSON data and writes the field records into the metadata table, including: After receiving the field configuration request, the server extracts the parent_id; If the parent_id is 0, then set the parent_id of the corresponding field record in the database metadata table to 0; If the parent_id is not empty, then the value of the parent_id is assigned to the parent_id record of the corresponding field in the metadata table; The server writes the field records into the metadata table. Each field record in the metadata table stores the definition information of a field. The field is associated with the content model through model_id and the field hierarchy is identified by parent_id. Parent_id=0 indicates that the field is a top-level field, and parent_id greater than 0 points to the identifier of its parent field. After the server completes the writing, it returns the assigned real primary key identifier to the client.

[0011] In one possible implementation, the server reads the metadata and assembles a model definition object based on the metadata; the client recursively renders the form interface based on the model definition object, including: The server queries the metadata table based on the model_id to obtain all field records under the model; By recursively traversing the parent_id records in the field records, a model definition object containing field types, identifiers, configuration parameters, and a list of nested subfields is reconstructed. The client binds the corresponding fields to the pre-registered user interface (UI) components according to the field types in the model definition object; The client traverses the list of nested subfields in the model definition object through a recursive component. If the subfield is a regular field node other than a combined field, it is rendered as an independent input block. If the subfield is a combination field, it is rendered as a collapsible block, and its subfields are nested and rendered inside the block, until the rendering of all levels of fields is completed, so that the hierarchical structure of the form interface displayed by the client is completely matched with the tree structure of the model definition object assembled by the server.

[0012] In one possible implementation, before the server performs state management, soft deletion, and sorting processing on the content data, it also includes: The form data corresponding to the combination field is recursively parsed, and the non-image data obtained by parsing is serialized into JSON and stored. The image data obtained by parsing is extracted from the form data into an independent container and written into the media table. The server synchronously stores the image data in a multilingual environment and locates the position of the image data in the combination field structure using a unique identifier; The server writes the classification and association relationships of the content data into different tables.

[0013] One possible implementation also includes: The server configures associated model fields in the content model to enable cross-model content referencing, and writes the reference relationships between content into an independent content association table to support many-to-many associations and reverse queries.

[0014] Secondly, embodiments of the present invention provide a content model construction and unified engine execution system, including: The client-side component is used by clients to configure fields of the content model through a visual interface. The server-side component is used to construct the fields into a tree-like field structure according to their hierarchical relationship, and to store the tree-like field structure as metadata in the database. The server is also used to read the metadata and assemble a model definition object based on the metadata; The client is also used to recursively render the form interface according to the model definition object; The server is also used to generate corresponding data verification rules based on the configuration parameters in the metadata, and to verify the form data submitted by the client based on the data verification rules; and to store the verified form data into the main content table or the extended content table according to the field attributes in the metadata, and to perform status management, soft deletion and sorting processing on the content data.

[0015] Thirdly, embodiments of the present invention provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect or any possible implementation thereof.

[0016] This invention provides a content model construction and unified engine execution method, system, and device. The client configures content model fields through a visual interface, while the server constructs the fields into a tree-like field structure according to hierarchical relationships and stores this tree-like field structure as metadata in a database. By storing the content model structure as metadata, this invention completely decouples the model definition from the program code, allowing field configuration to be completed at runtime without code modification. This fundamentally solves the problem of strong coupling between the model and code, and the inability to dynamically configure them. The server reads metadata and assembles model definition objects based on the metadata. The client then recursively renders the form interface based on the model definition objects. The model definition objects are automatically reconstructed based on the metadata and recursively rendered. There is no need to write separate front-end templates for different content. It natively supports multi-level nested structures, ensuring that the form interface is strictly consistent with the model definition, and solving the problems of difficult nested expansion, template redundancy, and structural asynchrony. The server generates corresponding data validation rules based on the configuration parameters in the metadata, and validates the form data submitted by the client based on the data validation rules. The validation rules are dynamically generated by the configuration parameters, eliminating the need to write validation code separately for each model and each field, achieving unified validation logic across the platform, and eliminating the problems of duplicate code and inconsistent behavior. The server stores the validated form data into the main content table or the extended content table based on the field attributes in the metadata, and performs state management, soft deletion, and sorting on the content data. The main table / extended table is automatically split based on field attributes, and common functions such as state management, soft deletion, and sorting are implemented through a unified engine. This allows for full model reuse after a single development, solving the problems of fragmented common functions, non-standard storage, and high maintenance costs. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating the implementation of the content model construction and unified engine execution method provided in this embodiment of the invention. Figure 2 This is a schematic diagram of the structure of the content model construction and unified engine execution system provided in this embodiment of the invention; Figure 3 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0020] See Figure 1This document illustrates a flowchart of a content model construction and unified engine execution method provided by an embodiment of the present invention. This method is used for the no-code definition and full lifecycle management of various content modules in a B2B website building platform. The solution achieves complete decoupling of content structure and program logic through a three-layer architecture of "visual configuration + metadata storage + unified engine execution," ensuring consistency, maintainability, and scalability of system behavior. Details are as follows: Step 101: The client configures the fields of the content model through a visual interface. The server constructs the fields into a tree field structure according to the hierarchical relationship and stores the tree field structure as metadata in the database.

[0021] In this step, the client completes the configuration of content model fields through a visual interface. Based on the configuration information submitted by the client, the server constructs the fields into a tree-like field structure according to the hierarchical relationship, and persists the tree-like field structure to the database in the form of metadata, forming a metadata system that can be read and reused by the system.

[0022] In one embodiment, the client pre-configures atomic field types such as text, editor, image, select, and combination. The combination field is a container field that supports nested subfields and is used to implement a multi-level grouping structure. Where text is a single-line text, and the submitted value is a string, after... After processing, directly store the data in the content table; The editor is a rich text editor. It submits an HTML string, which is then decoded and stored in an extended table. The image is an uploaded image, submitted as an array of objects. It is not stored in the content table, but its metadata is extracted and written to a dedicated media table. If the field name is images, the first image is automatically used as the thumbnail. The select option is a drop-down radio button; once the option value is submitted, it is stored directly. The combination field is the only field type with container semantics. It accepts grouped nested data rather than a single value and requires recursive parsing by the backend. That is, the backend needs to traverse each group and call the corresponding processor to process each subfield according to its form type. If it is a text subfield, the text subfield is merged into a JavaScript Object Notation (JSON) string and then stored in the main table or extension table. If it is an image subfield, the image subfield is extracted into a separate imgs_data container and delayed until the media processing stage to be uniformly stored in the database. The group_num and index are recorded in the media table to restore its original position in the combination structure.

[0023] The system's pre-built atomic fields each have their own dedicated processing logic, covering the content structure requirements of all scenarios such as B2B website building products, news, and solutions, eliminating the need to develop separate field components for each type of content.

[0024] The client's visualization interface is divided into left and right display areas, namely: the left field tree display area and the right field type display area; the left field tree display area displays clickable field node buttons, which are used to render all the field nodes configured under the current model in the form of a recursive list. Each field node has a unique identifier and a parent node identifier; the right field type display area displays clickable field type buttons, allowing users to select the desired field type.

[0025] In one embodiment, the client configures the fields of the content model through a visual interface, and the server constructs the fields into a tree-like field structure according to their hierarchical relationship, and stores the tree-like field structure as metadata in the database, which may include: Determine the context parent node based on the field node selected by the user or the default settings; Receive the field type clicked by the user, and generate a temporary field object through a pop-up configuration based on the context parent node and the field type; Upon receiving confirmation from the user, the client serializes the temporary field object into JSON data and submits it to the server. The server establishes a parent-child hierarchy mapping relationship for fields based on the JSON data and writes the field records into the metadata table; After the client refreshes the page, the server reconstructs the tree field structure based on the metadata table and returns it to the client, which then recursively renders the tree field structure.

[0026] Optionally, the context parent node can be determined based on the field node selected by the user or the default settings. This can include: if the user selects a target field node in the field tree display area on the left, then the target field node is determined as the context parent node; if the user does not select any field node, or selects a non-composite type field, then the root level (parent Id = 0) is used as the context parent node by default.

[0027] After a user clicks on a field type, the client creates a temporary field object. This temporary field object is not written to the database immediately; it only exists in the front-end's memory. It's important to note that the front-end is the client-side application. The temporary field object's properties include: Form type: The type of the selected field; parent Id: The identifier of the parent node inherited from the current context; if none exists, it is 0. And the fields, name, setting, is_main, and is_core populated by the pop-up form; Field: Field name (the actual field name in the database); name: Field name (for display purposes); The `setting` property stores detailed configuration properties for specific fields, including several attributes: a. is_required: An indicator of whether the field is required; b. min_length: Minimum length limit; c. max_length: Maximum length limit; d. allowext: Allowed file extensions for uploading; e. allow_upload_num: The number of files allowed to be uploaded; is_main: An identifier that distinguishes whether data is stored in the main table or the extended table; is_core: An identifier that distinguishes whether a field is a built-in core field.

[0028] In one embodiment, the client serializes the temporary field object into JSON data and submits it to the server, which may include: The client serializes the temporary field object into JSON data and submits it to the server along with the content model identifier model_id and the parent field identifier parent_id as a field configuration request; The server establishes a parent-child hierarchy mapping relationship for fields based on the JSON data and writes the field records to the metadata table, including: After receiving the field configuration request, the server extracts the parent_id; If parent_id is 0, then set the parent_id of the corresponding field record in the database metadata table to 0; If parent_id is not empty, then the value of parent_id is assigned to the parent_id record of the corresponding field in the metadata table; The server writes the field records to the metadata table. Each field record in the metadata table stores the definition information of a field. The content model to which the field belongs is associated with the model_id, and the parent_id is used to identify the field hierarchy. Here, parent_id=0 indicates that the field is a top-level field, and parent_id greater than 0 points to the identifier of its parent field. After the server completes the writing, it returns the assigned real primary key identifier to the client.

[0029] Optionally, upon receiving a successful response, the client triggers a full page refresh and requests model field tree data from the server. The server queries the `cms_model_field` table based on `model_id`, filters for root fields where `parent_id=0`, recursively queries the subfields of each root field, constructs a complete tree-like field structure, and returns it to the client. The front-end template traverses the tree-like field structure using a recursive component, rendering each node as a block and combining fields as collapsible blocks, eliminating the need to modify the front-end code even with multiple layers. Each block is bound to a real ID as the context for edit and delete operations, completing the front-end recursive rendering and metadata binding. After configuration, the field tree is refreshed and rebuilt to avoid state inconsistencies caused by partial updates, achieving a "what you see is what you get" model definition.

[0030] Step 101 achieves decoupling of content model definition and code logic through client-side visual configuration, server-side tree structure construction, and metadata persistence. Specifically, the client directly selects field types and configuration parameters through the interface, replacing the traditional method of writing fields in code, lowering the threshold for model definition and supporting runtime dynamic configuration. The parent_id establishes hierarchical relationships between fields, enabling the construction of multi-level nested models and achieving a hierarchical tree structure. This naturally supports nesting and grouping, solving the problems of traditional systems not supporting dynamic nesting and having poor scalability. Temporary field objects are temporarily stored on the front end and submitted only after confirmation, preventing configuration from being directly written to the database during intermediate operations. This ensures that the configuration process is reversible, the interface is smoother, and the configuration interaction experience and operational security are improved. The tree field structure is converted to JSON serialization for transmission using a standard format, avoiding data loss or parsing errors. The unified data format between the front end and back end ensures stable transmission of complex hierarchical field data. The model structure is saved in the form of data records, such as metadata stored in the cms_model_field unified table, no longer coupled to the code, facilitating reuse throughout the entire process of subsequent reading, rendering, verification, and storage.

[0031] The metadata system built in step 101 is the core basis for the unified engine's execution, making it possible to automatically add, delete, modify, and query functions (Create, Read, Update, Delete, CRUD) and reuse common functions.

[0032] Step 102: The server reads the metadata and assembles the model definition object based on the metadata. The client then recursively renders the form interface based on the model definition object.

[0033] Based on the metadata persistently stored in step 101, the server reconstructs and generates a unified model definition object, providing a unified data basis for subsequent form rendering, data validation, and data storage. The client implements automated recursive rendering of the form interface based on the model definition object, ensuring that the form structure displayed on the front end is strictly consistent with the content model defined on the back end, thus solving the technical problems of traditional website building systems that require manual writing of form templates and difficulty in synchronizing structures.

[0034] In one embodiment, the server reads metadata and assembles a model definition object based on the metadata. The client then recursively renders the form interface based on the model definition object, which may include: The server queries the metadata table based on the model_id to retrieve all field records under that model; By recursively traversing the parent_id in the field records, a model definition object containing the field type (form type), identifier (field), configuration parameters (setting), and a list of nested subfields is reconstructed; The client binds the corresponding fields to the pre-registered UI components based on the field types in the model definition object; The client recursively traverses the list of nested subfields in the model definition object. If the subfield is a regular field node other than a combined field, it is rendered as an independent input block. If the subfield is a combination field, it is rendered as a collapsible block, and its subfields are nested and rendered inside the block, until all levels of fields are rendered, so that the hierarchical structure of the form interface displayed by the client is completely matched with the tree structure of the model definition object assembled by the server.

[0035] Optionally, when rebuilding the model definition object, the server recursively traverses and filters out the root field with parent_id of 0, and queries the corresponding sub-fields layer by layer starting from the root field to rebuild the tree structure model definition object in the server memory.

[0036] The server dynamically reconstructs model definition objects based on metadata, eliminating the need for hard-coded configuration. It can directly read metadata from the database to reconstruct the complete tree structure, providing a unified and standardized input source for form rendering, data validation, and data storage, ensuring data consistency throughout the entire process, and decoupling the content model from the code logic.

[0037] The server recursively reconstructs model definition objects based on `model_id` and `parent_id`. By recursively traversing the hierarchical relationship, it can completely restore nested field structures of arbitrary depth, solving the problems of traditional systems being unable to dynamically build complex models and having poor scalability. For example, a typical nested field structure has a depth of two levels; by recursively traversing the hierarchical relationship, a two-level nested field structure can be completely restored, where `combination` is the top-level field.

[0038] Dynamic matching and binding between corresponding fields and pre-registered UI components significantly reduces the amount of front-end template development and eliminates redundant code. For example, text is bound to an input component, and combination is bound to a recursive container component.

[0039] When the client performs recursive rendering, it iterates through the list of nested subfields in the model definition object using a recursive component: For combination fields, render them as collapsible blocks and nest their child fields within the blocks to ensure that the final form interface hierarchy, number of fields, and field types are completely consistent with the content model defined by the server-side metadata, without the need for manual intervention or code modification. For ordinary field nodes other than combination fields, they are directly rendered as independent input blocks; Meanwhile, the client binds the corresponding real primary key ID to each rendered field block as the context for subsequent editing, deletion and other interactive operations, ensuring that the interface operation and the backend data form a one-to-one mapping relationship, so that editing, deletion and other operations can accurately locate the target field and avoid operation errors and data chaos.

[0040] This step achieves automatic matching between the form structure and the content model by dynamically assembling model definition objects based on metadata on the server side and recursively rendering the form interface on the client side based on the model definition objects.

[0041] Step 103: The server generates corresponding data validation rules based on the configuration parameters in the metadata, and validates the form data submitted by the client based on the data validation rules.

[0042] Based on the metadata and model definition objects in steps 101 and 102, the server automatically generates dynamic and configurable data validation rules, eliminating the need to write separate validation code for different models and fields, thus unifying and automating the validation logic. At the same time, strict validation is performed when the form is submitted to ensure the legality, integrity, and standardization of the data submitted from the front end, preventing invalid data from entering the storage process from the source and improving system stability and data quality.

[0043] Data validation rules are dynamically constructed from configuration parameters in the field metadata. After receiving form data submitted by the client, the server queries the cms_model_field table based on the content model identifier model_id, loads the complete metadata definitions of all fields under that content model, iterates through the configuration parameters setting carried in the metadata of each field, and dynamically constructs the corresponding data validation rule chain.

[0044] Configuration parameters include whether the field is required (is_required), minimum length (min_length), maximum length (max_length), allowed file extension (allowext), and allowed upload quantity (allow_upload_num). The server generates matching validation rules based on these configuration parameters: if the value of the field is_required is 1 or true, it is considered a required field, and a non-empty validation rule is generated; if the field is a text type such as text or editor, and min_length and max_length are greater than 0, a string length validation rule is generated, with a rule for min_length that the string length is not less than the value, and a rule for max_length that the string length is not greater than the value; if the field is an upload type such as image, file format and upload quantity validation rules are generated; for non-text fields such as image, select, and combination, length-related validation is automatically ignored, and only the corresponding type's specific validation is performed.

[0045] In the scenario of saving drafts, the server automatically skips the mandatory validation corresponding to `is_required`, retaining only basic validation rules such as format, length, and security. This ensures that the data is basically valid while also meeting the temporary storage needs of incomplete content. The server executes the validation rules sequentially according to a preset order. If any validation fails, the process is immediately interrupted and the corresponding error message is returned to the client. Only after all validations pass can the subsequent data storage stage begin.

[0046] Through the dynamic verification mechanism described above, this step achieves deep binding between verification rules and metadata configuration. Modifications to model fields and adjustments to verification rules do not require changes to the backend code; only updates to metadata are needed for the changes to take effect, significantly improving system configurability and scalability. At the same time, the unified verification logic avoids the problems of redundant development and inconsistent rules, ensuring that the verification behavior of all model data is standardized and greatly reducing system maintenance costs.

[0047] Step 104: The server stores the validated form data into the main content table or the extended content table according to the field attributes in the metadata, and performs status management, soft deletion and sorting processing on the content data.

[0048] This step enables intelligent table partitioning of data based on field attributes in metadata, improving query and maintenance efficiency while ensuring data storage standardization. It also performs common processing such as status management, soft deletion, and sorting on content data through a unified engine, avoiding the need to repeatedly develop common functions for various types of content, and achieving the technical effects of unified logic, high reusability, and low maintenance cost.

[0049] Optionally, the server retrieves the validated form data and performs data routing and table partitioning based on the is_main field attribute in the metadata. If is_main=1, the corresponding field data is written to the main content table, for example, the main content table can be {model}_data. If is_main=0, the corresponding field data is written to the extended content table, for example, the extended content table can be {model}_detail. This achieves separate storage of frequently accessed fields with large and infrequently accessed fields, ensuring database standardization while improving data read and write efficiency.

[0050] In one embodiment, before the server performs state management, soft deletion, and sorting processing on the content data, it may also include: a structured storage of combined fields and a media separation mechanism.

[0051] The form data corresponding to the combination field is recursively parsed, and the non-image data obtained by parsing is serialized into JSON and stored. The image data obtained by parsing is extracted from the form data into an independent container and written into the media table. The server synchronously stores image data in a multilingual environment and uses a unique identifier to locate the position of the image data in the combination field structure; The server writes the classification and association relationships of the content data into different tables.

[0052] Optionally, for the form data corresponding to the combination field, the server recursively parses it, serializes the non-image data into JSON and stores it in the corresponding main content table or extended content table, and extracts the image data from the form data into an independent container and writes it uniformly into the common_image media table.

[0053] In a multilingual environment, image data can be uploaded once and synchronized across all languages. A unique identifier composed of `field_id`, `info_id`, `language_id`, `group_num`, and `index` precisely locates the image data within the combined field structure, achieving accurate binding and restoration of image resources and content structure. Simultaneously, the server writes the content data's category relationships to the `content_nav` table and the relationships between content items to the `content_relation` table, ensuring the integrity and clarity of related data storage.

[0054] Optionally, the server provides a unified processing interface for content data, performing status updates, sorting adjustments, soft deletions, and content restoration operations. Among these, updateStatus is the interface for updating content status; updateListOrder() is the interface for adjusting sorting weights; delete() is the interface for soft deletion, implemented by marking the recycling status, such as marking is_recycle = 1 to achieve soft deletion, without directly physically deleting data, thus improving data security and recoverability; and restore() is the interface for restoring recycled items.

[0055] When saving content data, the URL is automatically generated (Url::show()) and the route registration is completed (Routes::addContentRoute()), enabling content to be published as soon as it is saved, thus improving the ease of use and workflow of the system.

[0056] Through the aforementioned table partitioning, combined field parsing, media separation, and unified general function processing mechanism, this step decouples the data storage structure from the business logic. It eliminates the need to develop separate storage and general function code for different models, significantly reducing redundant code and improving system scalability and stability. The unified data processing rules ensure consistent behavior across all content models, and model changes do not require modifications to the storage logic; they can be completed simply by updating metadata, truly achieving non-intrusive data management and model evolution.

[0057] In one embodiment, the server configures an association model field in the content model to enable cross-model content referencing, and writes the reference relationship between content into a separate content association table to support many-to-many associations and reverse queries.

[0058] Configure a `relation` field in the content model specifically for expressing reference relationships between content items. Store a structured string list of `model_id` items that can be associated within the `relation` field to limit the scope of the references.

[0059] The reference relationships are stored in an independent relational table, content_relation, which includes data_id (source content ID), relation_data_id (target content ID), and relation_model_id (target model ID), supporting many-to-many relationships. A reverse query index is built using relation_model_id and relation_data_id to efficiently query the referenced content.

[0060] In one embodiment, when the content model changes, the server updates the metadata in the database. The server and client then load the corresponding model structure at runtime based on the updated metadata, achieving non-intrusive model evolution. In other words, model structure adjustments only require updating metadata records, without modifying program code. The latest definition is automatically loaded at runtime, effectively solving the technical problems of strong coupling between model and code, difficulty in making changes, and poor state consistency in traditional solutions.

[0061] Optionally, the runtime metadata query operation is as follows: before each content operation, the server re-queries the cms_model_field table to obtain the latest content model definition to ensure that the current valid structure is used; For fields with is_core=1, the field name must not be modified to prevent damage to critical fields that the system depends on. When new fields are missing from old content data, the front-end rendering layer automatically injects default values ​​or empty placeholders to ensure UI continuity and data integrity.

[0062] This invention provides a content model construction and unified engine execution method. The client configures the fields of the content model through a visual interface, while the server constructs the fields into a tree-like field structure according to hierarchical relationships and stores this tree-like field structure as metadata in the database. This invention stores the content model structure as metadata, completely decoupling the model definition from the program code. Field configuration can be completed at runtime without modifying the code, fundamentally solving the problem of strong coupling between the model and code and the inability to dynamically configure them. The server reads metadata and assembles model definition objects based on the metadata. The client then recursively renders the form interface based on the model definition objects. The model definition objects are automatically reconstructed based on the metadata and recursively rendered. There is no need to write separate front-end templates for different content. It natively supports multi-level nested structures, ensuring that the form interface is strictly consistent with the model definition, and solving the problems of difficult nested expansion, template redundancy, and structural asynchrony. The server generates corresponding data validation rules based on the configuration parameters in the metadata, and validates the form data submitted by the client based on the data validation rules. The validation rules are dynamically generated by the configuration parameters, eliminating the need to write validation code separately for each model and each field, achieving unified validation logic across the platform, and eliminating the problems of duplicate code and inconsistent behavior. The server stores the validated form data into the main content table or the extended content table based on the field attributes in the metadata, and performs state management, soft deletion, and sorting on the content data. The main table / extended table is automatically split based on field attributes, and common functions such as state management, soft deletion, and sorting are implemented through a unified engine. This allows for full model reuse after a single development, solving the problems of fragmented common functions, non-standard storage, and high maintenance costs.

[0063] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0064] The following are device embodiments of the present invention. For details not described in detail, please refer to the corresponding method embodiments described above.

[0065] Figure 2 The diagram illustrates the structure of a content model construction and unified engine execution system according to an embodiment of the present invention. For ease of explanation, only the parts relevant to the embodiment of the present invention are shown, and are described in detail below: like Figure 2 As shown, the content model building and unified engine execution system includes: client 21 and server 22.

[0066] Client 21 is used by the client to configure the fields of the content model through a visual interface; Server 22 is used to construct a tree-like field structure based on hierarchical relationships of the fields, and store the tree-like field structure as metadata in the database; Server 22 is also used to read metadata and assemble model definition objects based on the metadata; Client 21 is also used to recursively render the form interface based on the model definition object; Server 22 is also used to generate corresponding data validation rules based on the configuration parameters in the metadata, and to validate the form data submitted by the client based on the data validation rules; and to store the validated form data into the main content table or the extended content table according to the field attributes in the metadata, and to perform status management, soft deletion and sorting processing on the content data.

[0067] In one possible implementation, when the content model changes, the server 22 is also used to update the metadata in the database. The server 22 and the client 21 load the corresponding model structure at runtime based on the updated metadata, thereby achieving non-intrusive evolution of the model.

[0068] In one possible implementation, the client pre-defines atomic field types such as text, editor, image, select, and combination. The combination field is a container field that supports nested subfields to implement a multi-level grouping structure. The visualization interface includes: a field tree display area on the left and a field type display area on the right; the field tree display area on the left displays clickable field node buttons, which are used to render all the field nodes configured under the current model in the form of a recursive list; the field type display area on the right displays clickable field type buttons.

[0069] In one possible implementation, client 21 is used to determine the context parent node based on the field node selected by the user or the default setting; and to receive the field type clicked by the user, and generate a temporary field object through a pop-up configuration according to the context parent node and the field type. Upon receiving the user's confirmation, client 21 serializes the temporary field object into JSON data and submits it to server 22. Server 22 is used to establish the parent-child hierarchy mapping relationship of fields based on JSON data and write the field records to the metadata table; After the client 21 refreshes the page, the server 22 reconstructs the tree field structure based on the metadata table and returns it to the client 21, which then recursively renders the tree field structure.

[0070] In one possible implementation, client 21 is used to serialize the temporary field object into JSON data and submit it to server 22 along with the content model identifier model_id and the parent field identifier parent_id as a field configuration request; Server 22 is used to extract parent_id after receiving the field configuration request; and if parent_id is 0, set the parent_id of the corresponding field record in the database metadata table to 0; and if parent_id is not empty, assign the value of parent_id to the parent_id of the corresponding field record in the metadata table. Server 22 is also used to write field records into the metadata table. Each field record in the metadata table stores the definition information of a field, which is associated with the content model through model_id and identified by parent_id. Parent_id=0 indicates that the field is a top-level field, and parent_id greater than 0 points to the identifier of its parent field. After the server completes the writing, it returns the assigned real primary key identifier to the client.

[0071] In one possible implementation, server 22 is used to query the metadata table based on model_id to obtain all field records under the model; and to reconstruct the model definition object containing field types, identifiers, configuration parameters and a list of nested subfields by recursively traversing the parent_id in the field records. Client 21 is used to bind the corresponding fields to pre-registered UI components based on the field types in the model definition object; Client 21 is used to traverse the list of nested subfields in the model definition object through recursive components. If the subfield is a regular field node other than a combined field, it is rendered as an independent input block. If the subfield is a combination field, it is rendered as a collapsible block, and its subfields are nested and rendered inside the block until all levels of fields are rendered, so that the hierarchical structure of the form interface displayed by the client is completely matched with the tree structure of the model definition object assembled by the server.

[0072] In one possible implementation, server 22 is also used to recursively parse the form data corresponding to the combination field, and to serialize the parsed non-image data into JSON and store it, extract the parsed image data from the form data into an independent container, and write the image data into the media table in a unified manner. Server 22 is also used to synchronously store image data in a multilingual environment and locate the position of image data in the combination field structure through a unique identifier; Server 22 is also used to write the classification and association relationships of content data into different tables.

[0073] In one possible implementation, server 22 is also used to configure associated model fields in the content model to realize cross-model content references, and write the reference relationship between content into an independent content association table to support many-to-many associations and reverse queries.

[0074] This invention provides a content model construction and unified engine execution system. The client configures the fields of the content model through a visual interface, while the server constructs the fields into a tree-like field structure according to hierarchical relationships and stores this tree-like field structure as metadata in the database. This invention stores the content model structure as metadata, completely decoupling the model definition from the program code. Field configuration can be completed at runtime without modifying the code, fundamentally solving the problem of strong coupling between the model and code and the inability to dynamically configure them. The server reads metadata and assembles model definition objects based on the metadata. The client then recursively renders the form interface based on the model definition objects. The model definition objects are automatically reconstructed based on the metadata and recursively rendered. There is no need to write separate front-end templates for different content. It natively supports multi-level nested structures, ensuring that the form interface is strictly consistent with the model definition, and solving the problems of difficult nested expansion, template redundancy, and structural asynchrony. The server generates corresponding data validation rules based on the configuration parameters in the metadata, and validates the form data submitted by the client based on the data validation rules. The validation rules are dynamically generated by the configuration parameters, eliminating the need to write validation code separately for each model and each field, achieving unified validation logic across the platform, and eliminating the problems of duplicate code and inconsistent behavior. The server stores the validated form data into the main content table or the extended content table based on the field attributes in the metadata, and performs state management, soft deletion, and sorting on the content data. The main table / extended table is automatically split based on field attributes, and common functions such as state management, soft deletion, and sorting are implemented through a unified engine. This allows for full model reuse after a single development, solving the problems of fragmented common functions, non-standard storage, and high maintenance costs.

[0075] Figure 3 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. For example... Figure 3 As shown, the electronic device 3 of this embodiment includes a processor 30 and a memory 31. The memory 31 stores a computer program 32. When the processor 30 executes the computer program 32, it implements the steps in the various method embodiments described above. Alternatively, when the processor 30 executes the computer program 32, it implements the functions of each module / unit in the various device embodiments described above.

[0076] For example, computer program 32 may be divided into one or more modules / units, which are stored in memory 31 and executed by processor 30 to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 32 in electronic device 3.

[0077] Electronic device 3 may include, but is not limited to, processor 30 and memory 31. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 3 may also include input / output devices, network access devices, buses, etc.

[0078] The processor 30 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0079] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. Furthermore, the memory 31 can include both internal and external storage units of the electronic device 3. The memory 31 is used to store the computer program 32 and other programs and data required by the electronic device 3. The memory 31 can also be used to temporarily store data that has been output or will be output.

[0080] For the sake of simplicity and clarity, only the above-described functional modules / units are used as examples. In practical applications, the functions described above can be assigned to different functional modules / units as needed. These modules / units can be implemented in hardware, software, or a combination of both.

[0081] This invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the methods described in the above-described method embodiments.

[0082] This invention also provides a computer program product, including a computer program. When the computer program is executed by a processor, it implements the methods described in the above-described method embodiments.

[0083] Computer programs include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0084] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not detailed or described in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Unless otherwise specified or in conflict with logic, the terminology and / or descriptions between different embodiments are consistent and can be referenced interchangeably. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0085] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for content model construction and unified engine execution, characterized in that, include: The client configures the fields of the content model through a visual interface, and the server constructs the fields into a tree field structure according to the hierarchical relationship, and stores the tree field structure as metadata in the database; The server reads the metadata and assembles a model definition object based on the metadata. The client recursively renders the form interface based on the model definition object. The server generates corresponding data validation rules based on the configuration parameters in the metadata, and validates the form data submitted by the client based on the data validation rules. The server stores the validated form data into the main content table or the extended content table according to the field attributes in the metadata, and performs status management, soft deletion and sorting processing on the content data.

2. The content model construction and unified engine execution method according to claim 1, characterized in that, Also includes: When the content model changes, the server updates the metadata in the database. The server and the client load the corresponding model structure at runtime based on the updated metadata, thus achieving non-intrusive model evolution.

3. The content model construction and unified engine execution method according to claim 1, characterized in that, The client pre-configures atomic field types: text, editor, image, select, and combination. The combination field is a container field that supports nested subfields and is used to implement multi-level grouping structures. The visualization interface includes: a field tree display area on the left and a field type display area on the right; the field tree display area on the left displays clickable field node buttons, which are used to render all field nodes configured under the current model in the form of a recursive list; the field type display area on the right displays clickable field type buttons.

4. The content model construction and unified engine execution method according to claim 3, characterized in that, The client configures the fields of the content model through a visual interface. The server constructs the fields into a tree-like field structure according to their hierarchical relationship and stores the tree-like field structure as metadata in the database, including: Determine the context parent node based on the field node selected by the user or the default settings; Receive the field type clicked by the user, and generate a temporary field object through a pop-up configuration based on the context parent node and the field type; Upon receiving confirmation from the user, the client serializes the temporary field object into JSON data and submits it to the server. The server establishes a parent-child hierarchy mapping relationship for the fields based on the JSON data and writes the field records into the metadata table; After the client refreshes the page, the server reconstructs the tree field structure based on the metadata table and returns it to the client, which then recursively renders the tree field structure.

5. The content model construction and unified engine execution method according to claim 4, characterized in that, The client serializes the temporary field object into JSON data and submits it to the server, including: The client serializes the temporary field object into JSON data and submits it to the server along with the content model identifier model_id and the parent field identifier parent_id as a field configuration request; The server establishes a parent-child hierarchy mapping relationship for the fields based on the JSON data and writes the field records into the metadata table, including: After receiving the field configuration request, the server extracts the parent_id; If the parent_id is 0, then set the parent_id of the corresponding field record in the database metadata table to 0; If the parent_id is not empty, then the value of the parent_id is assigned to the parent_id record of the corresponding field in the metadata table; The server writes the field records into the metadata table. Each field record in the metadata table stores the definition information of a field. The field is associated with the content model through model_id and the field hierarchy is identified by parent_id. Parent_id=0 indicates that the field is a top-level field, and parent_id greater than 0 points to the identifier of its parent field. After the server completes the writing, it returns the assigned real primary key identifier to the client.

6. The content model construction and unified engine execution method according to claim 5, characterized in that, The server reads the metadata and assembles a model definition object based on the metadata. The client recursively renders the form interface based on the model definition object, including: The server queries the metadata table based on the model_id to obtain all field records under the model; By recursively traversing the parent_id records in the field records, a model definition object containing field types, identifiers, configuration parameters, and a list of nested subfields is reconstructed. The client binds the corresponding fields to the pre-registered user interface (UI) components according to the field types in the model definition object; The client traverses the list of nested subfields in the model definition object through a recursive component. If the subfield is a regular field node other than a combined field, it is rendered as an independent input block. If the subfield is a combination field, it is rendered as a collapsible block, and its subfields are nested and rendered inside the block, until the rendering of all levels of fields is completed, so that the hierarchical structure of the form interface displayed by the client is completely matched with the tree structure of the model definition object assembled by the server.

7. The content model construction and unified engine execution method according to claim 6, characterized in that, Before the server performs status management, soft deletion, and sorting on the content data, it also includes: The form data corresponding to the combination field is recursively parsed, and the non-image data obtained by parsing is serialized into JSON and stored. The image data obtained by parsing is extracted from the form data into an independent container and written into the media table. The server synchronously stores the image data in a multilingual environment and locates the position of the image data in the combination field structure using a unique identifier; The server writes the classification and association relationships of the content data into different tables.

8. The content model construction and unified engine execution method according to claim 5, characterized in that, Also includes: The server configures associated model fields in the content model to enable cross-model content referencing, and writes the reference relationships between content into an independent content association table to support many-to-many associations and reverse queries.

9. A content model construction and unified engine execution system, characterized in that, include: The client-side component is used by clients to configure fields of the content model through a visual interface. The server-side component is used to construct the fields into a tree-like field structure according to their hierarchical relationship, and to store the tree-like field structure as metadata in the database. The server is also used to read the metadata and assemble a model definition object based on the metadata; The client is also used to recursively render the form interface according to the model definition object; The server is also used to generate corresponding data verification rules based on the configuration parameters in the metadata, and to verify the form data submitted by the client based on the data verification rules; and to store the verified form data into the main content table or the extended content table according to the field attributes in the metadata, and to perform status management, soft deletion and sorting processing on the content data.

10. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 8.

Images