The controller architecture has a number of questions to answer about how things happen and how it determines what happens. First, the question becomes how is a particular action invoked - that is, the client presses a button, and then what happens? (Alternatively, the browser has a timer event go off etc.) How does the client tell the server what the parameters are relating to this action?
Then, how does the client view get refreshed - what parts of the screen need to be updated, and how does that get determined.
Since the client is a web client, I'm going to assume that there is a post request being performed that includes the parameters of action - it may include more parameters than necessary, but it at least includes the ones relevant to the current action. Additional parameters provided need to be preserved on the next rendering of the same page, assuming that page is being re-rendered.
There are a number of levels of the client sending an action in terms of what happens, some of these are:
- Client selects some action such as search that affects just some region of the screen.
- Client selects some action such as configuration that shows a completely different screen.
- Client selects some action such as display this patient that renders a certain set of frames and everything below them, nothing above them.
- Client selects some action that affects portions of multiple frames, or sections of frames. In the case of having no frames, ONE of these actions had better be the "primary" new frame/page to display - this can be the current page or a new one (the current page would be updated appropriately.)
For the parameters for an action, they will typically need to include only the changes made - that may involve form inputs for something a search page, selection of studies or other objects, or just the button and some identification as to what conversation is being affected.
Responsibilities of Controller
The primary responsibilities of a controller component are:
- Specify when a mode is disabled/passive/active
- Specify which events are of interest for a mode when the mode is passive/active
- Specify which actions are executed for different events
- Specify any view replacements/updates after an action completes
- May specify different actions/view replacements based on preferences and display capabilities (eg JavaScript action versus Seam action)
- Specify the updated/history URL
Unorganized thoughts on Controller
What about using XLink external files to define what gets called? Then, these can be used to drive Javascript OR server side clicks/buttons/modes? This would define what gets updated, what gets called to do the updating etc? Could they also define what JavaScript is changed, and perhaps what history information gets changed/modified?
For the Display area, it seems likely that we will have various modes that can be turned on/off, at least one for each type of operation.
Modes are responsible for driving various layer display.
Modes can handle dynamic, client side updates
Modes can also handle server side updates for some of the same type of information.
Modes can listen to mouse movement or button presses
Modes can affect the URL of the image being retrieved.
Modes can be turned on/off by button clicks or context menu.
Modes can be turned on/off by preferences, or by information in the DICOM.
Modes probably have at least 3 states: off, passive and active - where passive means they affect the default display, but don't consume any user based events. Off means that they contribute nothing to the display.
Some modes are compatible, while others are not - in general, two modes are compatible if they don't exclusively use the same event, OR drive the same response.
Are m x n display's handled with modes or with some higher level mechanism - that is, who determines how the screen is layed out? (answer could be different for study, series and image level breakdowns).
Thoughts on controller information:
- Activated by the mode being active, and the right listening being active
- May have custom client side Javascript (eg window level, zoom/pan, markup)
Examples of Modes:
- Window level - Series - event handler would be a window level series updater, view affected would be the entire series, and there would be two handlers for events - one for image map mapping, and another for javascript customized mapping.
- CINE - defines entire series view, adds custom buttons/control tray, has custom javascript mapping. Modifies the next image available.
- Zoom/pan - defines level of magnification - version for series and for image (perhaps for study or across study?)
- GSPS display - controls default window level, Zoom/pan modes, graphics overlay, shutter etc.
- Search Mode - handles timed updates of list (this is on display page)
It would be nice to have the following features around modes:
- Pluggable - a new mode can be added without needing to edit the primary source of Xero
- Mostly independent - two modes should not need to know about each other, unless they are likely to modify the same things at the same time, or consume the same event at the same time (eg mouse move when WL is active)
- Extendible based on earlier modes - eg hanging protocols can build on layout modes?
- Can be determined what initial setting is (off, passive of active) based on study/series/image information - use this to control initial setup and display.
- Have multiple rendering styles (eg Frames vs no-Frames, Javascript on/off, AJAX DIV style layout etc) Mostly this should be independent of the mode itself except where it needs customization.
- Require javascript that becomes "active" only when mode becomes active (otherwise, not included.)
- Be able to provide services or data down-stream, eg help information (this could happen via meta-data instead)
- Modes can define what data sources are available
- The currently active list of modes and the associated data can be stored/handled either server side or client side (eg, no round trip is required, a-priori for a mode change)