Patent Application
20200394055
This disclosure relates generally to user interfaces. More specifically, this disclosure relates to a system and method for a configurable user interface using a self-describing data system.
User interfaces include numerous user interface elements or controls that provide different functionality. For example, a button may be a user interface element that, when selected (e.g., clicked), causes an operation to be performed (e.g., sends a search request to a server, etc.). To that end the user interface may provide a front end for an application that accesses one or more data systems associated with the application. Various entities may have differing requirements for functionality of the application that are exposed via a user interface, and thus, may desire differing user interface elements to be included in the user interface of the application. Additionally, the functionality requirements of the user interface for the entity may change over time as the needs of the entity change.
This disclosure provides a system and method for a configurable user interface for managing a self-describing data system.
In a first embodiment, a method for configuring a layout of a user interface for a set of clients may include receiving, from a first client, a first message including a modification to a user interface element at a location of a section of the user interface, and a property of the user interface element. The method also may include modifying, based on the first message, an item within a self-describing data structure that defines an overall layout of the user interface. The item represents the user interface element. The method may also include receiving, from the first client, a request to view the user interface, and determining metadata that defines a tailored layout of the user interface including the user interface element for the first client using the self-describing data structure based on at least the property of the user interface element. The method also may include providing a second message including the metadata to the first client to render the tailored layout of the user interface including the user interface element for the first client on a display.
In a second embodiment, a tangible, non-transitory computer-readable medium storing instructions that, when executed, cause one or more processing devices to receive, from a first client, a first message including a modification to a user interface element at a location of a section of the user interface, and a property of the user interface element. The instructions also, when executed, cause the one or more processing devices to modify, based on the first message, an item within a self-describing data structure that defines an overall layout of the user interface, where the item represents the user interface element. The instructions also, when executed, cause the one or more processing devices to receive, from the first client, a request to view the user interface, and determine metadata that defines a tailored layout of the user interface including the user interface element for the first client using the self-describing data structure based on at least the property of the user interface element. The instructions also, when executed, cause the one or more processing devices to provide a second message including the metadata to the first client to render the tailored layout of the user interface including the user interface element for the first client on a display.
In one embodiment, a system includes one or more memory devices storing instructions and one or more processing devices communicatively coupled to the one or more memory devices. The one or more processing devices may execute the instructions to receive, from a first client, a first message including a modification to a user interface element at a location of a section of the user interface, and a property of the user interface element. The instructions also, when executed, cause the one or more processing devices to modify, based on the first message, an item within a self-describing data structure that defines an overall layout of the user interface, where the item represents the user interface element. The instructions also, when executed, cause the one or more processing devices to receive, from the first client, a request to view the user interface, and determine metadata that defines a tailored layout of the user interface including the user interface element for the first client using the self-describing data structure based on at least the property of the user interface element. The instructions also, when executed, cause the one or more processing devices to provide a second message including the metadata to the first client to render the tailored layout of the user interface including the user interface element for the first client on a display.
Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.
Before undertaking the DETAILED DESCRIPTION below, it may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The term “couple” and its derivatives refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with one another. The terms “transmit,” “receive,” and “communicate,” as well as derivatives thereof, encompass both direct and indirect communication. The terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation. The term “or” is inclusive, meaning and/or. The phrase “associated with,” as well as derivatives thereof, means to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The term “controller” means any device, system or part thereof that controls at least one operation. Such a controller may be implemented in hardware or a combination of hardware and software and/or firmware. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. The phrase “at least one of,” when used with a list of items, means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, “at least one of: A, B, and C” includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C.
Moreover, various functions described below can be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms “application” and “program” refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code. The phrase “computer readable program code” includes any type of computer code, including source code, object code, and executable code. The phrase “computer readable medium” includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory. A “non-transitory” computer readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer readable medium includes media where data can be permanently stored and media where data can be stored and later overwritten, such as a rewritable optical disc or an erasable memory device.
Definitions for other certain words and phrases are provided throughout this patent document. Those of ordinary skill in the art should understand that in many if not most instances, such definitions apply to prior as well as future uses of such defined words and phrases.
For a more complete understanding of this disclosure and its advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:
Some aspects of the present disclosure relate to a platform that includes one or more services hosted by one or more servers. The services may be accessed by a front-end client application that executes on a client device. The terms “front-end client application” and “client application” may be used interchangeably herein. The front-end client application may provide a user interface to enable a user to interact with data stored on the one or more servers. Each client application may be individually tailored to provide user interface elements that are desired by a user of the respective application. The platform may enable an entity to model their business using a self-describing data system. The terms “self-describing data system” and “self-describing data model” may be used interchangeably herein. The platform may be flexible and enable a user or system to create objects and relationships between the objects to define any suitable behavior or workflow for a lifecycle of the entity. For example, the platform may refer to a toolkit that allows programming an enterprise application.
According to certain embodiments, the foundational element of a self-describing data system is an item, instances of which may be maintained in persistent storage in a relational database. An “item type” may refer to a class and an “item” may refer to an object of the class. According to certain embodiments, the configuration and properties of an item may be expressed in a markup language, such as extensible markup language (XML), or Aras Markup Language (AML), which, as described in greater detail herein, follows a repeating “/Item/Relationships/Item/Relationships” pattern to describe item configurations.
Data in the platform for an entity may be described using item types and items. Metadata may be stored and/or generated that describes the item types and items. A web-based client application that executes in a browser or a standalone client application that executes by itself may provide a user interface that enables transmitting a request (e.g., XML or AML message) for data associated with an entity. The one or more servers may build a hierarchical definition using the metadata that is found for the entity in the self-describing data system. The definition may describe a layout of the user interface for the application. A response (e.g., XML or AML message) may be sent by the server including the definition of the layout, and the user interface may be dynamically rendered by the client application. In some embodiments, a format of the response message may be based on the type of the computing device that made the request. That is, the platform may be client-agnostic in that any suitable type of client may benefit from the disclosed techniques. The client devices may include one or more operating systems, such as Windows®, Android®, MacOS®, iOS®, and the like. The client application that is associated with the platform may include a UI engine that interprets user interface metadata modeling definitions in order to render the client user interface and support the behavior defined by the code associated with the definition.
The configuration of the layout may be completely customizable by the entities. The servers may maintain numerous different definitions of user interfaces for different client applications. For example, a first client application may include a definition for a button in a toolbar, and a second client application may include a definition for an input box in the same toolbar. The first and second client applications may be executed concurrently to access the platform, and the toolbar in the user interface for the first application may include the button, while the toolbar in the user interface for the second application may include the input box. At runtime, the definitions (metadata) of the layouts for the different user interfaces may be determined and/or generated and dynamically rendered by each respective client application.
The disclosed embodiments may enable modeling (e.g., creating, editing, moving, deleting, etc.) each user interface element of a user interface of a client application. For example, command bars, command buttons, forms, menus, toolbars, sidebars, shortcuts, content, item windows, sliders, accordions, and the like may be modeled in a self-describing data model using the disclosed techniques. The disclosed techniques may support content of the user interface, layout of the user interface, and behavior/functionality of the user interface.
In some embodiments, user interface modules may be developed that may be applied to differing types of client applications as long as the client applications are capable of processing the hierarchical definitions in the metadata. For example, the metadata definition for a particular command bar may be rendered by differing client applications using respective UI engines to embed the command bar into the respective user interfaces of the differing client applications. To that end, the user interface modules may be customized by each client, and thus, some embodiments enable multiple different types of user interface layouts to be generated for different types of clients (e.g., web client, mobile clients, etc.). In some embodiments, the user interface modules may be added to a user interface by configuring the client application and/or by performing a drag-and-drop operation.
The self-describing data system may be used to build the hierarchical metadata definitions that are dynamically rendered by the client applications. The term “hierarchical metadata definition” and “configurable user interface (CUI) definition” may be used interchangeably herein. The items in the definition of the layout may be defined declaratively and/or dynamically. That is, certain portions of the user interface may be defined statically in metadata (declaratively) in the self-describing data system, while others may be generated dynamically by calling one or more functions and the functions return the content for these portions. For example, how many reports that can be shown may depend on particular instance of an item, and thus, the reports may be dynamically defined at runtime. The dynamic elements may be specified as being defined through a function that returns a message (e.g., XML, AML) definition that depends on runtime content. The functions may include conditions, such as if condition 1, then return one user interface element, or if condition 2, then return three user interface elements. Further, for each user interface element, an event handler may be defined for any client runtime event and the functions to perform in response to that client runtime event may be defined.
In some embodiments, each CUI definition may be associated with a particular type of client (e.g., web client, mobile client, etc.), which allows defining a different set of user interface elements (e.g., command bars, menus, toolbars, sidebars, etc.) for the different client applications. In some embodiments, the client applications may be responsible for defining the look-and-feel of the user interfaces. In some embodiments, the individual user interface elements defined in the CUI definition may be arranged next to each other in the order in which they are defined in the CUI definition. Further, as for the overall location of a menu set, toolbar, sidebar, shortcut, etc., certain standard locations may be defined in the CUI definition that are provided to the particular client application. Thus, based on knowing the location of a particular toolbar, for example, defined through the CUI definition, the client application may determine how and where to render the toolbar.
In some embodiments, the disclosed techniques enable inheriting CUI definitions from a “global level” to a “level of item type” to a “level of individual item,” which may allow building item type-specific and/or item-specific user interface elements (e.g., command bars, menus, toolbars, sidebars, shortcuts, etc.). For example, a CUI definition for “global level” may have a toolbar for “item window toolbar” location defined with two buttons “B1” and “B2,” but an administrator desires, for items of type Part, that the toolbar in the same location contains buttons “B1” and “B3”. In this instance, in the CUI definition for item type Part, the toolbar in the same “item window toolbar” location needs to remove button “B2” and add button “B3” to the toolbar. By merging the “global level” CUI definition with the CUI definition for item type Part, the server may provide a combined definition of the toolbar with buttons “B1” and “B3”. As another example, the disclosed techniques may enable deriving item type specific command bars from global level command bars with options to add, remove, and/or override behavior of all or some user interface elements (e.g., command bar items) of the global level command bar.
In addition to merging CUI definitions based on level—global, item type, or item—to form a CUI definition that is specific for a particular context, the disclosed techniques may enable defining individual elements (e.g., a particular menu item) or group of elements (e.g., toolbar section) per identity (e.g., a user or group of users (designers, administrators, etc.) and per classification (e.g., electrical, mechanical, etc.) of the context item. This may enable, even on a single level (e.g., on “global level”), to produce different CUI definitions at runtime for different users and/or context items. For example, some embodiments enable defining, in the self-describing data system, the content of a static command bar based on the context in which the command bar is shown in the user interface. Specifically, the content of the static command bar may be modified based on the identity of the logged-in user and a classification of the context item.
A CUI definition may include the user interface metadata and may not include item specific values that fill particular user interface elements. To obtain the specific values for an item, the client may send another request to the platform. In this way, the user interface metadata may be separated from the actual item's data. The client may cache the CUI definition for faster rendering when subsequently accessed.
Further, in the non-limiting example of
According to various embodiments, the instance of the item defined by <item> tag 100 comprises three principal attributes, a type 105, an ID 110 and an action 115. It should be noted that the following three attributes are not the only attributes which can be applied to an item.
In the non-limiting example shown in
According to various embodiments, ID 110 comprises a unique identifier for the instance of an item created by <item> tag 100. In the non-limiting example of
In some embodiments, action 115 comprises a method to be applied to the instance of an item defined by <item> tag 100. In the non-limiting example of
Referring to the non-limiting example of
According to certain embodiments, the configuration 200 of an item may be expressed as a markup language document (for example, an AML document). In some embodiments, item 200's configuration may be expressed through an “/Item/Relationships/Item/Relationships” pattern in an AML document. Further, the document expressing the configuration 200 of the item may contain data 220 (some of which are themselves, items), structure or relationships 210 (which are hierarchical items) and logic, which, as shown in the example of
In the non-limiting example of
As shown in
In some embodiments, when the RelationshipType 212 is created, is_relationship 214 is also created. Is_relationship 214 comprises an item, and its id is the value of the relationship_id property of RelationshipType 212. As such, is_relationship 214 operates to provide an ItemType pairing to RelationshipType 212, and to define a RelationshipType rule and an ItemType for storing the source_relationship 216 and target_relationship 218 properties of the RelationshipType item 212.
According to certain embodiments, source_relationship 216 is a property of RelationshipType 212 which comprises a link pointing to a parent item. Similarly, target_relationship 218 is a property of RelationshipType 212, which comprises a link to a child item.
As shown in the non-limiting example of
According to certain embodiments, a property 222 defines data for an item. Examples of properties may include, for example, a cost for an item, which could be expressed in AML or XML in the form: “<cost>232.13</cost>” indicating that a particular item has a cost value of “232.13” units.
According to certain embodiments, items of data for an item may be further specified with an attribute 224, which may be analogized as metadata for the item or property, and controlling logic and methods associated with the item. For example, an attribute may define a conditional, producing an AML or XML expression of the form “<cost condition=“between”>10.00 and 50.00</cost>.” In this example, the property “cost” is further specified through the “between” attribute for which the values 10.00 and 50.00 are specified.
According to certain embodiments, the configuration 200 for an item may further include history data for the item, showing some or all of the previous configurations of the item.
The properties 310 of the item are set forth, and include an “item_number” value (which, according to certain embodiments, may function as a unique identifier of the instance of the item) and a “description” value, which, in this case is “Some Assy” (an abbreviation of “some assembly.”)
Container tag 315 specifies that the item has relationships, including a first relationship 320 with item indicating an “add” method with an item of the type “Part BOM.” Item configuration 300 further specifies a “related_id” (e.g., child relationship between the “Part BOM” item and a child “part” item 325. Thus, by applying the “/Item/Relationships/Item/Relationships” pattern, a part-to-part BOM relationship may be described.
According to certain embodiments, database server 405 is a server hosting data and implementing one or more database applications supporting query functionalities and user interface configuration functionalities. Database server 405 is generally platform-agnostic and may host data in a number of known database formats, including a relational database format (for example, by running an instance of .SQL server) or as a columnar database format. In the non-limiting example of
According to certain embodiments, database server 405 is configured to receive queries and/or commands expressed as statements in a domain-specific language (for example, structured query language), and return results from the database hosted on database server 405. In some embodiments, metadata that defines a layout of a user interface for the client application 430 may be stored in the database server 405 and various user interface elements of the user interface may be added, modified, deleted, etc. using the client application 425 executing on the front end 420.
According to certain embodiments, backend 410 comprises a server or other computer configured to implement a CUI server engine 415 configured to receive, from front end 420 requests expressed in the syntax of a self-describing data system (for example, AML). The requests may be query requests for retrieving a CUI definition for a user interface of the client application 425, a request to add, modify, remove one or more user interface elements of the user interface of the client application 425, and so forth. As noted elsewhere, embodiments according to this disclosure are platform-agnostic and may be practiced across a wide range of hardware configurations and development environments. In some embodiments, the CUI server engine 415 may be implemented as an ASP.NET web service. Although just one back end 410 is depicted, it should be understood that any suitable number of back ends 410 may be deployed and in communication with one another to form the platform described herein. The CUI server engine 415 may be implemented in computer instructions stored on one or more memory devices of backend 410 and executable by one or more processing devices of the backend 410.
In the non-limiting example of
The client application 425 and/or the CUI client engine 430 may be implemented in computer instructions stored on one or more memory devices of the front end 420 and executable by one or more processing devices of the front end 420. The CUI client engine 430 may receive a CUI definition including hierarchy metadata defining a layout of a user interface content of the user interface, layout of the user interface, and behavior of the user interface elements (controls) of the screen. The CUI client engine 420 may be configured to process and interpret the CUI definition to generate HTML, web components, or the like that represents the user interface elements on the user interface for presentation by a display screen of the front end 420. To that end, the front end 420 may be any suitable computing device, including a laptop, a desktop, a smartphone, a server, a tablet, and so forth.
Although just one front end 420 is depicted, it should be understood that any suitable number of front ends 420 may be used by various entities to access the platform. The front ends 420 may be referred to as clients herein. Each front end 420 may customize the user interface of the client applications 430 as described herein, such that the different client applications 425 have one or more similar controls and/or different controls on their respective user interfaces. The metadata for the various user interface elements may be stored in the self-describing data system in the database server 405.
According to the non-limiting example of
In some embodiments, the property may specify including the user interface element at the location in the section globally. When the user interface element is included at the location in the section globally, each client application 425 may present that user interface element at the specified location unless further configurations are made, such as specifying the item type for the user interface element, an identity of users that may view the user interface element, and/or a classification of the user interface element. In some embodiments, the property specifies including the user interface element at the location in the section based on an item type (e.g., part) of the section. In some embodiments, the property specifies including the user interface element at the location in the section based on an identity (e.g., designer, administrator, etc.) of a user associated with the client 420 requesting the user interface. In some embodiments, the property specifies including the user interface element at the location in the section based on a classification (e.g., electrical, mechanical, software, etc.) of the item type of the section. In some embodiments, the property may specify a combination of global level, item type level, identity, and/or classification.
In some embodiments, the first message may further include an event and an event handler for the user interface element. The event may include any action performed on the client 420 that triggers the event handler to perform a specified operation to handle the event. For example, selecting a button may be a defined event and display a particular message may be the operation that handles the event.
At operation 510, the CUI server engine 415 may modify, based on the first message, an item within a self-describing data system that defines an overall layout of the user interface, where the item represents the user interface element. As discussed elsewhere in this disclosure, certain embodiments according to this disclosure utilize a self-describing data system, wherein the fundamental element of the data system is the item, which is an instance of an ItemType, which is, in turn, itself an item. Further, in certain self-describing data systems according to this disclosure, the configuration of items may be expressed through an “/Item/Relationships/Item/Relationships” pattern. The item in the self-describing data system may be modified based on the event and the event handler for the user interface element.
At operation 515, the CUI server engine 415 may receive, from the first client, a request to view the user interface. In some embodiments, the request to view the user interface may be transmitted by the client 420 concurrently with the first message including the modification, while in other instances, the request may be transmitted by the client 420 upon refreshing the user interface or logging out and logging back into the client application 425.
At operation 520, the CUI server engine 415 may determine metadata that defines a tailored layout of the user interface including the user interface element for the first client using the self-describing data system based on at least the property of the user interface element. For example, if the property of the user interface element specifies that the identity of users has to be Developers to be able to view the user interface element, then the CUI server engine 415 may determine whether the requesting user has the proper identity. If the property of the user interface element specifies that the user interface element is associated with items of type “part”, the CUI server engine 415 may determine whether the user is requesting to view items having type part or some other item type and build the CUI definition including the metadata accordingly.
At operation 525, the CUI server engine 415 may provide a second message including the metadata to the first client 420 to render the tailored layout of the user interface including the user interface element for the first client 420 on a display. The CUI client engine 430 of the client application 425 at the client 420 may interpret and process the metadata CUI definition to represent the user interface elements defined by the metadata on the user interface of the client application 425. The client 420 may render, using the CUI client engine 430, the user interface including the user interface element at the location in the section at runtime based on the metadata in the second message.
According to certain embodiments, the second message may include a markup language document (for example, a document in XML, AML or some other extensible markup language dialect). The second message may have a format type that is specific to the client 420. For example, the client 420 may be a mobile client or a web-based client and the second message may be formatted accordingly. Further, the client 420 may have a certain type of operating system, and the second message may be formatted accordingly.
In some embodiments, the CUI server engine 415 may receive, from a second client, a request to view the user interface, where the request includes a second property. The CUI server engine 415 may determine second metadata that defines a second tailored layout of the user interface, where the second tailored layout (i) excludes the user interface element for the second client using the self-describing data system based on at least the property of the user interface element (e.g., this may occur if the property specifies that the user interface element is associated with developer identities and the second client is not associated with the developer identity), (ii) includes a second user interface element for the second client that is excluded from the first tailored layout for the first client (e.g., this may occur if the second property is for items of type part and the first tailored layout was generated for items having a different type than part), or (iii) includes a third user interface element that is common in both the second tailored layout for the second client and the tailored layout for the first client (e.g., this may occur if the first client and second client are associated with the same identity and are presented with the third user interface element for that identity). Further, the CUI server engine 415 may provide a third message including the second metadata to the second client to render the second tailored layout of the user interface.
According to the non-limiting example of
At operation 610, the CUI server engine 415 may modify, based on the third message, a second item within the self-describing data system, where the second item represents the second user interface element. At operation 615, the CUI server engine 415 may receive, from the first client, a request to view the user interface.
At operation 620, the CUI server engine 415 may determine second metadata that defines a tailored layout of the user interface for the first client using the self-describing data system based on at least the property of the user interface element and the second property of the second user interface element. The second metadata may also be determined based on the type of the client 420.
At operation 625, the CUI server engine 415 may provide a fourth message including the second metadata to the first client to render the tailored layout of the user interface including the user interface element and the second user interface element on the display. For example, if the property and second property indicate that the user interface element and the second user interface element are defined at the global level, then they may both be included in the second metadata. In another example, if the property and second property indicate that the user interface element and the second user interface element are defined at the item type level for part, and the second client requested the user interface for item having the part type, then the user interface element and the second user interface element may be included in the second metadata.
According to the non-limiting example of
At operation 715, the CUI server engine 415 may receive, from a second client, a third request to view the user interface. The third request may include a third property pertaining to a second item type different than the first item type. At operation 720, the CUI server engine 415 may determine third metadata that defines a third tailored layout of the user interface that includes a third user interface element using the self-describing data system based on the third property pertaining to the second item type. The third user interface element may be different than the second user interface element.
At operation 725, the CUI server engine 415 may provide a third message including the second metadata to the first client to render the second tailored layout of the user interface. At operation 730, the CUI server engine 415 may provide a fourth message including the third metadata to the second client to render the third tailored layout of the user interface. As such, the second tailored layout of the user interface may present a different user interface element associated with a different item type than the third tailored layout.
The user interface 800 includes various sections that may be modeled declaratively (e.g., having item type form in the first accordion element 802), and some sections that may be modeled dynamically (e.g., a set of relationship tabs that are shown in a second accordion element 804 varies as it depends on the set of relationship types available on the particular item type.
The user interface elements that may each be modeled as a specific type of cui_Control. Each specific cui_Control may contain zero or more other cui_Controls. The CUI client engine 430 may be configured to render the cui_Controls. In some embodiments, the cui_Controls may be placed into a specific cui_WindowSection, which has a “location”. One or more cui_WindowSections with the same “location” may be combined into a single user interface shown by the client application 425. In some embodiments, there may be a single predefined “location” for cui_WindowSections for items, which may be referred to as item_content_window. There may be other predefined “locations” for cui_WindowSections, for example a search_grid_window.
As shown in the data model in
The CUI server engine 415 may generate a completed CUI definition that includes a hierarchy of cui_Controls (each control in the hierarchy has a specific type) to be rendered in the user interface by the CUI client engine 430. When the client application 425 requests to view the user interface, the following properties may be included in the requests: (i) a type of the client (e.g., web client, mobile client, etc.), (ii) “location” of the cui_WindowSection, (iii) a type of the context item, (iv) an identifier of the context item, and/or (v) additional information that may be assed to the method that builds “dynamic” cui_WindowSection.
The CUI server engine 415 may receive the requests and generate the requested CUI definition for the specified client, location, and/or context using cui_WindowSections defined on global, item type, and item levels. The CUI server engine 415 may transmit the generated CUI definition using any suitable format (e.g., JavaScript Object Notation (JSON)) that includes a hierarchy of cui_Controls with the information that is used by the CUI client engine 430 to render the user interface. In some embodiments, the client application 425 may cache the response including the CUI definition from the CUI server engine 415 so that it may be used when the CUI definition for the same “location” and item type is desired.
The following list includes example cui_Controls that may be used in various embodiments of the disclosure:
The following controls are processed by the CUI server engine 415 at runtime to return context specific information along with each control: cui_ToolbarControl (location=“item_content_toolbar”, width=“3*”), cui_ToolbarControl (location=“item_content_toolbar”, width=“1*”), cui_FormControl, cui_xClassCoontrol (xtree_path=“*”), cui_TabContainer (location=“item_relationships”), cui_ItemVersionsControl, cui_ItemHistoryControl, cui_LifeCycleControl, cui_WorkflowProcessControl, and cui_ItemPermissionsControl.
Each of these controls will now be discussed with reference to
Beginning with
At control B, for cui_FormControl, the CUI server engine 415 may identify a Form item for the specified Item and return a JSON similar to the one depicted. In some embodiments, just the ID of the Form may be returned because, in some instances, the client application 425 may cache the Form and can use the ID to obtain the Form. In another instance, the ID may be used to obtain the Form from the backend 410 in a separate request.
At control C, for cui_xClassControl (xtree_path=“*”), the CUI server engine 415 may, based on the xtree_path specified, identify the xClasses that the context item is classified with and the xProperties. The CUI server engine 415 may return a JSON 1000 similar to the one depicted.
In some instances, if the visibility of a parent cui_Control (e.g., in this case cui_AccordionElementControl) is set to collapsed or hidden, the CUI server engine 415 may postpone returning the CUI definition of the control to enhance peformance. Instead, the information may be returned based on another request from the client application 425 (e.g., when the user expands the accordion element on the user interface). In such an instance, the reduced JSON 1002 may be returned with the initial CUI definition.
In some embodiments, when the ID of the cui_WindowSection is included in the response JSON, the CUI definition associated with that control may be obtained in a separate request to the backend 410. When such a request is made to the backend 410, the CUI server engine 415 may determine if the parent cui_WindowSection has a “dynamic” or “declarative” type. If the type is “declarative”, then the CUI server engine 415 may use context information (e.g., item and its item type) to build the CUI definition of the requested control (e.g., in the case of cui_xClassControl it may include information about xClasses and xProperties that should be displayed in the control). If the type is “dynamic”, then the CUI server engine 415 may call the building method set on the “dynamic” cui_WindowSection, and pass to it the information sent by the client and a null as a reference to the CUI definition structure previously formed by cui_WindowSections with the identical location. The method may return the CUI definition for the requested control.
At control D, for cui_TabContainer (location=“item_relationships”), the CUI server engine 415, when processing the design-time CUI definition, may insert the depicted JSON 1004. In some embodiments, the content of the cui_TabContainer may be filled by the dynamic cui_WindowSection. For example, a method, buildRelationshipTabs, that is defined in the section may be used. The buildRelationshipTabs may accept the context item and its item type as parameters. Because each declarative section is processed prior to calling the method and the method accepts the result of this processing as a parameter, the method may find, in the parameter, the JSON 1004 for the cui_TabContainer using its location and convert it into JSON 1006.
Turning to
At the root node, ItemType is depicted. PresentationConfiguration depends from ItemType and has a relationship type of ITPresentationConfiguration with ItemType. It should be noted that ITPresentationConfiguration may be defined per client type. Also, a GlobalPresentationConfiguration may be associated with the PresentationConfiguration. The GlobalPresentationConfiguration may be defined per client type, per location (e.g., MainWindow, ItemWindow, etc.). An item type for CommandBarSection may be related to PresentationConfiguration based on a relationship type of PresentationCommandBarSection.
As depicted, each CommandBarItem is associated with a CommandBarSection via a relationship type of CommandBarSectionItem. Each CommandBarMenuXXX items that form a hierarchy between themselves also are associated with a CommandBarSection. The relationship CommandBarSectionItem is not only responsible for associating a particular instance of CommandBarItem with a particular CommandBarSection, but it may also hold information that is used to build context specific CommandBarSection. For example, CommandBarSectionItem relationship may define: (i) context related information like identity of the current user and classification of the context item that is used to determine if the related CommandBarItem should be considered during the process of building the CommandBarSection, (ii) an action applied to the related CommandBarItem when building the CommandBarSection (possible values of the action may include add, remove, replace, clear all), and/or (iii) an order in which the CommandBarItem will be inserted into the CommandBarSection. The same process may be applied when building a set of menus that have hierarchical structure and each CommandBarMenuXXX item, besides being associated with the parent CommandBarSection, may have a reference to the parent CommandBarMenu.
As depicted, the partial data model 1200 includes the same item types and relationship types starting at PresentationConfiguration and above as the partial data model 1100 of
cui_Control (IT)
cui_WindowSection (ItemType)
cui_PresentationConfigurationWindowSection (RelationshipType)
cui_WindowSectionControl (RelationshipType)
cui_Location (ItemType)
cui_Event (ItemType)
cui_ControlEventHandler (RelationshipType)
In some embodiments, each control may include its own set of unique control-specific types of events. For instance, current grid implementation in Aras Innovator web client has events like: “cell focus”, “cell edit”, “drag column”, etc. Because in the disclosed embodiments each client application 425 may have its own set of controls, the set of events that can be fired in each client application can be very different from events in another client application 425. Thus, any desired custom event may be created to which other controls should be capable to subscribe. To support this, and as described above, the data model may include ItemType cui_Event instances of which can created by administrator.
Events may be fired by the client application 425 (i.e. by the code that constitutes the client application) from practically anywhere (it depends on how the code is written, etc.) in the code. Further, the same event can be fired from more than one place in the code—e.g. the same event can be fired when user clicked a button, pressed a short-cut key combination or dragged an icon in the user interface to a specific location. At the same time, a set of events that a specific client application can fire are correlated with the types of events defined in the metadata. Thus, any time administrator would like to add a new type of event that some of controls can fire and other controls should be able to subscribe to, a new instance of cui_Event in the database may be created.
Firing events may be performed by the code implementing the client application 425, and broadcasting the fired events to controls that subscribed to the fired events may also be performed by the code implementing the client application 425. The client application 425 may have a mechanism that catches fired events and forwards them to subscribers of the event. A standard “event catcher” may be implemented on the level of cui_WindowSections with identical location—i.e. all events fired by controls inside cui_WindowSections with the same location will bubble up, using Hyper Text Markup Language (HTML)/Document Object Model (DOM) bubbling mechanism, to the DOM element that defines the “window section” (e.g. <div> or <iframe>). This DOM element has an event handler that is triggered for all events that can possibly be fired by controls inside the window section and that will play the role of “dispatcher”. The dispatcher checks which controls inside the window section subscribed to this particular event, and from this particular location, and invokes their corresponding event handlers passing to them certain information. Note that client code that fires the event on a control may pass the type of the control and the location of the control (e.g., ctype=“cui_AccordionElementControl”; location=“item_content_window”) that enables subscribers to identify which controls fired the event in case multiple controls of the same type exist inside the “window section”.
The metadata may define the kinds of events to which the control subscribes and the code/method to call to handle the events. Thus, each control may have a set of event handlers associated with it and the kind of event for which the event handler is invoked. The cui Event items may be used for this purpose. Having the ability to declaratively define, at design-time, the events to which each control will subscribe, and implement event handlers for corresponding events, provides users with customization points that can be used to alter behavior of controls supported by a specific client application 425.
The disclosed technique separates hierarchy of controls (in this case CommandBarMenuXXX items) from the information that allows, at runtime, determining whether a particular control needs to be considered to be applied to the hierarchy. Since each CommandBarItem is directly associated with a CommandBarSection, this may support (i) a mechanism of building context specific sections that entail merging CommandBarSections with the same location from “global scope”, “item type scope”, and “item scope”, and/or (ii) setting up particular parts of the hierarchy that are shown for a particular identity or for a particular classification of the context item.
In some embodiments, the cui_Controls form a hierarchy and cui_Control hierarchies defined on global, item type, and item level and associated with cui_WindowSections with the same location may be merged. To merge, each cui_Control may be directly associated with cui_WindowSection. This association (relationship type) may include the following information: (i) identity of the current user and classification of the context item that enables determining at runtime if the control should be considered during the process of building the CUI definition for a particular cui_WindowSection, (ii) action (add, remove, modify, etc.) that is applied to the respective control when the control is used in the building process of the cui_WindowSection, and/or (iii) an order in which the cui_Control is inserted into its parent's hierarchy.
At operation 1505, the CUI server engine 415 may identify a cui_WindowSection with a certain location on the global level. At operation 1510, the CUI server engine 415 may determine a set of cui_Controls associated with the cui_WindowSection and that are to be processed based on the identity of the current user and classification of the context item. At operation 1515, the CUI server engine 415 may determine a subset of cui_Controls from the set of cui_Controls that have “parent control” set to null (these are the top-level controls in the cui_WindowSection. At operation 1520, based on the corresponding cui_WindowSectionControl.action, add or remove the control into the resulting CUI definition in ascending order.
At operation 1525, for each top-level control, determine a set of child controls that have the top-level control as a parent. At operation 1530, based on the corresponding cui_WindowSectionControl.action for each of the set of child controls, add or remove the child control in the CUI definition in ascending order. Operations 1525 and 1530 may be repeated recursively for children of controls added in the operation 1515 and 1520.
At operation 1535, a determination may be made whether the cui_WindowSection exist for the same location on the “item type scope” (e.g., on PresentationConfiguration associated with the context item's ItemType). If so, the method 1500 may proceed to operation 1510 to continue processing for the cui_WindowSection. If not, the method 1500 may include performing operation 1540 by determining whether the cui_WindowSection exist for the same location on the “item scope”. If so, the method 1500 may proceed to operation 1510 to continue processing for the cui_WindowSection.
Further, some menus, such as Menu 1 having an identity World, may appear when the user has selected identity for Designer. Since World may indicate a global level definition, which may specify that the item appear regardless of other items appear, Menu 1 may be included in the TOC 1602. To understand the identity that is set on the relationship CommandBarSectionitem that connects CommandBarSection(location=TOC) to Menu 1, an indicator 1606 is used to identify that the identity for Menu 1 is World. The indicators 1606 for Menu 2 and Menu 3 indicate the identity is Designer. Accordingly, using such indicators 1606 may provide clarity to why certain menus are included in the TOC 1600.
In embodiments where “All” is selected for the identities, the user interface 1600 may present a TOC tree that represents the union of all TOC trees for all identities or, which is the same, the TOC structure as it would be seen by a “super user” identity. In some embodiments, building the table of contents 1602 may be interactive. For example, an ability to drag-and-drop tree nodes (including non-leaf nodes) to other places in the hierarchy may be enabled. The order of nodes at runtime may be the same as order of nodes created at design-time. Note that when node N1 is moved under a new parent—e.g. node P1—a determination may be made that the identity that is set on the CommandBarSectionitem to the node N1 is a member of the identity set on the CommandBarSectionitem of its parent node P1. If it is not a member, a warning may be displayed that not all members of the identity, that is set on the CommandBarSectionitem to the node N1, may be able to see the TOC structure the way the administrator is trying to build it.
To understand the situation better, consider the following example: CommandBarSectionitem to node N1 has identity World and CommandBarSectionitem to node P1 has identity Designer. Right now, anyone can see node N1 in TOC tree. If node N1 is moved under new parent P1, users who are not members of the Designer identity, then N1 will not be shown in the user interface 1600 because its parent P1 cannot be seen, and, correspondingly, the users are not able to see the whole subtree under P1. If the administrator decides to ignore the warning then parts of the TOC structure that have “incorrect” identities may be displayed in a distinct color to alarm administrator that the structure has problems. This may be useful in scenarios where the identity membership was consistent when the TOC was designed but later was modified in such a way that identities set on the TOC structure are “incorrect”. In this case, when an administrator opens the user interface for modeling the TOC, the administrator may see the parts of the structure that are not “correct” and which need changes of identities set on some CommandBarSectionItems. Further, some embodiments provide an ability to change identity set on the CommandBarSectionitem to any node in TOC tree, and an ability to find and select an ItemType and drag-and-drop it into the existing TOC tree structure.
There may be a GlobalPresentationConfiguration including ItemTypes of CommandBarSection, which may include definitions for default user interface elements and self-defined user interface elements for various command bars (meus, toolbars, sidebars). The GlobalPresentationConfiguration may define, for each location of the user interface, what the user interface elements are, the content, and the way they behave. When a user interface element or control is defined on the global level, the user interface element applies to any item or item type specified for the user interface element. Each client application 425 may modify the user interface elements associated with a CommandBarSection by defining a type of the user interface element, a location of the user interface element, an identity associated with the user interface element, an event associated with interacting with the user interface element, and an event handler to handle the event, and so forth. These modifications may be performed on a global level, item type level, or item level. In some embodiments, item type level specific command bars may be applied on top of global level command bars.
In the depicted user interface 1800, the global presentation configuration may be selected from the table of contents. A name 1802 of “Global” may be presented in a section of the user interface 1800. A command bar section tab 1804 may be presented with data arranged in rows and columns for “Classification”, “Name”, “Location” “Builder Method”, “Label”, “Description”, “Additional Data”, “sort_order”, “For Identity”, “For Classification”. The classification may include “Data Model” or “Method”. The name may be a unique text string. The Location may specify which portion of the user interface the row is associated with. For example, Locations may include “Item Window Sidebar”, “Popup Menu for Main Window TOC”, “Main Menu”, “Main Toolbar” (shown as 1806), “Main Window Toolbar” (shown as 1808), “Items Grid Toolbar”, “Tearoff Window Main Menu”, and so forth. The builder method may specify the method that is called by CUI server engine 415 when building the “dynamic” parts of the CUI definition. The Label may provide a brief label for the user interface element. Additional data may allow any suitable data to be associated with the user interface element, such as layout data. The sort order may specify in which order the user interface element is to be added to a sequence of a command bar. The For Identity may specify which identities can interact with the user interface element. The For Classification may specify which classifications can interact with the user interface element. This information may be added to the self-describing data system as metadata for the user interface element.
To add a button to the Main Window Toolbar, administrator may use an input peripheral (mouse, keyboard, stylus, touchscreen) to select item with Location: Main Window Toolbar, and select “View ‘Command Bar Section’”. Further, the user may select to create a user interface element related to the Main Window Toolbar in a Command Bar Item tab, and that it is a new relationship. A radio button list 1900 of item types may appear, as depicted in
The user interface 2100 may present graphical user interface elements to input button details. For example, options for “Name”, “Label” (“Button Label” has been input), “Tooltip_Template” (“Button Tootip” has been input), “Additional Data”, “On_Init_Handler”, “On_Click_Handler” (“Hello World” has been input), and an “Image” (the capital letter B has been chosen. The details may be saved and the user may close all Items that were opened. In some instances, the user may log out of the client application 425 and log back into the client application 425 to view the changes, while in some embodiments the user may refresh the user interface.
In any instance, a request may be transmitted to the backend 410 to cause the CUI server engine 415 to generate the CUI definition including the metadata for the newly added button at the global level. The CUI definition may be returned to the client application 425 and rendered on the display screen. For example,
None of the description in this application should be read as implying that any particular element, step, or function is an essential element that must be included in the claim scope. The scope of patented subject matter is defined only by the claims. Moreover, none of the claims is intended to invoke 35 U.S.C. § 112(f) unless the exact words “means for” are followed by a participle.
This application claims priority to and the benefit of U.S. Provisional Application Patent Ser. No. 62/860,657 filed Jun. 12, 2019, the entire disclosure of which is hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62860657 | Jun 2019 | US |
