| Version: | 1.1 |
|---|---|
| Code Basis: | AG 2.1.2 |
| Author: | Thomas D. Uram |
| Status: | Draft |
This document describes a plan to refactor the venue client code to separate the application code from the user interface code. This will make the code easier to maintain, and allow components to replaced modularly. The appearance of the venue client is expected to remain unchanged.
This separation and refactoring work is motivated by two desires:
The design uses the Model-View-Controller pattern, defining the following components:
VenueClient module
Includes the application logic of the venue client (currently AccessGrid/VenueClient.py)
VenueClientUI module
Includes the user interface code (currently portions of AccessGrid/VenueClientUIClasses.py and bin/VenueClient.py)
VenueClientController module
Includes the functional code to handle user interface actions (currently portions of AccessGrid/VenueClientUIClasses.py and bin/VenueClient.py)
VenueClientObserver module
Defines the interface that the venue client will call to update observers, which includes the VenueClientUI
VenueClient executable
Executable which associates the component parts of the venue client
The VenueClient class includes the following components:
VenueClientIW
Used for calls to the venue
SOAP Server
Used for lead/follow and personal data
Text Client
Used to connect to the TextService for sending and receiving messages
Data Store
Used to store personal data
Data Store Client
Used for file transfers with the venue data store
EventClient
Defines the SOAP interface to the VenueClient class. The SOAP interface specifications are in AGEP-0116 [3].
This module defines the venue client UI and its constituent parts.
Defines callbacks to capture wx nature of callbacks and events
For example, the typical wx callback takes an "event" argument. Callbacks will extract the necessary data from the event, and call the controller method to do the real work.
Implements the VenueClientObserver interface
Enables the VenueClientUI as an observer of the VeneuClient. Given that these calls may be made from a thread other than the main (wx) thread, wxCallAfter is used within these methods to pass the call off to the main thread. This hides the interthread intricacy within the VenueClientUI.
Implements additional methods for the controller to manipulate the UI and access its data
An implementation of the controller interface that manipulates the model and updates the view accordingly.
Defines the interface implemented by observers of the venue client.
An implementation of the Observer interface intended for testing.
This module reduces to code necessary to bring the parts together as an executable:
The classes are associated according to the MVC pattern. The Observer pattern [1] is used to define the relationship between the VenueClient and (its observer) the VenueClientUI. Multiple observers can be registered with the VenueClient. Observers must implement the VenueClientObserver interface [2].
Calls made across each of the associations are categorized here (and pictorially here). These associations are explicit references:
VenueClientUI -> VenueClient
Calls to query venue client state
VenueClientUI -> VenueClientController
Calls originating from user interface callbacks
VenueClientController -> VenueClientUI
Update the view
VenueClientController -> VenueClient
Manipulate the model
This association is through the Observer pattern:
VenueClient -> VenueClientUI
Propagate changes in the VenueClient (possibly from incoming events) to the VenueClientUI
The following functionality currently resides in user interface code, but will be moved to the VenueClient module:
None; this set of modifications should in no way affect the security of the system.
The refactoring in this proposal should not affect the interoperability of the client with servers and services. This is an internal refactoring.
This document is Copyright 2003, The University of Chicago/Argonne National Laboratory.
