A conditional rendering method and system for resolving hidden placeholders

By binding business data with template elements, parsing conditional rendering instructions, and hiding placeholders, the problem of layout blanks and misalignments when template element conditions are not met is solved, achieving page continuity and stability, and is suitable for complex grid layouts and multi-terminal rendering scenarios.

CN121722384BActive Publication Date: 2026-06-30JIANGSU GONGCHUANG SOFTWARE CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
JIANGSU GONGCHUANG SOFTWARE CO LTD
Filing Date
2026-02-25
Publication Date
2026-06-30

Smart Images

  • Figure CN121722384B_ABST
    Figure CN121722384B_ABST
Patent Text Reader

Abstract

This invention relates to the field of computer software technology, and in particular to a conditional rendering method and system for hiding placeholders. The invention proposes the following solution: by binding business data to template elements, parsing and evaluating the conditional rendering instructions associated with the template elements, the rendering judgment result of the template elements is determined. When a template element does not meet the rendering conditions, its placeholder area is discretized based on the template grid structure. The actual placeholder range is determined by combining logical layout position and content style simulation. Furthermore, the row and column objects to be eliminated are determined through structural closure and minimum coverage solutions. This allows for the hiding of template elements while reclaiming their layout space, achieving automatic backfilling of adjacent content. This method effectively avoids blank space residue and layout misalignment in complex grid layouts and merged cell scenarios, improving the continuity and stability of the page structure in conditional rendering scenarios.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a conditional rendering method and system for resolving hidden placeholders. Background Technology

[0002] In existing template-driven page or document generation technologies, preset conditions and control instructions are typically used in the template to selectively render parts of the content based on different states of business data, thereby achieving dynamic changes in the page structure. This type of technology is widely used in scenarios such as report generation, document output, and configurable page rendering, and can reduce the number of templates and improve template reuse efficiency to a certain extent.

[0003] However, in the aforementioned existing technical solutions, when a template element is determined not to be displayed due to unmet conditions, only the template element itself is hidden or an empty value is output, without simultaneously processing the space occupied by the template element in the overall layout structure. The direct result is that in the final rendered output, although the template element is no longer displayed, its original row height, column width, or merged area is still retained, creating obvious blank areas or breaks in the page, affecting the continuity and aesthetics of the overall layout.

[0004] Furthermore, when the template contains merged cells, complex row and column structures, or strict alignment relationships, the conditional hiding process in existing technologies is prone to causing layout misalignment issues. For example, adjacent content may not automatically fill back to the position where the hidden element is released, table borders may be interrupted or misaligned, and unexpected spacing may occur between text paragraphs, thereby reducing the readability and professionalism of the final rendered result.

[0005] To address the above issues, this application presents a conditional rendering method and system for resolving hidden placeholders. Summary of the Invention

[0006] The technical problem this invention aims to solve is to address the shortcomings of existing technologies by providing a conditional rendering method and system for hiding placeholders. This method binds business data to template elements, parses and evaluates the conditional rendering instructions associated with the template elements, and determines the rendering result of the template elements. When a template element does not meet the rendering conditions, its placeholder area is discretized based on the template grid structure. The actual placeholder range is determined by combining logical layout position and content style simulation. Furthermore, structural closure and minimum coverage solutions are used to determine the rows and columns that need to be eliminated. This allows for the hiding of template elements while reclaiming their layout space, achieving automatic backfilling of adjacent content. This method effectively avoids blank space residue and layout misalignment in complex grid layouts and merged cell scenarios, improving the continuity and stability of the page structure in conditional rendering scenarios.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A conditional rendering method for hiding placeholders is applied to a rendering engine. The rendering engine is configured with template files set according to preset template rules. The template files describe the layout structure of the page to be rendered. The template files include multiple template elements and conditional rendering instructions associated with the template elements. The conditional rendering instructions include at least a `renderIf` instruction for controlling the display state of the template elements. The method includes:

[0009] Obtain business data and match the business data with the template file to bind the business data to multiple template elements one by one;

[0010] The renderIf directive is evaluated based on the binding result to obtain the conditional rendering determination result for each template element;

[0011] When the conditional rendering result of any template element does not meet the rendering conditions, a hidden placeholder resolution process is performed on the corresponding template element. The hidden placeholder resolution process includes: setting the rendering target corresponding to the template element to a hidden state and resolving the space occupied by the rendering target in the layout so that the content adjacent to the rendering target can be backfilled.

[0012] The template elements are rendered and output based on the layout and style information defined in the template file.

[0013] The business data includes data objects used to drive template rendering. The data objects include at least structured field data, wherein the structured field data includes field identifiers and field values ​​that correspond one-to-one with the template elements.

[0014] Matching the business data with the template file includes:

[0015] Parse the template file to obtain the element identifier and data binding identifier corresponding to each template element;

[0016] Based on the element identifier and data binding identifier, a matching field identifier is retrieved in the structured field data to determine the mapping relationship between the field identifier and the element identifier;

[0017] According to the mapping relationship, the matched field values ​​are written into the corresponding template elements to generate a one-to-one binding result between the business data and the multiple template elements;

[0018] When there is an unmatched field identifier, the unmatched field identifier is marked as redundant data.

[0019] Retrieving matching field identifiers from the structured field data and determining the mapping relationship between field identifiers and element identifiers includes:

[0020] Obtain the data binding identifier of the template element, and perform path parsing on the data binding identifier to obtain the field retrieval key, wherein the field retrieval key includes at least the field name, hierarchical path and array subscript information;

[0021] An index table is created in the structured field data, with field identifiers as keys and field values ​​as values. The index table is then matched based on the field retrieval keys to obtain a set of candidate field identifiers.

[0022] When there are multiple matching items in the candidate field identifier set, the candidate field identifier set is disambiguated based on a preset priority rule. The preset priority rule includes at least the following: full path matching takes precedence over partial path matching, consistent field type takes precedence over inconsistent field type matching, and the nearest level matching takes precedence over cross-level matching.

[0023] The mapping field identifier of the template element is determined based on the target field identifier after disambiguation, and the mapping field identifier is written into the mapping relationship.

[0024] The renderIf directive is evaluated based on the binding result to obtain the conditional rendering determination result for each template element, including:

[0025] Parse the renderIf directive associated with the template element, obtain the logical expression carried by the renderIf directive, and parse the logical expression into an executable expression tree;

[0026] Based on the binding result, the parameter values ​​participating in the calculation are extracted from the field values ​​corresponding to the template element, and the parameter values ​​are subjected to type normalization processing, wherein the type normalization processing is used to convert strings, numbers, booleans and null values ​​into a unified comparison type;

[0027] The parameter values ​​are calculated according to the order of operations in the expression tree to obtain the evaluation result of the logical expression;

[0028] The evaluation result is converted into a conditional rendering result, and the conditional rendering result is associated with the corresponding template element to obtain the conditional rendering result for each template element.

[0029] The renderIf directive is evaluated based on the binding result to obtain the conditional rendering determination result for each template element. The evaluation also includes incremental evaluation processing to reduce the overhead of repeated evaluations. This incremental evaluation processing includes:

[0030] Static analysis is performed on the expression tree to extract the set of field identifiers that the logical expression depends on, and a dependency mapping table between field identifiers and template elements is established.

[0031] When an update to the business data is detected, the target field identifier that has changed is determined, and a set of template elements to be updated that are associated with the target field identifier is filtered out based on the dependency mapping table.

[0032] The renderIf directive corresponding to the set of template elements to be updated is re-evaluated to update the corresponding conditional rendering result.

[0033] The process of hiding and resolving placeholder elements for the corresponding template elements includes:

[0034] Obtain the layout scope information of the rendering target corresponding to the template element, wherein the layout scope information is used to indicate the place range of the rendering target in the template file, and the place range includes at least one of row range, column range and cell merge range;

[0035] The placeholder resolution object is determined based on the layout scope information, and the placeholder resolution object includes at least the target row and target column to which the rendering target belongs;

[0036] Set the rendering target to a hidden state and perform a space resolution operation on the placeholder object, wherein the space resolution operation includes at least: setting the row height of the target row to a preset minimum height or setting the column width of the target column to a preset minimum width;

[0037] After the space elimination operation is completed, the content adjacent to the placeholder elimination object is rearranged according to the grid order of the template file so that the content fills the empty area after the space elimination.

[0038] Obtain the layout scope information of the rendering target corresponding to the template element, and determine the placeholder resolution object based on the layout scope information, including:

[0039] The grid region of the template element is discretized and divided into multiple micro-units, wherein each micro-unit is associated with at least its row identifier, column identifier, and merged cell component identifier;

[0040] The set of logical placeholder micro-units of the rendering target is determined based on the logical layout position of the rendering target in the template element;

[0041] Based on the content value and style information of the rendering target, the layout simulation of the rendering target is performed through the preset rendering semantics to obtain the set of visible placeholder micro-units of the rendering target, and the set of visible placeholder micro-units is merged with the set of logical placeholder micro-units to obtain the target placeholder micro-unit set.

[0042] The target placeholder micro-unit set is subjected to structural closure processing to obtain a dissolved micro-unit set, and the placeholder range corresponding to the dissolved micro-unit set is used as the layout scope information. The structural closure processing includes: when the dissolved micro-unit set hits some micro-units of the merged cell component, the dissolved micro-unit set is expanded to all micro-units corresponding to the merged cell component.

[0043] Based on the set of resolution micro-units, a bipartite graph of row nodes and column nodes is constructed. The minimum cover solution is performed on the bipartite graph to obtain the minimum set of row nodes and the minimum set of column nodes that cover all edges of the bipartite graph. The row corresponding to the minimum set of row nodes and the column corresponding to the minimum set of column nodes are determined as the placeholder resolution objects.

[0044] The template elements are rendered and output according to the layout and style information defined in the template file, including:

[0045] Get the final layout position and style parameters for each template element;

[0046] Based on the final layout position, the template elements are arranged according to the row and column structure defined in the template file, and the style parameters are applied to the corresponding template elements;

[0047] After the template elements have been formatted and styled, they are converted into a rendering structure that the target device can recognize, and the corresponding rendering results are output.

[0048] A conditional rendering system for hiding placeholders, the system comprising:

[0049] The template binding module is used to parse the template file set according to the preset template rules, obtain the template elements and the conditional rendering instructions associated with the template elements, and match the business data with the template elements to form a one-to-one binding relationship;

[0050] The condition determination module is used to evaluate the renderIf directive corresponding to the template element based on the binding relationship, and obtain the condition rendering determination result of each template element;

[0051] The placeholder resolution module is used to determine the corresponding placeholder resolution object when the template element does not meet the rendering conditions, and to perform hiding processing and space resolution operation on the placeholder resolution object to release the layout space.

[0052] The rendering output module is used to arrange and render the template elements after conditional rendering and placeholder resolution processing, based on the layout and style information defined in the template file.

[0053] Compared with the prior art, the beneficial effects of the present invention are:

[0054] This invention introduces a hidden placeholder resolution mechanism during conditional rendering. This allows template elements to be effectively hidden when rendering conditions are not met, and simultaneously releases the space they occupy in the layout structure, thus avoiding blank gaps or invalid placeholders in the final rendering result. By resolving the placeholder range of template elements, adjacent content can be automatically backfilled according to the grid order defined by the template, ensuring the overall layout remains continuous, compact, and as expected.

[0055] Furthermore, this application achieves linked control of conditional rendering and layout adjustment without relying on pre-defined fixed structural areas in templates. It is compatible with templates containing merged cells, complex row and column structures, and diverse style constraints, effectively improving the template's adaptability in complex scenarios. Moreover, through a unified rendering process, this application helps ensure consistent visual presentation of the same template across different output terminals or formats, thereby improving the stability and maintainability of rendering results and reducing the cost of template configuration and subsequent adjustments. Attached Figure Description

[0056] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0057] Figure 1 An exemplary application scenario diagram provided for an embodiment of the present invention;

[0058] Figure 2 This is a flowchart illustrating a conditional rendering method for resolving hidden placeholders, provided in an embodiment of the present invention. Detailed Implementation

[0059] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0060] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0061] The conditional rendering method for resolving hidden placeholders described in this application is applicable to scenarios where page / report / document content generation is driven by template files and business data, and is especially suitable for rendering engines where templates need to maintain a consistent visual structure across different output platforms. In practice, enterprises often use tabular templates (such as templates with grid-defined layouts that support styles and merged cells) to carry complex layouts: they need to express hierarchical structures such as titles, groups, headers, details, and summaries, while also supporting various style constraints such as fonts, borders, alignment, merging, and row and column sizes. Furthermore, they want the same template to be output in multiple formats, including webpage previews, editable documents, and archived documents. Because templates inherently possess advantages such as visual layout, reusability, and ease of delivery, template-based multi-platform rendering has gradually become a common technical approach for generating result pages in business systems.

[0062] However, when templates are implemented in real business environments, conditional display scenarios are almost unavoidable: for example, certain fields may not display the entire description when empty, certain groups may not display the entire area when there is no data, and certain rows and columns may only be displayed for specific roles or states. Existing technologies typically introduce conditional directives into templates to control whether elements are output. The basic approach is often: after business data is bound to template elements, the conditional expression is evaluated; if it is not satisfied, the corresponding element is marked as not displayed or outputs empty content. This approach can achieve display / hide at the logical level, but it is often difficult to achieve a layout where no gaps are left after hiding. This is because the space occupied by table grids or layout containers is usually structural: even if an element is not drawn, its row height, column width, merged areas, and the arrangement relationship of adjacent content still hold, ultimately forming obvious blank breaks, misalignment marks, or page jumps in the rendering result; in more complex cases, the hiding target is superimposed with style constraints such as merged cells, border closure, and automatic line wrapping, which can also cause local structural collapse failure, resulting in a visual defect where it appears to be hidden but actually still occupies space.

[0063] Those skilled in the art often encounter a common dilemma in engineering implementation: On the one hand, template authors are accustomed to expressing modular layouts using row and column grids, and hiding an element often implies the expectation that the entire block-level area will shrink and refill accordingly; on the other hand, to ensure cross-platform consistency, rendering engines must usually strictly adhere to the row and column structure and style constraints of the template. Simply deleting nodes or crudely splicing layouts can easily disrupt border continuity, merging relationships, and alignment baselines, thereby introducing new layout errors. Especially in multi-platform output scenarios, different platforms do not interpret hiding in the same way: some platforms will retain row and column placeholders, some will collapse the display but retain the rendering box model, and some platforms will amplify blank space issues due to pagination and measurement differences, causing the same template to present inconsistent visual results on different platforms, leading to difficulties in acceptance and increased maintenance costs.

[0064] Based on the aforementioned engineering background, the core logic of this application does not merely use conditional judgment for rendering, but rather implements conditional rendering and placeholder resolution as a unified action: after establishing a binding relationship between business data and template elements, the conditional rendering judgment result of the template element is obtained by executing and evaluating the logical expression carried by the renderIf directive; when the judgment result does not meet the rendering conditions, not only is the corresponding rendering target set to a hidden state, but the space it occupies in the grid layout is further resolved, allowing adjacent content to be backfilled according to the template grid order, thereby visually achieving a continuous layout effect of hiding as collapsing and collapsing as backfilling. The principle of this logic stems from a fundamental fact of template grid layout: placeholders are not equivalent to whether to draw, but depend on whether row and column sizes, merging ranges, and adjacent relationships are released; therefore, this application explicitly defines placeholder resolution as a necessary step in the rendering process, extending conditional rendering from logical-level display control to the structural continuity guarantee at the layout level.

[0065] It should be noted that the `renderIf` directive in this application can be understood as a conditional rendering directive embedded in the template file, used to describe the rules for determining whether a template element participates in the output during the rendering phase. This directive is associated with the template element in the form of a logical expression, which is constructed based on the business data fields bound to the template element and is used to dynamically determine the display state of the template element during the rendering process.

[0066] In this application, the renderIf directive is not limited to a specific syntax or implementation language. It can exist in the template file as an explicit tag, extended attribute, or placeholder expression, or it can be associated with the template element as metadata or configuration field. The core is that the directive can be parsed into executable conditional judgment logic in the rendering engine and participate in the rendering decision process after the business data binding is completed.

[0067] In one optional implementation, the renderIf directive can be configured in the template file as an inline expression within a cell or as a metadata attribute of a template element. For clarity, an intuitive example is provided below, whose semantics are: "Render this area only when user.vip is true in the business data; otherwise, hide it and trigger placeholder resolution."

[0068] For example, configure the following renderIf directive on the template element corresponding to a header line in the template file (e.g., the line containing "VIP Exclusive Benefits"): Where: renderIf represents a conditional rendering directive; The text contains logical expressions; user.vip is a field identifier, corresponding to the field value in the business data object. For comparison operations, it is used to map field values ​​to Boolean judgment results.

[0069] During the rendering process, after the rendering engine completes the binding of business data to template elements, it reads the renderIf directive of the template element and evaluates the expression: if the value of the user.vip field is true, the row containing the template element is rendered and output normally according to the layout and style defined in the template; if the value of the user.vip field is false or empty, it is determined that the template element does not meet the rendering conditions, the rendering engine sets the rendering target corresponding to the template element to a hidden state, and performs a process to eliminate the row / column space it occupies, so that the content below automatically moves up to fill the space, thereby avoiding blank space.

[0070] Therefore, this application is particularly suitable for the following typical application environments: the template contains a large number of optional blocks (description sections, group blocks, condition columns, optional rows), and the blocks rely on continuous borders, merged cells, or strict alignment; the business data is highly dynamic (fields may be missing, list lengths are variable, and conditions are frequently displayed); the output includes at least two forms such as web page preview and archived document, and requires the same template to maintain a consistent visual layout across different platforms. By linking the condition judgment results with placeholder resolution, this application can provide a more stable implementation path for engineering challenges such as "hidden conditions leading to holes, merging / style constraints leading to collapse failure, and semantic differences across platforms leading to inconsistencies" without relying on the template to pre-divide fixed structure blocks. It also establishes a more predictable layout contract between template authors and rendering engines.

[0071] refer to Figure 1 , Figure 1 This is an exemplary application scenario diagram provided for an embodiment of this application.

[0072] like Figure 1As shown, the application scenarios include edge devices, rendering engines, and business systems. These components work together through communicable connections to support template selection, content filling, and result output based on business data.

[0073] The edge device serves as the entry point for service triggering. It can receive user operations, external system calls, or upper-layer business instructions, and send the corresponding business data to the rendering engine for processing. The edge device can be an electronic device with computing and communication capabilities, including but not limited to client devices, business terminals, or access nodes. Its main function is to initiate business requests and display the final results.

[0074] The rendering engine is used to parse, judge, and process business data from the end device. After receiving the business data, the rendering engine first analyzes the content characteristics, status information, or business rules of the business data to determine whether template rendering needs to be triggered and the corresponding rendering method. After completing the rendering judgment, the rendering engine further performs rendering and obtains the corresponding template resources from the template library according to the judgment result, parses and fills the template, thereby generating the target output content.

[0075] The business system is used to centrally store and manage template-related resources, which may include template files and template elements. The template file describes the overall structure, layout rules, and rendering logic, while the template elements define content units that can be dynamically populated by business data. It should be noted that the template file in this application can be implemented based on a spreadsheet file, such as an Excel file. The overall layout, field mapping relationships, and rendering rules of the template file are configured through a preset row and column structure, and the corresponding template elements and their populated positions are defined through cell content or tags. Using an Excel-based template file format facilitates visual maintenance and configuration by business personnel, while reducing the dependence of template updates on system code. Those skilled in the art will understand that the specific implementation form of the template file is not limited to an Excel file, and this application does not further limit it in this regard.

[0076] Next, with reference to the accompanying drawings, the conditional rendering method for hiding placeholders provided in the embodiments of this application will be further elaborated. Figure 2 The method shown is applied to a rendering engine configured with template files set according to preset template rules. The template files describe the layout structure of the page to be rendered. The template files include multiple template elements and conditional rendering instructions associated with the template elements. The conditional rendering instructions at least include a `renderIf` instruction for controlling the display state of the template elements. The method includes:

[0077] S1: Obtain business data and match the business data with the template file to bind the business data to multiple template elements one by one;

[0078] In this embodiment, the conditional rendering method for resolving hidden placeholders is applicable to rendering scenarios where pages or reports are dynamically generated based on template files. For example, the business side generates display pages based on business data such as orders, work orders, alarms, and customer information. Business data can be reported by the end-side device, returned by the business interface, or read from local storage. Specific data types may include structured fields (such as numeric, enumeration, and status codes), semi-structured fields (such as key-value pair extended fields), and text fields, etc., as long as they can at least satisfy the template element value retrieval and condition evaluation. This embodiment does not impose further limitations.

[0079] The template file describes the page layout structure in a configurable manner, and each template element has a parsable element identifier and data binding description in the template file. When business data is matched with the template file, the fields in the business data are bound to the corresponding template elements one by one according to the element identifier, field path or mapping rules. Default value filling, data type normalization and formatting can be completed during the binding process. For example, empty values ​​are uniformly mapped to preset placeholders, numeric fields are converted according to unit rules, and status fields are mapped to readable text, so that subsequent evaluation of conditional rendering commands and rendering output have a consistent data input basis.

[0080] S2: Evaluate the renderIf directive based on the binding result to obtain the conditional rendering determination result for each template element;

[0081] In this embodiment, the `renderIf` directive is used to control whether template elements participate in rendering. Its evaluation process is preferably based on the bound field values ​​and the semantics of a preset expression to avoid misjudgments caused by relying solely on string judgments. Specifically, the `renderIf` directive can be parsed into a logical expression tree or an executable conditional unit, and the corresponding field values ​​can be retrieved from the bound data context for calculation. The expression supports equality comparisons, range comparisons, null value judgments, set inclusion, compound logic (AND / OR / NOT), and state mapping judgments, and a consistent evaluation strategy can be set for scenarios with missing or null fields. For example, missing fields can be treated as not satisfying the condition or as default values ​​to ensure predictable judgment results. By obtaining the conditional rendering judgment result of each template element before rendering, subsequent hidden placeholder resolution can be decided before layout calculation, avoiding reflow jitter and layout jumps caused by rendering first and then recycling.

[0082] S3: When the conditional rendering result of any template element does not meet the rendering conditions, the corresponding template element is hidden and the placeholder is resolved.

[0083] The hidden placeholder resolution process includes: setting the rendering target corresponding to the template element to a hidden state, and resolving the space occupied by the rendering target in the layout, so that the content adjacent to the rendering target can be backfilled.

[0084] In this embodiment, the difficulty of conditional rendering lies not in hiding elements, but in how to avoid blank breaks, misalignment, or residual spacing on the page after hiding them, especially when template elements use grid layout, flow layout, or table layout. Simply setting an element to invisible often leaves it with its occupied space, preventing adjacent content from filling in. To address this, the hidden placeholder resolution process uses a combination of hidden state control and placeholder space reclamation: on one hand, the corresponding rendering target is set to a hidden state, preventing it from participating in drawing and event response; on the other hand, the size, margins, and placeholder units corresponding to the rendering target in the layout calculation are resolved, making it equivalent to a zero-size node or a removed node in the layout tree or typography sequence, thereby triggering automatic refilling of adjacent content under the same layout constraints. During placeholder resolution, the constraints of the outer container associated with the element can be processed simultaneously. For example, when the template element is located in a row container, its column width is reclaimed and redistributed to elements at the same level; when the template element is located in a list or table, the corresponding row height or cell span is reclaimed and the alignment baseline is updated. Through the above processing, elements that do not meet the conditions are not only invisible, but also do not leave gaps in the layout, thus maintaining a compact page structure and visual continuity.

[0085] S4: Render and output the template elements according to the layout and style information defined in the template file;

[0086] In this embodiment, after completing the condition determination and hidden placeholder resolution, the set of template elements participating in rendering has been decomposed into only valid elements that meet the conditions. At this point, a one-time layout calculation and rendering output can be performed based on the layout and style information preset in the template file. The layout information may include the element hierarchy, grid rules, alignment, spacing rules, row / column span rules, or adaptive rules, etc.; the style information may include font, color, border, background, icon, unit format, and display precision, etc. During rendering output, the final page structure can be generated according to the element order of the template file or the rendering tree order, and the formatted result bound to the business data is applied in the output stage to ensure that the displayed content is consistent with the business semantics. Since the hidden placeholder resolution is completed before the layout calculation, the final rendering process does not require secondary rearrangement of the hidden elements, and the page output process is more likely to maintain stable layout consistency. Those skilled in the art will understand that the template file can be stored in Excel, JSON, or other parsable formats. The expression capabilities and evaluation strategies of the renderIf directive can also be extended according to the actual rendering framework. As long as it can at least meet the conditional control of the display state of the template elements and realize the elimination of the placeholder space after hiding, this embodiment does not impose any further limitations.

[0087] Before detailing the specific technical aspects corresponding to the steps, this application's embodiments need to reiterate:

[0088] For rendering processes that describe page layout structure using template files and dynamically populate template elements with business data, there are numerous optional information blocks on the page. For example, some fields only appear under specific business conditions, some display modules only need to be presented when the data is complete, and some prompts should only be displayed in abnormal or alarm scenarios. These optional information blocks often do not exist independently but rather form grid alignment, column layout, or hierarchical nesting relationships with surrounding elements. Therefore, changes in their display status not only affect their own presentation but also alter the arrangement structure of adjacent content. Common phenomena in engineering practice include: when a template element is determined not to render, the page still retains blank rows, empty columns, or blank spacing; or adjacent content that originally depended on the element for alignment exhibits misalignment, alignment baseline drift, broken separator lines, and other layout anomalies. These anomalies are not simply hiding issues but rather layout remnants caused by the failure to properly release the space occupied after hiding. Ultimately, this manifests as a loose page structure, fragmented information blocks, and disrupted reading order, thereby affecting the consistency and usability of the business page presentation.

[0089] In existing implementations, a common approach is to perform visibility control on template elements that do not meet the conditions, such as setting the element to invisible, transparent, or not drawing; or replacing the element content with an empty string or empty image during the rendering stage. While these methods are applicable to simple linear layouts, when template elements have nested containers, span across rows and columns, automatic line wrapping, or adaptive line height, the element's placeholder parameters in the layout calculation are often retained. For example, fixed height, margins, column widths, or grid cells are retained, causing the layout engine to reserve space for the element during typesetting, resulting in adjacent content not being able to fill the space naturally. Furthermore, when a template element also serves as a style anchor (e.g., a separator line, title bar, alignment reference), simply hiding it may cause an imbalance in container boundary calculations, forcing other elements in the same row to wrap or compress, resulting in unpredictable offsets in the overall page presentation.

[0090] The approach of this application is to treat template elements that do not meet rendering conditions as a source of space occupation risk. Before rendering output, these elements are hidden and their space occupation is resolved, making them not only visually invisible but also no longer occupying any computable space in the layout model. This allows adjacent content to fill in the space under the original layout constraints. This process does not rely on redesigning the template or requiring the template file to be pre-divided into fixed cavities or fixed structural blocks. Instead, it dynamically resolves the space occupation relationship between template elements and layout rules: on the one hand, the rendering target is set to a hidden state, preventing it from participating in drawing and interaction; on the other hand, its size, spacing, and grid cell occupation in the layout tree are simultaneously eliminated, making it equivalent to a zero-size node or a removed node during layout calculation, thereby triggering the layout engine to naturally rearrange adjacent content. As a result, conditional rendering is no longer a single-point control of showing / hiding, but a continuous process, ensuring that the final page output maintains a compact structure and layout coherence, avoiding presentation problems such as empty holes, alignment drift, and layered segmentation.

[0091] Those skilled in the art will understand that the layout model involved in hiding placeholder resolution can be a grid, flow, table, or a combination thereof, as long as it can synchronously control the element rendering state and eliminate its layout occupation when the conditions are not met. This application does not impose any further limitations on this.

[0092] In one example, the business data includes a data object used to drive template rendering. The data object includes at least structured field data, wherein the structured field data includes field identifiers and field values ​​that correspond one-to-one with the template elements.

[0093] It should be noted that the field identifier can be used to uniquely locate the template element to be bound or its data binding point in the template file. It can be represented in the form of field name, field path or preset code, such as orderId, customer.name, riskLevel and invoice.amount, etc. The field value is the business value corresponding to the field identifier. It can be a string, number, boolean value, enumeration value, time value or a combination thereof, as long as it can satisfy the template element value filling and conditional rendering instruction evaluation. This application does not impose further limitations on this.

[0094] For example, in the rendering scenario of the order details page, the data object may include the following structured field data: the field identifier orderId corresponds to the field value 202401160001; the field identifier orderStatus corresponds to the field value PAID; the field identifier payTime corresponds to the field value 2024-01-16. 09:20:15; The field identifier totalAmount corresponds to a value of 1299.00; the field identifier couponAmount corresponds to a value of 100.00; the field identifier isInvoiceNeeded corresponds to a value of true; the field identifier invoiceTitle corresponds to a value of a company; the field identifier refundStatus corresponds to a value of NONE; the field identifier remark corresponds to a value of null. In this example, template elements can be bound to the order number display area, payment status display area, invoice information module, discount information module, and remarks module, etc. The renderIf directive associated with the invoice information module can be evaluated based on the value of the field identifier isInvoiceNeeded to determine whether to render the invoice module; the renderIf directive associated with the discount information module can be evaluated based on whether the value of the field identifier couponAmount is greater than zero to determine whether to display the discount information.

[0095] For another example, in the rendering scenario of the alarm notification page, the data object may include the following fields: alarmType (value OVERTEMP); severit (value HIGH); deviceId (value DEV-7F2A91); deviceName (value Cabinet Temperature Control Unit A); alarmTime (value 2024-01-16 11:03:42); threshold (value 75); currentValue (value 86); suggestion (value "Check if cooling fan and air inlet are blocked"); and isAckRequired (value true). In this example, the renderIf directive associated with the confirmation button module can be evaluated based on the value of the isAckRequired field to determine whether to present the confirmation processing entry; the renderIf directive associated with the suggestion module can be evaluated based on whether the suggestion field is empty to determine whether to display a handling suggestion.

[0096] Those skilled in the art will understand that the above field identifiers and field values ​​are merely illustrative examples. Actual business data can be expanded or tailored according to the page type and template element configuration, as long as it can at least satisfy the binding relationship between the field and the template element and the condition evaluation requirements of the renderIf directive. This application does not impose further limitations.

[0097] In one example, matching the business data with the template file includes:

[0098] Parse the template file to obtain the element identifier and data binding identifier corresponding to each template element;

[0099] Based on the element identifier and data binding identifier, a matching field identifier is retrieved in the structured field data to determine the mapping relationship between the field identifier and the element identifier;

[0100] According to the mapping relationship, the matched field values ​​are written into the corresponding template elements to generate a one-to-one binding result between the business data and the multiple template elements;

[0101] When there is an unmatched field identifier, the unmatched field identifier is marked as redundant data.

[0102] It should be noted that the template files in this application are not dynamically generated during rendering, but can be configured and maintained through a pre-built interface library to ensure the stability and reusability of the template structure.

[0103] Specifically, the interface to be rendered can be predefined in an interface library, which centrally stores interface template configurations for different business scenarios. Each interface template in the interface library can be described by a template file, which at least describes the overall layout structure, element hierarchy, and basic style attributes of each template element. During the template file construction phase, the functional areas and display modules required by the interface can be determined based on the target business scenario, such as title areas, information display areas, operation areas, or prompt areas. Based on this, corresponding template element sets are divided, so that each template element has a clear position and function in the template structure.

[0104] In this embodiment, the construction of the template file also includes configuring data binding identifiers and conditional rendering instructions for each template element. The data binding identifier is used to declare the business field types or field paths that the template element expects to receive, so that it can be matched with the structured fields in the business data during rendering; the conditional rendering instruction is used to describe under what business conditions the template element participates in rendering, which can be associated with the values, states, or combination logic of the business fields.

[0105] Furthermore, the template files in the interface library can be maintained in a tabular or configurable manner, such as stored as Excel files, configuration tables, or other structured configuration formats, allowing template elements, binding identifiers, and conditional rendering instructions to be managed in rows, columns, or fields. This approach allows template adjustments and extensions to be completed without altering the rendering logic, reducing template maintenance costs and improving the flexibility of interface configuration. Those skilled in the art will understand that the organization of the interface library, the storage format of the template files, and the template construction process can all be adjusted according to actual application needs, as long as the interface structure, data binding relationships, and conditional rules are predefined before rendering; this application does not impose further limitations in this regard.

[0106] It is understandable that matching business data with template files is not a simple field replacement process, but rather a structured alignment of the relationships between data and layout units, based on the renderability of template elements and conditional judgment requirements. During the parsing phase, template files can be broken down into several template element nodes. Each template element node contains at least an element identifier, a data binding identifier, and a description of its associated rendering attributes. The element identifier uniquely locates the element's position within the template structure, while the data binding identifier indicates the business field type or field path that the element expects to receive.

[0107] Furthermore, during matching, the field identifier does not need to be exactly the same as the data binding identifier. Instead, alignment can be performed according to preset matching rules, such as supporting field alias mapping, hierarchical path matching, or type constraint matching. This allows template elements to obtain valid data sources even when field names differ. Once a field identifier matching the data binding identifier is found in the structured field data, a mapping relationship between the field identifier and the element identifier is established, and the corresponding field value is written into the rendering context of the template element. This writing process can simultaneously perform basic formatting processing, such as numerical precision control, time format conversion, or null value replacement, allowing the template element to directly use the standardized data results in subsequent rendering stages, thereby avoiding the repeated execution of data preprocessing logic during rendering.

[0108] In one example, retrieving matching field identifiers from the structured field data and determining the mapping relationship between field identifiers and element identifiers includes:

[0109] Obtain the data binding identifier of the template element, and perform path parsing on the data binding identifier to obtain the field retrieval key, wherein the field retrieval key includes at least the field name, hierarchical path and array subscript information;

[0110] An index table is created in the structured field data, with field identifiers as keys and field values ​​as values. The index table is then matched based on the field retrieval keys to obtain a set of candidate field identifiers.

[0111] When there are multiple matching items in the candidate field identifier set, the candidate field identifier set is disambiguated based on a preset priority rule. The preset priority rule includes at least the following: full path matching takes precedence over partial path matching, consistent field type takes precedence over inconsistent field type matching, and the nearest level matching takes precedence over cross-level matching.

[0112] The mapping field identifier of the template element is determined based on the target field identifier after disambiguation, and the mapping field identifier is written into the mapping relationship.

[0113] Specifically, the mapping between field identifiers and element identifiers does not rely on a manually maintained fixed lookup table. Instead, it uses the data binding identifier of template elements as the entry point to establish a parsable and fault-tolerant field retrieval mechanism to adapt to the differences in field naming and nesting in different interface versions, different business modules, or different data levels. The data binding identifier adopts a path-based expression to describe the location of the field in the business data object. For example, it can include information such as field name, object level path, and array subscript. By parsing the data binding identifier, it can be decomposed into field retrieval keys, so that subsequent matching can distinguish the cases of fields with the same name but located in different levels, and can handle the fixed-point value requirements of list-type fields. During path parsing, the level nodes can be split according to the preset separator, and the array subscript syntax can be identified to form an index indicator. For example, items[0].name can be decomposed into the level path "items→name" and carry the array subscript "0", so that it can point to a specific array element or default element when locating the field. Those skilled in the art will understand that path resolution rules can be configured based on template syntax, as long as they can convert data binding identifiers into structured keys that can be used for field retrieval.

[0114] In this embodiment, to avoid multiple hierarchical traversals of business data objects when matching each template element, an index table can be built on the structured field data first, establishing a fast lookup structure with field identifiers as keys and field values ​​as values. Field identifiers in the index table can be stored in the form of full path identifiers, such as including the complete path from the root node to the leaf node, to support full path matching; simultaneously, inverse indexes can be built for field names to support partial path matching or recall of fields with the same name. When matching based on the field search key, the candidate field identifier set can be retrieved in the index table first by the full path; if no full path is found, it degenerates to recalling candidates by field name or partial path, and retains the hierarchical depth, parent path information, and field type information of the candidate fields in the candidate set for subsequent disambiguation. For search keys containing array subscripts, the array elements can be expanded to form path identifiers with subscripts during index construction, or the specific element can be located by index and the corresponding path identifier generated during the matching stage, so that list-type fields can be stably mapped to specified template elements.

[0115] Furthermore, when multiple matches exist in the candidate field identifier set, disambiguation is used to determine the target field identifier when fields with the same name, multi-level fields, or multiple versions of fields coexist, thereby making the template element binding results predictable. During disambiguation, preset priority rules are applied sequentially: full path matches that are completely identical to the field search key are prioritized to ensure positioning accuracy; when multiple full path matches or only partial path matches exist, field type consistency is further compared, for example, numeric template elements are mapped to numeric fields first, and boolean conditions are mapped to boolean fields first, to reduce the risk of type conversion during subsequent renderIf evaluation; when field types still cannot be distinguished, the nearest level match is prioritized over cross-level matches based on hierarchical distance, making the candidate field structurally closer to the parent path described by the search key. Through this step-by-step disambiguation, binding stability can be maintained even when the business data field structure changes or fields are reused extensively, and misjudgments in condition rendering caused by incorrect binding can be reduced.

[0116] Those skilled in the art will understand that the specific entries of the priority rules can be extended according to the template syntax and business data specifications. For example, field alias weights, interface version number weights, or default field whitelists can be introduced. As long as the unique target field identifier can be determined and written into the mapping relationship when there is ambiguity in the candidate set, this embodiment does not impose further limitations.

[0117] Next, we will further elaborate on the technical content of the conditional rendering determination result of the method in this application.

[0118] It should be noted that the conditional rendering determination result is not merely used to provide a binary conclusion of rendering / not rendering, but rather serves as a priori basis for subsequent hidden placeholder resolution and layout reordering processes. Its granularity and consistency directly affect the final structural stability of the page. In engineering practice, template elements often have layout coupling relationships: for example, multiple columns within the same row share row height and alignment baseline, parent containers are sensitive to the number of child elements, table cells have cross-row and cross-column constraints, and list items and separators have grouped display relationships. If the conditional determination is evaluated independently for each element, elements within the same logical area may exhibit inconsistent display states, leading to broken backfill paths or localized residual placeholders. Therefore, this embodiment, when generating the conditional rendering determination result, tends to incorporate the determination process along with the structural relationships of template elements, data binding status, and computability of expressions, ensuring that the determination result simultaneously meets the requirements of semantic correctness and layout resolvability.

[0119] In one example, the renderIf directive is evaluated based on the binding result to obtain the conditional rendering determination result for each template element, including:

[0120] S2.1: Parse the renderIf directive associated with the template element, obtain the logical expression carried by the renderIf directive, and parse the logical expression into an executable expression tree;

[0121] Specifically, the display control of template elements in template files is often configured in the form of expressions. These expressions may contain simple null value checks or complex logic involving multiple fields. If only string matching or temporary concatenation is used for evaluation, inconsistencies may easily occur in terms of operation priority, nested brackets, and short-circuit logic processing. This can cause the same template to obtain different judgment results under different data formats, thereby affecting the stability of subsequent hidden placeholder resolution.

[0122] In this embodiment, the `renderIf` directive can be read from the attribute set of the template element during the template parsing stage. The logical expression carried by the `renderIf` directive can be in text form. During parsing, lexical analysis is first performed to break the expression into a token sequence. The token types include at least identifier tokens, constant tokens, comparison operator tokens, logical operator tokens, and bracket tokens. Identifier tokens are used to point to bound fields or derived fields, and constant tokens can include string constants, numeric constants, Boolean constants, and null constants. Subsequently, syntax analysis is performed to assemble the token sequence into an expression tree according to preset grammar rules. The expression tree nodes include at least logical nodes, comparison nodes, and value nodes. Logical nodes are used to represent AND / OR / NOT operations, comparison nodes are used to represent equality, not equal to, greater than, less than, contain, and null judgments, and value nodes are used to read field values ​​or constant values ​​from the binding result. After the expression tree is constructed, it can be associated with the element identifier of the template element for storage, so that it can be directly scheduled and executed during the rendering stage without repeated parsing.

[0123] It should be noted that the evaluation of the renderIf directive based on the binding result to obtain the conditional rendering determination result for each template element also includes incremental evaluation processing to reduce the overhead of repeated evaluation. This incremental evaluation processing includes:

[0124] Static analysis is performed on the expression tree to extract the set of field identifiers that the logical expression depends on, and a dependency mapping table between field identifiers and template elements is established.

[0125] When an update to the business data is detected, the target field identifier that has changed is determined, and a set of template elements to be updated that are associated with the target field identifier is filtered out based on the dependency mapping table.

[0126] The renderIf directive corresponding to the set of template elements to be updated is re-evaluated to update the corresponding conditional rendering result.

[0127] It is understandable that the incremental evaluation process described here is applicable to rendering scenarios where business data undergoes partial, batch, or high-frequency updates. For example, after the page is initially loaded, only some fields may change due to user actions, status postbacks, or asynchronous API responses. In such scenarios, if the renderIf directive associated with all template elements is fully evaluated every time data is updated, it not only incurs unnecessary computational overhead but may also cause frequent fluctuations in conditional judgment results within a short period. This increases the number of times hidden placeholder resolution and layout reordering are triggered, affecting overall rendering stability.

[0128] In this embodiment, incremental evaluation can be understood as a "field-driven conditional update mechanism." By performing static analysis on the expression tree during the template parsing phase, the set of field identifiers that each renderIf directive logically depends on can be clearly identified. For example, if the display condition of a certain template element depends only on the fields "orderStatus" and "payTime," then its conditional rendering result may only change when the above fields change. Based on this analysis result, a dependency mapping table between field identifiers and template elements is established, so that business data update events can be accurately located to the range of affected template elements. When a business data update is detected, the target field identifier that has changed can be identified first, and then the set of template elements that have a dependency relationship with that field can be filtered out according to the dependency mapping table. Only the renderIf directives in this set are re-evaluated, without having to recalculate unrelated template elements.

[0129] S2.2: Based on the binding result, extract the parameter values ​​participating in the calculation from the field values ​​corresponding to the template element, and perform type normalization processing on the parameter values, wherein the type normalization processing is used to convert strings, numbers, booleans and null values ​​into a unified comparison type;

[0130] Specifically, business data fields have diverse value sources. The same semantic field may be returned as a string, number, or enumerated text in different interfaces or business chains, and null values ​​may be represented as missing fields, null, empty strings, or special placeholders. Without type normalization, the same comparison operation in an expression may produce different evaluation results under different value forms. For example, the semantics of the string "0" and the number 0 are inconsistent in size comparison, and the semantics of the boolean type "true" and the string "true" are inconsistent in equality judgment. Ultimately, this manifests as instability in the conditional rendering judgment result when the data format changes. Therefore, uniform type normalization of parameter values ​​is performed before expression evaluation to ensure that subsequent comparison operations are performed on a consistent semantic basis.

[0131] In this embodiment, parameter value extraction can be accomplished by the value nodes of the expression tree: when the value node is a field reference, the corresponding field value is read from the binding result; when the value node is a constant, the constant value is used directly. The read field values ​​can first undergo null value judgment, which can cover cases such as missing fields, explicit null, empty strings, empty arrays, and preset placeholders, and uniformly map them to the null value type. Then, type normalization is performed: for strings that can be parsed into numbers, unit symbols or percentage signs can be removed according to preset rules and converted to a numeric type; for Boolean semantic strings, they can be converted to Boolean type according to the mapping table; for enumeration semantic fields, they can be converted to standard enumeration values ​​according to the enumeration mapping table; for time semantic fields, they can be converted to a unified time format or timestamp to support size comparison. During the type normalization process, it is preferable to retain both the original type marker and the normalized type marker of the field at the same time, so as to handle the case of inconsistent types in subsequent comparison operations. For example, when one side is a number and the other side is an unparseable string, it can fall back to string comparison or be judged as not satisfying.

[0132] S2.3: Calculate the parameter value according to the operation order of the expression tree to obtain the evaluation result of the logical expression;

[0133] Specifically, the evaluation process of an expression tree needs to adhere to the short-circuit semantics of logical operations and the deterministic order of comparison operations to ensure consistent results across different data formats for complex condition combinations, and to avoid retrieving and calculating unnecessary fields. Especially when there are many template elements and the `renderIf` expression involves multiple fields, the lack of a short-circuit mechanism in the evaluation process will lead to a large number of redundant field retrievals and comparisons, increasing rendering latency and introducing anomalies caused by missing fields. Therefore, evaluating expression trees recursively or iteratively by node type can control the computation path while ensuring semantic consistency.

[0134] In this embodiment, evaluation can begin from the root node of the expression tree: when the root node is a logical node, child nodes are evaluated sequentially according to the semantics of logical operators, and subsequent evaluations terminate when the short-circuit condition is met. For example, under "AND" logic, if the previous child node is false, there is no need to continue calculating the next child node; under "OR" logic, if the previous child node is true, there is no need to continue calculating the next child node; under "NOT" logic, a single child node is evaluated and then inverted. For comparison nodes, the normalized parameter values ​​of the left and right operands are read, and the comparison operation is performed according to the comparison operator. The comparison operation can include equality, inequality, size comparison, inclusion judgment, regular expression matching, or null value judgment, etc. When one side involved in the comparison is a null value type, it can be handled according to the preset null value comparison rules. For example, if "isEmpty(field)" is true, "field==null" is handled according to the equality rule, and the size comparison is judged as not satisfying by default when null values ​​are involved, in order to avoid null values ​​triggering exceptions. For function nodes, the corresponding function is called according to the function executor mapping, and the parameter value list is passed in to obtain a boolean or numerical result. During the evaluation process, intermediate results can be cached in the node-level context to avoid repeated normalization processing when the same field is referenced multiple times in an expression.

[0135] S2.4: Convert the evaluation result into a conditional rendering judgment result, and associate the conditional rendering judgment result with the corresponding template element to obtain the conditional rendering judgment result of each template element;

[0136] Specifically, the evaluation result of a logical expression is usually a Boolean value or a result that can be mapped to Boolean semantics. However, in a template rendering scenario, the judgment result needs to be further structured so that subsequent hidden placeholder resolution processing can determine whether an element participates in the layout calculation and the placeholder reclamation boundary based on the result. If only Boolean values ​​are saved, it will be difficult to distinguish between situations such as "dissatisfaction due to missing fields" and "dissatisfaction due to a false condition judgment," and it will also be difficult to perform consistency processing on grouped elements or elements spanning multiple rows and columns.

[0137] In this embodiment, the conditional rendering determination result may include at least one determination status field, which indicates whether the rendering conditions are met or not. It may also include an optional determination reason field and a key field list field. The determination reason field indicates the main reason for non-compliance, such as missing field, inconsistent types, invalid comparison, or a function returning false. The key field list field lists the identifiers of the fields involved in the evaluation, so as to associate and process dependencies during subsequent hidden placeholder resolution. After the determination result is generated, it can be written into the rendering context of the template element, for example, as attribute storage for the template element node, so that subsequent steps can directly read and execute the hidden placeholder resolution process. For template elements without a configured renderIf directive, their determination status can be set to meet the default rendering conditions. For template elements configured for group display, consistency correction within the group can be performed after single-element determination, propagating the determination status of key elements within the group to dependent elements to ensure continuous backfill paths during subsequent layout resolution.

[0138] For example, the following is a simplified example illustrating how the conditional rendering decision of a template element is obtained from the `renderIf` logical expression through a process of parsing, normalization, and evaluation. This example is only for explaining the computational chain and dimensional relationships; the selected fields, parameters, and values ​​are illustrative and do not represent actual calibration results or recommended engineering values.

[0139] Suppose a template element named E_invoice exists in the template file, with the element identifier "E_invoice", the data binding identifier "invoice.*", and a renderIf directive configured to control whether this module is rendered. An example of the logical expression carried by this renderIf directive is: isInvoiceNeeded == true AND totalAmount>=100 AND invoiceTitle != "".

[0140] Among them, "isInvoiceNeeded" indicates whether an invoice is needed, "totalAmount" indicates the total order amount, and "invoiceTitle" indicates the invoice title.

[0141] In this example, after the business data is bound to the template elements one by one, the field values corresponding to E_invoice can be exemplarily as follows: the field value of the field identifier "isInvoiceNeeded" is the string "1"; the field value of the field identifier "totalAmount" is the string "1299.00"; the field value of the field identifier "invoiceTitle" is the string "XX Technology Co., Ltd.". At the same time, assume that in another example comparison scenario, the field value of "invoiceTitle" is the empty string "". The above field values are the data context written into the template elements in the binding result, which are used as parameters for subsequent renderIf evaluation.

[0142] Subsequently, enter the renderIf evaluation link. First, perform lexical and syntactic parsing on the logical expression to convert it into an executable expression tree. Exemplarily, the root node of the expression tree is a logical AND node (AND), its left child node is a comparison node "isInvoiceNeeded == true", and the right child node is a logical AND node (AND); the left branch of the right child node is a comparison node "totalAmount >= 100", and the right branch is a comparison node "invoiceTitle != ''". At this point, the operation order of the expression is solidified into the top-down and child-to-parent evaluation order defined by the tree structure, and the parentheses and short-circuit semantics can also be clearly expressed in the tree structure.

[0143] Furthermore, extract the parameter values participating in the operation from the binding result and perform type normalization on the parameter values so that they can participate in unified comparison operations. In the example, the original value of "isInvoiceNeeded" is the string "1", and according to the preset boolean mapping rule, "1" can be normalized to the boolean value true; the original value of "totalAmount" is the string "1299.00", and according to the numerical parsing rule, it is normalized to the numerical value 1299.00; the original value of "invoiceTitle" is the string "XX Technology Co., Ltd.", and it remains a non-empty string after normalization; at the same time, the constant "true" is parsed as the boolean constant true, the constant "100" is normalized to the numerical value 100, and the constant is normalized to the empty string constant. At this point, both sides of the comparison operation have consistent comparability at the type level: boolean vs. boolean comparison, numerical vs. numerical comparison, and string vs. string comparison.

[0144] Furthermore, the evaluation is performed according to the operation order of the expression tree. First, evaluate the comparison node "isInvoiceNeeded == true": the left operand is true, the right operand is true, and the comparison result is true; then evaluate the comparison node "totalAmount >= 100": the left operand is 1299.00, the right operand is 100, and the comparison result is true; then evaluate the comparison node "invoiceTitle != ''": the left operand is "×× Technology Co., Ltd.", the right operand is an empty string, and the comparison result is true. Then evaluate the right logical AND node (AND): both of its left and right branches are true, and the result is true; finally, evaluate the root node logical AND: the left branch is true, the right branch is true, and the final evaluation result is true. At this time, convert this evaluation result into a conditional rendering determination result and associate it with the template element E_invoice, and the conditional rendering determination result of this template element can be obtained as "meeting the rendering conditions", that is, E_invoice participates in subsequent rendering output.

[0145] For easy comparison, the evaluation link of the same expression in the case of "invoiceTitle being empty" is given again. Assume that the field value of "invoiceTitle" in the binding result is an empty string "", and it remains an empty string after normalization. At this time, for the comparison node "invoiceTitle != ''", the left operand is an empty string, the right operand is also an empty string, and the comparison result is false; since the right logical AND node is "totalAmount >= 100 AND invoiceTitle != ''", and one of them is false, the evaluation result of the right logical AND is false; when evaluating the root node logical AND, the final result can be directly obtained according to the short-circuit semantics as false. Finally, it is converted into a conditional rendering determination result of "not meeting the rendering conditions" and associated with the template element E_invoice, so that the subsequent hidden placeholder resolution process can hide this template element and recycle its placeholder space.

[0146] Those skilled in the art can understand that the above examples are only used to illustrate the complete link of the renderIf expression from parsing, normalization to evaluation and generating the conditional rendering determination result; in actual projects, the expression can be more complex, and the field types and mapping rules can also be configured according to business specifications, as long as it can stably output repeatable determination results in the binding data context, and this application does not make further limitations on this.

[0147] Next, the technical content of the method of this application regarding the hidden placeholder resolution process is further expanded.

[0148] It's important to note that hiding placeholders is not the same as making template elements invisible or undrawn. Instead, when the conditional rendering criteria are not met, the corresponding template element is simultaneously removed from both the visual rendering layer and the layout calculation layer. This ensures that the final page output does not suffer from blank spaces, alignment shifts, or gaps caused by invisible elements. In templated rendering scenarios, template elements are often under layout constraints such as grids, flow tables, or tables. Elements on the same layer may share row heights, alignment baselines, or column widths, and the parent container may be highly sensitive to the number of child elements, their row / column spanning relationships, or content. Therefore, if only hiding is performed without reclaiming their layout space, the layout engine will still reserve size and spacing for them during typesetting, causing adjacent content to fail to fill naturally, resulting in an abnormal page appearance where content is squeezed but gaps remain. The value of hiding placeholders lies in transforming the rendering decision into a structural change that the layout engine can execute, allowing layout reordering to be completed in a single calculation, resulting in a more compact final presentation and a continuous reading order.

[0149] In one example, the hidden placeholder resolution process for the corresponding template element includes:

[0150] S3.1: Obtain the layout scope information of the rendering target corresponding to the template element, wherein the layout scope information is used to indicate the place range of the rendering target in the template file, and the place range includes at least one of row range, column range and cell merging range;

[0151] Specifically, the placeholder of a template element in a template file is not always the same as its own bounding box. Especially in grid layouts or tabular layouts, template elements may occupy entire rows, columns, or merged cells that span multiple rows and columns, or they may form implicit placeholders based on the row and column definitions of the parent container. In this case, if the rendering target is only hidden without recognizing its layout scope, the placeholder area may not be fully recycled. For example, only the content displayed in the upper left corner of a merged cell may be hidden, but the span across columns may still be retained, causing adjacent content to fail to fill or to break the alignment after filling.

[0152] In one example, the layout scope information of the rendering target corresponding to the template element is obtained, and the placeholder resolution object is determined based on the layout scope information, including:

[0153] S3.1.1: Discretize the grid area of ​​the template element and divide the grid area into multiple micro-units, wherein each micro-unit is associated with at least its row identifier, column identifier, and merged cell component identifier;

[0154] Specifically, in grid-based template layouts, the space occupied by template elements is often influenced by factors such as row height, column width, cell merging, and style margins. Using only the "start and end row / column range" as a placeholder description is insufficient to accurately depict complex placeholder boundaries. This is especially true when there are merged cells, border crossings, cell alignment, or nested containers, which can easily lead to an excessively large or small resolution range, resulting in incorrect recycling or residual holes. Discretizing the grid region into micro-units transforms the placeholder problem into a set operation on the discrete unit set. This provides a unified computational granularity for subsequent placeholder identification, closure expansion, and row / column resolution, ensuring controllable and reusable resolution boundaries.

[0155] In this embodiment, the discretization process is performed based on the grid division defined in the template file: First, the boundary of the grid region where the template element is located is read. The boundary can be determined by the starting row, starting column, row span, and column span of the template element, or by the grid range defined by its container. Then, a list of micro-units is generated by row and column intersection. Each micro-unit corresponds to a minimum grid intersection unit, and its row identifier and column identifier are written. For example, the row identifier is used as the row index or row number, and the column identifier is used as the column index, column letter, or column number. For merged cells, the template file usually contains the start and end coordinates of the merged block or the merged block identifier. In this embodiment, a merged cell component identifier can be assigned to each merged block, and this identifier can be written to all micro-units covered by the merged block, so that subsequent closure expansion can be performed on a component-by-component basis. After discretization, a micro-unit matrix or sparse micro-unit set with (row identifier, column identifier, merged component identifier) ​​can be obtained, providing a basic data structure for subsequent determination of the placeholder range.

[0156] S3.1.2: Determine the set of logical placeholder micro-units of the rendering target based on the logical layout position of the rendering target in the template element;

[0157] Specifically, when template elements are configured in a template file, they typically have a "logical layout position," such as being declared within a certain row and column range, set as a merged area spanning multiple rows and columns, or placed at a specified grid position within a specific container node. This logical layout position reflects the intended spatial location during template design, but it is not equivalent to the visual occupancy after final rendering. However, the logical layout position provides a stable placeholder base, making placeholder identification independent of pixel differences or font rendering differences in the rendering output medium. Therefore, it is preferable to first determine the set of logical placeholder micro-units based on the logical layout position before placeholder resolution, to limit the basic placeholder range that the rendering target may involve in the grid.

[0158] In this embodiment, the determination of the logical placeholder micro-unit set can be accomplished by reading the layout attributes of the rendering target: for example, reading its starting row identifier, starting column identifier, row span, and column span, or reading the address of its bound cell range (such as "B3:D4" in Excel), and selecting all micro-units falling into the range from the discretized micro-unit matrix as the logical placeholder micro-unit set; when the rendering target is located in a merged cell, all corresponding micro-units can be directly located by the merged cell component identifier as the logical set. For elements with relative positioning or anchor point positioning (such as being placed to the right or below a certain element), the logical position of the anchor point element can be parsed first, and then the logical grid area of ​​the current element can be calculated according to the relative offset rule and the corresponding micro-unit set can be extracted. The logical placeholder micro-unit set obtained in this way can be used as the input set for subsequent simulation and closure processing, avoiding the simulation range from spreading to irrelevant areas.

[0159] S3.1.3: Based on the content value and style information of the rendering target, the rendering target is laid out and simulated through preset rendering semantics to obtain the set of visible placeholder micro-units of the rendering target, and the set of visible placeholder micro-units is merged with the set of logical placeholder micro-units to obtain the target placeholder micro-unit set.

[0160] Specifically, in actual rendering, even if the rendering target is configured within a logical grid area, its visible footprint is often determined by content length, font size, line break rules, padding, and alignment. For example, within the same cell area, short text may only occupy a portion of the width and not trigger a line break, while long text may span multiple lines; icons or images may occupy a fixed size and trigger cell expansion; borders and whitespace may create additional visible footprint. If resolution is based solely on the logical placeholder set, sometimes the logical area is too large but only a small portion is actually occupied, resulting in an excessively large resolution range that affects adjacent content, or the logical area is too small but the actual content overflows into adjacent areas, resulting in insufficient resolution range and residual placeholders. Therefore, layout simulation based on content values ​​and style information can estimate the visible footprint range without requiring actual rendering output, making the subsequent resolution boundaries closer to the final rendering behavior.

[0161] In this embodiment, layout simulation can be implemented using preset rendering semantics. These rendering semantics can be understood as a set of computable typesetting rules used to approximate the occupancy of text, images, or components in a grid dimension. For example, for text-type rendering targets, the number of characters per line can be estimated based on font size, font weight, line spacing, and effective cell width. The required number of lines is then estimated by combining the text length and line break rules, thereby deriving the actual number of lines occupied within the logical area. For numerical or monetary fields, their horizontal occupancy within the cell can be determined based on the formatted character count and alignment. For image or icon fields, their width and height can be determined based on preset dimensions or adaptive rules and mapped to the corresponding micro-unit set. During simulation, the logical placeholder micro-unit set can be mapped to an available canvas, and the content placeholders can be projected onto this canvas according to the alignment (e.g., centered, right-aligned) to obtain a visual placeholder micro-unit set. After obtaining the set of visual placeholder micro-units, they are merged with the set of logical placeholder micro-units to form the target set of placeholder micro-units. This simultaneously covers the logical boundaries during design and the actual content-driven boundaries, ensuring that subsequent closure processing does not miss any areas that may have residual placeholders.

[0162] S3.1.4: Perform structural closure processing on the target placeholder micro-unit set to obtain a dissolved micro-unit set, and use the placeholder range corresponding to the dissolved micro-unit set as the layout scope information. The structural closure processing includes: when the dissolved micro-unit set hits some micro-units of the merged cell component, expanding the dissolved micro-unit set to all micro-units corresponding to the merged cell component.

[0163] Specifically, in a grid template, merged cells are a type of structural constraint. No individual micro-cell within a merged cell can be independently recycled or backfilled. The merging relationship causes the entire area to participate in row and column span and alignment calculations as a whole during layout computation. If the placeholder set only covers a portion of the micro-cells of the merged block without expanding into the full merged block, subsequent space resolution may result in "incomplete recycling" or "backfilling blocked by the merged span." For example, some columns involved in the merged block might be compressed, but the merge still exists, causing the layout engine to retain the overall span for the merged block, ultimately leaving gaps or causing alignment anomalies. Therefore, structural closure processing is used to elevate the placeholder set to a closed set of structural constraints, ensuring that subsequent resolution objects remain consistent with the structural constraints of the layout engine.

[0164] In this embodiment, the structural closure processing can be extended according to the merged cell component identifier: traverse each micro-cell in the target placeholder micro-cell set and read its merged cell component identifier; when the identifier is not empty and the component has not been fully contained, add all micro-cells corresponding to the merged component to the placeholder set, thereby obtaining the closure-resolved micro-cell set. For scenarios with multi-level merging or nested merging, this extension process can be executed recursively until the resolved micro-cell set no longer adds micro-cells. After the closure processing is completed, layout scope information can be generated accordingly, such as generating the minimum outer row and column range of the resolved micro-cell set, the list of involved merged components, and the related parent container identifier, so that subsequent steps can determine the placeholder resolution object in the row and column dimensions, and cancel or adjust the merging relationship when necessary. Through structural closure, the boundary of hidden placeholder resolution is consistent with the template structure constraint, making the space reclamation and adjacent content backfilling process more controllable.

[0165] S3.1.5 Based on the set of resolved micro-units, construct a bipartite graph of row nodes and column nodes, perform minimum coverage solution on the bipartite graph to obtain the minimum set of row nodes and the minimum set of column nodes that cover all edges of the bipartite graph, and determine the row corresponding to the minimum set of row nodes and the column corresponding to the minimum set of column nodes as the placeholder resolution object.

[0166] S3.2: Determine the placeholder resolution object based on the layout scope information, wherein the placeholder resolution object includes at least the target row and target column to which the rendering target belongs;

[0167] Specifically, in grid layouts, the placeholder space of template elements is not always a single-dimensional result, but is often influenced by multiple constraints such as row height, column width, and cell merging relationships. Especially in complex templates, the same rendering target may span multiple rows and columns, and its placeholder effect is determined by multiple sets of row and column nodes. If the hidden placeholder resolution is handled solely based on intuitive rules (such as prioritizing row compression or column compression), it is easy to cause compression redundancy, layout imbalance, or damage to valid content in the same layer. Therefore, determining the placeholder resolution target needs to strike a balance between "completely reclaiming placeholders" and "minimizing layout disturbance," so that the placeholders corresponding to the hidden rendering target can be completely resolved, while minimizing the impact on unrelated rows and columns.

[0168] In this embodiment, the placeholder area of ​​the rendering target is first decomposed into several "resolved micro-units" based on the layout scope information. Each resolved micro-unit corresponds to a basic placeholder unit in the template grid, such as the intersection of a specific row and a specific column. Then, the set of row nodes and the set of column nodes are respectively used as two disjoint node sets in a bipartite graph, and each resolved micro-unit is abstracted as an edge connecting its corresponding row node and column node, thereby constructing a bipartite graph model describing the placeholder relationship of the rendering target. In this bipartite graph, the existence of any edge indicates that if the row or column is not compressed, the placeholder still remains; conversely, as long as one of the row node or column node covering the edge is selected to perform a resolve operation, the space occupation corresponding to the micro-unit can be eliminated.

[0169] Furthermore, a minimum coverage solution is performed on the aforementioned bipartite graph to obtain the minimum set of row nodes and the minimum set of column nodes that cover all edges. Logically, this minimum coverage result means that only spatial resolution operations need to be performed on the rows and columns in this set to ensure that all placeholder micro-units introduced by the rendering target are recycled, without needing to process the remaining unselected rows or columns in the bipartite graph, thus avoiding unnecessary layout disturbances. The minimum coverage solution can employ the bipartite graph minimum vertex coverage algorithm well-known to those skilled in the art, or be obtained by conversion based on the maximum matching result; the specific algorithm implementation does not affect the technical effect of this embodiment. This embodiment, by introducing bipartite graph modeling and minimum coverage solution, transforms the determination of placeholder resolution objects from empirical rules into a structured computational process. While ensuring complete placeholder resolution, it reduces the intrusion on the overall template layout, which is beneficial for maintaining layout stability and predictability in templates with multiple elements and complex merged units. Those skilled in the art will understand that the granularity of the micro-units, the bipartite graph construction method, and the coverage solution strategy can all be adjusted according to the template mesh rules. It is sufficient to determine a minimum set of rows and columns to cover all the occupants of the rendering target. This application does not impose any further limitations.

[0170] For example, the following is a simplified example illustrating how to determine the placeholder resolution object. This example is only for explaining the relationship between computational links and dimensions; the selected mesh size, component range, and values ​​are illustrative and do not represent actual templates or engineering recommendations.

[0171] Assuming the template file uses a grid layout, a rendering target to be resolved is located within a 4x4 local grid region, with rows labeled R1, R2, R3, R4 and columns labeled C1, C2, C3, C4. After discretization, 16 micro-cells are obtained, each of which can be represented by "(Ri,Cj)". Further assuming that a merged cell component M1 exists within this local grid, covering rows R2-R3 and columns C2-C3, the merged block contains the micro-cells: (R2,C2), (R2,C3), (R3,C2), and (R3,C3), all of which carry the same merged cell component identifier M1.

[0172] In this example, based on the logical layout position of the rendering target, the set of logical placeholder micro-units is obtained as: L = {(R2,C2), (R2,C3)}, indicating that the rendering target is configured in the area from the second row to the third column. Simultaneously, after layout simulation based on content values ​​and style information, the set of visual placeholder micro-units is obtained as: V = {(R3,C2)}, for example, text wrapping or vertical alignment causing content to occupy a visible space on the next line. Combining these two sets yields the target placeholder micro-unit set: T = L∪V={(R2,C2), (R2,C3), (R3,C2)}.

[0173] Then, structural closure processing is performed. Since some micro-cells of the merged cell component M1 are hit in T (e.g., (R2,C2), (R2,C3), (R3,C2) but not (R3,C3)), according to the closure rules, all micro-cells corresponding to the merged component need to be included in the resolution set. Therefore, the resolution micro-cell set after closure is: D={(R2,C2), (R2,C3), (R3,C2), (R3,C3)}.

[0174] At this point, the layout scope information can be understood as "the merged block M1 whose occupying range covers R2~R3 and C2~C3". Next, a bipartite graph of row nodes and column nodes is constructed based on the resolution micro-unit set D. The left side of the bipartite graph is the row node set {R2,R3}, and the right side is the column node set {C2, C3}. Each micro-unit corresponds to an edge: edge e1 for micro-unit (R2,C2): R2—C2, edge e2 for micro-unit (R2,C3): R2—C3, edge e3 for micro-unit (R3,C2): R3—C2, and edge e4 for micro-unit (R3,C3): R3—C3. Therefore, the bipartite graph is a complete 2×2 bipartite subgraph.

[0175] The goal of finding the minimum cover solution for a bipartite graph is to select the fewest possible nodes from row and column nodes such that every edge is covered by at least one selected endpoint. For a 2×2 complete bipartite graph, the minimum cover size is 2. Multiple feasible minimum cover solutions exist, for example:

[0176] Solution A: Selecting row nodes {R2, R3} will cover all four edges (because each edge is connected to either R2 or R3).

[0177] Option B: Selecting column nodes {C2, C3} can also cover all four edges;

[0178] Option C: Selecting {R2, C2} does not cover e4 (R3—C3), therefore it does not cover the entire set;

[0179] Therefore, the effective solution for minimum coverage is to select two rows or two columns. In this embodiment, a secondary selection rule from the engineering side can be further introduced to determine the final placeholder elimination object. For example, priority can be given to eliminating the node set that has less impact on other effective content: if R2 and R3 are empty rows whose height is contributed only by the rendering target, while C2 and C3 still carry other modules, then {R2, R3} is selected first; conversely, if C2 and C3 are placeholder columns dedicated to the module, then {C2, C3} is selected first. Assuming that C2 and C3 in the template are also used to display other fields and are not suitable for compressing column width, then the row corresponding to the row node set {R2, R3} is finally selected as the placeholder elimination object, and the row height of R2 and R3 is compressed to the preset minimum height, thereby reclaiming all the placeholder space of the merged block.

[0180] For ease of comparison, the following presents a common existing technology processing method and its differences in placeholder area. For example, existing methods often employ a fixed strategy: compressing only the starting row or only the starting column of the rendering target. For instance, if only the starting row R2 is compressed, its space resolution object is only {R2}. In this example, (R3,C2) and (R3,C3) still belong to the placeholder area of ​​the merged block M1, the row height of row R3 is still preserved, and the page will retain a whole row of blank space. Alternatively, if only the cell content is hidden without processing the merge relationship and row / column constraints, the merged block M1 will still participate in the layout calculation with a span of 2 rows × 2 columns, and the empty area is fully preserved. That is, the existing method (compressing only R2): still retains the row height of R3, and the remaining placeholder area is approximately 1 row × 2 columns of grid area; if each row height is 40 pixels and each column width is 120 pixels, the remaining blank area is approximately 9600 pixels.

[0181] In this embodiment (minimum coverage selected as {R2,R3}): R2 and R3 are both compressed to the minimum height, the two rows of space corresponding to the merged block are completely reclaimed, and the remaining blank space is close to zero (if the minimum row height is 1 pixel, the remaining area is about 480 pixels, which is a negligible layout residue).

[0182] Similarly, if the template environment is more suitable for compressing columns than rows, then selecting {C2,C3} will compress the width of the two columns to the minimum width, so that the remaining area converges according to the column width scale.

[0183] S3.3: Set the rendering target to a hidden state and perform a space resolution operation on the placeholder object, wherein the space resolution operation includes at least: setting the row height of the target row to a preset minimum height or setting the column width of the target column to a preset minimum width;

[0184] Specifically, hiding the rendering target only solves the visual "invisibility," but the layout engine may still reserve space for it based on row height, column width, margins, inner margins, and merge span, thus ensuring the continued existence of blank areas in the layout. Space resolution operations directly affect layout constraints along the row and column dimensions, compressing the placeholder area to a negligible scale during layout calculations, thereby providing space for subsequent backfilling of adjacent content. For tabular templates, row height and column width are usually the most direct parameters determining placeholders; therefore, by adjusting the constraints on the target row height and target column width, placeholder reclamation can be achieved without disrupting the overall grid structure of the template.

[0185] In this embodiment, the hidden state of the rendering target can be achieved by setting display attributes, such as marking the rendering target as invisible, undrawable, and unparticipating in event hits, and setting a skip-draw flag for it in the rendering tree; at the same time, its content output can be set to empty to avoid generating placeholder text or placeholder images during the rendering stage. During space resolution, the preset minimum height and minimum width can be determined based on the minimum visible unit of the template rendering: for example, when the template uses pixels as the layout unit, the minimum height can be set to 0 or 1 pixel, and the minimum width can be set to 0 or 1 pixel; when the template is mapped to Excel row height and column width in row and column units, the minimum row height can be set to 0 points or equivalent to the row height value of the hidden row, and the minimum column width can be set to 0 character width or equivalent to the column width value of the hidden column. For example, if the template engine stores Excel row heights in points, the target row height can be set to 0 points; if the column width is stored in character widths, the target column width can be set to 0. If the underlying constraints do not allow values ​​to be 0, then the minimum acceptable positive value can be used, such as a row height of 0.5 points and a column width of 0.1 character width, so that layout calculations can still be performed but the footprint is close to zero. This preset minimum value can be stored as a global configuration item in the template library, or it can be configured separately according to the template type to ensure compatibility under different rendering output media.

[0186] S3.4: After completing the space elimination operation, the content adjacent to the placeholder elimination object is rearranged according to the grid order of the template file so that the content fills the empty area after the space elimination.

[0187] Specifically, space reduction compresses the space occupied by the target rows and columns, but whether adjacent content can "naturally move" to fill the gaps depends on the template's grid order, alignment rules, and the row-to-row and row-to-column relationships of adjacent elements. If a consistent rearrangement strategy is not applied to adjacent content, situations may arise where some content remains in its original position, the backfilling order is disordered, or cross-column elements are squeezed into incorrect columns, ultimately disrupting the page's reading order. Therefore, after space reduction, it is preferable to rearrange the adjacent content within the affected area according to the grid traversal order and layout rules defined in the template file, ensuring that the backfilling process remains consistent with the template's original layout logic.

[0188] In this embodiment, position rearrangement can be performed based on grid order, such as traversing template elements from top to bottom and left to right in a row-first manner. For elements located after the eliminated rows and columns, their target row and column numbers are recalculated, allowing them to move forward while maintaining relative order to fill gaps. For grid layouts, column alignment constraints can be prioritized during backfilling: if an element originally occupied a column and that column was not completely eliminated, the column remains unchanged, and only the row number is moved up; if its column is eliminated, it is moved to the nearest available column according to preset column migration rules, such as prioritizing backfilling to the left or maintaining the relative column positions of elements in the same group. For elements that span rows and columns, their span parameters can be updated synchronously during rearrangement to prevent cross-column elements from covering already compressed columns; for table-type elements, the order relationship between the table header, group rows, and data rows can be maintained during rearrangement to ensure that the table semantics are still met after backfilling. After position rearrangement is completed, a partial layout refresh can be performed on the affected area, recalculating the position and size only for elements whose positions have changed, to reduce the overhead of full rearrangement.

[0189] In yet another example, the template elements are rendered and output based on the layout and style information defined in the template file, including:

[0190] Get the final layout position and style parameters for each template element;

[0191] Based on the final layout position, the template elements are arranged according to the row and column structure defined in the template file, and the style parameters are applied to the corresponding template elements;

[0192] After the template elements have been formatted and styled, they are converted into a rendering structure that the target device can recognize, and the corresponding rendering results are output.

[0193] In yet another example, this application embodiment provides a conditional rendering system for hiding placeholders, the system comprising:

[0194] The template binding module is used to parse the template file set according to the preset template rules, obtain the template elements and the conditional rendering instructions associated with the template elements, and match the business data with the template elements to form a one-to-one binding relationship;

[0195] The condition determination module is used to evaluate the renderIf directive corresponding to the template element based on the binding relationship, and obtain the condition rendering determination result of each template element;

[0196] The placeholder resolution module is used to determine the corresponding placeholder resolution object when the template element does not meet the rendering conditions, and to perform hiding processing and space resolution operation on the placeholder resolution object to release the layout space.

[0197] The rendering output module is used to arrange and render the template elements after conditional rendering and placeholder resolution processing, based on the layout and style information defined in the template file.

[0198] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A conditional rendering method for resolving hidden placeholders, applied to a rendering engine, characterized in that, The rendering engine is configured with template files set according to preset template rules. These template files describe the layout structure of the page to be rendered. Each template file includes multiple template elements and conditional rendering instructions associated with those elements. The conditional rendering instructions at least include a `renderIf` instruction for controlling the display state of the template elements. The method includes: Obtain business data and match the business data with the template file to bind the business data to multiple template elements one by one; The renderIf directive is evaluated based on the binding result to obtain the conditional rendering judgment result of each template element. For template elements configured to be displayed in groups, after the single element judgment is completed, the consistency correction within the group is performed to propagate the judgment state of the elements within the group to the dependent elements. When the conditional rendering result of any template element does not meet the rendering conditions, a hidden placeholder resolution process is performed on the corresponding template element. The hidden placeholder resolution process includes: setting the rendering target corresponding to the template element to a hidden state, and resolving the space occupied by the rendering target in the layout, so that the content adjacent to the rendering target can be backfilled. The template elements are rendered and output according to the layout and style information defined in the template file; The process of hiding and resolving placeholder elements for the corresponding template elements includes: Obtain the layout scope information of the rendering target corresponding to the template element, wherein the layout scope information is used to indicate the place range of the rendering target in the template file, and the place range includes at least one of row range, column range and cell merge range. The placeholder resolution object is determined based on the layout scope information, and the placeholder resolution object includes at least the target row and target column to which the rendering target belongs; Set the rendering target to a hidden state and perform a space resolution operation on the placeholder object, wherein the space resolution operation includes at least: setting the row height of the target row to a preset minimum height or setting the column width of the target column to a preset minimum width; After the space elimination operation is completed, the content adjacent to the placeholder elimination object is rearranged according to the grid order of the template file so that the content fills the empty area after the space elimination. Obtain the layout scope information of the rendering target corresponding to the template element, and determine the placeholder resolution object based on the layout scope information, including: The grid area of ​​the template element is discretized and divided into multiple micro-units, wherein each micro-unit is associated with at least its row identifier, column identifier, and merged cell component identifier. The set of logical placeholder micro-units of the rendering target is determined based on the logical layout position of the rendering target in the template element; Based on the content value and style information of the rendering target, the layout simulation of the rendering target is performed through the preset rendering semantics to obtain the set of visible placeholder micro-units of the rendering target, and the set of visible placeholder micro-units is merged with the set of logical placeholder micro-units to obtain the target placeholder micro-unit set. The target placeholder micro-unit set is subjected to structural closure processing to obtain a dissolved micro-unit set, and the placeholder range corresponding to the dissolved micro-unit set is used as the layout scope information. The structural closure processing includes: when the dissolved micro-unit set hits some micro-units of the merged cell component, the dissolved micro-unit set is expanded to all micro-units corresponding to the merged cell component. Based on the set of resolved micro-units, a bipartite graph of row nodes and column nodes is constructed. The minimum cover solution is performed on the bipartite graph to obtain the minimum set of row nodes and the minimum set of column nodes that cover all edges of the bipartite graph. The row corresponding to the minimum set of row nodes and the column corresponding to the minimum set of column nodes are determined as the placeholder resolution objects. When there are multiple minimum cover solutions, a secondary selection rule is introduced to resolve the node sets in the multiple minimum cover solutions.

2. The conditional rendering method for resolving hidden placeholders according to claim 1, characterized in that, The business data includes data objects used to drive template rendering. The data objects include at least structured field data, wherein the structured field data includes field identifiers and field values ​​that correspond one-to-one with the template elements.

3. The conditional rendering method for resolving hidden placeholders according to claim 2, characterized in that, Matching the business data with the template file includes: Parse the template file to obtain the element identifier and data binding identifier corresponding to each template element; Based on the element identifier and data binding identifier, a matching field identifier is retrieved in the structured field data to determine the mapping relationship between the field identifier and the element identifier; According to the mapping relationship, the matched field values ​​are written into the corresponding template elements to generate a one-to-one binding result between the business data and the multiple template elements; When there is an unmatched field identifier, the unmatched field identifier is marked as redundant data.

4. The conditional rendering method for resolving hidden placeholders according to claim 3, characterized in that, Retrieving matching field identifiers from the structured field data and determining the mapping relationship between field identifiers and element identifiers includes: Obtain the data binding identifier of the template element, and perform path parsing on the data binding identifier to obtain the field retrieval key, wherein the field retrieval key includes at least the field name, hierarchical path and array subscript information; An index table is created in the structured field data, with field identifiers as keys and field values ​​as values. The index table is then matched based on the field retrieval keys to obtain a set of candidate field identifiers. When there are multiple matching items in the candidate field identifier set, the candidate field identifier set is disambiguated based on a preset priority rule. The preset priority rule includes at least the following: full path matching takes precedence over partial path matching, consistent field type takes precedence over inconsistent field type matching, and the nearest level matching takes precedence over cross-level matching. The mapping field identifier of the template element is determined based on the target field identifier after disambiguation, and the mapping field identifier is written into the mapping relationship.

5. The conditional rendering method for resolving hidden placeholders according to claim 1, characterized in that, The renderIf directive is evaluated based on the binding result to obtain the conditional rendering determination result for each template element, including: The renderIf directive associated with the template element is parsed to obtain the logical expression carried by the renderIf directive, and the logical expression is parsed into an executable expression tree; Based on the binding result, the parameter values ​​participating in the calculation are extracted from the field values ​​corresponding to the template element, and the parameter values ​​are subjected to type normalization processing, wherein the type normalization processing is used to convert strings, numbers, booleans and null values ​​into a unified comparison type; The parameter values ​​are calculated according to the order of operations in the expression tree to obtain the evaluation result of the logical expression; The evaluation result is converted into a conditional rendering result, and the conditional rendering result is associated with the corresponding template element to obtain the conditional rendering result for each template element.

6. The conditional rendering method for resolving hidden placeholders according to claim 5, characterized in that, The renderIf directive is evaluated based on the binding result to obtain the conditional rendering determination result for each template element. The evaluation also includes incremental evaluation processing to reduce the overhead of repeated evaluations. This incremental evaluation processing includes: Static analysis is performed on the expression tree to extract the set of field identifiers that the logical expression depends on, and a dependency mapping table between field identifiers and template elements is established. When an update to the business data is detected, the target field identifier that has changed is determined, and a set of template elements to be updated that are associated with the target field identifier is filtered out based on the dependency mapping table. The renderIf directive corresponding to the set of template elements to be updated is re-evaluated to update the corresponding conditional rendering judgment result.

7. The conditional rendering method for resolving hidden placeholders according to claim 1, characterized in that, The template elements are rendered and output according to the layout and style information defined in the template file, including: Get the final layout position and style parameters of each template element; Based on the final layout position, the template elements are arranged according to the row and column structure defined in the template file, and the style parameters are applied to the corresponding template elements; After the template elements have been formatted and styled, they are converted into a rendering structure that the target device can recognize, and the corresponding rendering results are output.

8. A conditional rendering system for resolving hidden placeholders, implemented based on a conditional rendering method for resolving hidden placeholders as described in any one of claims 1-7, characterized in that, The system includes: The template binding module is used to parse template files set according to preset template rules, obtain template elements and conditional rendering instructions associated with template elements, and match business data with template elements to form a one-to-one binding relationship. The condition determination module is used to evaluate the renderIf directive corresponding to the template element based on the binding relationship, obtain the condition rendering determination result of each template element, and perform group consistency correction after completing the single element determination. The placeholder resolution module is used to determine the corresponding placeholder resolution object based on the bipartite graph minimum coverage solution and secondary selection rules when the template element does not meet the rendering conditions, and to perform hiding processing and space resolution operation on the placeholder resolution object to release the layout space. The rendering output module is used to arrange and render the template elements after conditional rendering and placeholder resolution processing, based on the layout and style information defined in the template file.