Ci-dessous, les différences entre deux révisions de la page.
tm:appendixc [d-m-Y H:i] boris créée |
tm:appendixc [d-m-Y H:i] boris |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | [[tm: | ||
+ | |||
====== Appendix C Technical Supplements ====== | ====== Appendix C Technical Supplements ====== | ||
===== C.1 Prototype 2 Server Domain Classes ===== | ===== C.1 Prototype 2 Server Domain Classes ===== | ||
- | | + | |
A business model is composed by all its layers, elements and annotations. A business model can also have many children to create the branch graph of the snapshot manager. | A business model is composed by all its layers, elements and annotations. A business model can also have many children to create the branch graph of the snapshot manager. | ||
Ligne 13: | Ligne 15: | ||
There are also java enum classes to define the value range of some of the attributes. | There are also java enum classes to define the value range of some of the attributes. | ||
- | > {{main054.gif}} | + | Figure C.1: Prototype 2 server domain classes and attributes |
+ | |||
+ | {{tm: | ||
===== C.2 Prototype 2 Client Classes ===== | ===== C.2 Prototype 2 Client Classes ===== | ||
- | Figure | + | Figure |
The model part is composed of business services which are the connection points to the backend server. The Value Object are a local representation of the server domain classes, they need to be defined to allow proper mapping between Java and ActionScript. The model class itself is a singleton regrouping all the state information and data for binding to views. | The model part is composed of business services which are the connection points to the backend server. The Value Object are a local representation of the server domain classes, they need to be defined to allow proper mapping between Java and ActionScript. The model class itself is a singleton regrouping all the state information and data for binding to views. | ||
Ligne 23: | Ligne 27: | ||
The views are for the most part all defined in mxml and organized in subfolders only for clarity. The appcontroller class connects the events to commands. One event can have multiple types, but each type of an event is mapped to a unique command. | The views are for the most part all defined in mxml and organized in subfolders only for clarity. The appcontroller class connects the events to commands. One event can have multiple types, but each type of an event is mapped to a unique command. | ||
- | > {{main055.gif}} | + | Figure C.2: File structure of the 2nd prototype’s client |
+ | |||
+ | {{tm: | ||
===== C.3 Detailed Example Roundtrip of a Query ===== | ===== C.3 Detailed Example Roundtrip of a Query ===== | ||
- | The client being a user interface and object oriented program, most of the actions are initiated by events. Figure | + | The client being a user interface and object oriented program, most of the actions are initiated by events. Figure |
- | > {{main056.gif}} | + | Figure C.3: Event sequence of a link creation after drag and drop |
+ | |||
+ | {{tm: | ||
Dragging an element will start an event that registers the drag operations. Whenever the dragged element enters in contact with another element, a new event is started which will check if the two elements can be dragged onto each other (1.1). If this is the case, the icon of the dragged element will change, the underlying element will get highlighted and the correct operations are set in the drag manager. This allows, when the element is dropped (1.2), to execute the link creation event between the two elements(1.2.1-3). This action will call the appropriate method on the server via the service endpoint (4-6). The server looks up the correct elements from the database, validates if linking this two types of element is allowed and then creates the associations that represents the link between the two elements. After receiving confirmation of success from the server (6-7), the client starts another event that will do a refresh of the model (8-10). The refresh event, will contact the server to get the last version of the complete graph of object and then parse it (11-14). While parsing the data, objects are put in their respective lists which are watched by the graphical objects which display the model (15). Also additional listeners are added to be able to interact easily with the data from the different user generated events (15.1). Finally flex’s automatic data binding will triggers its own refresh events on the subscribed view elements (16). | Dragging an element will start an event that registers the drag operations. Whenever the dragged element enters in contact with another element, a new event is started which will check if the two elements can be dragged onto each other (1.1). If this is the case, the icon of the dragged element will change, the underlying element will get highlighted and the correct operations are set in the drag manager. This allows, when the element is dropped (1.2), to execute the link creation event between the two elements(1.2.1-3). This action will call the appropriate method on the server via the service endpoint (4-6). The server looks up the correct elements from the database, validates if linking this two types of element is allowed and then creates the associations that represents the link between the two elements. After receiving confirmation of success from the server (6-7), the client starts another event that will do a refresh of the model (8-10). The refresh event, will contact the server to get the last version of the complete graph of object and then parse it (11-14). While parsing the data, objects are put in their respective lists which are watched by the graphical objects which display the model (15). Also additional listeners are added to be able to interact easily with the data from the different user generated events (15.1). Finally flex’s automatic data binding will triggers its own refresh events on the subscribed view elements (16). | ||
Ligne 64: | Ligne 72: | ||
* [[http:// | * [[http:// | ||
* [[http:// | * [[http:// | ||
+ | |||
+ | [[tm: | ||