Source: https://patents.google.com/patent/EP1770510B1/en
Timestamp: 2020-01-19 19:03:08
Document Index: 581251200

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60']

EP1770510B1 - Executable and declarative specification for graphical user interfaces - Google Patents
Executable and declarative specification for graphical user interfaces Download PDF
EP1770510B1
EP1770510B1 EP06020331.2A EP06020331A EP1770510B1 EP 1770510 B1 EP1770510 B1 EP 1770510B1 EP 06020331 A EP06020331 A EP 06020331A EP 1770510 B1 EP1770510 B1 EP 1770510B1
EP06020331.2A
EP1770510A2 (en
EP1770510A3 (en
2005-09-30 Priority to US72288805P priority Critical
2005-12-29 Priority to US11/324,155 priority patent/US8407610B2/en
2006-09-27 Application filed by SAP Portals Israel Ltd filed Critical SAP Portals Israel Ltd
2007-04-04 Publication of EP1770510A2 publication Critical patent/EP1770510A2/en
2009-01-28 Publication of EP1770510A3 publication Critical patent/EP1770510A3/en
2018-01-24 Publication of EP1770510B1 publication Critical patent/EP1770510B1/en
230000036462 Unbound Effects 0 description 9
101700070918 CALC family Proteins 0 description 3
101700017623 CALCA family Proteins 0 description 3
The present application is a non-provisional application claiming benefit under 35 U.S.C. 119(e) of U.S. Provisional Patent Application No. 60/722,888 (Attorney Docket No. 017900-005900US) titled EXECUTABLE SPECIFICATION OF GRAPHICAL USER INTERFACES (XGL) filed September 30, 2005, the entire contents (including all the appendices) of which are herein incorporated by reference for all purposes.
Document US 2004/0148586 A1 discloses a modeling system for universal specification of user interfaces. The system provides a means for defining user interfaces in a manner that is independent of any implementation context. The modeling system leads from a user friendly visual representation of the user interface through progressively detailed specification and structural and behavioral aspects of the user interface parts until a rigorous definition of the user interface in all its contexts of use is achieved.
Document by Jean Vanderdonck: "An MDA-compliant environment for developing user interfaces of information systems", Advanced System Information Systems Engineering; LNCS, Volume 3520, Springer Verlag, Berlin/Heidelberg, Germany, 2005-05-17, pages 16 to 31, discloses an environment which allows to develop user interfaces at a level of extraction that is higher than the level where the code is manipulated. The environment includes models that characterize a user interface from the end user's viewpoint and a specification language that allows designers to specify such interfaces, the method for developing interfaces in forward, reverse, and lateral engineering based on these models and a suite of tools that support designers in applying the method based on the models.
Document by Quentin Limbourg et al.:"USIXML: A language supporting multi-path development of user interfaces", Engineering Human Computer Interaction and Interactive Systems, LNCS, Volume 3425, Springer Verlag, Berlin/Heidelberg, Germany, 2005-06-30, pages 200 to 220, discloses a user interface description language allowing designers to apply a multi-path development of user interfaces. It is disclosed that the user interface can be specified and produced at and from different, and possible multiple, levels of extraction while maintaining the mappings between these levels, if required.
Document by Mir Farouq Ali et al.: "Building Multi-Platform User Interfaces with UIML", 2001-11-09, pages 1 to 12, discloses a user interface markup language based on an XML-based language that allows the canonical description of user interfaces for different platforms.
Document US 6,342,901 discloses a specification language for defining user interface panels that are platform-independent. Thereby, the creation and modification of platform-independent user interfaces is possible without programming directly in the specification language.
Document Bernhard Humm et al.: "Model-Driven Development - Hot Spots in Business Information Systems", Model-Driven Architecture - Foundations and Applications Lecture Notes in Computer Science, LMCS, Volume 3748, pages 103 to 114, Springer, Berlin, 2005-01-01, disclosed advantages of model-driven development.
Document by Martin Kempa et al.: "Model-driven Architecture", Informatik-Spektrum, Springer, Berlin, Volume 28, No. 4, pages 298 to 302, discloses a brief introduction in model-driven architecture, where models form the central elements of a software development process.
An XGL representation that is created from a model representation may then be used for processing in the runtime environment. For example, the XGL representation may be used to generate a machine-executable runtime GUI (or some other runtime representation) that may be executed by a target device. As part of the runtime processing, an XGL representation may be transformed into one or more runtime representations (e.g., source code in a particular programming language, machine-executable code for a specific runtime environment, executable GUI, etc.) that may be generated for specific runtime environments and devices. Since the XGL representation, rather than the design-time model representation, is used by the runtime environment, the design-time model representation is decoupled from the runtime environment. An XGL representation thus serves as the common-ground or interface between design-time user interface modeling tools and a plurality of user interface runtime frameworks. It provides a self-contained, closed, and deterministic definition of all aspects of a graphical user interface in a device-independent and programming-language independent manner. In an embodiment, the XGL semantics may be rigorously defined using an abstract model of a GUI framework. A specific embodiment of XGL is described below under the section titled "SAMPLE XGL SPECIFICATION (example embodiment)".
Fig. 1 depicts a simplified environment 100 in which an embodiment of the present invention may be used. As depicted in Fig. 1, a modeling tool 104 running-on a data processing system 102 may be used by a GUI designer during the application design phase to create a model representation 106 for a GUI application. Model representation 106 may be a machine-readable representation of an application or a domain specific model. Model representation 106 may encapsulate various design parameters related to the GUI such as GUI components, dependencies between the GUI components, inputs and outputs, and the like. Model representation 106 provides a form in which a model(s) is persisted and transported, and possibly handled by various tools such as code generators, runtime interpreters, analysis and validation tools, merge tools, and the like. In one embodiment, model representation 106 may be a collection of XML documents with a well-formed syntax. Various different modeling tools 104 may be used to generate model representation 106. These tools include but are not restricted to Visual Composer™ provided by SAP AG of Germany, Rational Rose™, Borland Together™, Microsoft Visio™, and others. Modeling tool 104 and model representation 106 may be considered to be part of a design time environment.
As previously indicated, XGL is independent of any GUI framework or runtime platform and is also independent of any programming language or target device characteristic. Further, XGL is capable of unambiguously encapsulating execution semantics for the GUI model representation. Accordingly, XGL representation 110 generated for a model representation 106 is declarative and executable -- XGL representation 110 thus provides a representation of the GUI of model 106 that is not dependent on any device or runtime platform, is not dependent on any programming language, and unambiguously encapsulates execution semantics for the GUI. The execution semantics may include for example, identification of various components of the GUI, interpretation of connections between the various GUI components, information identifying the order of sequencing of events, rules governing dynamic behavior of the GUI, rules governing handling of values by the GUI, and the like. The XGL representation is also not GUI runtime-platform specific. The XGL representation provides a self-contained, closed, and deterministic definition of all aspects of a graphical user interface that is device independent and language independent. XGL generator 108 may be configured to generate XGL representations for models of different types, which may be created using different modeling tools 104.
It should be apparent that abstract XGL representation 110 may be used to generate GUIs for various other runtime platforms (e.g., Extensible Application Markup Language (XAML), etc.) and devices. The same model representation 110 may be mapped to various runtime representations and device-specific and runtime platform specific GUIs. In general, in the runtime environment, machine executable instructions specific to a runtime environment may be generated based upon XGL representation 110 and executed to generate a GUI in the runtime environment. The same XGL representation may be used to generate machine executable instructions specific to different runtime environments and target devices.
This section-describes two examples depicting the process of generating an abstract representation for a model representation and using the abstract representation to generate GUIs for different runtime platforms. These examples are however not intended to limit the scope of the present invention as recited in the claims.
An XGL generator 404 is used to generate an XGL representation 406 for the model representation. XGL generator 404 may use mapping rules to transform the model representation to an XGL representation. According to an embodiment of the present invention, the XGL representation may be in the form of an XML file. An XGL representation in XML for the model representation depicted in Fig. 4B is provided in Appendix A of U.S. Provisional Patent Application No. 60/722,888 (Attorney Docket No. 017900-005900US) filed September 30, 2005.
XGL representation 406 is then used to generate GUIs for various different devices and runtime platforms. In this example, an XGL-to-Java compiler 408 generates Java code 410 based upon XGL representation 406. Rules may be provided for mapping the XGL representation to Java code. An example of the Java code that may be generated for the bank application GUI is depicted in Appendix B of U.S. Provisional Patent Application No. 60/722,888 (Attorney Docket No. 017900-005900US) filed September 30, 2005. The Java code may then be executed by a Java runtime environment 412 on a target device to generate a GUI 414. A screenshot of the generated GUI for a Java platform target device is depicted in Fig. 4C.
The same XGL representation 406 (e.g., the XGL representation depicted in Appendix A of U.S. Provisional Patent Application No. 60/722,888 ) may also be used to generate a GUI for a Flash runtime environment. As depicted in Fig. 4A, an XGL-to-Flash compiler 416 generates Flash code 418 based upon the XGL representation 406. Rules may be provided for mapping the XGL representation to Flash code. An example of the Flash code that may be generated for the bank application GUI is provided in Appendix C of U.S. Provisional Patent Application No. 60/722,888 (Attorney Docket No. 017900-005900US) filed September 30, 2005. The Flash code 418 may then be executed by a Flash runtime environment 420 on a target device to generate a GUI 422. A screenshot of the generated GUI for a Flash target device is depicted in Fig. 4D.
The XGL representation 406 (e.g., the XGL representation provided in Appendix A of U.S. Provisional Patent Application No. 60/722,888 ) may also be used to generate a GUI for a DHTML runtime environment. As depicted in Fig. 4A, an XGL-to-DHTML interpreter 424 is used to dynamically generate DHTML (or machine-executable code) on-the-fly based on XGL representation 410 and the DHTML is executed by a DHTML runtime environment 426 on a target device to generate a GUI 428. Rules may be provided for mapping the XGL representation to DHTML. A example screenshot of the generated GUI for a DHTML target device is depicted in Fig. 4E.
An XGL generator 504 is used to generate an XGL representation 506 for the model representation. XGL generator 404 may use mapping rules to transform the model representation to an XGL representation. According to an embodiment of the present invention, the XGL representation may be in the form of an XML file. An XGL representation in XML form for the model representation depicted in Fig. 5B is provided in Appendix D of U.S. Provisional Patent Application No. 60/722,888 . XGL representation 506 is then used to generate GUIs for various different devices and runtime platforms. In this example, an XGL-to-Java compiler 508 generates Java code 510 based upon XGL representation 506. Rules may be provided for mapping the XGL representation to Java code. An example of the Java code that may be generated for the analytics dashboard application GUI is provided in Appendix E of U.S. Provisional Patent Application No. 60/722,888 . The Java code may then be executed by a Java runtime environment 512 on a target device to generate a GUI 514. A screenshot of the generated GUI for a Java platform target device is depicted in Fig. 5C.
The XGL representation 506 (e.g., the XGL representation provided in Appendix D of U.S. Provisional Patent Application No. 60/722,888 ) may also be used to generate a GUI for a Flash runtime environment. As depicted in Fig. 5A, an XGL-to-Flash compiler 516 generates Flash code 518 based upon the XGL representation 506. Rules may be provided for mapping the XGL representation to Flash code. An example of the Flash code that may be generated for the analytics dashboard application GUI is provided in Appendix F of U.S. Provisional Patent Application No. 60/722,888 . The Flash code 518 may then be executed by a Flash runtime environment 520 on a target device to generate a GUI 522. A screenshot of the generated GUI for a Flash target device is depicted in Fig. 5D.
The XGL representation 506 (e.g., the XGL representation depicted in Appendix D of U.S. Provisional Patent Application No. 60/722,888 ) may also be used to generate a GUI for a DHTML runtime environment. As depicted in Fig. 5A, an XGL-to-DHTML interpreter 524 is used to dynamically generate DHTML on the fly based on XGL representation 510 and the DHTML is executed by a DHTML runtime environment 526 on a target device to generate a GUI 528. Rules may be provided for mapping the XGL representation to DHTML. A screenshot of the generated GUI for a DHTML target device is depicted in Fig. 5E.
Details related to the XGL specification embodiment described in this section are provided in Appendix G of U.S. Provisional Patent Application No. 60/722,888 (Attorney Docket No. 017900-005900US) filed September 30, 2005, the entire contents (including all the appendices) of which are herein incorporated by reference for all purposes.
The documentation for this embodiment is organized according to the XGL component structure. For example, "Part I: Data model" describes the elements that define the XGL data model including fields, infosets, infoactors, operators, and enumerations. "Part II: User interface" describes the elements that define the XGL display hierarchy including controls, interactors, and containers. This part also describes the various types of XGL resources. "Part III: Execution control" describes the elements that define the XGL execution semantics including actions, relays, and execution plans.
A Component element may have the following attributes in one embodiment: Attribute Type Description urn uri Required. The universal component name. The component urn uniquely identifies the component within the deployed system. xmlns:?? uri These are the namespace declarations for Error! Unknown document property name. and its extension kits.
xmlns:xg = "http://www.sap.com/visualcomposer/2005/xgl"
xmlns:ep = "http://www.sap.com/visualcomposer/2005/xgl/portal"
xmlns:bi = "http://www.sap.com/visualcomposer/2005/xgl/bi"
Mime type and file extension: The mime type for XGL document files is "text/xml". It is recommended that XGL files have the extension ".xgl" (all lowercase) on all platforms. It is recommended that gzip-compressed XGL files have the extension ".xglz" (all lowercase) on all platforms.
PART I: DATA MODEL 2. Fields and Expressions
Field categories: XGL defines three categories of fields in one embodiment (varies other categories may be provided in alternative embodiments):
Real fields: Fields in this category are defined by the underlying application.
Virtual fields: Fields in this category are used for temporary storage of end-user input.
Calculated fields: Fields in this category are computed from the values of other fields.
Objects, and the fields they contain, can be created under three different circumstances: (1) when the containing infoset is populated with data returned from the application (e.g., "Query Sales Data"), (2) when a new object is created as a result of a user interaction (e.g., "Add Row"), or (3) when an object is copied as a result of a user interaction (e.g., "Copy/Paste" or "Drag & Drop").
Depending on the object creation method and the field category, in one embodiment fields are initialized according to: Field Category Populate Object Create New Object Copy Object Real Application data init expression Copied data Virtual init expression init expression Copied data Calculated calc expression calc expression calc expression
The operands of an expression include literals, fields, functions, and other expressions. The operators of an expression indicate which operations to apply to the operands. There are two kinds of operators in one embodiment: (1) Unary operators (The unary operators take one operand and use a prefix notation (such as -x); and (2) Binary operators (The binary operators take two operands and use an infix notation (such as x+y)). Various operators are available in XGL. When an expression contains multiple operators, the precedence of the operators controls the order in which the individual operators are evaluated. For example, the expression x+y*z is evaluated as x+(y*z) because the * operator has higher precedence than the + operator. When an operand occurs between two operators with the same precedence, the operators are evaluated from left to right (left-associativity). For example, the expression x+y+z is evaluated as (x+y)+z. Precedence and associativity can be controlled using parentheses. For example, the expression x+y*z first multiplies y by z and then adds the result to x, but the expression (x+y)*z first adds x and y and then multiplies the result by z.
Implicit conversions: A conversion enables an expression of one type to be treated as another type. Conversions can be implicit or explicit, and this determines whether an explicit cast is required. Implicit conversions can occur in when the actual arguments of a function or an operator do not match its formal arguments. For instance, the conversion from type Number to type String is implicit, so the expression 'B' & 52 can implicitly be treated as the-expression 'B' & '52', which evaluates to 'B52'. XGL defines implicit conversions in various cases. Conversions may never cause exceptions to be thrown. If an implicit conversion doesn't succeed, the expression evaluates to undefined. If a conversion is required but there is no suitable implicit conversion, the expression evaluates to undefined.
2.4 Built-in functions: XGL provides a set of built-in functions for commonly used computations including string functions, numeric functions, scientific functions, date functions. time functions, and conditional functions.
Expression dependencies: The XGL generator can be configured to extract the expression dependencies and produce them as part of the generated XGL document. The expression dependencies information is required for the recalculation engine, and so it is handy to be able to obtain this information without having to actually parse the source expressions. The expression dependencies are produced in special attributes marked with the .refs suffix. For each XGL attribute attr that contains an expression, a corresponding attribute named attr.refs is also generated. The attr.refs contains the attr expression dependencies in a space-separated list. If the attr is a composite expression that does not have any dependencies, then attr.refs is set to the special value '1'. If the attr is a literal value or is undefined, then attr.refs is left empty.
Infoset cursor: All infosets maintain a cursor - that is, a pointer to the current infoset object. A non-empty infoset always has exactly one current object. When the infoset is populated with new data, the cursor is set to the first object in the infoset. The cursor can subsequently be moved to other positions in the infoset, but it is always kept within the bounds of the infoset - even when objects are inserted or removed.
An object type implements the following abstract interface in one embodiment: Method Description clone () : Object Clones the object getField (name): Variant Gets the value of a specified object field setField (name, value) Sets the value of a specified object field
3.5 Input and output ports: -A common use of infosets is for passing parameters through actor ports. Ports-are named connection points through which parameters flow between actors during execution. In one embodiment, each port is associated with an infoset, which holds the parameters that are sent or received through the port. Ports are uni-directional and are therefore divided into: Inports (input ports), used for sending input parameters to an actor when it is evaluated; and Outports (output ports), used for receiving output parameters from an actor after it has been evaluated. Port declarations appear inside the declarations of their containing actors, such as infoactors, operators, and certain kinds of interactors and relays.
4.2 Remote functions: The SAP Portal kit extends XGL with a set of infoactors that can be used for remote function invocation, including SAP R/3 functions, JDBC functions, and third-party functions, through the portal connectors framework.
Various infoactors are provided such as SAPFunction infoactor, JDBCFunction infoactor, and ExternalFunction infoactor.
5.1 Unary operators: Unary operators are operators that transform a single input infoset (named "IN") into a single output infoset (named "OUT").
5.2 N-ary operators: N-ary operators are operators that transform multiple input infosets (named "IN1,IN2,...,INX") into a single output infoset (named "OUT").
An enumeration is a.discrete values space defined as a list of {value:text} items. Enumerations are used for restricting data field values or for providing values help in input controls. Enumerations can be static or dynamic. Enumerations are declared in the Enumerations section of an XGL document:
Dynamic enumeration input: The dynamic enumeration contains a standard infoactor declaration that is used for retrieving the enumeration items at runtime. Any one of the supported XGL infoactor types can be used in a dynamic enumeration. The enumeration's infoactor is not part of any execution plan. It is evaluated when the enumeration is first accessed, or whenever any of its input field values is changed due to recalculation. The input infoset of the enumeration's infoactor controls the enumeration by defining its input parameters using calculated fields. The calculation expressions of the enumeration's input fields are defined in the context of the element that uses the enumeration, but the expressions can also contain fully qualified references to any field in the component. Whenever any of the enumeration's input fields is recalculated, the enumeration becomes invalid and its infoactor needs to be reevaluated. The reevaluation of the enumeration infoactor can be delayed by the XGL implementation until the next time the enumeration is accessed. However, if the enumeration is actively used in the current state of the user interface, then it should be immediately reevaluated. For example, if the enumeration is used for defining the entries list in a radio buttons group, the radio buttons need to be immediately redrawn -whenever the enumeration is invalidated. If the calculation expressions of the enumeration's input fields do not contain any field references (i.e., they are constant expressions), then the enumeration needs to be evaluated at most once (when it is first accessed).
PART II: USER INTERFACE 7. Controls
Examples of available control types, their classification criteria, and applicable attributes are detailed in Appendix G of U.S. Provisional Patent Application No. 60/722,888 (Attorney Docket No. 017900-005900US) filed September 30, 2005.
Data attributes: define the data field bound to the control and its values space.. The data attributes apply to data-bound controls.
7.4 Range controls: Range controls enable the user to select a value from a continuous range of values, defined using min/max values and an optional step value (precision). The range can be bound on both sides (both min and max are specified), bound on one side (either min or max are specified), or unbound (neither min nor max are specified). Examples include: spinner control (a Spinner is a numeric range control with up/down buttons for stepping through the values in the range.); HSlider and VSlider controls (an HSlider / VSlider is a numeric selection control that lets the user select a value by moving a slider thumb between the end points of a horizontal/vertical slider track.); HRange and VRange controls (an HRange / VRange is a numeric selection control that lets the user select a range of values by moving two slider thumbs between the end points of a horizontal/vertical slider.); DatePicker control (a DatePicker is a date selection control that allows the user to select a date using a dropdown calendar); Calendar control (a Calendar is a date selection control that allows the user to select a date or a range of dates using a navigable monthly calendar.).
7.6 Unbound controls: Unbound controls are controls that are not bound to any data field. Unbound controls are typically used for decorating the display or for invoking actions. Examples include: Button control (a Button is an unbound control that is used for invoking actions when it is clicked with the mouse or the keyboard.); PlainText control (a PlainText is an unbound control that is used for displaying a text message with uniform formatting.); HtmlText control (an HtmlText is an unbound control that is used for displaying an html-formatted fragment.); Image control (an Image is an unbound control that is used for displaying an embedded image. The Image control can only be used for images that are embedded inside the XGL component.); HSeparator and VSeparator controls (a HSeparator/VSeparator is an unbound control that is used for displaying a horizontal / vertical separator line.).
TreeView interactor (A TreeView interactor is used for browsing a tree infoset using an expandable tree display. TreeView displays each infoset object in a separate tree node, and enables the user to expand nodes and display their child nodes. The tree node corresponding to the current infoset object is highlighted by changing its background or border color.)
Part III: EXECUTION CONTROL 11. Actions
where: name = The name of the declared action; scope = The scope over which the action applies to. The scope attribute can reference either an interactor or a container. If omitted, the scope is taken to be the entire component; disable expr<bool> = Indicates whether the action is disabled. When an action is disabled, all controls that are associated with it are disabled as well. The default value is false.
Signalln relay (A SignalIn relay represents an incoming signal received from the embedding component.);
where: id = The id attribute uniquely identifies the plan within the XGL component; action = (optional) The plan's action trigger; data = (Optional) The plan's data expression trigger; scope = (Optional) Limits the scope of the plan to a specific container or interactor. If scope is provided, the plan will be triggered only if the trigger originated from the specified element. Otherwise, the plan will be triggered regardless of the trigger origin; priority = (Optional) The plan's priority level, given as a numeric value. Smaller values get higher priority. The default is 1; reaction = (Optional) An action to be triggered in reaction to successful execution of this-plan.
Plan execution order: The body of the Plan declaration defines the sequence of steps that need to be executed and their ordering. The plan steps are executed after the built-in system response (if any) is carried out. The plan steps are numbered sequentially using the index attribute, and are executed in according order. A plan step may depend on preceding steps in the plan, as listed in the precedents attribute. During a run-to-completion all the plan steps are visited in turn, even if some steps fail along the way. Before a step is executed, its precedents list is examined. A step will be executed only if all its precedent steps have been executed successfully. Otherwise, the step will be skipped and marked as unsuccessful. Each step is completely executed before proceeding to the next-step. The step execution can be synchronous or asynchronous, depending on the-step type. When the step execution completes, the step is marked with the success / failure status, and execution continues to the following steps.
Plan execution strategy: The Plan declaration defines the plan's steps, the order in which they must be executed, and the pre-conditions for their execution. However, the plan does not dictate when the plan steps should be executed. The execution timing strategy is left to the XGL implementation. The straightforward execution strategy is to simply execute the plan steps immediately, in a single run-to-completion. This is a perfectly valid strategy, and will always result in the correct execution semantics. However, this strategy might not be the most optimal way to execute the plan, since all steps are always executed - even if their execution could have been delayed to a later stage (or even never reached). If the XGL component is well-defined according to the expression determinism rules, it follows that an execution plan can be incrementally executed at different points in time, as long the ordering of the plan steps is maintained and provided that a plan step is never executed before all its preceding steps have been executed. That is, a plan can be run to completion in several runs, instead of in a single run. The first step in an execution plan always invalidates all the infosets that may be affected by any of the plan steps that follow. An optimized execution strategy can take advantage of this fact and execute the plan in a run-on-demand basis. In a run-on-demand strategy, the first run invalidates all infosets that are affected by the plan. Then, the run proceeds with the execution of the following steps in the plan, but only as long as they affect display elements that are currently visible. Plan steps that do not affect any visible display elements do not need to be executed immediately. Their execution, and the execution of the steps that precede them can be delayed to a later run, which will be initiated when their respective display elements become visible. The on-demand execution strategy can result in significant performance optimization, especially when the steps that are delayed involve expensive operations such as data service invocation or bulk data copy. However, the implementation of an on-demand strategy is also more involved, because it is harder to ensure that the execution semantics of the plan are preserved when it is split over several runs.
13.2 Execution Steps: Examples of execution plan steps available in XGL include invalidation-step-decl, copying-step-decl, mapping-step-decl, evaluation-step-decl, transition-step-decl, and others.
Invalidation step (An Invalidate step-clears and invalidates a given list of infosets.);
User interface input devices 812 may include a keyboard, pointing devices such as a mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touchscreen incorporated into the display, audio input devices such as voice recognition systems, microphones, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information to computer system 800. A user may use an input device to interact with design modeling tools to create a model representation for a GUI application.
User interface output devices 814 may include a display subsystem, a printer, a fax machine, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat-panel device such as a liquid crystal display (LCD), or a projection device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 800. An output device may be used to output a GUI to the user.
Although specific embodiments of the invention have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the invention. The described invention is not restricted to operation within certain specific data processing environments, but is free to operate within a plurality of data processing environments. For example, description has been provided with regards to various runtime environments such as Java runtime platform, HTML runtime platform, Flash runtime platform, etc. These examples are not intended to limit the scope of the present invention. The teachings of the present invention may also be applied to other runtime environment platforms. As another example, a specific XGL specification is described above and in Appendix G of U.S. Provisional Patent Application No. 60/722,888 (Attorney Docket No. 017900-005900US) filed September 30, 2005. Other XGL specifications may also be provided in accordance with the present invention. Additionally, although the present invention has been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present invention is not limited to the described series of transactions and steps.
A method performed by a computer system of generating an abstract representation (110) for a model representation (106), the method comprising:
receiving (302) information identifying a model representation (106) for an application, the model representation (106) comprising information describing a graphical user interface (GUI) (118, 124, 128) for the application;
generating (304) an abstract representation (110) for the GUI (118, 124, 128) based upon the model representation (106), the abstract representation (110) being an executable GUI language (XGL) representation in a form of an XML file, wherein the XGL is a generic, declarative, and executable GUI language, wherein the XGL is used for generating representations of different GUIs and supports connectivity to different application data services, wherein the abstract representation (106) is independent of a runtime environment platform (202) for executing the application; wherein generating the abstract representation (110) comprises using a first set of mapping rules for generating the abstract representation (110) from the model representation (106);
generating a first GUI (118, 124, 128) for a first runtime environment platform (202) using the abstract representation, wherein generating the first GUI (118, 124, 128) comprises using a second set of mapping rules for generating the first GUI (118, 124, 128) from the abstract representation (110); and
generating a second GUI (118, 124, 128) for a second runtime environment platform (202) using the abstract representation (110), wherein the second runtime environment platform (202) is different from the first runtime environment platform (202), wherein generating the second GUI (118, 124, 128) comprises using a third set of mapping rules for generating the second GUI (118, 124, 128) from the abstract representation (110);
wherein the application is packaged as a collection of XGL documents with inter-dependencies and deployed to any system supporting XGL implementation;
wherein the XGL defines data models including a data model called infoactors representing the different application data services, wherein the infoactors are declared using a system alias rather than an actual system connection, wherein the infoactors are defined in an extension kit and declared using a respective kit namespace;
wherein the XGL defines resources including a resource called systems representing a connection to a backend system that provides an access to the different application data services, wherein a system declaration associates a system connection with the system alias, and wherein the system alias used in the infoactor declarations is replaced with the actual system connection during deployment.
The method of claim 1 wherein generating the first GUI (118, 124, 128) comprises:
generating first source code based upon the abstract representation (110), wherein the first source code is in a language supported by the first runtime environment platform (202); and
executing the first source code using the first runtime environment platform (202) to generate the first GUI (118, 124, 128).
generating machine executable statements specific to the first runtime environment platform (202) based upon the abstract representation (110); and
executing the machine executable statements using the first runtime environment platform (202) to generate the first GUI (118, 124, 128).
The method of any one of claims 1 to 3 wherein the first runtime environment platform (202) is at least one of a Java platform, a Flash platform, Extensible Application Markup Language (XAML) platform, or a dynamic HTML (DHTML) platform.
The method of any one of claims 1 to 4 wherein the abstract representation (110) is not dependent on a GUI-framework of the runtime environment platform (202) .
The method of any one of claims 1 to 5 wherein the abstract representation (110) is not dependent on a language of the runtime environment platform (202).
A system for generating an abstract representation (110) for a model representation (106), the system comprising:
a memory storing a model representation (106) for an application, the model representation (106) comprising information describing a graphical user interface (GUI) (118, 124, 128) for the application; and
a processor coupled to the memory, wherein the processor is configured to execute the method according to claim 1.
The system of claim 7 wherein the processor is configured to generate the first GUI (118, 124, 128) by:
generating first source code based upon the abstract representation (110),
wherein the first source code is in a language supported by the first runtime environment platform (202); and
The system of claim 7 wherein the processor is configured to generate the first GUI by:
The system of any one of claims 7 to 9 wherein the first runtime environment platform (202) is at least one of a Java platform, a Flash platform, Extensible Application Markup Language (XAML), or a dynamic HTML (DHTML) platform.
The system of any one of claims 7 to 10 wherein the abstract representation (110) is not dependent on a GUI-framework of the runtime environment platform (202).
The system of any one of claims 7 to 11 wherein the abstract representation (110) is not dependent on a language of the runtime environment-platform (202).
A computer-readable medium storing a plurality of instructions for controlling a data processor to generating an abstract representation (110) for a model representation (106), the plurality of instructions comprising instructions that cause the data processor to execute the method according to claim 1.
EP06020331.2A 2005-09-30 2006-09-27 Executable and declarative specification for graphical user interfaces Active EP1770510B1 (en)
US72288805P true 2005-09-30 2005-09-30
US11/324,155 US8407610B2 (en) 2005-09-30 2005-12-29 Executable and declarative specification for graphical user interfaces
EP1770510A2 EP1770510A2 (en) 2007-04-04
EP1770510A3 EP1770510A3 (en) 2009-01-28
EP1770510B1 true EP1770510B1 (en) 2018-01-24
ID=37562274
EP06020331.2A Active EP1770510B1 (en) 2005-09-30 2006-09-27 Executable and declarative specification for graphical user interfaces
US (1) US8407610B2 (en)
EP (1) EP1770510B1 (en)
EP2530583B1 (en) 2011-05-31 2019-11-27 Accenture Global Services Limited Computer-implemented method, system and computer program product for displaying a user interface component
2005-12-29 US US11/324,155 patent/US8407610B2/en active Active
2006-09-27 EP EP06020331.2A patent/EP1770510B1/en active Active
US20070094609A1 (en) 2007-04-26
US8407610B2 (en) 2013-03-26
EP1770510A3 (en) 2009-01-28
EP1770510A2 (en) 2007-04-04
ES2473765T3 (en) 2014-07-07 Parallelization and instrumentation in a programming framework oriented to producer graphs
2009-09-30 AKX Designation fees paid
Ipc: G06F 9/44 20060101AFI20170713BHEP
Ipc: G06F 9/45 20060101ALI20170713BHEP
Ref document number: 966135
Ref document number: 602006054599
Ipc: G06F 9/44 20180101AFI20170713BHEP
Ipc: G06F 9/45 20181130ALI20170713BHEP