Web-based primitive event attribute decoupling method

Abstract

This disclosure proposes a method for decoupling and binding event attributes of graphical elements on a web platform. The method includes: determining a triggering graphical element and a receiving graphical element; determining a trigger event type corresponding to the triggering graphical element based on its type; determining a receiving event type corresponding to the receiving graphical element based on its type; generating a first executable file corresponding to the triggering graphical element based on its type and the trigger event type; generating a second executable file corresponding to the receiving graphical element based on its type and the receiving event type; and generating an event attribute object based on the triggering graphical element type, the trigger event type, the first executable file, the receiving graphical element type, the receiving event type, and the second executable file. By implementing this method, since the event attributes of graphical elements are managed uniformly in the form of event attribute objects, the graphical elements and event attributes can be decoupled, improving the configuration efficiency of event attributes for graphical elements.

Description

Technical Field

[0001] This disclosure relates to the field of software development technology, specifically to a method for decoupling and binding event attributes of web-based primitives. Background Technology

[0002] In web-based graphical applications, attribute binding for graphical elements is crucial. Graphical elements can include, for example, nodes, lines, graphic elements, images, videos, buttons, input boxes, text, audio, charts, and so on. Following object-oriented design principles, these can be categorized into state attributes and event attributes (event attributes describe the operations associated with the graphical element). State attributes can be bound to graphical elements through direct assignment, while binding event attributes is more complex. For example, it may involve injecting large blocks of code directly into the graphical element to bind event attributes.

[0003] In this approach, the coupling between primitives and event attributes is high, resulting in low efficiency in configuring event attributes for primitives. Summary of the Invention

[0004] This disclosure aims to at least partially address one of the technical problems in the related art.

[0005] Therefore, the purpose of this disclosure is to propose a web-based method for decoupling and binding event attributes of graphic elements, which can decouple graphic elements and event attributes and improve the configuration efficiency of event attributes of graphic elements.

[0006] The Web-based primitive event attribute decoupling and binding method disclosed herein includes: determining the triggering primitive and the receiving primitive; determining the triggering event type corresponding to the triggering primitive based on the type of the triggering primitive, and determining the receiving event type corresponding to the receiving primitive based on the type of the receiving primitive; generating a first executable file corresponding to the triggering primitive based on the type of the triggering primitive and the triggering event type, and generating a second executable file corresponding to the receiving primitive based on the type of the receiving primitive and the receiving event type; and generating an event attribute object based on the type of the triggering primitive, the triggering event type, the first executable file, the type of the receiving primitive, the receiving event type, and the second executable file.

[0007] The web-based method for decoupling and binding event attributes of graphical elements disclosed herein determines the triggering graphical element and the receiving graphical element. Based on the type of the triggering graphical element, it determines the trigger event type corresponding to the triggering graphical element; based on the type of the receiving graphical element, it determines the receiving event type corresponding to the receiving graphical element; based on the type of the triggering graphical element and the trigger event type, it generates a first executable file corresponding to the triggering graphical element; based on the type of the receiving graphical element and the receiving event type, it generates a second executable file corresponding to the receiving graphical element; and based on the type of the triggering graphical element, the trigger event type, the first executable file, the type of the receiving graphical element, the receiving event type, and the second executable file, it generates an event attribute object. Because the event attributes of graphical elements are managed uniformly in the form of event attribute objects, the graphical elements and event attributes are decoupled, improving the configuration efficiency of the event attributes of graphical elements.

[0008] Additional aspects and advantages of this disclosure will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this disclosure. Attached Figure Description

[0009] The above and / or additional aspects and advantages of this disclosure will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, in which:

[0010] Figure 1 This is a flowchart illustrating a Web-based primitive event attribute decoupling binding method proposed in an embodiment of this disclosure;

[0011] Figure 2 This is a schematic diagram of the event attribute editor in an embodiment of this disclosure;

[0012] Figure 3 This is a flowchart illustrating a Web-based primitive event attribute decoupling binding method proposed in another embodiment of this disclosure. Detailed Implementation

[0013] Embodiments of this disclosure are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are used only to explain this disclosure, and should not be construed as limiting this disclosure. Rather, embodiments of this disclosure include all variations, modifications, and equivalents falling within the spirit and scope of the appended claims.

[0014] Figure 1 This is a flowchart illustrating a Web-based primitive event attribute decoupling binding method proposed in an embodiment of this disclosure.

[0015] like Figure 1 As shown, this web-based meta-event attribute decoupling method includes:

[0016] S101: Determine the triggering element and the element to be affected.

[0017] In this context, a triggering element is a graphical element used to trigger an event (e.g., an operation method), while a receiving element is a graphical element that receives the triggered event. For example, the graphical element that triggers an event can be called a triggering element, and the graphical elements affected after the "event" is triggered can be called receiving elements; there are no restrictions on this.

[0018] Optionally, in some embodiments, the triggering element and the receiving element can be determined based on user selection.

[0019] Optionally, in some embodiments, an event property editor can be provided on the web, in which users can select the triggering element and the receiving element.

[0020] Optionally, in some embodiments, the process of determining the triggering element and the receiving element can be implemented by providing an event attribute editor (on the web platform). This event attribute editor includes at least a first selection control (e.g., a dropdown control) and a second selection control. The first selection control is used to select the triggering element, and the second selection control is used to select the receiving element. This allows for personalized configuration of the triggering and receiving elements, improving configuration flexibility and efficiency.

[0021] Optionally, in some embodiments, the event attribute editor further includes a display area; during the process of selecting a triggering element through a first selection control and a receiving element through a second selection control, the triggering element, receiving element, trigger event type, and receiving event type can also be dynamically displayed in the display area. This enables visual configuration of the triggering element and the receiving element, supporting improved configuration efficiency and accuracy.

[0022] Optionally, in some embodiments, a graphic element may be either the graphic element that triggers an event or the graphic element that receives an event; this attribute of the graphic element may also be referred to as a graphic element attribute. This graphic element attribute may be defined for an event attribute object.

[0023] Optionally, in some embodiments, an event attribute structure can be predefined for the event attribute object. The event attribute structure may include various fields such as: unique code (id), name, description, creation date (create_time), update time (update_time), trigger element type (trigger_cell), trigger element event type (trigger_event_type), trigger element executable code block (trigger_code), subject element type (act_cell), subject element event type (act_event_type), subject element executable code block (act_code), and notes. This enables unified storage and management of event attribute objects.

[0024] The meanings and explanations of the above fields are as follows:

[0025] The unique ID represents the unique code of the event attribute object. This unique ID is generated by the backend after the event attribute object is successfully added. The name represents the event attribute name, which can be entered by the user. If the user does not enter a name, it can be set to a default value. The description describes the event attribute and can be entered by the user. If the user does not enter a name, it can be left blank. `create_time` represents the event creation time, which the backend can obtain when it first receives an automatic creation request. `update_time` represents the event update time, which the backend automatically obtains when it receives an update request. `trigger_cell` represents the trigger element (referred to as trigger element), which can be selected via a dropdown list (an optional example of the first selection control mentioned above). `trigger_event_type` represents the trigger event type, which can be selected via a dropdown list (an optional example of the third selection control mentioned above). The dropdown list displays a value that can be filtered using the trigger-cell. Different trigger-cells support different event sources (see Table 1 below for event sources and event types). `trigger_code` represents the executable code block of the trigger element (an optional example of the first executable file mentioned above), which can be generated according to user requirements. `act_cell` represents the receiving element (abbreviated as receiving element), which can be selected via a dropdown list (an optional example of the second selection control mentioned above). `act_event_type` represents the receiving event type, which can also be selected via a dropdown list (an optional example of the fourth selection control mentioned above). The dropdown list displays a value that can be filtered using the `act-cell`. Different `act-cells` support different event sources (see Table 1 below for event sources and event types). `act_code` represents the executable code block of the receiving element (an optional example of the second executable file mentioned above), which can be generated according to user requirements. `Note` represents event comments, which can be entered by the user as supplementary explanations for the event.

[0026] Table 1

[0027]

[0028] For example, an event property editor can be built using a graphics engine on the web (e.g., a web configuration page). This event property editor provides CRUD (Create, Read, Update, Delete) functionality for event property objects. The functional modules and workflow are as follows: Figure 2 As shown. Figure 2This is a schematic diagram of the event attribute editor in an embodiment of this disclosure. The first and second selection controls are shown as dropdown boxes as examples. The event attribute editor can generate event attribute object primitives (e.g., trigger primitives and / or bearer primitives). In the event attribute editor, the user is prompted to select the trigger primitive `trigger_cell` and the bearer primitive `act_cell` from the dropdown boxes. After the user selects, the selected primitives are displayed in real-time on the page (an optional example of the display area of ​​the event attribute editor), supporting convenient one-to-one event binding. Simultaneously, it also supports dragging one or more primitives from the primitive list provided on the side of the event attribute editor onto the page. Then, trigger primitives and bearer primitives can be selected from the primitives displayed on the page, thus effectively applicable to the processing of batches of complex events.

[0029] Optionally, in some embodiments, the triggering graphic element mentioned above can be a global graphic element (e.g., for events originating from the keyboard, events originating from the right click, etc.), or a triggering graphic element, or a single graphic element, such as: a graphic box, a button, text, an input box, an image, voice, video, etc.

[0030] S102: Based on the type of the triggering element, determine the trigger event type corresponding to the triggering element, and based on the type of the receiving element, determine the receiving event type corresponding to the receiving element.

[0031] The type of the triggering element refers to the element type of the triggering element, such as a graphic box or a button. The type of the receiving element refers to the element type of the receiving element, such as an input box or an image, and there are no restrictions on this.

[0032] Optionally, in some embodiments, after determining the triggering element, the trigger event type corresponding to the triggering element (e.g., the trigger_event_type mentioned above) can be determined based on the type of the triggering element, and after determining the receiving element, the receiving event type corresponding to the receiving element (e.g., the act_event_type mentioned above) can be determined based on the type of the receiving element.

[0033] Optionally, in some embodiments, the type of the triggering element, the type of the triggering event, the type of the receiving element, and the type of the receiving event can be used together to form an event attribute object, as can be seen in subsequent embodiments.

[0034] Optionally, in some embodiments, during the process of determining the trigger event type corresponding to the trigger element based on its type, the user may be prompted to configure a trigger event type for the trigger element, and the configured trigger event type may be determined as the trigger event type corresponding to the trigger element. Similarly, during the process of determining the bearing event type corresponding to the bearing element based on its type, the user may be prompted to configure a bearing event type for the bearing element, and the configured bearing event type may be determined as the bearing event type corresponding to the bearing element; alternatively, artificial intelligence may be used to determine both the trigger event type and the bearing event type; or any other possible method may be used to determine both the trigger event type and the bearing event type, without limitation.

[0035] Optionally, in some embodiments, the trigger event type can be configured for the triggering element through visual configuration, and the receiving event type can be configured for the receiving element through visual configuration.

[0036] Optionally, in some embodiments, the event property editor described above may further include a third selection control and a fourth selection control, wherein the third selection control is used to select the trigger event type and the fourth selection control is used to select the subject event type.

[0037] Therefore, when configuring the trigger event type for the triggering element through the event property editor, the trigger event type can be selected using the third selection control, and the selected trigger event type will be confirmed as the trigger event type corresponding to the triggering element. Similarly, when configuring the bearer event type for the bearer element through the event property editor, the bearer event type can be selected using the fourth selection control, and the selected bearer event type will be confirmed as the bearer event type corresponding to the bearer element. This significantly improves the flexibility and accuracy of trigger event type and bearer event type configuration, not only supporting personalized configuration of trigger event types and bearer event types but also greatly improving the configuration efficiency, thus enhancing development efficiency.

[0038] In other words, the above-mentioned determination of the trigger event type corresponding to the triggering element and the bearer event type corresponding to the bearer element through the event attribute editor can be considered as an event filtering based on the type of the triggering element and the type of the bearer element. Through event filtering, the user can be prompted to select the trigger event type trigger_event_type corresponding to the triggering element and the bearer event type act_event_type corresponding to the bearer element.

[0039] Optionally, in some embodiments, to reduce the coupling of events while conforming to the linear unified binding mechanism of event triggering-acceptance, the number of triggering elements can be one, while the number of accepting elements can be multiple. If multiple triggering elements exist, the events corresponding to multiple triggering elements can be split into multiple independent events. For example, if the event is: based on the values ​​of the first two text boxes, the running status is reflected in the third text box, then the first text box can be set as the triggering element (value change event), the second text box as the accepting element (listener), and the third text box as the accepting element (listener). One triggering element corresponds to multiple accepting elements; for example, clicking the start button (triggering element) can control the start of multiple devices (achieved through multiple independent accepting elements).

[0040] S103: Generate a first executable file corresponding to the triggering element based on the type of the triggering element and the type of the triggering event, and generate a second executable file corresponding to the receiving element based on the type of the receiving element and the type of the receiving event.

[0041] Optionally, the first executable file mentioned above can be, for example, an executable program code file corresponding to the triggering element. When the first executable file is executed, it can implement the triggering event corresponding to the triggering graph. The first executable file may contain logic code for implementing the corresponding triggering event, which can also be referred to as the logic code of the triggering element.

[0042] Optionally, in some embodiments, pseudocode for the triggering event can be dynamically added based on the selected trigger cell and trigger event type, and a first executable file can be formed based on the pseudocode for the triggering event.

[0043] Optionally, in some embodiments, the first executable file may be, for example, the trigger_code described above. The first executable file may contain: relevant code blocks (or trigger primitive program code) generated according to user requirements and assisting in the judgment and execution of the triggering event. Optionally, in some embodiments, the information transmission involved in the code blocks can uniformly use the third-party dependency library mitt for cross-page (component) communication, with actual parameters uniformly passed in the form {oldVal, newVal}. Here, the third-party dependency library mitt is a lightweight event bus library used to implement cross-component communication.

[0044] Optionally, the second executable file can be, for example, an executable program code file corresponding to the bearing element. When the second executable file is executed, it can implement the bearing event corresponding to the bearing diagram. The second executable file may contain logic code for implementing the corresponding bearing event, which can also be referred to as the logic code of the bearing element.

[0045] Optionally, in some embodiments, pseudocode for the bearer event can be dynamically added based on the selected bearer element act_cell and bearer event type act_event_type, and a second executable file can be formed based on the pseudocode of the bearer event.

[0046] Optionally, in some embodiments, the second executable file may be, for example, the act_code described above. The second executable file may contain: relevant code blocks (or: event-responding primitive program code) generated according to user requirements and used to assist in the judgment and execution of the event-responding function.

[0047] Optionally, in some embodiments, the first executable file and / or the second executable file described above can be dynamically added. Furthermore, after the first executable file and / or the second executable file are dynamically added, if the component containing the trigger element is unloaded, the first executable file and / or the second executable file can be dynamically unloaded.

[0048] S104: Generate an event attribute object based on the type of the triggering element, the type of the triggering event, the first executable file, the type of the receiving element, the type of the receiving event, and the second executable file.

[0049] Following the types of triggering elements, triggering event types, first executable files, types of receiving elements, receiving event types, and second executable files, event attribute objects can be generated based on the aforementioned content.

[0050] Optionally, in some embodiments, an event attribute object can refer to a special object that encapsulates event-related data and functionality. An event attribute object can also be referred to as an event attribute instance object.

[0051] Optionally, in some embodiments, the type of the triggering element, the type of the triggering event, the first executable file, the type of the receiving element, the type of the receiving event, and the second executable file can be encapsulated by a predefined event attribute structure to obtain an event attribute object. Alternatively, artificial intelligence can be used to process the aforementioned contents to obtain an event attribute object. Or, any other possible method can be used to process the aforementioned contents to obtain an event attribute object, without any limitation.

[0052] In this embodiment, by determining the triggering element and the receiving element, and based on the type of the triggering element, determining the trigger event type corresponding to the triggering element, and based on the type of the receiving element, determining the receiving event type corresponding to the receiving element, a first executable file corresponding to the triggering element is generated based on the type of the triggering element and the trigger event type, and a second executable file corresponding to the receiving element is generated based on the type of the receiving element and the receiving event type. Furthermore, an event attribute object is generated based on the type of the triggering element, the trigger event type, the first executable file, the type of the receiving element, the receiving event type, and the second executable file. Since the event attributes of the elements are managed uniformly in the form of event attribute objects, the elements and event attributes can be decoupled, improving the configuration efficiency of the event attributes of the elements.

[0053] Optionally, in some embodiments, the trigger element program code in the first executable file corresponding to the trigger element can be encapsulated and parsed, and the bearer element program code in the second executable file corresponding to the bearer element can also be encapsulated and parsed. This enables support for subsequent development processes related to the trigger element and the bearer element, and significantly improves development efficiency.

[0054] The following is an example of the encapsulation and parsing of trigger element program code (e.g., operation functions): Encapsulation of trigger element program code: Operation functions can be directly attached to the trigger element using the value of `trigger_event_type`. The internal judgments and execution code of the operation function can be dynamically encapsulated, and the encapsulation format can be a string. The passed parameters must be uniformly named, with naming formats such as `params1`, `params2`, etc. Parsing of trigger element program code: Parsing can be done directly through the Web-side `Function` class. The constructor's passed arguments can be in the format: `new Function('params1', 'params2', ..., '${trigger_code}')`, and the returned object is the executable function (another optional example of the first executable file mentioned above).

[0055] The following is an example of the encapsulation and parsing of the code for the bearer element: Encapsulation of the bearer element code: First, dynamically construct the mitt event listener in the initialization function of the page (component) where the bearer element `act_cell` resides. Then, construct the executable function `functionA` using the parameters passed in `trigger_code`, which can be directly stored as a string in `act_code`. Parsing of the bearer element code: First, perform a specificity check based on `act_event_type`, and then encapsulate the function using `new Function`.

[0056] Figure 3 This is a flowchart illustrating a Web-based primitive event attribute decoupling binding method proposed in another embodiment of this disclosure.

[0057] like Figure 3 As shown, this web-based meta-event attribute decoupling method includes:

[0058] S301: Determine the triggering element and the receiving element.

[0059] S302: Based on the type of the triggering element, determine the trigger event type corresponding to the triggering element, and based on the type of the receiving element, determine the receiving event type corresponding to the receiving element.

[0060] S303: Generate a first executable file corresponding to the triggering element based on the type of the triggering element and the type of the triggering event, and generate a second executable file corresponding to the receiving element based on the type of the receiving element and the type of the receiving event.

[0061] S304: Generate an event attribute object based on the type of the triggering element, the type of the triggering event, the first executable file, the type of the receiving element, the type of the receiving event, and the second executable file.

[0062] For a detailed description of S301-S304, please refer to the above embodiments, which will not be repeated here.

[0063] S305: Determine the descriptive information associated with the triggering element and the receiving element, wherein the descriptive information includes at least one of the following: encoding information, name information, sub-descriptive information, and remarks information.

[0064] Optionally, in some embodiments, the encoding information may be, for example, the unique encoded ID described above. The name information may be, for example, the name described above. The sub-description information may be, for example, the "description" described above. The remarks information may be, for example, the "note" described above.

[0065] Optionally, in some embodiments, the process of determining the descriptive information related to the triggering and bearing elements may involve obtaining the encoded information related to the triggering and bearing elements from the server, obtaining the user-inputted name information through a first interface in the event attribute editor (where the first interface is used to obtain the name information), obtaining the user-inputted sub-description information through a second interface in the event attribute editor (where the second interface is used to obtain the sub-description information), and obtaining the user-inputted remarks information through a third interface in the event attribute editor (where the third interface is used to obtain the remarks information). This allows for accurate acquisition of the descriptive information related to the triggering and bearing elements and supports personalized configuration of the descriptive information, enabling the generated event attribute object to meet the needs of personalized development scenarios.

[0066] S306: Associate description information and event attribute objects.

[0067] Optionally, in some embodiments, after determining the descriptive information related to the triggering element and the receiving element, the descriptive information and the event attribute object can be associated. That is, an association relationship can be established between the descriptive information and the event attribute object.

[0068] S307: Store description information and event attribute objects in a database table through a gateway interface with the database.

[0069] Optionally, in some embodiments, the gateway interface may be, for example, as described above. Figure 2 The gateway interface is shown below. After associating the description information and event property objects, the description information and event property objects can be stored in a table in the database.

[0070] Optionally, in some embodiments, upon receiving a trigger instruction, an event attribute editor is launched, wherein the trigger instruction is used to select descriptive information from a table or select an event attribute object, and the triggering element, the receiving element, the triggering event type, and the receiving event type are displayed in the display area of ​​the event attribute editor.

[0071] For example, in the event attribute editor, when a user confirms the creation of an event attribute object, a record is stored in the backend event attribute table (an optional example of the "database table" mentioned above). This stored data includes description information and the event attribute object associated with the description information. Simultaneously, the event attribute editor can be launched using the stored data. Once launched, the event attribute editor allows previewing, editing, and saving of the event attribute object's elements and / or events. Because the event attribute data format is fixed, it effectively supports batch import, export, and data sharing of event attribute objects, supporting cross-platform and cross-device data management.

[0072] In this embodiment, by determining the triggering element and the receiving element, and based on the type of the triggering element, determining the trigger event type corresponding to the triggering element, and based on the type of the receiving element, determining the receiving event type corresponding to the receiving element, a first executable file corresponding to the triggering element is generated based on the type of the triggering element and the trigger event type, and a second executable file corresponding to the receiving element is generated based on the type of the receiving element and the receiving event type. Furthermore, an event attribute object is generated based on the type of the triggering element, the trigger event type, the first executable file, the type of the receiving element, the receiving event type, and the second executable file. Since the event attributes of the elements are uniformly managed in the form of event attribute objects, the elements and event attributes can be decoupled, improving the configuration efficiency of the event attributes of the elements. This embodiment supports the decoupling of elements and events, and allows events to be reused by different elements. Moreover, by independently storing the event attribute objects, the reusability of the event attribute objects can be greatly improved. It also supports binding a single event to multiple different elements, thereby effectively reducing the time spent on repetitive event configuration and saving time costs. Furthermore, the visual configuration and real-time preview of event attribute objects can support complex business event configurations, greatly improve the efficiency of business function development, and reduce development time. In addition, the unified event attribute management mechanism can effectively reduce repetitive development work and improve team collaborative development efficiency.

[0073] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0074] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

[0075] It should be noted that in the description of this disclosure, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this disclosure, unless otherwise stated, "a plurality of" means two or more.

[0076] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of preferred embodiments of this disclosure includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this disclosure pertain.

[0077] It should be understood that various parts of this disclosure can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0078] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0079] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0080] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0081] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

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

Claims

1. A method for decoupling and binding event attributes of web-based primitives, characterized in that, include: Identify the triggering element and the element that receives the trigger; Based on the type of the triggering element, determine the trigger event type corresponding to the triggering element, and based on the type of the receiving element, determine the receiving event type corresponding to the receiving element; Based on the type of the triggering element and the type of the triggering event, a first executable file corresponding to the triggering element is generated, and based on the type of the bearing element and the bearing event, a second executable file corresponding to the bearing element is generated. Based on the type of the triggering element, the type of the triggering event, the first executable file, the type of the receiving element, the type of the receiving event, and the second executable file, an event attribute object is generated to uniformly manage the event attributes of the elements in the form of the event attribute object, thereby decoupling the elements and the event attributes. The determination of the triggering element and the receiving element includes: An event property editor is provided, which further includes a third selection control and a fourth selection control. The third selection control is used to select the triggering event type, and the fourth selection control is used to select the receiving event type. The step of determining the trigger event type corresponding to the trigger element based on the type of the trigger element, and determining the acceptance event type corresponding to the acceptance element based on the type of the acceptance element, includes: The trigger event type is selected through the third selection control, and the selected trigger event type is determined as the trigger event type corresponding to the trigger element; The fourth selection control is used to select the event type, and the selected event type is determined as the event type corresponding to the event element.

2. The method as described in claim 1, characterized in that, The determination of the triggering element and the receiving element includes: The event attribute editor includes at least a first selection control and a second selection control, wherein the first selection control is used to select the triggering element and the second selection control is used to select the receiving element. The trigger element is selected using the first selection control, and the receiving element is selected using the second selection control.

3. The method as described in claim 2, characterized in that, The event property editor further includes: a display area; the method further includes: The triggering element, the receiving element, the triggering event type, and the receiving event type are dynamically displayed in the display area.

4. The method as described in claim 2, characterized in that, The method further includes: Determine the descriptive information associated with the triggering element and the bearing element, wherein the descriptive information includes at least one of the following: encoding information, name information, sub-description information, and remarks information; Associate the description information and the event attribute object; The description information and the event attribute object are stored in a table in the database through a gateway interface between the database and the database.

5. The method as described in claim 4, characterized in that, The method further includes: Upon receiving a trigger instruction, the event attribute editor is launched, wherein the trigger instruction is used to select the description information from the table or to select the event attribute object; The triggering element, the receiving element, the triggering event type, and the receiving event type are displayed in the display area of ​​the event attribute editor.

6. The method as described in claim 4, characterized in that, The determination of descriptive information related to the triggering element and the bearing element includes: Obtain encoded information related to the triggering element and the receiving element from the server; The name information input by the user is obtained through the first interface in the event property editor, wherein the first interface is used to obtain the name information; The sub-description information input by the user is obtained through the second interface in the event attribute editor, wherein the second interface is used to obtain the sub-description information; The user-inputted remarks are obtained through a third interface in the event property editor, wherein the third interface is used to obtain the remarks.

7. The method as described in claim 1, characterized in that, The method further includes: The trigger element program code in the first executable file corresponding to the trigger element is encapsulated and parsed. The program code for the bearing element in the second executable file corresponding to the bearing element is encapsulated and parsed.

Images