Abstract: A secondary output of a user interface created using a presentation framework may be created by making a clone of the user interface, then modifying the cloned user interface by expanding various components. The cloned user interface may also be configured to the output characteristics of the secondary output, which may be a printer or other hardcopy device. The user interface may be created with callbacks or other actions that may be executed when the cloned user interface is configured. The callbacks may cause certain user interface components to be changed on the cloned version of the user interface.

Abstract: A user interface mechanism may be defined by a story from which a wizard engine may create a user interface. The engine may present the story using various user interface containers that define a layout and general functions of a user interface, along with styles that may define the ‘look and feel’ of the user interface. The story may define an action performed once data are collected from the user. The story may also define data passed to the action, as well as the data collected from a user. The story may further define translation routines or other actions that may be launched in response to receiving user action and used to generate data that may be passed to the action.

Abstract: A secondary output of a user interface created using a presentation framework may be created by making a clone of the user interface, then modifying the cloned user interface by expanding various components. The cloned user interface may also be configured to the output characteristics of the secondary output, which may be a printer or other hardcopy device. The user interface may be created with callbacks or other actions that may be executed when the cloned user interface is configured. The callbacks may cause certain user interface components to be changed on the cloned version of the user interface.

Abstract: A user interface mechanism may be defined by a story from which a wizard engine may create a user interface. The engine may present the story using various user interface containers that define a layout and general functions of a user interface, along with styles that may define the ‘look and feel’ of the user interface. The story may define an action performed once data are collected from the user. The story may also define data passed to the action, as well as the data collected from a user. The story may further define translation routines or other actions that may be launched in response to receiving user action and used to generate data that may be passed to the action.

Abstract: A secondary output of a user interface created using a presentation framework may be created by making a clone of the user interface, then modifying the cloned user interface by expanding various components. The cloned user interface may also be configured to the output characteristics of the secondary output, which may be a printer or other hardcopy device. The user interface may be created with callbacks or other actions that may be executed when the cloned user interface is configured. The callbacks may cause certain user interface components to be changed on the cloned version of the user interface.

Abstract: A user interface mechanism may be defined by a story from which a wizard engine may create a user interface. The engine may present the story using various user interface containers that define a layout and general functions of a user interface, along with styles that may define the ‘look and feel’ of the user interface. The story may define an action performed once data are collected from the user. The story may also define data passed to the action, as well as the data collected from a user. The story may further define translation routines or other actions that may be launched in response to receiving user action and used to generate data that may be passed to the action.

Abstract: A user interface may be selected for a system with hierarchical data types by traversing an inheritance tree to find a pre-defined user interface, or by automatically generating a user interface based on the type definition. The automatically generated user interface may include tabs or groupings for components of the data type that may be inherited from other data types. In some embodiments, portions of the automatically generated user interface may be obtained from other data types.

Abstract: A change management system for managing configurable devices such as computer systems uses a set of rules for validating change requests, linking change requests, and determining inconsistencies within various configuration states. Analysis and validation may happen at the time the change request is created with respect to the current environment, as well as analysis and validation with respect to other pending requests and proposals, and historical actual states. The maintenance of accurate and consistent state and change information may enable various automated tools to analyze and manipulate change requests, including analysis of future desired states, historical actual states, pending change requests, and current state. The change request may be processed through an approval cycle all the while being incorporated into a scheduling system that may be used to detect inconsistent, illogical or harmful configurations in potential future configurations.

Abstract: An enterprise application may operate on a platform that is able to execute a solution pack that may have various configurable items incorporated into the solution pack. During runtime, the platform may present the configurable items in a user interface. The items may be embedded within the solution pack, which may contain various descriptors of a business process, including workflow definitions, data types handled in the process, and various rules or other definitions. The options made available within the solution pack may alter the workflow, alter conditions used within the workflow, change data types, or change any other element. The options may also be made available through an application programming interface to the platform.

Abstract: A change management system for managing configurable devices such as computer systems uses a set of rules for validating change requests, linking change requests, and determining inconsistencies within various configuration states. Analysis and validation may happen at the time the change request is created with respect to the current environment, as well as analysis and validation with respect to other pending requests and proposals, and historical actual states. The maintenance of accurate and consistent state and change information may enable various automated tools to analyze and manipulate change requests, including analysis of future desired states, historical actual states, pending change requests, and current state. The change request may be processed through an approval cycle all the while being incorporated into a scheduling system that may be used to detect inconsistent, illogical or harmful configurations in potential future configurations.