A method for dynamic rendering based on list buttons

Abstract

This invention discloses a dynamic rendering method based on list buttons, belonging to the field of application software development technology. The method includes: modeling the state logic of a behavioral feature set; constructing a button micro-state machine template; binding parameters and performing transition path deduction on the button micro-state machine template to generate a button state mapping package; analyzing the rendering attributes of the button state mapping package and instantiating nodes to construct a button rendering topology tree; capturing trigger events of the button rendering topology tree and performing operation scheduling on the trigger events to generate an execution chain feedback package; performing context correction, decision re-derivation, and local rendering updates on the execution chain feedback package, and outputting an incrementally updated rendering set. This invention models the rendering context dataset using a graph structure and constructs a button micro-state machine template, improving interface response speed and user experience consistency.

Description

Technical Field

[0001] This invention relates to the field of application software development technology, and in particular to a method for dynamic rendering of list buttons. Background Technology

[0002] With the rapid development of internet applications and enterprise-level information systems, list-based interactive interfaces have become one of the main forms of business operation entry points. Operations such as "edit, delete, approve, export, and jump" within these lists are typically presented as button sets. The order, grouping, visibility, disabled status, and style of these buttons often need to be constrained by multiple sources of context, including user permissions, business status, terminal device type, and operating environment. Current technologies primarily involve statically rendering the button set in the front-end code using conditional statements or simple configuration tables, making a one-time determination based on a single state or role only when the page loads. Alternatively, a general permission engine or rule engine can be introduced, with the back-end outputting a "set of available operations," which the front-end then renders according to a fixed template.

[0003] However, existing technologies still have some shortcomings. Most solutions only consider a single dimension of permissions or business status, making local judgments on button visibility and availability. It is difficult to simultaneously characterize "permission constraints, environment constraints, state constraints, and competitive relationships such as mutual exclusion, dependency, and order between buttons" under a unified structure. This can easily lead to problems where some buttons, which should logically be hidden or disabled in specific scenarios, are still rendered. Existing solutions often adopt a full recalculation and full re-rendering processing mode, lacking the ability to abstract button behavior characteristics into state logic and perform transition deduction and incremental updates through state machines or graph structures. When user operations trigger context changes, the permission judgment and template rendering process often need to be re-run, which increases the coupling between the front-end and back-end and is not conducive to ensuring response performance and consistency of interface behavior in high-frequency interaction scenarios. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a method for dynamically rendering list buttons to solve the problems of being unable to handle button competition and lacking efficient dynamic update capabilities.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] This invention provides a method for dynamically rendering list buttons, comprising:

[0008] Collect a rendering context dataset, perform graph structure modeling on the rendering context dataset, and construct a button competition graph;

[0009] Analyze the relationship constraints of the button competition graph and arrange conflict decisions to generate a button decision structure, and extract the behavioral feature set of the button decision structure;

[0010] State logic modeling is performed on the behavioral feature set, a button micro-state machine template is constructed, parameter binding and transition path deduction are performed on the button micro-state machine template, and a button state mapping package is generated.

[0011] Analyze the rendering properties of the button state mapping package and instantiate the nodes, construct the button rendering topology tree, capture the triggering events of the button rendering topology tree, perform operation scheduling on the triggering events, and generate an execution chain feedback package;

[0012] The execution chain feedback package performs context correction, decision re-derivation, and local rendering updates, and outputs an incrementally updated rendering set.

[0013] As a preferred embodiment of the dynamic rendering method based on list buttons described in this invention, the rendering context dataset includes user context data, environment context data, list row data, and button metadata.

[0014] As a preferred embodiment of the dynamic rendering method based on list buttons described in this invention, the specific steps for modeling the rendering context dataset into a graph structure and constructing a button competition graph are as follows.

[0015] Parse the permission rules in the user context data and perform condition matching to obtain the permission constraint set;

[0016] Perform layout constraint analysis and visibility rule parsing on the environmental context data to generate an environmental constraint set;

[0017] Extract the fields from the list row data and perform state condition parsing to output the state constraint set;

[0018] Perform attribute parsing and relation rule extraction on the button metadata to generate a button relation rule set;

[0019] The permission constraint set, environment constraint set, state constraint set, and button relationship rule set are mapped graphically to construct a button competition relationship graph.

[0020] As a preferred embodiment of the dynamic rendering method based on list buttons described in this invention, the specific steps for parsing the relationship constraints of the button competition graph and arranging conflict decisions to generate a button decision structure are as follows.

[0021] Perform relationship classification parsing on the button competition graph to obtain the relationship classification package;

[0022] Identify execution conflicts in relational classification packages and perform reduction solutions to generate a conflict reduction result set;

[0023] Derive the executable decision chains of the conflict reduction result set and rewrite the conditions, then output the set of feasible decision chains;

[0024] The presentation order of the feasible decision chain is planned, and the behavioral logic is abstracted to generate the button decision structure.

[0025] As a preferred embodiment of the dynamic rendering method based on list buttons described in this invention, the specific steps for extracting the behavioral feature set of the button decision structure are as follows:

[0026] Parse the operation attributes of the button decision structure and obtain the operation attribute tag set;

[0027] Analyze the relational patterns of the button decision structure and output a set of behavioral role labels;

[0028] The operation attribute tag set and the behavior role tag set are aggregated and merged to generate a behavior feature set.

[0029] As a preferred embodiment of the dynamic rendering method based on list buttons described in this invention, the specific steps for modeling the state logic of the behavioral feature set and constructing a button micro-state machine template are as follows:

[0030] Divide the state nodes into behavioral feature sets, obtain the state node set, parse the transition conditions of the state node set, and generate a transition condition set.

[0031] Assemble the state logic of the state node set and the transition condition set to construct a button micro-state machine template.

[0032] As a preferred embodiment of the dynamic rendering method based on list buttons described in this invention, the specific steps for binding parameters and performing transition path deduction on the button micro-state machine template to generate a button state mapping package are as follows.

[0033] Based on the rendering context dataset, perform parameter binding on the button micro-state machine template to generate a bound state machine;

[0034] Perform condition evaluation and reachability analysis on the bound state machine to obtain the reachable state set;

[0035] The system deduces the transition path of the reachable state set and aggregates the presentation attributes to generate a button state mapping package.

[0036] As a preferred embodiment of the dynamic rendering method based on list buttons described in this invention, the specific steps for analyzing the rendering attributes of the button state mapping package and instantiating nodes to construct a button rendering topology tree are as follows.

[0037] Parse the rendering fields of the button state mapping package to generate a set of rendering attributes;

[0038] Instantiate button nodes based on the rendering attribute set, and obtain the button node set;

[0039] Perform hierarchical relationship deduction and topological connection on the button node set to construct the button rendering topology tree.

[0040] As a preferred embodiment of the dynamic rendering method based on list buttons described in this invention, the specific steps of capturing the trigger event of the button rendering topology tree, performing operation scheduling on the trigger event, and generating an execution chain feedback package are as follows.

[0041] Perform event binding parsing on the button rendering topology tree to generate an event binding set;

[0042] Capture the triggered event based on the event binding set, parse the behavior logic of the triggered event, and obtain the event parsing result set;

[0043] Perform operation scheduling and execution chain concatenation on the event parsing result set to generate an execution chain feedback package.

[0044] As a preferred embodiment of the dynamic rendering method based on list buttons described in this invention, the steps of performing context correction, decision re-derivation, and local rendering update on the execution chain feedback package, and outputting an incrementally updated rendering set, are as follows:

[0045] Based on the execution chain feedback packet, perform context correction operations on the rendering context dataset to generate a corrected dataset;

[0046] Using the corrected dataset, a decision re-derivation is performed on the button competition graph to form a corrected button structure;

[0047] Modify the structure via the button to perform a partial rendering update and generate an incrementally updated rendering set.

[0048] The beneficial effects of this invention are as follows: by performing graph structure modeling on the rendering context dataset and performing relation conflict reduction, a button decision structure that can explicitly express mutual exclusion, dependency and order constraints is constructed, realizing unified judgment of rendering logic under multi-source constraints; by abstracting behavioral features into transferable states and constructing button micro-state machine templates, a button state mapping package that can dynamically evolve with the context is obtained, realizing the transformation of buttons from static rules to runtime state-driven, overcoming the latency and instability caused by full recalculation, and improving interface response speed and user experience consistency. Attached Figure Description

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

[0050] Figure 1 This is a flowchart of a method for dynamically rendering based on list buttons.

[0051] Figure 2 A flowchart for rendering the topology tree for the button.

[0052] Figure 3 A flowchart for generating the button decision structure and behavior feature set.

[0053] Figure 4 A flowchart for rendering the topology tree and generating incremental update render sets for buttons. Detailed Implementation

[0054] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0055] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0056] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0057] Reference Figures 1-4 This is one embodiment of the present invention, which provides a method for dynamically rendering list buttons, including the following steps:

[0058] S1. Collect the rendering context dataset, perform graph structure modeling on the rendering context dataset, and construct a button competition relationship graph.

[0059] S1.1 The rendering context dataset includes user context data, environment context data, list row data, and button metadata.

[0060] It should be noted that user context data is obtained by reading user login status, permission configuration files, and locally stored user preference information; environment context data is collected by calling the device information interface, display area query interface, and network status query interface provided by the terminal, including device type, screen size, theme mode, and current available network conditions; list row data is obtained by the front end through field parsing after obtaining the response content of the business data interface, extracting status fields, business identifiers, and associated fields from the returned data records; button metadata is read from the button configuration file when the interface loads and the configuration data at runtime, including button identifier, grouping information, show / hide conditions, disable conditions, style parameters, and event binding information.

[0061] S1.2 Parse the permission rules of the user context data and perform condition matching to obtain the permission constraint set.

[0062] It should be noted that, by consulting the permission rule file corresponding to the permission code (the permission rule file is provided with the business application installation package and contains the mapping relationship between permission codes and operation scopes), the permission code conditions, such as the allowed conditions and restricted conditions associated with the permission code, are extracted; the role information in the user context data is matched with the operation restriction fields recorded in the role entries and compared with the restriction condition entries in the permission rule file to identify the role's enable conditions, prohibit conditions, and hide conditions, etc.; the user preference fields in the user context data are read, and the display selection, availability settings, or behavior restriction information recorded in the preference fields are parsed into intuitive user preference conditions; the permission code conditions, role restriction conditions, and user preference conditions are merged item by item in a fixed order to form a permission constraint set with a consistent structure.

[0063] S1.3 Perform layout constraint analysis and visibility rule parsing on the environmental context data to generate an environmental constraint set.

[0064] The system reads the device type field from the environment context data and, by retrieving the device adaptation parameter table released with the application, determines the allowed layout methods and arrangement densities when the button list is displayed. It also reads the screen size and display area information and, by comparing the size classification conditions in the adaptation parameter table, determines the maximum number of visible rows that can be used in the button list, the number of buttons that can be loaded per row, and the aspect ratio of the scrollable area. The system parses the theme settings field from the environment context data, converting the brightness mode, contrast requirements, and visual layering rules corresponding to the theme into visibility conditions that can participate in rendering decisions. Finally, it reads the network status from the environment context data and, based on the network level and latency parameters recorded in the parameter table, uses the button's enabled state and lazy loading behavior as network-related conditions. The layout conditions, size conditions, visibility conditions, and network-related conditions are then structurally merged in a fixed order to form an environment constraint set.

[0065] S1.4 Extract the fields of the list row data and perform state condition parsing to output the state constraint set.

[0066] It should be noted that the business identifier field in the list row data is read, and the business category corresponding to the current business identifier and the scope of button actions involved are determined by consulting the field description table provided with the business interface definition file (including API documentation, data dictionary, and field specification document); the status field in the list row data is extracted, and the business status value recorded in the status field is matched with the status judgment conditions in the field description table to identify the status matching conditions such as allowed operation conditions, restricted operation conditions, and hidden conditions corresponding to the business status value; the association field in the list row data is read, and the parent-child business relationship, approval relationship, or status dependency information recorded in the association field is parsed and converted into status dependency conditions that can be used for relationship identification; the business category conditions, status matching conditions, and status dependency conditions are structurally merged in a fixed order to form a set of status constraints.

[0067] S1.5 Perform attribute parsing and relation rule extraction on the button metadata to generate a button relation rule set.

[0068] It should be noted that the button identifier field in the button metadata is read, and the button's display position in the list, its logical group, and its association with other buttons are determined by consulting the button definition description record attached to the interface configuration file. The display / hidden condition field in the button metadata is parsed, and the field names in the condition expression are matched with the fields in the rendering context dataset to extract the trigger conditions used to determine whether to show or hide the button, which are then used as display / hidden condition entries. The disable condition field in the button metadata is parsed, and the state constraints, role constraints, or device restriction information recorded in the disable rules are converted into disable condition entries that can be used for relationship identification. The event binding information in the button metadata is read, and the event target, trigger method, and callback condition are logically decomposed and converted into event dependency conditions that can participate in relationship analysis. The grouping information is parsed, and the grouping relationship corresponding to the button identifiers under the same group is recorded as group dependency conditions. The display / hidden condition entries, disable condition entries, event dependency conditions, and group dependency conditions are structured and merged in a predetermined order to form a button relationship rule set.

[0069] S1.6. Map the permission constraint set, environment constraint set, state constraint set and button relationship rule set into a graph to construct a button competition relationship graph.

[0070] It should be noted that the process involves reading button identifiers and group dependencies, visibility relationships, and event dependencies from the button relationship rule set, registering each button identifier as a node entry; traversing the permission condition entries from the permission constraint set, converting permission conditions that mutually exclude or restrict the same button into mutually exclusive edges or disabled edges between nodes; traversing the layout and visibility conditions from the environment constraint set, recording button overlay and collapse relationships caused by device type, screen size, or network status as overlay edges or visibility edges; traversing the business state conditions and state dependency conditions from the state constraint set, converting pre-dependencies and post-operations based on business states into dependency edges or sequence edges; after completing the mapping of constraint entries to graph edge relationships, combining all node entries and edge entries according to the graph structure storage format to form a button competition relationship graph containing a set of nodes and multiple types of edge sets; edge entries recording mutually exclusive or disabled edges as mutually exclusive entries, edge entries recording overlay edges as overlay entries, edge entries recording visibility edges formed by visibility conditions as visibility entries, edge entries recording dependency edges as dependency entries, and edge entries recording sequence edges as sequence entries.

[0071] S2. Analyze the relationship constraints of the button competition graph and arrange conflict decisions to generate the button decision structure and extract the behavioral feature set of the button decision structure.

[0072] S2.1 Perform relationship classification parsing on the button competition relationship graph to obtain the relationship classification package.

[0073] It should be noted that all edge entries in the button competition graph are read. Based on the mutual exclusion, disable, override, show / hide, dependency, and order markers on the edge entries, each edge entry is judged. Edge entries indicating that buttons cannot be effective simultaneously or are mutually exclusive are classified into the mutual exclusion subset. Edge entries indicating that one button depends on the execution result of another button or has a prerequisite are classified into the dependency subset. Edge entries indicating that one button covers, collapses, or replaces other buttons in the layout are classified into the override subset. Edge entries that control the display and hide based on the show / hide conditions are classified into the show / hide subset. Edge entries that reflect the order of operation execution are classified into the order subset. Other edge entries are recorded as extended subsets. The mutual exclusion subset, dependency subset, override subset, show / hide subset, order subset, and extended subset are packaged according to a unified data structure to form a relation classification package.

[0074] S2.2 Identify execution conflicts in relational classification packages and perform reduction solutions to generate conflict reduction result sets.

[0075] It should be noted that the process involves traversing the subsets of mutually exclusive and dependent relationships, comparing mutually exclusive and dependent entries involving the same button pair, and marking cases where one party requires simultaneous existence while the other requires non-existence as mutual exclusion and dependency conflicts; traversing the subsets of overlay and explicit / implicit relationships, performing condition overlap analysis on cases where the same button is marked as simultaneously displayed, covered, or hidden in different relationship entries, and marking records expressing opposite display effects or contradictory priorities as display conflicts; traversing the subset of sequential relationships, performing loop detection and sequence consistency checks on sequential edge entries forming circular dependencies or contradictory execution orders, and marking detected loop relationships as sequence conflicts; and comparing the relationship entries marked as conflicting according to the data source of the constraint entries, prioritizing entries from the permission rule file, second-best entries from the field description table, and entries from the button definition description record. For general entries, entries from the device adaptation parameter table are used as auxiliary entries. When there is overlap in the condition range within the same source file, the relationship condition entries with higher accuracy scores (including mutually exclusive entries, dependency entries, overriding entries, explicit / implicit entries, and sequence entries) are retained. When the priority order of the sources cannot be distinguished, the relevant entries are merged to form a unified specification expression. If it is a permission condition entry or a state matching condition, the intersection specification is performed on the condition value range to obtain the minimum condition range that is commonly satisfied. If it is an explicit / implicit condition entry, a disabled condition entry, or an overriding entry, explicit / implicit specification is performed according to the predetermined priority order "hidden > disabled > displayed". If there are inconsistent directions in the dependency or sequence relationship but they do not constitute a loop, the triggering conditions are merged in a logical "OR" manner to form a unified dependency expression that can be satisfied simultaneously. The adjusted relationship entries are organized into a conflict specification result set in a structured format.

[0076] The expression for calculating the accuracy score is:

[0077] ;

[0078] in, Indicates the first The precision score of each relation condition item. Indicates the first The interval specificity index of each relation condition item. Indicates the first The logical complexity index of each relation condition entry. Indicates the first Field granularity metrics for each relation condition entry. Indicates the interval specificity weight. Indicates the weight of logical complexity. This indicates the field granularity weight.

[0079] It should also be noted that by directly reading the judgment expression in the relation condition entry, when the judgment expression contains upper and lower limits (such as a≤x≤b), the difference between the upper and lower limits is used as the interval width; when the judgment expression is a discrete set (such as x∈{1,3,7}), the number of elements in the discrete set is used as the set width; and the interval width or the sum of the reciprocals of the set width is used as the interval specificity index.

[0080] The sum of the number of atomic conditions and the number of logical symbols in a relation condition entry is used as a logical complexity index. An atomic condition refers to an independent judgment expression that contains only a single field name, comparison symbol, and comparison value, without any logical connectors.

[0081] By reading the field name recorded in each atomic condition in the relation condition entry, the field name is divided into multiple hierarchical segments by dot numbers, and the sum of the number of all hierarchical segments is used as the field granularity index.

[0082] The conditional logic complexity weight is obtained by normalizing the number of logical operators in the relation condition entries; the field reference count weight is obtained by normalizing the number of fields appearing in the relation condition entries; and the field granularity weight is obtained by normalizing the number of hierarchical segments of fields in the relation condition entries.

[0083] S2.3 Derive the executable decision chain of the conflict reduction result set and rewrite the conditions to output the feasible decision chain set.

[0084] It should be noted that the dependency entries recorded in the conflict specification result set are read, and the dependency entries are concatenated one by one according to the dependency relationship to form a preliminary decision chain segment. During the concatenation process, button nodes that would cause mutual exclusion conflicts are excluded based on mutual exclusion entries. For each button node in the preliminary decision chain segment, display and hidden entries and overriding entries are matched. The execution conditions of the preliminary decision chain segment are modified according to the display conditions in the display and hidden entries and the overriding conditions in the overriding entries. Button nodes that do not meet the conditions of the current rendering context dataset are removed from the chain segment. The chain segment after removal and adjustment is compared with the order entries. When the execution order relationship required by the order entries is consistent with the current rendering context dataset conditions, the button nodes that do not meet the current rendering context dataset conditions are removed from the chain segment. The chain segment after removal and adjustment is compared with the order entries. When the existing order of chain segments is inconsistent, the chain segments are rearranged according to the order requirements of the sequence entries to form corrected chain segments that satisfy dependency and order conditions. The condition fields in the corrected chain segments are rewritten with the corresponding fields in the rendering context dataset. The permission conditions, status conditions, explicit / implicit conditions, or device conditions used in the condition logic are standardized and replaced according to the field names in the rendering context dataset, so that the condition expressions form an executable format that can reference the context fields at runtime. The chain segments formed after dependency concatenation, explicit / implicit correction, order rearrangement, and condition rewriting are organized in a structured format to output a feasible decision chain set.

[0085] It should also be noted that the rendering context dataset conditions refer to the set of conditions recorded in the rendering context dataset, such as permission conditions, layout conditions, visibility conditions, state conditions, and button attribute conditions, used to determine whether a button is displayed, executable, and allowed to participate in the decision chain in the current scene.

[0086] S2.4. The presentation order of the feasible decision chain set is planned, and the behavioral logic is abstracted to generate the button decision structure.

[0087] It should be noted that the button identifier order, associated sequence entries, and sorting fields and grouping information recorded in the button metadata of each decision chain in the feasible decision chain set are read. Based on the grouping information, button identifiers belonging to the same logical group are grouped into the same presentation branch. The button identifiers within the same branch are arranged and adjusted according to the order relationship of the sorting fields and sequence entries to obtain a button presentation order that meets the requirements of business execution order and interface display. While determining the button presentation order, the permission conditions, status conditions, visibility conditions, disabling conditions, and event binding information corresponding to each button identifier in the decision chain are summarized. The triggering method, execution target, dependency relationship, and restrictive conditions of the button in the current decision chain are abstracted into behavior description fields and relationship description fields. Based on the button identifier presentation order information, behavior description fields, and relationship description fields, the presentation position, group, executable conditions, and dependency or mutual exclusion relationship between each button and other buttons are recorded as decision entries in a unified structure. All decision entries are combined in a structured format to form a button decision structure.

[0088] S2.5. Parse the operation attributes of the button decision structure and obtain the operation attribute tag set.

[0089] It should be noted that the operation type field, execution target field, scope field, execution method field, and risk-related field of each decision entry recorded in the button decision structure are read. The values ​​in the operation type field that represent creation, editing, deletion, approval, export, jump, etc. are grouped into operation type labels according to the classification dimension. The business object, data entity, or interface area information identified in the execution target field is abstracted into the target object label. The scope information recorded in the scope field that represents the scope of single record operation, batch operation, or cross-list operation is abstracted into the scope of influence label. The information in the execution method field that represents the method of synchronous execution, asynchronous execution, confirmation required, or reversal is abstracted into the execution mode label. The high-risk operation prompt requirements or the degree of impact of sensitive data recorded in the risk-related field are abstracted into the risk level label. The operation type label, target object label, scope of influence label, execution mode label, and risk level label are aggregated and organized according to the button identifier. All types of labels related to the same button are recorded as operation attribute label entries in a unified structure. The operation attribute label entries corresponding to all buttons are output in set form to form an operation attribute label set.

[0090] S2.6 Analyze the relational patterns of the button decision structure and output the set of behavior role labels.

[0091] It should be noted that, after traversing all dependencies in the button decision structure, button identifiers that appear only as the foreground in any dependency and not as the background in any dependency are marked as driving role candidates; after traversing all dependencies again, button identifiers that appear only as the background in any dependency and not as the foreground in any dependency are marked as termination role candidates; after traversing all mutual exclusion relationships, button identifiers that appear as one end of at least two mutual exclusion relationships and are located in the earlier position within the same group in the presentation position field are marked as master role candidates; after jointly analyzing dependencies and sequence relationships, button identifiers that appear only as subordinate nodes in dependencies and are always not located in the first position in sequence relationships are marked as auxiliary role candidates; after parsing the execution target field and operation type field in the decision entries, button identifiers whose execution target is page jump, view switching, or list range switching are marked as navigation role candidates. Using button identifiers as indices, the markings of the same button in the candidate drive role, candidate termination role, candidate master role, candidate auxiliary role, and candidate navigation role are merged. When the same button meets multiple candidate conditions, the main behavior role of the button is determined according to a fixed priority order: drive role takes precedence over master role, master role takes precedence over navigation role, navigation role takes precedence over auxiliary role, and auxiliary role takes precedence over termination role. The obtained main behavior roles are recorded as behavior role tag entries in a unified format. The behavior role tag entries corresponding to all buttons are output in set form to form a behavior role tag set.

[0092] S2.7 Aggregate and merge the operation attribute tag set and the behavior role tag set to generate a behavior feature set.

[0093] It should be noted that, using the button identifier as the aggregation index, the operation type label, target object label, scope of influence label, execution mode label, and risk level label corresponding to the button identifier in the operation attribute label set are merged with the behavior role labels recorded in the behavior role label set in field order. An aggregation entry is created for each button identifier, and the label fields recorded in the operation attribute label set are written into the attribute fields corresponding to the aggregation entry item by item. The role labels recorded in the behavior role label set are written into the role fields corresponding to the aggregation entry item. For content with logical repetition or semantic inclusion relationship in the label fields, a merging and simplification process is performed. Labels expressing the same meaning are retained as a single label, and content expressing the same role characteristic by multiple labels is merged into a unified role label. All aggregation entries that have completed aggregation and simplification are output in set format to form a behavior feature set.

[0094] S3. Perform state logic modeling on the behavior feature set, construct a button micro-state machine template, perform parameter binding and migration path deduction on the button micro-state machine template, and generate a button state mapping package.

[0095] S3.1. Divide the state nodes of the behavioral feature set, obtain the state node set, parse the transition conditions of the state node set, and generate the transition condition set.

[0096] It should be noted that by combining and judging the operation type label, target label, scope of influence label, execution mode label, risk level label, and behavior role label recorded in each aggregated entry of the behavior feature set, aggregated entries with the same operation type label, behavior role label, and execution mode label are merged into the same state node. A corresponding state node record is established for each group of merged aggregated entries to form all state nodes contained in the state node set. After the state node division is completed, the execution logic between adjacent aggregated entries in the behavior feature set is read, and the operation type label and behavior role label of adjacent aggregated entries in the behavior feature set are determined. If the execution mode label changes, it is recorded as a migration action. When generating a migration action, the state node before the migration action occurs is used as the starting state node, and the state node after the migration action occurs is used as the target state node. State node pairs are formed according to the pairing format of "(starting state node, target state node)". The trigger condition field corresponding to the migration action is matched with the permission conditions, state conditions, visibility conditions or device conditions in the rendering context dataset. The matching result is recorded as the migration condition between state nodes in the migration condition entry. All migration condition entries are organized by state node pairs and output in a unified format to form a migration condition set.

[0097] S3.2 Assemble the state logic of the state node set and the transition condition set to construct the button micro-state machine template.

[0098] It should be noted that the process involves reading the node identifier, node attribute fields, and associated operation type, behavior role, and execution mode labels corresponding to each state node in the state node set, and registering the state node as the starting state record in the button microstate machine template. For each migration condition entry in the migration condition set that starts from the current state node, the process reads it one by one, writes the target state node identifier recorded in the migration condition entry into the migration target field corresponding to the starting state record, and writes the trigger condition field recorded in the migration condition entry into the trigger condition field corresponding to the starting state record. All migration condition entries starting from the current state node are then organized according to field order, and the migration target field and trigger condition field are combined and recorded as a migration action record, which is then written into the button microstate machine template. After completing the migration action record for the current state node, the same method is used to assemble migration actions for other state nodes in the state node set, recording all state nodes and their corresponding migration actions according to a unified state logic structure in the button microstate machine template.

[0099] S3.3. Based on the rendering context dataset, perform parameter binding on the button micro-state machine template to generate a bound state machine.

[0100] It should be noted that the following steps are performed: First, the permission conditions, environment conditions (including layout and visibility conditions), state conditions, and button attribute conditions in the rendering context dataset are read. Then, the condition fields related to the operation type label, behavior role label, and execution mode label recorded in the state node are matched. The matched context fields are written as parameters to the corresponding parameter fields of the state node, forming the parameter binding record for the state node. Second, the field names containing variable references are extracted from the trigger condition fields of each migration action. These field names are matched one-to-one with the corresponding fields in the rendering context dataset. The field variables used in the button micro-state machine template are replaced with the actual field names from the rendering context dataset as specific parameter references. The replaced conditional expressions are written to the trigger condition fields corresponding to the migration action, forming the parameter binding record for the trigger condition. Finally, the state node records and migration action records with completed parameter binding are recombined according to their original state logic order and output in a unified format to form a bound state machine.

[0101] S3.4 Perform condition evaluation and reachability node analysis on the bound state machine to obtain the reachable state set.

[0102] It should be noted that, taking each transition action in the bound state machine as the calculation object, the atomic conditions concatenated by logical operators in the trigger condition expression recorded in the transition action are separated, so that each atomic condition contains only one field, one comparison method, and one comparison value. The validity of each atomic condition is judged according to the corresponding field value in the rendering context dataset. A valid return value is represented as 1, and a false return value is represented as 0. When at least one atomic condition in the validity judgment result is valid, the target state node is considered to be a reachable node. The reachable nodes calculated by all transition actions in the bound state machine are collected in a set form to form a reachable state set.

[0103] The expression that returns a true value is:

[0104] ;

[0105] in, Indicates from the state node To the state node The return value between them is true. Indicates the first The Boolean judgment results of each atomic condition in the current rendering context dataset. This represents the total number of atomic conditions.

[0106] S3.5. Derive the transition path of the reachable state set and aggregate the presentation attributes to generate a button state mapping package.

[0107] It should be noted that, taking the state nodes and outgoing edge transition actions recorded in the bound state machine as the starting point of deduction, all reachable transition actions and corresponding target state nodes associated with the starting point in the reachable state set are read. The transition actions are then expanded layer by layer between state nodes, and the state transition path sequence is formed by recording them according to the access order of the state nodes. In the process of constructing the state transition path sequence, the operation type label, behavior role label, and execution mode label recorded in the button micro-state machine template of the state nodes passed through each transition path are read. At the same time, the permission conditions, state conditions, visibility conditions, and device conditions contained in the trigger condition fields corresponding to the transition actions on the transition path are read. All label information and condition fields are aggregated and organized according to the order of the transition path to form a set of presentation attributes. The set of presentation attributes that the same button identifier appears in different state transition paths is summarized. The permission conditions, state conditions, visibility conditions, and execution modes recorded in the path-level presentation attribute set are merged and simplified to obtain the comprehensive presentation attribute record in different states. The comprehensive presentation attribute record of all state nodes in the reachable state set is output in set form to form a button state mapping package.

[0108] S4. Analyze the rendering properties of the button state mapping package and instantiate the nodes, construct the button rendering topology tree, capture the trigger events of the button rendering topology tree, perform operation scheduling on the trigger events, and generate the execution chain feedback package.

[0109] S4.1 Parse the rendering fields of the button state mapping package and generate a rendering attribute set.

[0110] It should be noted that the button state mapping entries are read one by one from the button state mapping package. Using the button identifier and state identifier as parsing indexes, the visibility condition field, disable condition field, execution mode field, and style parameter field, layout position field, and interactive tooltip field recorded in the button state mapping entries are parsed sequentially. The judgment conditions used to control the display and hiding in the visibility condition field are organized into visibility attributes. The judgment conditions used to control clickability in the disable condition field are organized into usability attributes. The color configuration, font configuration, border configuration, and icon configuration in the style parameter field are organized into style attributes. The row and column position, alignment, and width occupied in the layout position field are organized into layout attributes. The synchronous execution mode, asynchronous execution mode, confirmation required, and floating tooltip information recorded in the execution mode field and interactive tooltip field are organized into interactive attributes. Using the button identifier and state identifier as indexes, the visibility attributes, usability attributes, style attributes, layout attributes, and interactive attributes are recombined and recorded as rendering attribute entries in a fixed field order. The rendering attribute entries generated from all button state mapping entries are output in set form to form a rendering attribute set.

[0111] S4.2 Instantiate button nodes based on the rendering attribute set and obtain the button node set.

[0112] It should be noted that the rendering attribute entries are read one by one from the rendering attribute set. The button identifiers and status identifiers recorded in the rendering attribute entries are concatenated into strings in a fixed order, and the current rendering round number is used as a suffix to generate a button node identifier, which is then written into the identifier field of the button node entry. The visibility attribute in the same rendering attribute entry is parsed, and the judgment conditions used to control the display and hiding are recorded and written into the visibility control field of the button node entry. The usability attribute is parsed, and the judgment conditions used to control whether it is clickable or not are recorded and written into the usability control field of the button node entry. The style attribute is expanded, and the color configuration is... The font configuration, border configuration, and icon configuration are written into the style field of the button node entry. The layout attributes are expanded, and the row and column positions, alignment, and occupied width are written into the layout field of the button node entry. The interaction attributes are expanded, and the synchronous or asynchronous execution mode, confirmation prompt requirements, and floating prompt information are written into the interaction field of the button node entry. After completing the above identifier generation and field writing, the record containing the button node identifier, visibility control field, availability control field, style field, layout field, and interaction field is registered as a button node entry. All button node entries in the rendering attribute set are output in set form to form a button node set.

[0113] S4.3 Perform hierarchical relationship deduction and topological connection on the button node set to construct the button rendering topology tree.

[0114] It should be noted that the row and column positions, alignment, and width occupied of each button node entry are read from the layout field of the button node set. Button nodes with the same row number are sorted according to column number and alignment. Button nodes with the same row number and adjacent column numbers are recorded as sibling node candidates at the same level. Button nodes with smaller row numbers are recorded as upper-level node candidates. Button nodes with larger row numbers and column numbers within the range of upper-level node column numbers are recorded as lower-level node candidates. Based on the row and column inclusion relationship between upper-level node candidates and their corresponding lower-level node candidates, lower-level nodes that satisfy the column number inclusion relationship are registered as child nodes of their corresponding upper-level nodes. A parent-child hierarchy relationship record is generated for each pair of parent and child nodes. At the same time, the order relationship between adjacent sibling nodes in the same row is recorded as a sibling order relationship record. All parent-child hierarchy relationship records and sibling order relationship records are organized, and each button node entry is associated with its corresponding parent node, child node, and sibling node to construct a button rendering topology tree.

[0115] S4.4 Perform event binding parsing on the button rendering topology tree to generate an event binding set.

[0116] It should be noted that the button node identifier and interaction field information of each button node entry are read one by one from the button rendering topology tree. Based on the parent-child hierarchy and sibling order of the button node identifier in the button rendering topology tree, the path position of the current button node in the tree structure is determined, and the path position is recorded as the event propagation path identifier. The event trigger type, trigger method, and event target identifier inherited from the button metadata in the interaction field of the button node are parsed. The event trigger types such as click, long press, swipe, and hover are recorded as the event type field, the trigger methods generated by mouse, touch, or keyboard input are recorded as the input method field, and the execution action number or callback identifier recorded in the event target identifier is recorded as the processing target field. At the same time, the event propagation mode information recorded in the interaction field is parsed. The propagation mode that indicates priority processing in the parent node is recorded as "top to bottom", and the propagation mode that indicates priority processing in the current node and its lower-level nodes is recorded as "bottom to top". All propagation modes are recorded in the event propagation direction field.

[0117] Based on the parent-child relationships and sibling order in the button rendering topology tree, parent and child nodes on the same path are compared. When the event triggering types of the parent and child nodes are the same and the input methods are compatible, the event handling target of the child node is recorded as a candidate target that can participate in event bubbling or capturing. The path is sorted in conjunction with the event propagation direction field. When the event propagation direction field is "top to bottom", the node sequence is formed in the hierarchical order from the starting parent node of the path to the current button node. When the event propagation direction field is "bottom to top", the node sequence is formed in the reverse hierarchical order from the current button node to the starting parent node of the path. The event propagation scope field is created by generating a node sequence and writing the node sequence into the event propagation range field. The control information recorded in the interaction field, which indicates whether interruption of propagation is allowed, is parsed. When the interaction field marks that the current button node can prevent subsequent nodes from continuing to process after execution, the current mark is written into the interruption control field. The numerical value in the interaction field that represents the processing order between different button nodes on the same path is recorded as the event priority field. Using the button node identifier as an index, all fields are combined and recorded as event binding entries. The event binding entries generated by all button nodes in the button rendering topology tree are output in set form to form an event binding set.

[0118] S4.5. Capture the triggered event based on the event binding set and parse the behavioral logic of the triggered event to obtain the event parsing result set.

[0119] It should be noted that during the operation of the monitoring program, user interaction signals generated on the terminal are recorded in chronological order as trigger event entries. The event type, input method, and target component identifier are parsed from each trigger event entry. The button node identifier corresponding to the target component identifier is located in the button rendering topology tree. Using the event type and input method as matching conditions, event binding entries matching the button node identifier are retrieved from the event binding set. A one-to-one correspondence is established between the successfully matched event binding entries and the current trigger event entry. For each pair of associated trigger events… Event entries and event binding entries are generated. The event binding entries read the event handling target field, event propagation path identifier, and event propagation range field. The button node set reads the synchronous or asynchronous execution method, confirmation prompt requirements, and floating prompt information recorded in the interaction field of the button node identifier. The event type, input method, button node identifier, event handling target, event propagation path identifier, event propagation range, execution method, and prompt information are combined and recorded in a fixed field order as event parsing result entries. All triggering events that have completed behavioral logic parsing are organized and summarized according to the event parsing result entries, and output in set form to form the event parsing result set.

[0120] S4.6 Perform operation scheduling and execution chain splicing on the event parsing result set to generate an execution chain feedback package.

[0121] It should be noted that the scheduling is based on the trigger event identifier, button node identifier, event processing target, event propagation path identifier, event propagation direction field, event propagation range field, interruption control field, event priority field, and timestamp field recorded in the event parsing results. The execution action number or callback identifier recorded in the event processing target is registered as the operation identifier, and the operation identifiers are sorted according to the time sequence corresponding to the same trigger event to obtain the initial operation sequence. When different trigger events correspond to the same event propagation path identifier and the node sequences covered by the event propagation range field overlap, the event priority field is further compared based on the timestamp field sorting. The operation identifier with the larger event priority field value is placed before the operation identifier with the smaller event priority field value to resolve the execution order conflict when the same path is triggered concurrently. Based on the event propagation path identifier and event propagation range, the propagation direction of the operation identifiers in the initial operation sequence is analyzed. When the event propagation range indicates top-down propagation, the operation identifier corresponding to the parent node on the path is used. Prioritize the operation identifiers. When the event propagation range indicates bottom-up propagation, prioritize the operation identifiers corresponding to the child nodes on the path, and record the adjusted order as the propagation sequence. While processing operation identifiers one by one according to the propagation sequence, read the interruption control field of each operation identifier. When the interruption control field indicates that the current operation allows termination of subsequent propagation, and the execution result triggered after the current operation is executed meets the interruption condition, no further operation identifiers will be concatenated on the remaining nodes corresponding to the event propagation range field. Further read the execution method, event type, and input method from the event parsing result entries of all uninterrupted operation identifiers. Use synchronous or asynchronous execution methods as scheduling strategies, and event types and input methods as execution constraints, and combine them with the corresponding operation identifiers to record them as execution step entries. Concatenate the execution step entries according to the propagation sequence to form an execution chain entry containing trigger event identifiers, button node identifier sequences, operation identifier sequences, execution method sequences, and propagation path information. Organize all execution chain entries into an execution chain feedback package in set form.

[0122] S5. Perform context correction, decision re-derivation, and local rendering update on the execution chain feedback package, and output the incrementally updated rendering set.

[0123] S5.1. Based on the execution chain feedback packet, perform a context correction operation on the rendering context dataset to generate a corrected dataset;

[0124] It should be noted that the button node identifier, event type, event processing target, and execution method recorded in the execution chain entry serve as the triggering basis for context correction. Based on the button node identifier, the corresponding fields of the associated user context data, environment context data, list row data, and button metadata in the rendering context dataset are located. The event type field is parsed. When the event type represents an operation that can cause a business status update, such as "status change," "approval completed," "submission successful," "row selected," or "row deselected," the target status value recorded in the event processing target is written into the status field of the list row data, forming a status update entry. The event processing target field is parsed. When the event processing target represents a jump, switch, filter, or reload operation, the filter conditions, range conditions, and new identifier in the target parameters are written into the corresponding fields in the rendering context dataset. The system parses the execution method field. When the execution method is asynchronous and requires callback confirmation, the callback result or confirmation flag in the execution chain entry is written into the preference field or permission field in the user context data, forming a user preference correction entry or permission correction entry. The system parses the button metadata corresponding to the button node identifier. When the button node interaction rule requires the relevant button's visibility or disable conditions to change with business actions, the visibility or availability changes recorded in the event chain entry are written into the visibility or disable condition field in the button metadata, forming a button attribute correction entry. All correction entries are written to the corresponding positions according to the field structure of the rendering context dataset, forming a correction dataset containing user context data correction content, environment context data completion content, list row data update content, and button metadata adjustment content.

[0125] S5.2 Using the corrected dataset, perform decision re-derivation on the button competition graph to form a corrected button structure;

[0126] It should be noted that, based on the updated user context data, environment context data, list row data, and button metadata in the corrected dataset, the condition parsing of the permission fields, layout fields, visibility fields, status fields, and button attribute fields recorded in the corrected dataset is re-executed. Permission condition entries are re-extracted from the updated user context data and reorganized into a new permission constraint set; layout conditions, size conditions, visibility conditions, and network-related conditions are re-extracted from the updated environment context data and reorganized into a new environment constraint set; business category conditions, status matching conditions, and status dependency conditions are re-extracted from the updated list row data and reorganized into a new status constraint set; and the show / hide bar is re-extracted from the updated button metadata. The button relationship rule set is reorganized into a new set of rules, including item entries, disabled condition entries, event dependency conditions, and group dependency conditions. The new set of permission constraints, environment constraints, state constraints, and button relationship rules are then rewritten into the corresponding node condition fields and edge condition fields according to the graph structure format of the button competition relationship graph. Relationship classification, conflict identification, and reduction processing are performed on the updated graph structure. The re-reduced relationship entries are then reconnected into decision chains, and explicit / implicit corrections, order adjustments, and condition rewriting are performed on these decision chains. The corrected presentation order, behavioral logic, and constraint relationships are combined and recorded in a unified format as button correction structure entries. All button correction structure entries are output as a set to form the button correction structure.

[0127] S5.3. Modify the structure via the button to perform local rendering updates and generate an incremental update rendering set.

[0128] It should be noted that the button correction structure entries are read one by one from the button correction structure. The button identifier, presentation order, visibility conditions, usability conditions, behavioral logic conditions, and grouping relationships recorded in the button correction structure entries are used as the basis for local rendering updates. The button identifier is matched with the node identifiers in the current button rendering topology tree to locate the target button node that needs updating. The visibility control field of the target button node is compared. If the display / hidden conditions recorded in the button correction structure entry are inconsistent with the display / hidden conditions recorded in the current button node in terms of text content, it is determined that there is a difference in display / hidden conditions. The updated display / hidden conditions are written into the visibility control field of the button node and registered as a display / hidden update entry. The usability control field of the target button node is compared. If the disable conditions recorded in the button correction structure entry are inconsistent with the disable conditions recorded in the current button node in terms of expressed disable logic, it is determined that there is a difference in disable conditions. The updated disable conditions are then updated. The disabling conditions are written into the availability control field of the button node and registered as an availability update entry. The presentation order field of the target button node is compared. If the sorting position of the button correction structure entry is inconsistent with its current position in the sibling node set, it is determined that there is a difference in presentation order. The sibling order relationship is adjusted according to the presentation order recorded in the button correction structure entry and registered as an order update entry. The grouping relationship of the target button node is compared. If the grouping information recorded in the button correction structure entry is not synchronized with the grouping information recorded by the parent node (grouping node) of the button in the original topology tree, it is determined that there is a difference in grouping structure. The parent-child hierarchical relationship is reattached according to the new grouping relationship and registered as a structure update entry. All update entries are aggregated and organized according to the button node identifier. The button node update field, hierarchical structure update field, and order adjustment field are used as incremental update content and output in set form to form an incremental update rendering set.

[0129] It should also be noted that the sibling node set refers to the set of nodes in the button rendering topology tree that share the same parent node as the target button node.

[0130] In summary, this invention achieves unified judgment of rendering logic under multi-source constraints by: performing graph structure modeling on the rendering context dataset and performing relation conflict reduction to construct a button decision structure that can explicitly express mutual exclusion, dependency, and order constraints; and by abstracting behavioral features into transferable states and constructing a button micro-state machine template to obtain a button state mapping package that can dynamically evolve with the context, thereby realizing the transformation of buttons from static rules to runtime state-driven, overcoming the latency and instability caused by full recalculation, and improving interface response speed and user experience consistency.

[0131] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for dynamically rendering list buttons, characterized in that: include, A rendering context dataset is collected, and a graph structure model is performed on the dataset to construct a button competition graph. The specific steps for constructing the button competition graph are as follows. Parse the permission rules in the user context data and perform condition matching to obtain the permission constraint set; Perform layout constraint analysis and visibility rule parsing on the environmental context data to generate an environmental constraint set; Extract the fields from the list row data and perform state condition parsing to output the state constraint set; Perform attribute parsing and relation rule extraction on the button metadata to generate a button relation rule set; The permission constraint set, environment constraint set, state constraint set, and button relationship rule set are mapped graphically to construct a button competition relationship graph; The process involves parsing the relationship constraints of the button competition graph, arranging conflict decisions, generating a button decision structure, and extracting the behavioral feature set of the button decision structure. The specific steps for generating the button decision structure are as follows. Perform relationship classification parsing on the button competition graph to obtain the relationship classification package; Identify execution conflicts in relational classification packages and perform reduction solutions to generate a conflict reduction result set; Derive the executable decision chains of the conflict reduction result set and rewrite the conditions, then output the set of feasible decision chains; The presentation order of the feasible decision chain set is planned, and the behavioral logic is abstracted to generate the button decision structure; The specific steps for extracting the behavioral feature set of the button decision structure are as follows. Parse the operation attributes of the button decision structure and obtain the operation attribute tag set; Analyze the relational patterns of the button decision structure and output a set of behavioral role labels; The operation attribute tag set and the behavior role tag set are aggregated and merged to generate a behavior feature set; State logic modeling is performed on the behavioral feature set to construct a button micro-state machine template. Parameter binding and transition path deduction are then performed on the button micro-state machine template to generate a button state mapping package. The specific steps for constructing the button micro-state machine template are as follows. Divide the state nodes into behavioral feature sets, obtain the state node set, parse the transition conditions of the state node set, and generate a transition condition set. The state node set and the transition condition set are assembled into a state logic to construct a button micro-state machine template. The specific steps for generating the button state mapping package are as follows: Based on the rendering context dataset, perform parameter binding on the button micro-state machine template to generate a bound state machine; Perform condition evaluation and reachability analysis on the bound state machine to obtain the reachable state set; The transition path of the reachable state set is deduced and the presentation attributes are aggregated to generate a button state mapping package; The button state mapping package's rendering attributes are analyzed and nodes are instantiated to construct a button rendering topology tree. Triggering events of the button rendering topology tree are captured, and operation scheduling is performed on these events to generate an execution chain feedback package. The specific steps for constructing the button rendering topology tree are as follows: Parse the rendering fields of the button state mapping package to generate a set of rendering attributes; Instantiate button nodes based on the rendering attribute set, and obtain the button node set; Perform hierarchical relationship deduction and topological connection on the button node set to construct the button rendering topology tree; The specific steps for generating the execution chain feedback package are as follows: Perform event binding parsing on the button rendering topology tree to generate an event binding set; Capture the triggered event based on the event binding set, parse the behavior logic of the triggered event, and obtain the event parsing result set; Perform operation scheduling and execution chain concatenation on the event parsing result set to generate an execution chain feedback packet; The execution chain feedback package performs context correction, decision re-derivation, and local rendering updates, and outputs an incrementally updated rendering set.

2. The dynamic rendering method based on list buttons as described in claim 1, characterized in that: The rendering context dataset includes user context data, environment context data, list row data, and button metadata.

3. The dynamic rendering method based on list buttons as described in claim 1, characterized in that: The specific steps for correcting the execution chain feedback package, re-deriving decisions, and updating local rendering to output an incrementally updated rendering set are as follows. Based on the execution chain feedback packet, perform context correction operations on the rendering context dataset to generate a corrected dataset; Using the corrected dataset, a decision re-derivation is performed on the button competition graph to form a corrected button structure; Modify the structure via the button to perform a partial rendering update and generate an incrementally updated rendering set.

Images