Screen Updates: Difference between revisions
From ParaQ Wiki
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== | == Overview == | ||
The time required to update the visualization network and redraw the display(s) may vary widely - thus we should not assume that all UI changes will cause an immediate screen update. Conversely, we should not assume that all updates will be slow - for simple networks & data, it should be possible to allow for immediate updates without user intervention. | |||
== Requirements == | |||
* Allow the user to make as many changes as they want before requesting an update, regardless of how many user interface components they interact with. | |||
* Allow the user to "reset" the UI, abandoning all of the changes they've made since the last update. A reset must restore the state(s) of UI components to match the server state. | |||
* Support a wide variety of update policies - immediate update, update only when the user explicitly requests it, etc. | * Support a wide variety of update policies - immediate update, update only when the user explicitly requests it, etc. | ||
* The mechanism for handling updates should be usable by third-parties and application developers with a minimum of overhead. | |||
== | == Reference Implementation == | ||
Early versions of the ParaQ demo included a set of classes that accomplished some of the requirements, using Command Design Pattern: | |||
* pqImmediateCommandDispatcher - immediately executes each command it receives | * pqCommandDispatcherManager - singleton class that maintained a "current" command-dispatcher. | ||
* pqTimeoutCommandDispatcher - caches incoming commands until a timeout expires, then executes the cached commands and updates the display. | * pqCommandDispatcher - abstract interface responsible for "executing" commands. | ||
* pqExplicitCommandDispatcher - caches incoming commands until the user explicitly decides to execute them. | * pqImmediateCommandDispatcher - pqCommandDispatcher implementation that immediately executes each command it receives and updates the display. | ||
* pqTimeoutCommandDispatcher - pqCommandDispatcher implementation that caches incoming commands until a timeout expires, then executes the cached commands and updates the display. | |||
* pqExplicitCommandDispatcher - pqCommandDispatcher implementation that caches incoming commands until the user explicitly decides to execute them. | |||
* pqCommand - abstract interface for a "command" that can be executed at a later time. | |||
UI components such as pqSMAdaptor do not update the visualization network directly - instead, they created derivatives of pqComand which encapsulated the state changes to be made. These instances were handed-off to the pqCommandDispatcher implementation maintained by pqCommandDispatcherManager. The pqCommandDispatcher implementation controls when to "execute" each command, and deletes the command once executed. | |||
Latest revision as of 11:45, 23 March 2006
Overview
The time required to update the visualization network and redraw the display(s) may vary widely - thus we should not assume that all UI changes will cause an immediate screen update. Conversely, we should not assume that all updates will be slow - for simple networks & data, it should be possible to allow for immediate updates without user intervention.
Requirements
- Allow the user to make as many changes as they want before requesting an update, regardless of how many user interface components they interact with.
- Allow the user to "reset" the UI, abandoning all of the changes they've made since the last update. A reset must restore the state(s) of UI components to match the server state.
- Support a wide variety of update policies - immediate update, update only when the user explicitly requests it, etc.
- The mechanism for handling updates should be usable by third-parties and application developers with a minimum of overhead.
Reference Implementation
Early versions of the ParaQ demo included a set of classes that accomplished some of the requirements, using Command Design Pattern:
- pqCommandDispatcherManager - singleton class that maintained a "current" command-dispatcher.
- pqCommandDispatcher - abstract interface responsible for "executing" commands.
- pqImmediateCommandDispatcher - pqCommandDispatcher implementation that immediately executes each command it receives and updates the display.
- pqTimeoutCommandDispatcher - pqCommandDispatcher implementation that caches incoming commands until a timeout expires, then executes the cached commands and updates the display.
- pqExplicitCommandDispatcher - pqCommandDispatcher implementation that caches incoming commands until the user explicitly decides to execute them.
- pqCommand - abstract interface for a "command" that can be executed at a later time.
UI components such as pqSMAdaptor do not update the visualization network directly - instead, they created derivatives of pqComand which encapsulated the state changes to be made. These instances were handed-off to the pqCommandDispatcher implementation maintained by pqCommandDispatcherManager. The pqCommandDispatcher implementation controls when to "execute" each command, and deletes the command once executed.
