Patent Publication Number: US-2011078103-A1

Title: Framework to support application context and rule based ui-control

Description:
FIELD OF THE INVENTION 
     The disclosure relates to a system and method for providing user interface (UI) control for software applications, in particular, UI control based on application context and rules. 
     BACKGROUND 
     Modern enterprises such as governmental organizations and private businesses typically use computer systems to manage their operations. Software applications designed to run on these computer systems may have a variety of user interfaces. In some situations, one software application that involves user interactions may need to vary the user interface according to different user groups, business units and/or operations to be performed, etc. For example, a tax processing application may have only one backend tax engine but may have different UIs according to different types of taxes being processed (e.g., personal income tax, corporate tax, sales tax). Therefore, in some cases, after a business software application is delivered to a customer, the customer may need to customize the UI layout and UI element properties according to the customer&#39;s specific business requirements, which cannot be covered by the business application out of the box. 
     Typically, when a software application is delivered, the application user interface is fixed. In some cases, the software vendor may provide some a plurality of user interface templates for a software application so the software application may have different UIs by default for different business requirements. However, using current technology, neither the fixed UI nor the default UIs can fulfill all specific requirements of customers. Efforts to change the situation have not been successful so far for several reasons. First, from a software application developer&#39;s point of view, it is difficult to foresee all customer requirements for UI layout and/or UI display properties during the development phase of a software application for all potential customers. It is either too expensive or too many different preferences or even requirements for UIs by a large amount of customers. Second, some UI changes are business-context related. When a new business requirement arises, UI changes may be needed. These UI changes cannot be foreseen before the business application is delivered. Third, the business application may be improved continuously after delivery to a customer, that is, UI changes may be needed with the continuous usage of the business application. 
     Therefore, presently, any changes for a user interface of a delivered software application beyond the templates provided by default is difficult and need involvement of a software developer to re-program the software application (e.g., change software code of the software application). Accordingly, there is a need in the art for providing user interface (UI) control for software applications that can adapt to customers&#39; needs without application developers&#39; involvement or coding changes after the software applications have been delivered to customers. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram according to an exemplary embodiment of the present invention. 
         FIG. 2  is a process diagram for creating and maintaining rules for a business application in design-time according to an exemplary embodiment of the present invention. 
         FIG. 3  is a process diagram for creating and changing a social service plan according to an exemplary embodiment of the present invention. 
         FIG. 4  illustrates a display of a design-time configuration tool according to an exemplary embodiment of the present invention. 
         FIG. 5  illustrates another display of the design-time configuration tool according to an exemplary embodiment of the present invention. 
         FIG. 6  is an exemplary system implementation according to an exemplary embodiment of the present invention. 
         FIG. 7  is another exemplary system implementation according to an exemplary embodiment of the present invention. 
         FIG. 8  shows a structure of a computer running a rule-based UI control framework according to an exemplary embodiment of the present invention. 
         FIG. 9  shows a multi-tier computer system for a rule-based UI control framework according to an exemplary embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments of a method and system provide a rule based user interface control for a software application user interface. At configuration time of an installed software application, the method may provide a design-time environment for defining a rule for a UI element to be displayed in the software application. The rule may affect a value of a property of the UI element. The method may further persist the rule in a rule engine. Then at runtime, upon receiving from the software application a request to determine the value of the property of the UI element, the method may retrieve the rule from the rule engine by a runtime service, evaluate the rule to determine the value for the property of the UI element and set the value for the property according to the evaluated rule. Next, the method may return the set value for the property to the software application for displaying the UI element according to the set value. 
       FIG. 1  illustrates an exemplary software system  100  according to the present invention. The software system  100  may comprise an application  102 , a rule based UI control framework  110  and a rule engine  112 . The application  102  may be a business application that interacts with users (e.g. display or change a sales order). The application  102  may comprise a context  104 , an UI control  106  and a view modifier  108 . The context  104  may represent application related data (e.g., a data object containing application related data). The application related data may be provided by application logic (e.g., logic implemented for pertinent tasks to be performed by the application) and consumed by presentation logic (e.g., logic implemented to determine how user interface elements may be presented). The UI layout  106  may define how the user interface looks like (e.g., which UI elements are displayed and how they are displayed relating each other). The view modifier  108  may be used to visualize the application during runtime (e.g., rendering the display). The view modifier  108  may be responsible for selecting a correct UI layout, triggering data initialization, executing input processing, creating and rendering a view instance. 
     In one exemplary embodiment, the application  102  may be implemented based on a model view controller (MVC) design pattern to ensure a clear distinction between application logic and presentation logic. The MVC design pattern may allow a software application to compartmentalize the user interface, business logic, and flow logic so these components of the software application can be readily reused and more easily maintained. The UI layout  106  and UI element properties may be defined in the view part of the pattern and the view modifier  108  may be implemented as a controller. 
     The rule based UI control framework  110  may comprise a design-time portion  116  and a runtime service  114 . The design-time portion  116  may comprise design-time tools such as a configuration tool  118 , a rule definition  120  and a rule binding  122 . In design-time, the design-time portion  116  may facilitate creation of rules that control how UI elements may be displayed in the application  102 . In runtime, the runtime service  114  may execute the created rules to determine values of the properties associated with the UI elements. The configuration tool  118  may comprise a user interface that helps a user to create rules. The rule definition  120  may help defining what conditions need to be included in a rule. 
     In one embodiment, a rule may be defined to take into consideration of application contexts, and may affect a UI property of a corresponding UI element. The application contexts may include application parameters and business contexts. Application parameters may include data applicable to the application as a whole. For example, a shared application may contain an application parameter tracking how many users currently are logged in, an application parameter representing a system time, and/or an application parameter representing a current user. The business context may be data objects representing relevant data for business operations. For example, in an flight booking application, information corresponding to flight may be considered as business context, such as, but not limited to, carrier ID, flight number, departure and arrival time and destination, etc. In an expense claiming application, information such as, but not limited to, expense type, amount, currency and place may be considered as business context. Accordingly, for example, in an application for air travel management, a rule may be defined as “if carrier id=LH(Lufthansa), then set the UI element as read-only” (LH may be short hand id for Lufthansa); in another application for customer relationship management, a rule may be defined as “if business partner is ‘BP 1 ’ and contract object is ‘CO 1 ,’ then set the UI element visible but read only.” 
     Once a rule is defined in the rule definition  120 , the rule binding  122  may assign (e.g., bind) the rule to a UI element by defining a linkage between the newly defined rule and the UI element. 
     The rule engine  112  may provide a storage for the defined rules and assignment (binding) of the defined rules to UI elements. As shown in  FIG. 1 , the rule definition  120  may be coupled to the rule engine  120 , thus, once a rule is defined, it may be processed and persisted in the rule engine  112 . In one embodiment, the application  102  may be a compiled desktop software application. For example, the application  102  may be the client portion of a client-server application with the rule based UI control framework  110  and the rule engine  112  as the server portion. In another embodiment, the application  102  may be a portal application implemented in a browser like display (e.g., HTML displayed in a browser type of user interface). For example, the application  102 , the rule based UI control framework  110  and the rule engine  112  may be implemented as a three-tier application. The application  102  may be the first tier interfacing users, the rule based UI control framework  110  may be a middle tier performing business processes and the rule engine  112  may be the back end tier for data storage. The three tiers may be deployed on one physical machine or spread out into multiple machines (e.g., the application  102  on a web server, the rule based UI control framework  110  on an application server and the rule engine on a data server.) 
     The rule based UI control framework  110  may control the application user interface based on the rules. In design-time, a user may use the design-time tools of the design-time portion  116  to configure and assign rules to UI elements in a view (e.g., a display of a UI) of the application  102 . Defined rules may be persisted in the rule engine  112 . In runtime, before displaying the view, the view modifier  108  of the application  102  may send the runtime service  114  a list of UI elements to be displayed in the view. In response, the runtime service  114  may retrieve defined rules associated with (e.g., assigned to) each UI element in the list from the rule engine  114  and evaluate the retrieved rules. Based on the evaluation result, the view modifier  108  in the application  102  may set the values for the properties of corresponding UI elements to be displayed accordingly. 
     In embodiments, a rule may be implemented in a decision table, decision tree, formula or any other rule type provided by the rule engine  112 . For example, an decision table may be used to define a rule where a selected application context may be used as a source to determine the UI property of a UI element. Embodiments of the present invention may define rules to take any view and/or controller context into consideration as a part of impacting facts for UI element properties(e.g. visible/invisible, mandatory/optional, enable/disable etc). In one embodiment, by using different rule expression type (e.g. decision table or formula), users of the design-time tools may determine how the context will affect UI element properties by maintaining content of a defined rule in the rule engine  112 . Different user groups may provide their own rules for UI logic in the view to satisfy their own needs. 
     In one embodiment, the rule definition  120  may take advantage of rule engine to model the presentation logic of UI layout by rules instead of using program code. The input of the rule may be the business context (e.g., relevant business data (Lufthansa as a carrier vs. to use American Airline as the carrier) for an operation of the application (e.g., displaying flight information)) or application parameters (e.g., system time, current user), and output the rule may be UI elements properties&#39; values. 
     In one embodiment, the configuration tool  118  may be implemented as a what you see is what you get (WYSIWYG) design environment. Implementation may be achieved via, for example, an application programming interface (API) of an application development environment. In one embodiment, the configuration tool  118  may retrieve a UI layout for the application  102 , determine a MVC context, evaluate application parameters and UI element properties for a view of the application  102 . By using the information retrieved, the configuration tool  118  can visualize the application  102 &#39;s view and UI layout in a way of WYSIWYG (e.g., display the UI layout and corresponding UI elements accordingly in the configuration tool  118 ). Therefore, using the configuration tool  118 , for each UI element, a user can choose a corresponding application parameter and/or business context and/or MVC context that may contribute to certain UI element property (e.g. visible/invisible) and determine how the UI element looks in the view of the application  102 . In one exemplary embodiment, a decision table in rule engine  112  may used. In this decision table, the source fields may be selected context(s) and target fields may be selected UI element properties. Different users may maintain the decision table values according to their own business requirements. The decision table together with it&#39;s content may be persisted by the rule engine  112 . The rule based UI control framework  110  may act as a bridge that links the application  102  and the rule engine  112 , and may extend the flexibility of UI control for the application  102 . 
     Design-time tools (e.g., the configuration tool  118 , the rule binding  112  and the rule definition  120 ) of the design-time portion  116  may provide the functionalities to assign/reassign/remove a rule to certain UI element. In one embodiment, instead of or in addition to a WYSIWYG design environment, a testing mode may be provided to check the runtime behavior on how assigned (e.g., bound) rules affect an application UI. 
       FIG. 2  illustrates user interactions for creating and maintaining rules for a business application at design-time according to an exemplary embodiment of the present invention. It should be noted that the design-time is a configuration time that the software application has been developed or even deployed, but not the time that the software application is still under development. In an action  202 , a user  230  may select an application he/she wants to influence (e.g., modify) the UI behavior of. The rule based UI control framework  110  may be triggered by the action  202  and may perform a function  204  to retrieve existing context available in the application. In one embodiment, the existing context may include all available information designed for the selected application. The information may influence the UI behavior at runtime of the selected application and may be represented by context objects (e.g., software data objects). In one or more embodiments, the user  230  may be a software application developer, an administrator administering the application in a deployed working environment (e.g., an information system administrator at a customer site), or an end user using the application. 
     After the function  204  to retrieve existing context available in the application, the rule based UI control framework  110  may perform another function  206  to retrieve existing rules and the assignments for each rule assigned to UI elements stored in a rule repository  208  that may locates in a rule engine  112 . Thereafter, at a step  210 , the available context objects and rules may be displayed to the user  230  to let the user  230  to take an overview of existing rules/assignments. 
     The user  230  may decide at a decision step  212  to take one of the following actions: to create a new rule  218 , to assign an existing rule to a UI element  214 , or to exit  222 . If the user  230  selects to create a new rule  218 , a design interface (e.g., the configuration tool  118 ) for the new rule may be displayed and the user  230  may interact with the design interface to create a new rule. In one embodiment, creation of the new rule may also include assigning the new rule to at least one UI element. Upon finishing creating the new rule, the rule based UI control framework  110  may update the rule engine repository at a step  216 . If the user  230  selects to assign an existing rule to the UI element  214 , the user  230  may select existing rule(s) and assign the rule(s) to certain UI element(s). Upon finishing the action  214 , the rule based UI control framework  110  may update the rule engine repository at the step  216 . If the user  230  selects to exit  222 , the user may have finished the interaction with the application and may end the application. 
       FIG. 3  illustrates a process  300  for loading and displaying a business software application according to an exemplary embodiment of the present invention. The process  300  may begin when a user  302  starts the application  102  in a step  310 . The application  102  may prepare context data at a step  312 . The prepared context data may include any available information designed for the application  102  (e.g., user  302 &#39;s log in id, user  302 &#39;s accessing privilege defined in the application  102 , operations the user  302  may be performing). As described above, the available information may be represented in context objects. 
     At step  314 , the application  102  may evaluate the attributes for UI elements to be displayed in a view of the application  102 . The application  102  may invoke run time services in the rule based UI control framework  110  (e.g., the runtime service  114  in  FIG. 1 ) to perform UI control functions. At step  316 , in response to the application  102 &#39;s request, the rule based UI control framework  110  may rules associated with UI elements to be displayed from the rule engine  112 . At step  318 , the rule engine  112  may retrieve the rules at step  318  and return the rules to the rule based UI control framework  110 . Next, at step  320 , the rule based UI control framework  110  may evaluate the rules and return the evaluation results to the application  102 . Then, at step  322 , the application  102  may update the attributes of the UI elements according to evaluation result provided by the rule based UI control framework  110 . Then, at step  324 , the UI of the application  102  may be populated with the UI elements with attributes determined by the rules assigned to the UI elements. Finally, after the UI of the application  102  is rendered, the control of the application  102  may be returned to the user  302  for further actions. 
       FIG. 4  illustrates a display of a user interface  400  for rule configurations at design-time according to an exemplary embodiment of the present invention. The design-time configuration tool  400  may be used to configure an application  401  (e.g., an airline business application code named as ZFPM_FDT_FLIGHT). The design-time configuration tool  400  may include a panel displaying an application hierarchy  402  and a window  418  for creating a rule for the application  401 . The window  418  may be anchored to the application  401  (e.g., docked next to the panel displaying the application hierarchy  402 ) or floating (e.g., a pop up window that may be drag around on the user interface  400 ). In one embodiment, the application  401  may represent a software application including several components that may be configured together in specific layouts and/or steps. 
     The application hierarchy  402  may comprise application configuration  403  as a root. The application configuration  403  may be used as a configuration root template for a series or a variety of software products containing common components provided by a software company. The common components may be configured together to form a particular UI layout. The application configuration  403  may comprise an instance  404  of the application configuration. The instance  404  may be one specific configuration for the application configuration  403 . The instance  404  may comprise one or more variants  406  (only one shown) for the application configuration  403 . Each variant  406  may contain configuration for a group of components in a specific layout and/or step. Thus, different variants  406  may correspond to different UI layouts. In one embodiment, a user may choose one variant to be displayed according to a business context at runtime. 
     The variant  406  may comprise a main view  408 . The main view  408  may be referred to as the main view for a specific lay out (e.g., a main view in the airline business application ZFPM_FDT_FLIGHT/MAIN). The main view  408  may comprise a sub view  410 . The sub view  410  may by a part of the main view  408  and may contain a subset of components to be displayed on the main view  408 . In one embodiment, the sub view  410  may be a frame or a tab displayed in the main view  408 . In one or more embodiments, the sub view  410  may be referred to as a container. The sub view  410  may comprise a component  412  for the sub view  410  and the component  412  may comprise a view  414  (e.g., a view coded named V_MAIN for the airline business application ZFPM_FDT_FLIGHT). The view  414  may comprise a list of elements  416  (e.g., including a UI element  416   a ) for the view  414 . In one embodiment, the view  414  may be implemented as a view in the MVC pattern and each UI element may be implemented as a configurable building block and may be implemented in an object oriented programming language (e.g., Java or C#), or other suitable non-object oriented programming languages. 
     The window  418  may be a user interface for creating a rule and assignment. The window  418  may include an information label  419 . The information label  419  may show the name of the component, the name of the view and the element associated with the rule being worked on. In one embodiment, the window  418  may be a pop up window when a user right clicks an element in the hierarchy  402  and invokes a “create a rule” command form the pop up menu, so these context information may be provided to the window  418  and displayed automatically. In the example shown in  FIG. 4 , the information label  419  may show the component  412  (e.g., ZFPM_FDT_FLIGHT), the view  414  (e.g., V_MAIN) and a specific element of the view  414  (e.g., the UI element  416   a , a flights airline carrier id named “TRC_FLIGHTS_LINE_CARRID_LBL”). The window  418  may also comprise a drop down box  420  to allow a user to select an existing rule as a template. If an existing rule is selected, a button (not labeled) next to the drop down box  420  may be enabled to allow the user to copy the existing rule as a template (e.g., context objects to be considered and properties to be affected) for a new rule to be created. The window  418  may further comprise a text box  421  for the user to enter a name for the rule. 
     The window  418  may comprise a drop down box  430  to let the user to select a context that may be taken into consideration for the rule. Once the user selects a context (e.g., FLIGHTS), context attributes available for the selected context may be shown in an area  422  of the window  418 . The area  422  may also show application parameters pertinent to the whole application  401  (e.g., current user, system time). In one embodiment, the business context and application parameters may be displayed side by side with the context attributes available for the selected context in the drop down box  430 . 
     The window  418  may further include displays for element properties  423 , source columns  424 , target columns  426 , a decision table  428  and functional buttons  430 . The element properties  423  shows properties for a selected UI element (e.g., the UI element  416   a  selected in the view  414  from the hierarchy  402 ). The source columns  424  may contain source context objects. A source context object may be selected from either the application parameters or context attributes available for the selected context. For example, when the selected context is “FLIGHTS,” a source context object “CARRID” may be selected from the list of the available context attributes shown in the area  422 . The target columns may contain properties of the UI element to be affected. For example, “enabled” may be added to the target columns for the UI element  416   a . Thus, a rule may be created and saved in the decision table  428 . For example, “if carrier_id=LH (Lufthansa), then set it read-only.” The decision table  428  may contain function buttons (e.g., add a row, delete a row). And the window  418  may also contain functional buttons (e.g., save, cancel). The window  418  may provide an easy way of rule customization based on a decision table. 
       FIG. 5  illustrates a display of a rule engine workbench  500  according to an exemplary embodiment of the present invention. In one or more embodiments, a rule engine may provide a tool to display and facilitate configuration of rules stored at the rule engine. For example, the rule engine workbench  500  may be provided by a rule engine and thus provides a display of the rules from a rule engine perspective. The rule engine workbench  500  may comprise a rule name display  502  showing the rule&#39;s name, a short text  504  for a short description for the rule, an application label  508  for the software application the rule may be applied to and a drop down box  506  to specify an access level for a user. 
     Moreover, in a detailed display section, the rule engine workbench  500  may further comprise a plurality of functional buttons  510  for a decision table. The functional buttons include functions to manipulate data rows inside the decision table, for example, to insert a row, to append a row, to remove a row, to copy a row, to move a row up or down, to export data to an excel spreadsheet or to import data from an excel spreadsheet. The decision table may include context attributes  512  (e.g., application contexts or view contexts) and configurable properties  514 . Each row in the decision table may represent how configurable properties of the UI element may be affected by the context attributes. For example, the sample rule represented in  FIG. 5  may be “if business_partner is ‘BP 1 ’ and contract_object is ‘CO 1 ’, then set the UI element visible but read only, if business_partner is ‘BP 2 ’ and contract_object is ‘CO 3 ’, then set the UI element visible and mandatory.” In the example shown, the context attributes  512  may contain two columns (e.g., for a business partner and a contract object) and the configurable properties  514  may contain three columns (e.g., visible, enabled, state (read only, mandatory, etc.)). However, in another embodiment, different number of columns for either the context attributes or the configurable properties, or both may be implemented. 
       FIG. 6  is an exemplary system  600  implementation according to an exemplary embodiment of the present invention. In the exemplary system  600 , a business application may be deployed to a business environment and installed on a server  602 . An administrator  606  may connect to the server  602  from a workstation  604  and configure the business application for all users in a business unit that access the business application. Thereafter, users  608  and  612  may access the business application through their workstations  606  and  610  respectively. The user interface of the business application may be configured for business needs for users  608  and  612  based on the business unit they are in and access level they may have. In one embodiment, the user interface may be one common user interface for all users belong to the same business unit. In another embodiment, based on access level, UI elements may have different properties for different users (e.g., managers have more elements visible and enabled). The administrator  606  may be an information system administrator, a business partner, or a business administrator. 
       FIG. 7  is another exemplary system  700  implementation according to an exemplary embodiment of the present invention. In the exemplary system  700 , a business application may be deployed to a business environment and installed on a server  702 . Users  706  and  708  may access the business application through their workstations  704  and  710  respectively. Each user  706  or  708  may configure the user interface of the business application by creating rules satisfying their respective needs. Their personal configuration of UI may persisted in the rule engine as described above and the rules may be associated with their personal user id. Thus, each user  706  and  708  may have their own unique UI for the same business application running on a single server. In another embodiment, the business applications may be installed from the server  702  to each machines  704  and  710 . However, this will not change the way the UI is controlled by storing the rules governing the UI control in a respective rule engine. The rule engine may be stored in the server  702  or respectively on workstations  704  and  710  to be with the business application. 
     In one or more embodiments, the business application implementing rule based UI control may be a composite application. In the composite application, each UI element may be implemented as a generic building block that may be used in a variety of applications. The UI element may be programmed (e.g., coded) using one of the objected programming languages, such as Java, C#, or scripting languages, such as Java script, PHP, or other suitable programming technologies, such as JSP, ASP.NET, Java Servlet. In one embodiment, the software vendor may create rules for UI elements and deliver the rules as part of the software application. In another embodiment, the software vendor may create rules for UI elements and deliver the rules as additional content for the software application. In this embodiment, no changes to the application or the rule based UI control framework need to be redeployed, just adding new content to the rule engine in a customer working site. In yet another embodiment, a rule may comprise a logic affecting one or more UI elements. The logic may determine the manner a UI element may be displayed (e.g., a group of UI elements and one UI element displayed after another in a view; a group of UI elements that each displayed relative to another with respect to time and/or position). 
     It should be noted that the rule-based UI control according to the present invention differs from the traditional software application that varies UI based on roles of operators. In the traditional software application, the logic that controls what should be shown for a particular role is typically programmed in the source code and compiled into the application. Thus, the logic is fixed during the development phase of the traditional software application. Further, for the traditional software application, operators with the same role will always get the same UI layout, even under different business contexts (e.g., using either Lufthansa or American Airline as the carrier wont&#39; make any difference for the UI). 
     On the contrary, a software application based on the rule-based UI control according to the present invention may just enable the ability to vary UI according to rules. No rules need to be delivered with the software application. A customer can use the design-time configuration tool to define rules to meet whatever requirements (e.g., using Lufthansa as the carrier, the corresponding UI element may be read only; using American Airline as the carrier, the corresponding UI element may be editable). In one embodiment, users&#39; roles may be part of the application parameter and/or business context and a customer may define rules according to users&#39; roles and/or other business context information. But, still, the rules may be stored in the rule engine instead of compiled into the software application. 
     In one embodiment, the business application may be implemented based on rule engines, as known in the computer science field and provided by vendors such as SAP® and the like. The business application may also be built using web technology. In one or more embodiments, the end users (e.g., governmental agencies, corporations and businesses) may customize the rules for UI elements in the business applications according to the present invention. The rules may be created and maintained by the end user. This allows the end user to modify any rules as changes occur in the criteria related to the business criteria. In addition, as new needs may arise, the end user may generate new rules. 
     Embodiments of the present invention may provide software applications that may control user interface based on application context and rules. In one embodiment, the rule based UI control framework may take advantage of rule engine to define and persist rules for UI element of business application. The UI logic may be defined and encapsulated in the rule that is stored in a rule engine (e.g. by using common rule engine expressions like: decision table, decision tree, formula, etc). This framework can take application parameters and business context as decision factors for application UI layout and UI element properties. As UI control may be persisted and executed by rule engine, no programming enhancement is needed for application UI adjustment, changes can be delivered as rule engine content instead of code adjustment. 
     By using rule based UI control framework according to the present invention, business application developer, 3 rd  party middleware provider and customer may enhance or differentiate application user interface to fulfill their specific business requirement. These kind of enhancement may be achieved code-free. Also, these kind of enhancement may still be flexible enough to also take into the consideration of application parameters and context. 
       FIG. 8  depicts a structure of a computer server  602  according to one embodiment of the invention. The computer server  602  includes a processor  802 , memory  804 , and an I/O device(s)  806 . The processor  802  is connected to the memory  804  and I/O device(s)  806 . These connections are direct or via other internal electronic circuitry or components. 
     The processor  802  is a programmable processor that executes instructions residing in the memory  804  to receive and send data via the I/O device(s)  806 . The instructions may perform the operations of the application context and rule based UI control described herein. The term programmable processor as used herein is any programmable microprocessor or processor or combination of microprocessors or processors that can operate on digital data, which may be special or general purpose processors coupled to receive data and instructions from, and to transmit data and instructions to, a machine-readable medium. According to one embodiment of the present invention processor  802  is an Intel microprocessor. 
     Memory  804  is a machine-readable medium that stores data that is processed by processor  802 . The term machine-readable medium as used herein is any addressable storage device that stores digital data including any computer program product, apparatus and/or device (e.g., a random access memory (RAM), read only memory (ROM), magnetic disc, optical disc, programmable logic device (PLD), tape, hard drives, RAID storage device, flash memory or any combination of these devices). This may include external machine-readable mediums that are connected to processor  802  via one or more I/O device(s)  806 . 
     The I/O device(s)  806  may be one or more input/output interfaces that receive and/or send digital data to and from an external device. Interfaces as used herein are any point of access to an external device where digital data is received or sent, including ports, buffers, queues, subsets thereof, or any other interface to an external device. 
       FIG. 9  shows a multi-tier computer system  900  for a rule-based UI control framework according to an exemplary embodiment of the present invention. As described above, in one embodiment, the application  102 , the rule based UI control framework  110  and the rule engine  112  may be implemented as a three-tier application. The multi-tier computer system  900  may comprise a user terminal  902 , a web server  904 , an application server  906  and a database server  908 . A portal application according to present invention may deployed on the web server  904  to be the first tier interfacing users. A rule based UI control framework according to the present invention may be deployed on the application server  906  to be the middle tier performing business processes and a rule engine may be deployed on the database server  908  to be the back end tier for data storage. 
     It should be understood that there exist implementations of other variations and modifications of the invention and its various aspects, as may be readily apparent to those of ordinary skill in the art, and that the invention is not limited by specific embodiments described herein. Features and embodiments described above may be combined with and without each other. It is therefore contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the basic underlying principals disclosed and claimed herein.