A low-code page non-rendering style completion method and system

Abstract

The application relates to the technical field of software engineering and low-code platform, in particular to a low-code page non-rendering style completion method and system, wherein a lightweight DOM context is pre-registered in a server computing node, a low-code editor instance is initialized under a non-browser rendering process, material definitions are registered, and page data is loaded; subsequently, a component tree is recursively traversed in a parent-first-child mode, version migration, Schema analysis, dynamic CSS rule idempotent update, static style node mounting, parent-child Schema injection propagation and content template refreshing are sequentially performed on components with material identifiers; after the traversal is completed, page Schema is exported and cleaned, and complete page data that can be stored in a database and published is obtained. The application can complete a missing style generation link in a native non-rendering mode, and improve the consistency of a server page generation result and a browser editor end result.

Description

[Technical Field] This invention relates to the fields of software engineering and low-code platform technology, and in particular to a method and system for completing low-code page styles without rendering. [Background Technology] Low-code platforms typically build pages using visual editors. Taking GrapesJS-based low-code visual editors as an example, the final style data for page components usually includes two types of content: dynamic CSS rules and static CSS nodes.

[0001] Dynamic CSS rules are typically generated from component configuration parameters. After the user adjusts the component configuration parameters in the editor, the editor reads the style transformation rules declared in the material's Formal Schema, converts the configuration values ​​in `settingsValue` into CSS properties and values, and then writes them into the `CssComposer` rule set. For responsive configurations, the editor also needs to generate CSS rules with media query conditions based on different device types such as desktop and mobile. For complex materials, CSS rules may also be bound to selectors specified inside the component, rather than simply to the component's own identifier.

[0002] Static CSS nodes are typically generated during the material registration phase or the component lifecycle phase. Materials can create callbacks through static styles by attaching the material's inherent style tag under the component-style-tags container node in the component tree, thus including the material's basic CSS class definition in the page data.

[0003] On the browser editor side, the aforementioned dynamic and static styles can be implemented using the browser DOM environment, rendered view objects, and component lifecycle logic. However, in a server-side environment without browser rendering, the existing solution still has the following problems: First, when using headless browser solutions such as Headless Chrome or Puppeteer, a full browser process needs to be launched. While this method provides a browser runtime environment, it consumes a lot of resources per instance, limits concurrent processing capabilities, and has high deployment complexity, making it unsuitable for lightweight CI / CD pipeline integration. Furthermore, this method may still fail to fully trigger custom links related to version migration and parent-child component style injection in the low-code platform's material system.

[0004] Secondly, when using a manual maintenance approach for server-side style generation code, a separate set of logic for converting `settingsValue` to CSS rules needs to be implemented on the server side. Due to the large number of low-code materials and frequent iterations, the server-side code must continuously synchronize the material's Formal Schema with the browser editor's style conversion logic; otherwise, missing or inconsistent styles are likely to occur. For complex scenarios such as parent-child component style inheritance, responsive field expansion, and material version migration, manual maintenance makes it difficult to reliably reproduce editor-side behavior.

[0005] Third, while using GrapesJS's native headless mode avoids launching the browser process, the render process is skipped when loading existing ProjectData, and the view object doesn't exist. This causes some style generation branches that depend on the view object or component lifecycle to be silently skipped. For example, the chain of updateStyles, addMaterielStaticStyle, handleVersionUpdate, and applyComponentUpdated cannot be executed completely in the browser-side manner, which may ultimately result in an empty exported schema.styles, missing static style nodes, or systematic differences from the output of the browser editor. [Summary of the Invention] To overcome the above problems, this invention proposes a low-code page style completion method and system that can effectively solve the above problems.

[0006] The present invention provides a technical solution to the above-mentioned technical problems: a low-code page style completion method without rendering, applied to server computing nodes, the method comprising: Step S1: Obtain the low-code page data to be completed. The low-code page data includes component tree data and material identifier, version information and configuration parameters of at least one component. Step S2: Before the low-code editor kernel is loaded, a lightweight DOM context is registered in the server computing node, so that the server computing node obtains the document object and window object for component registration and component lifecycle related logic calls; Step S3: Initialize the low-code editor instance in no-rendering mode, and register the material definitions in the same material registration order as the browser editor. The material definitions include at least the material form description information, component type definition, component default attributes, material target version information, static style generation information, and component lifecycle hooks. Step S4: Load the low-code page data into the component manager of the low-code editor instance to form a component tree memory structure; Step S5: Perform a recursive style compensation traversal on the component tree memory structure according to the order of parent components before child components; when the target component with a material identifier is encountered, perform the following compensation processing in sequence: Step S51: Compare the current version information of the target component with the target version information in the corresponding material definition; if the two are inconsistent, perform material version migration processing before the style rule is generated, so that the configuration parameters of the target component are converted into a data structure that matches the target version information. Step S52: Read the form description information of the corresponding material according to the material identifier of the target component, merge the form description information with the extended form description information received by the target component, parse the field path, style conversion function, responsive tag and selector tag used for style generation, and establish the style mapping table of the target component; Step S53: Generate dynamic CSS rules based on the migrated configuration parameters and the style mapping table, and perform add or overwrite updates on the dynamic CSS rules according to the rule unique key composed of component identifier, field path, device type, media query conditions and target selector, so as to write them into the CSS rule manager of the low code editor instance. Step S54: Based on the static style generation information of the material corresponding to the target component, find or create a style node corresponding to the material in the static style container node of the component tree memory structure, and write the inherent CSS content of the material into the style node; Step S55: Trigger the component update logic of the target component, inject the form extension configuration declared by the parent component into the corresponding child component, so that the child component rebuilds the style mapping table based on the injected form extension configuration, and performs addition or overwrite update on the dynamic CSS rules of the child component with the rule unique key; Step S56: When the material corresponding to the target component has a content template, refresh the DOM attributes, text content or sub-component template inside the target component according to the configuration parameters of the target component; Step S57: Continue executing steps S51 to S56 on the sub-components of the target component until the complete component tree memory structure is traversed. Step S6: After completing the recursive style compensation traversal, export the page schema data, and extract runtime internal attributes, versioned runtime attributes, and runtime DOM attributes from the page schema data to obtain the low-code page data after style completion.

[0007] Preferably, the low-code page data in step S1 includes a component configuration tree generated by a large language model, or serialized data of existing low-code pages; the configuration parameters include at least one of the component's style parameters, content parameters, behavior parameters, and responsive parameters.

[0008] Preferably, the lightweight DOM context in step S2 is provided by a DOM simulation library, including happy-dom or jsdom; the lightweight DOM context only provides the DOM interface required for component registration and style compensation, without starting the browser rendering process.

[0009] Preferably, the low-code editor instance is a GrapesJS editor instance, the no-rendering mode is headless mode, the component manager is DomComponents, the CSS rule manager is CssComposer, and the low-code page data is ProjectData.

[0010] Preferably, the material definition in step S3 includes a Block definition and a ComponentType definition; the Block definition includes a material identifier, a material content definition, a material target version information, a material form description information, and static style generation information; the ComponentType definition includes component default attributes, an initialization hook, an update hook, and content template refresh logic.

[0011] Preferably, the material version migration process in step S51 includes at least one of renaming the configuration parameter field path, converting the configuration parameter data format, completing the old version default value, and updating the component version information; the configuration parameter data format conversion includes converting the numerical configuration value into an object-type configuration value that contains both numerical value and unit.

[0012] Preferably, the material form description information in step S52 is a Formal Schema, which declares the extended properties x-datatransform, x-responsive, and x-selector; wherein, x-datatransform is used to declare the conversion relationship between configuration parameters and CSS properties, x-responsive is used to declare whether the configuration parameters generate responsive styles according to the device type, and x-selector is used to declare the target selector for CSS rule binding.

[0013] Preferably, step S53 includes: When the target field is marked as a responsive field and its value includes both desktop and mobile values, the corresponding style conversion function is called according to the desktop and mobile values ​​respectively to generate independent CSS rules with media query conditions; When the target field is configured with a selector tag, the generated CSS rules are bound to the CSS selector corresponding to the selector tag; When a target field is marked as a responsive field but its value is a flat format that is not device-grouped, the target field is downgraded to a global style field to generate CSS rules that are not device-specific.

[0014] Preferably, the rule unique key in step S53 includes at least five of the following: component unique identifier, material identifier, field path, device type, media query condition, target selector, and CSS property name; when there is an existing rule in the CSS rule manager that corresponds to the rule unique key, the existing rule is updated; when there is no corresponding rule, a new CSS rule is added.

[0015] Preferably, the static style generation information in step S54 includes a static style content hash and a static style creation callback; when searching for or creating a style node in the static style container node, deduplication is performed according to the static style content hash. If a corresponding style node already exists, the style node is reused; if no corresponding style node exists, a new style tag node is created.

[0016] Preferably, step S55 includes: Read the child component's form override configuration from the parent component's default properties; Locate the target child component among the descendant components of the parent component based on the child component type identifier or component role attribute; Write extended form description information to the target sub-component; In response to changes in the extended form description information, the target sub-component is triggered to re-parse the form description information, rebuild the style mapping table, and update the dynamic CSS rules based on the rebuilt style mapping table.

[0017] Preferably, the content template refresh in step S56 includes at least one of refreshing the tab text of the tab component, refreshing the number of slides of the carousel component, refreshing the image item structure of the image gallery component, and refreshing the runtime DOM properties of the component.

[0018] Preferably, the runtime internal properties stripped in step S6 include at least one of formalilySchema, schemaValues, defaultValues, extraFormily, componentProps, defaultSettings, and componentsTemplate; the versioned runtime properties stripped include at least one of copyable, removable, draggable, droppable, highlightable, selectable, editable, and badgable; and the runtime DOM properties stripped include at least one of ljs-text, data-panel, on:mounted, and glyph.

[0019] Preferably, after step S6, the method further includes: performing a normalization comparison between the style-completed low-code page data and the browser editor's baseline page schema data; the normalization comparison includes component random identifier normalization, namespace hash normalization, CSS rule array sorting, and CSS selector placeholder replacement, and outputting the first difference path during field-level in-depth comparison.

[0020] This invention also provides a low-code page style completion system without rendering, comprising: The data acquisition module is used to acquire the low-code page data to be completed; The DOM context pre-registration module is used to register a lightweight DOM context in the server compute node before the low-code editor kernel is loaded. The material registration and data loading module is used to initialize the low-code editor instance in no-rendering mode, register the material definition, and load the low-code page data into the component manager of the low-code editor instance. The style compensation traversal module is used to perform recursive style compensation traversal on the component tree memory structure in the order of parent components before child components, and to perform version migration, form description information parsing, dynamic CSS rule idempotent update, static style node mounting, parent and child component style schema injection and propagation, and content template refresh for target components with material identifiers in sequence. The Schema Export and Cleaning module is used to export page schema data and remove runtime internal attributes, versioned runtime attributes, and runtime DOM attributes to obtain low-code page data with style completion.

[0021] Preferably, the style compensation traversal module includes: The version migration unit is used to perform material version migration processing before style rules are generated when the current version information of a component is inconsistent with the target version information of the material. The schema parsing unit is used to merge the material form description information with the extended form description information received by the component, and extract the field paths, style transformation functions, responsive tags and selector tags required for style generation; The dynamic style update unit is used to generate dynamic CSS rules based on component configuration parameters and style mapping tables, and to perform addition or overwrite updates on dynamic CSS rules based on the rule's unique key; The static style mounting unit is used to find or create style nodes based on the static style content hash and write the inherent CSS content of the material. The parent-child injection propagation unit is used to inject the form extension configuration declared by the parent component into the child component and trigger the child component to regenerate dynamic CSS rules. The template refresh unit is used to refresh the DOM properties, text content, or child component templates of a component based on the component's configuration parameters.

[0022] The present invention also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements the low-code page no-rendering style completion method.

[0023] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the low-code page no-rendering style completion method.

[0024] Compared with the prior art, the low-code page no-rendering style completion method and system of the present invention have the following beneficial effects: 1. This invention pre-registers a lightweight DOM context before the low-code editor kernel is loaded, enabling server computing nodes to execute component registration and style compensation logic without starting the browser process, significantly reducing server resource consumption.

[0025] 2. This invention reuses the material definition, formal schema, style conversion function and component lifecycle hooks on the browser editor side, eliminating the need for manual maintenance of another set of server-side style generation logic, thus reducing maintenance costs and style inconsistency risks caused by material iteration.

[0026] 3. This invention places the material version migration before the dynamic CSS rule generation, so that the style rule generation is based on the migration configuration parameters, avoiding style result errors caused by old version fields or old data formats.

[0027] 4. This invention uses a unique rule key to add or overwrite dynamic CSS rules, which can avoid duplicate CSS rule writing caused by extraformally changes, version migration recalculations, or multiple rounds of traversal, thus ensuring the stability of the schema.styles structure.

[0028] 5. This invention, through recursive style compensation traversal, can simultaneously complete dynamic CSS rules, static style nodes, material version migration results, parent-child component schema injection results, and content template refresh results, avoiding the problem of empty style rules or missing static styles in the native no-rendering mode.

[0029] 6. This invention supports degradation processing for responsive style fields, target selector bound fields, and flat format responsive fields, which can cover complex style generation scenarios commonly found in low-code materials.

[0030] 7. This invention can be used for automated style completion after AI generates low-code page data, so that the component structure data output by the large language model can be completed before entering the page publishing process.

[0031] 8. This invention can be used for schema regression testing in CI / CD pipelines to automatically verify the style integrity of existing pages after low-code material iteration.

[0032] In one test scenario, after excluding component random identification, namespace hashing, and differences in CSS rule sorting, the number and content of schema.styles rules output by the server are consistent with the baseline results on the browser editor side; the average processing time per page is about 4 seconds; compared with the Headless Chrome solution, server memory usage is reduced by about 60%; compared with manual field-by-field verification, the manual cost of style verification is reduced by about 80%. [Attached Image Description] Figure 1 This is the overall flowchart of the low-code page style completion method of the present invention.

Detailed Implementation Methods

[0033] It should be noted that in the embodiments of the present invention, all directional indications (such as up, down, left, right, front, back, etc.) are limited to relative positions on the specified view, rather than absolute positions.

[0034] Furthermore, in this invention, descriptions involving "first," "second," etc., are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0035] Please see Figure 1 The technical problem to be solved by the present invention is to provide a method and system for completing low-code page styles without rendering, which enables the server computing node to perform style generation, static style mounting, material version migration, parent and child component style schema injection and propagation, and content template refresh of low-code page components without starting the full browser rendering process, thereby obtaining low-code page data that can be stored in the database, published, and whose style results are consistent with those of the browser editor.

[0036] To solve the above-mentioned technical problems, the present invention adopts the following technical solution.

[0037] A low-code, non-rendering style completion method for web pages, applied to server compute nodes, includes the following steps.

[0038] Step 1: Obtain the low-code page data to be completed.

[0039] The low-code page data can be a component configuration tree generated by a large language model based on the user's page description, or it can be serialized data of existing low-code pages. The low-code page data includes at least component tree data, component type or material identifier, current component version information, component configuration parameters, and necessary page hierarchy relationships. Component configuration parameters may include style parameters, content parameters, behavior parameters, and responsive parameters.

[0040] Step two: Perform DOM context pre-registration.

[0041] Before the low-code editor kernel loads, a lightweight DOM context is registered in the server compute node. This lightweight DOM context provides the `document` and `window` objects required for low-code editor component registration and the execution of component lifecycle-related logic. This DOM context can be provided by happy-dom, jsdom, or other lightweight DOM simulation libraries compatible with the DOM interface.

[0042] By pre-registering the DOM context before the low-code editor's kernel loads, exceptions due to missing document or window objects during component registration can be avoided, and there is no need to start a full browser process such as Headless Chrome.

[0043] Step 3: Perform material registration and initialize the no-rendering mode.

[0044] The server compute node initializes the low-code editor instance in headless mode. For the GrapesJS editor kernel, headless mode can be used for initialization.

[0045] After initialization, register the material definitions in the same order as in the browser editor. The material definitions include, but are not limited to: Block definition includes material identifier, material content definition, material target version information, material default configuration and material form description information; The ComponentType definition includes the component's default properties, initialization hooks, update hooks, and internal component processing logic; Material form description information, including configuration parameter fields, field paths, field default values, and extended attributes; Static style generation information, including static style creation callbacks and static style content hashes; Content template information, including the component's internal DOM structure, text content template, and child component template.

[0046] Step 4: Load page data and build the component tree memory structure.

[0047] The low-code page data to be completed is loaded into the low-code editor instance, enabling the component manager of the low-code editor instance to establish a complete component tree memory structure. This component tree memory structure preserves the parent-child hierarchy, component type, material identifier, configuration parameters, version information, and default properties of each component in the page.

[0048] Step 5: Perform a recursive pattern compensation traversal.

[0049] After the page data is loaded, a recursive traversal of the component tree memory structure is performed, starting with the parent component and ending with the child component. For each component encountered during the traversal, if the component has a material identifier, it is identified as the target component, and the following compensation process is performed on it.

[0050] The first step is to determine the version status and migrate the material version.

[0051] Read the current version information of the target component and the target version information in the corresponding material definition. If they are inconsistent, execute the material custom version migration logic before the dynamic CSS rules are generated; if they are consistent, skip the version migration logic.

[0052] Version migration logic can include renaming configuration parameter field paths, ensuring compatibility with old fields, completing default values, converting configuration parameter data formats, and updating component version information. For example, numeric width parameters in the old version can be converted to object parameters containing both numbers and units, and flat fields in the old version can be migrated to nested fields in the new version. By prioritizing version migration, it ensures that subsequent schema parsing and dynamic CSS rule generation are based on the migrated configuration parameters, avoiding style errors caused by generating styles based on old fields first and then migrating the configuration.

[0053] The second step is to parse the Formic Schema and rebuild the CSS mapping.

[0054] The Formal Schema of the corresponding material is read from the material registry based on the material identifier of the target component. If the target component has received extraFormily extended form description information injected by the parent component, the original Formally Schema of the material is merged with the extraFormily to obtain the actual form description structure of the target component.

[0055] Subsequently, the actual form description structure is parsed in a structured manner, extracting field paths containing extended attributes such as x-datatransform, x-responsive, and x-selector, and establishing a style mapping table. The style mapping table includes at least field paths, current field values, style transformation functions, responsive tags, target CSS selectors, and default degradation rules.

[0056] The third step is dynamic CSS rule generation and idempotent updates.

[0057] Dynamic CSS rules are generated based on the migrated configuration parameters and style map.

[0058] For fields configured with x-datatransform, the corresponding style transformation function is called based on the current value of the field to convert the configuration parameters into CSS properties and values.

[0059] For fields configured with `x-responsive` and whose values ​​include Desktop and Mobile device groups, corresponding CSS rules are generated based on the Desktop and Mobile values ​​respectively, and appropriate media query conditions are added for different device types. For example, a minimum width media query condition can be generated for desktop styles, and a maximum width media query condition can be generated for mobile styles.

[0060] For fields configured with x-selector, the generated CSS rules are bound to the target selector specified by x-selector. This target selector can be a selector of child elements within a component, a role attribute selector, or a combinatorial selector.

[0061] For fields marked as responsive but actually having flat values, they are automatically downgraded to global style fields, thereby generating device-insensitive CSS rules and avoiding style loss due to incomplete data format.

[0062] After generating dynamic CSS rules, a unique rule key is established based on the component's unique identifier, material identifier, field path, device type, media query conditions, target selector, and CSS property name. If a rule corresponding to this unique rule key already exists in the CSS rule manager, the existing rule is overwritten and updated; otherwise, a new rule is created. This unique rule key mechanism avoids duplicate CSS rule writing caused by recalculation after version migration, recalculation after extraFormal changes, or multiple rounds of compensation traversal, thus maintaining the stability of the schema.styles structure.

[0063] The fourth step is to mount static style nodes.

[0064] Based on the static style information of the material corresponding to the target component, the static style of the material is mounted under the static style container node in the component tree memory structure.

[0065] Specifically, the corresponding style tag node is searched in the static style container node based on the hash of the material's static style content. If the corresponding node already exists, it is reused to avoid writing the same static style repeatedly; if the corresponding node does not exist, a new style tag node is created, and the inherent CSS content returned by the material's static style creation callback is written to the style tag node.

[0066] This process ensures that page data exported from a server-side, non-rendering environment also includes the material's inherent CSS class definitions and basic style nodes.

[0067] Step 5: Inject and propagate style schemas from parent and child components.

[0068] Trigger the component update logic of the target component, enabling the parent component's style schema extension for the child component to take effect in a non-rendering environment.

[0069] For components that inherit from container-type materials, the parent component can declare form override configurations for child component types in its default properties. When the target component executes update logic, it reads this form override configuration and searches for matching child components among its descendant components. The search can be based on the child component type identifier, or on component role attributes, component path indexes, or pre-built indexes in the component tree.

[0070] After locating the target child component, the form override configuration declared by the parent component is written to the child component as extraFormily. Upon detecting changes to extraFormily, the child component re-parses the Formal Schema, rebuilds the style mapping table, and regenerates or overrides dynamic CSS rules according to the rule's unique key. Therefore, the injection of reactive tags, selector tags, and style transformation rules from the parent component to the child component can be fully propagated in a server-side, non-rendering environment without causing duplicate rule accumulation.

[0071] Step 6: Refresh the content template.

[0072] If a content template exists in the material definition corresponding to the target component, then the component's internal DOM attributes, text content, or number of child components will be refreshed according to the target component's current configuration parameters. For example, for a tab component, the tab text can be refreshed according to the configuration parameters; for a carousel component, the number of slides can be refreshed according to the configuration parameters; and for an image gallery component, the gallery item structure and corresponding text attributes can be refreshed according to the configuration parameters.

[0073] After completing the compensation process described above for the target component, the same process is recursively applied to the list of child components of the target component until the entire component tree memory structure is traversed. Since the traversal order is parent component before child component, the extraFormal injected by the parent component into the child component can take effect before the final style of the child component is generated.

[0074] Step 6: Export the schema and separate runtime attributes.

[0075] After completing the recursive style compensation traversal, the page data export logic is invoked to export the page schema data. Since some runtime auxiliary attributes are generated during the no-rendering completion process, the exported page schema data needs to be cleaned to ensure that the final page data is suitable for storage and deployment.

[0076] The cleaning process includes stripping runtime internal attributes, stripping versioned runtime attributes, stripping runtime DOM attributes, and cleaning up attributes of special wrapper nodes.

[0077] The runtime internal properties include formallySchema, schemaValues, defaultValues, extraFormily, componentProps, defaultSettings, and componentsTemplate.

[0078] The versioned runtime attributes include behavioral attributes such as copyable, removable, draggable, droppable, highlightable, selectable, editable, and badgable, which are dynamically calculated by the component initialization logic.

[0079] The runtime DOM properties include properties such as ljs-text, data-panel, on:mounted, and glyph, which are written by the content template refresh logic but should not be retained as persistent page schemas.

[0080] For Wrapper nodes, the stylable property can also be stripped to avoid the wrapper layer persisting unnecessary runtime style configurations.

[0081] After the above processing, complete low-code page data that can be stored in a database and published is output. The complete low-code page data includes component tree data, dynamic CSS rules, and necessary static style nodes.

[0082] Specifically, this embodiment provides a low-code page style completion method without rendering. This method runs on a server computing node, which can be a Node.js service process, a CI / CD pipeline execution node, an offline page generation service node, or a page pre-deployment verification node.

[0083] In this embodiment, the low-code editor kernel uses GrapesJS, the material form description information uses FormicySchema, the CSS rule manager uses CssComposer within GrapesJS, and the DOM simulation library uses happy-dom. It should be noted that GrapesJS, Formicy Schema, CssComposer, and happy-dom are specific implementation choices in this embodiment. In other embodiments, a low-code editor kernel, form description protocol, CSS rule manager, and DOM simulation library with similar functionality can be used.

[0084] The server compute nodes first receive the page data to be processed. This page data can originate from the output of the large language model. For example, if the user inputs the page description "generate a three-column image gallery with shadow effects," the large language model outputs page structure data containing gallery components, image item components, configuration parameters, and hierarchical relationships. This page structure data typically includes component types and configuration parameters, but may not necessarily include a complete set of CSS rules and static style nodes for materials.

[0085] The server compute nodes convert the page structure data output from the large language model into a page data skeleton that can be recognized by a low-code editor. This page data skeleton includes the page root node, component tree, component material identifiers, component configuration parameters, default values ​​for reactive fields, and default configurations for the root component. During the conversion process, reactive fields in `settingsValue` can be normalized, and default values ​​for the root component can be merged.

[0086] Subsequently, the server compute nodes register the `document` and `window` objects provided by `happy-dom` before loading the relevant GrapesJS modules. Once registered, the GrapesJS component registration phase can access necessary DOM interfaces, thus preventing component registration failure due to the absence of a browser environment.

[0087] Next, the server compute node initializes the GrapesJS editor instance in headless mode. After initialization, all materials are registered in the same order as in the browser editor. Material registration includes registering Block definitions and ComponentType definitions. The Block definition includes the material identifier, material content definition, material target version information, Formal Schema, and static style generation information; the ComponentType definition includes the component's default properties, initialization hooks, update hooks, and component internal template refresh logic.

[0088] The server compute node loads the page data skeleton into the GrapesJS editor instance, enabling GrapesJS's DomComponents to establish a complete component tree memory structure. This component tree memory structure contains a gallery component and three image item sub-components. Each image item component has a corresponding material identifier, version information, and configuration parameters.

[0089] After the page data is loaded, the server compute node performs a recursive style compensation traversal.

[0090] For the gallery component, the server compute node reads its material identifier and version information, and retrieves the corresponding target version information of the material from the material registry. If the current version of the gallery component is lower than the target version of the material, field migration, default value completion, and data format conversion are performed first, followed by subsequent style processing.

[0091] For each image item component, the server compute node also first performs a version status check. If an old version of the shadow field or width field exists, it is migrated to a data structure that the target version of the Formily Schema can recognize.

[0092] After the version migration is complete, the server compute node reads the formal schema of the image item component and extracts the field paths used for shadow style generation. If the field declares `x-datatransform`, the corresponding style transformation function is called according to the image item component's configuration parameters to convert the shadow configuration into the `box-shadow` style attribute. If the field also declares `x-responsive`, and the configuration parameters include both desktop and mobile values, then desktop and mobile media query rules are generated respectively.

[0093] For the three image item components, corresponding desktop and mobile shadow rules can be generated separately. Each rule has a unique key formed by the component identifier, field path, device type, media query conditions, and target selector. For example, the desktop and mobile shadow rules for the same image item component will have different unique keys due to differences in device type and media query conditions; when the same field is calculated repeatedly, the original rule will be updated based on the same unique key.

[0094] If the image item component corresponds to a material with inherent CSS content, the server compute node searches for the corresponding style tag node under the component-style-tags container node in the component tree based on the hash of the material's static style content. If not found, the style tag node is created and the material's inherent CSS content is written into it; if found, the existing style tag node is reused.

[0095] For child component form override configurations declared by the parent component, the server compute node triggers the parent component's update logic. It reads the required child component schema extensions from the parent component's configuration and locates the corresponding child component in the descendant components. After locating the child component, it writes the extended form description information to the child component, causing the child component to re-parse the schema and regenerate or override the style rules according to the unique key.

[0096] If the gallery component or image item component has a content template, the server compute node refreshes its internal DOM properties and text content based on the current configuration parameters. For example, the internal image item structure is refreshed based on the number of image items, and the text node content is refreshed based on the image title configuration.

[0097] After the recursive traversal is complete, the server compute node exports the page schema data. The exported data includes component tree data and dynamic CSS rule arrays, as well as static style container nodes and their style tag content.

[0098] The server compute nodes clean the exported page schema data. During cleaning, runtime internal properties such as formallySchema, schemaValues, defaultValues, extraFormily, componentProps, defaultSettings, and componentsTemplate are removed; runtime behavioral properties such as copyable, removable, draggable, droppable, highlightable, selectable, editable, and badgable are removed; runtime DOM properties such as ljs-text, data-panel, on:mounted, and glyph are removed; and the stylable property is removed from the Wrapper node.

[0099] After cleaning, complete low-code page data that can be stored in the database and published is obtained. Taking a three-column image gallery as an example, in one output result, the three gallery-items generate a total of six box-shadow rules based on Desktop and Mobile values, respectively. These six rules correspond to the shadow styles of the three image item components on desktop and mobile devices. Because idempotent updates are performed using unique rule keys, even if the parent component injects extraFormal and triggers a recalculation in the child component, existing rules will be overwritten and updated without being duplicated.

[0100] In another embodiment, a schema regression testing method for CI / CD pipelines is provided, which is based on the low-code page no-rendering style completion method described above.

[0101] After a material iteration, the low-code platform needs to verify whether the new material causes any destructive changes to existing pages. The server compute nodes pre-store multiple test cases, each including input page data and baseline page schema data exported from the browser editor.

[0102] After the CI / CD pipeline is triggered, the server compute node performs the following processing for each test case: First, read the input page data from the test case.

[0103] Second, execute the no-rendering style completion method to regenerate the output page schema data.

[0104] Third, normalization processing is performed on both the output page schema data and the baseline page schema data. Normalization processing includes component random ID normalization, namespace hash normalization, CSS rule array sorting, CSS selector placeholder replacement, and removal of irrelevant runtime attributes.

[0105] Fourth, perform a field-level in-depth comparison between the normalized output page schema data and the baseline page schema data. If a difference is found, output the first difference path, the difference field value, and the name of the corresponding test case; if no difference is found, the test case is considered to have passed.

[0106] In one test scenario, test cases included material pages such as buttons, carousels, galleries, and tabs. After processing, the output page schema of each test case was consistent with the baseline schema on the browser editor after normalization. The test results showed that twenty-three tests passed. This test result demonstrates that the present invention can automatically verify the style integrity of existing pages after low-code material iteration.

[0107] Another embodiment of the present invention provides a low-code page style completion system without rendering. The system includes a data acquisition module, a DOM context pre-registration module, a material registration and data loading module, a style compensation traversal module, a schema export and cleaning module, and an optional regression testing module.

[0108] The data acquisition module receives the low-code page data to be completed. This data can be page structure data generated by a large language model, or serialized data of existing pages.

[0109] The DOM context pre-registration module is used to register a lightweight DOM context before the low-code editor kernel loads, enabling server compute nodes to obtain the necessary document and window objects.

[0110] The material registration and data loading module is used to initialize the no-rendering editor instance, register material definitions, and load page data into the component manager, thereby forming a component tree memory structure.

[0111] The style compensation traversal module is used to perform a recursive traversal of the component tree memory structure, starting with the parent component and ending with the child component. This module includes a version migration unit, a schema parsing unit, a dynamic style update unit, a static style mounting unit, a parent-child injection propagation unit, and a template refresh unit.

[0112] The version migration unit is used to compare the current version information of the component with the target version information of the material, and performs version migration before style generation when the two are inconsistent.

[0113] The Schema parsing unit is used to read the material's Formal Schema and merge it with the ExtraFormal Schema received by the component, parsing to obtain field paths, style transformation functions, responsive tags, and selector tags.

[0114] The dynamic style update unit generates CSS rules based on component configuration parameters and style maps, and writes these rules to the CSS rule manager using their unique keys. It overwrites existing rules and adds new rules if none exist.

[0115] The static style mounting unit is used to find or create style tag nodes based on the static style content hash of the material, and write the inherent CSS content of the material.

[0116] The parent-child injection propagation unit is used to read the form override configuration declared by the parent component for the child component, locate the child component and write it to extraFormily, so that the child component can be regenerated or override the style rules.

[0117] The template refresh unit is used to refresh the component's internal DOM properties, text content, and child component template structure based on the component's configuration parameters.

[0118] The Schema export and cleaning module is used to export page schema data and strip away runtime internal attributes, versioned runtime attributes, and runtime DOM attributes to obtain complete page data that can be stored in a database and published.

[0119] The regression testing module is used to normalize and perform in-depth comparison of the output page schema data and the baseline page schema data in the editor, thereby determining whether the unrendered style completion results meet the release requirements.

[0120] Another embodiment of the present invention provides an electronic device. The electronic device includes a processor, a memory, and a computer program stored in the memory. When the computer program is executed by the processor, it implements the method described in Embodiment 1 or Embodiment 2.

[0121] The electronic device can be a server, a cloud computing node, a continuous integration execution node, a page publishing server, or a local development device.

[0122] Another embodiment of the present invention provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, it implements the method described in Embodiment 1 or Embodiment 2.

[0123] The computer-readable storage medium may be a disk, solid-state drive, flash memory, read-only memory, random access memory, removable storage medium, or cloud storage medium.

[0124] Terminology Explanation A no-rendering environment refers to a program runtime environment that does not start the browser's visual rendering engine, such as a server-side Node.js process.

[0125] The low-code editor kernel refers to the basic framework of a low-code editor used to build component trees, register component types, manage page schemas, and output page data.

[0126] GrapesJS is an open-source visual page builder framework, which is used as the kernel of a low-code editor in this embodiment of the invention.

[0127] CssComposer is a CSS rule manager in GrapesJS, used to store and output dynamic CSS rules.

[0128] Formily Schema is a form description structure used to describe material configuration items, field paths, default values, and extended attributes.

[0129] `settingsValue` is a collection of component configuration parameters, which can include style, content, and behavior configurations.

[0130] ProjectData is a serialized data structure for low-code pages, which can include component tree data and style rule sets.

[0131] blockId is the type identifier of the material component, used to locate the corresponding material definition in the material registry.

[0132] extraFormily is an extended configuration of form descriptions that a parent component injects into a child component.

[0133] happy-dom is a lightweight DOM simulation library used to provide document and window objects in a Node.js environment.

[0134] cssHash is a hash identifier for the static style content of materials, used for deduplication and positioning of static style nodes.

[0135] The rule unique key is an identifier used to determine whether a dynamic CSS rule corresponds to the same component, the same field, the same device type, the same media query condition, and the same target selector.

[0136] CI / CD stands for Continuous Integration and Continuous Deployment, used to automate testing, building, and deployment.

[0137] LLM stands for Large Language Model, which can be used to generate low-code page structure descriptions or component configuration data.

[0138] Without altering the core concept of this invention, the DOM simulation library can be replaced by happy-dom with jsdom or other lightweight DOM simulation libraries that can provide document and window interfaces.

[0139] The material version comparison method can be expanded from simple version number inconsistency judgment to semantic version number range judgment, and supports cross-version chain migration.

[0140] The method for locating parent and child components can be replaced by traversing and searching based on component type identifiers, or by quickly searching based on component role attributes, component path indexes, or pre-built indexes of the component tree.

[0141] When generating dynamic CSS rules, the device type is not limited to desktop and mobile devices, but can also be extended to tablet, widescreen, or custom breakpoint types.

[0142] The deduplication method for static style nodes is not limited to cssHash; it can also be a combination of material identifier, style content summary, material version number, and style content summary.

[0143] The unique key of a dynamic CSS rule is not limited to a combination of component identifier, field path, device type, media query conditions, and target selector, but may also include CSS property names, material version numbers, namespace identifiers, or style group identifiers.

[0144] Page schema cleaning strategies can be extended according to the persistence protocols of different low-code platforms. As long as their purpose is to strip away runtime auxiliary attributes and retain publishable page data, they are all equivalent implementations of this invention.

[0145] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any modifications, equivalent substitutions and improvements made within the concept of the present invention should be included within the patent protection scope of the present invention.

Claims

1. A low-code page style completion method without rendering, characterized in that, Applied to server computing nodes, the method includes: Step S1: Obtain the low-code page data to be completed. The low-code page data includes component tree data and material identifier, version information and configuration parameters of at least one component. Step S2: Before the low-code editor kernel is loaded, a lightweight DOM context is registered in the server computing node, so that the server computing node obtains the document object and window object for component registration and component lifecycle related logic calls; Step S3: Initialize the low-code editor instance in no-rendering mode, and register the material definitions in the same material registration order as the browser editor. The material definitions include at least the material form description information, component type definition, component default attributes, material target version information, static style generation information, and component lifecycle hooks. Step S4: Load the low-code page data into the component manager of the low-code editor instance to form a component tree memory structure; Step S5: Perform a recursive style compensation traversal on the component tree memory structure according to the order of parent components before child components; when the target component with a material identifier is encountered, perform the following compensation processing in sequence: Step S51: Compare the current version information of the target component with the target version information in the corresponding material definition; if the two are inconsistent, perform material version migration processing before the style rule is generated, so that the configuration parameters of the target component are converted into a data structure that matches the target version information. Step S52: Read the form description information of the corresponding material according to the material identifier of the target component, merge the form description information with the extended form description information received by the target component, parse the field path, style conversion function, responsive tag and selector tag used for style generation, and establish the style mapping table of the target component; Step S53: Generate dynamic CSS rules based on the migrated configuration parameters and the style mapping table, and perform add or overwrite updates on the dynamic CSS rules according to the rule unique key composed of component identifier, field path, device type, media query conditions and target selector, so as to write them into the CSS rule manager of the low code editor instance. Step S54: Based on the static style generation information of the material corresponding to the target component, find or create a style node corresponding to the material in the static style container node of the component tree memory structure, and write the inherent CSS content of the material into the style node; Step S55: Trigger the component update logic of the target component, inject the form extension configuration declared by the parent component into the corresponding child component, so that the child component rebuilds the style mapping table based on the injected form extension configuration, and performs addition or overwrite update on the dynamic CSS rules of the child component with the rule unique key; Step S56: When the material corresponding to the target component has a content template, refresh the DOM attributes, text content or sub-component template inside the target component according to the configuration parameters of the target component; Step S57: Continue executing steps S51 to S56 on the sub-components of the target component until the complete component tree memory structure is traversed. Step S6: After completing the recursive style compensation traversal, export the page schema data, and extract runtime internal attributes, versioned runtime attributes, and runtime DOM attributes from the page schema data to obtain the low-code page data after style completion.

2. The low-code page style completion method without rendering according to claim 1, characterized in that, The low-code page data in step S1 includes a component configuration tree generated by a large language model, or serialized data of existing low-code pages; the configuration parameters include at least one of the component's style parameters, content parameters, behavior parameters, and responsive parameters.

3. The low-code page style completion method without rendering according to claim 1, characterized in that, The lightweight DOM context in step S2 is provided by a DOM simulation library, including happy-dom or jsdom; the lightweight DOM context only provides the DOM interface required for component registration and style compensation, without starting the browser rendering process.

4. The low-code page style completion method without rendering according to claim 1, characterized in that, The low-code editor instance is a GrapesJS editor instance, the no-rendering mode is headless mode, the component manager is DomComponents, the CSS rule manager is CssComposer, and the low-code page data is ProjectData.

5. The low-code page style completion method without rendering according to claim 1, characterized in that, The material definition in step S3 includes Block definition and ComponentType definition; the Block definition includes material identifier, material content definition, material target version information, material form description information and static style generation information; the ComponentType definition includes component default attributes, initialization hook, update hook and content template refresh logic.

6. The low-code page style completion method without rendering according to claim 1, characterized in that, The material version migration process in step S51 includes at least one of the following: renaming the configuration parameter field path, converting the configuration parameter data format, completing the old version default value, and updating the component version information; the configuration parameter data format conversion includes converting the numeric configuration value into an object-type configuration value that contains both the numeric value and the unit.

7. The low-code page style completion method without rendering according to claim 1, characterized in that, The material form description information in step S52 is a Formal Schema, which declares the extended properties x-datatransform, x-responsive, and x-selector. Among them, x-datatransform is used to declare the transformation relationship between configuration parameters and CSS properties, x-responsive is used to declare whether the configuration parameters generate responsive styles according to the device type, and x-selector is used to declare the target selector for CSS rule binding.

8. The low-code page style completion method without rendering according to claim 7, characterized in that, Step S53 includes: When the target field is marked as a responsive field and its value includes both desktop and mobile values, the corresponding style conversion function is called according to the desktop and mobile values ​​respectively to generate independent CSS rules with media query conditions; When the target field is configured with a selector tag, the generated CSS rules are bound to the CSS selector corresponding to the selector tag; When a target field is marked as a responsive field but its value is a flat format that is not device-grouped, the target field is downgraded to a global style field to generate CSS rules that are not device-specific.

9. The low-code page style completion method without rendering according to claim 1, characterized in that, The rule unique key in step S53 includes at least five of the following: component unique identifier, material identifier, field path, device type, media query condition, target selector, and CSS property name; when there is an existing rule in the CSS rule manager that corresponds to the rule unique key, the existing rule is updated; when there is no corresponding rule, a new CSS rule is added.

10. A low-code page style completion system without rendering, characterized in that, include: The data acquisition module is used to acquire the low-code page data to be completed; The DOM context pre-registration module is used to register a lightweight DOM context in the server compute node before the low-code editor kernel is loaded. The material registration and data loading module is used to initialize the low-code editor instance in no-rendering mode, register the material definition, and load the low-code page data into the component manager of the low-code editor instance. The style compensation traversal module is used to perform recursive style compensation traversal on the component tree memory structure in the order of parent components before child components, and to perform version migration, form description information parsing, dynamic CSS rule idempotent update, static style node mounting, parent and child component style schema injection and propagation, and content template refresh for target components with material identifiers in sequence. The Schema Export and Cleaning module is used to export page schema data and remove runtime internal attributes, versioned runtime attributes, and runtime DOM attributes to obtain low-code page data with style completion.

Images