Slicer3:StatelessGUI - Revision history

Grundlett: Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

2017-07-10T18:07:19Z

Text replacement - "http://www.slicer.org/slicerWiki/index.php/" to "https://www.slicer.org/wiki/"

Marianna: Unprotected "Slicer3:StatelessGUI"

2008-05-20T17:37:02Z

Marianna: Replacing page with ''''Note:''' We are migrating this content to the slicer.org domain - The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:StatelessGU...'

2008-05-20T17:36:44Z

Replacing page with '<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:StatelessGU...'

Wjp: /* Independent stateless GUI layer */

2007-01-11T16:31:13Z

Independent stateless GUI layer

Wjp: /* Independent stateless GUI layer */

2007-01-10T05:25:20Z

Independent stateless GUI layer

Wjp: /* Independent stateless GUI layer */

2007-01-10T05:17:52Z

Independent stateless GUI layer

Wjp at 05:15, 10 January 2007

2007-01-10T05:15:57Z

New page

== Independent stateless GUI layer ==

Its important to restrict application state to the MRML and Logic classes and to keep the GUI completely independent of these two application layers. MRML and Logic should know nothing about the GUI. Keeping the GUI in sync with MRML and Logic is accomplished with observers and mediator functions.

Since this approach is substantially different than that used in Slicer2, some sketches are shown below to illustrate how events are invoked and processed, and how the GUI tracks MRML and Logic, but remains stateless itself.

The first sketch is the simplest example, in which a GUI’s observed interface element invokes an event when a user enters a new value. The sketch shows how that event is observed, processed, and MRML is updated. This triggers a MRML event, which is observed by the GUI and processed to bring the GUI’s interface elements into sync with MRML state. In each case, before an element in the GUI or MRML is modified, a check is performed to determine whether the new value and old value are different, in order to avoid infinite looping.

--simple figure--

The second sketch is a more complicated example, showing an accompanying Logic class. This class may encapsulate pipelines and mediate access to data stored in a MRML node; it can also contain helper classes for the GUI to use. In this example, the GUI is observing MRML and Logic, as well as its own interface elements. The sketch shows a button being clicked in the GUI which causes a new “Thing” to be created. In response, the Logic class creates several new MRML nodes, adds them to the MRML scene and sets the Thing to be active in the MRMLSelectionNode. MRML invokes several events (NodeAddedEvents and a ModifiedEvent). Both the Logic and the GUI may respond to these events. The Logic may itself become modified, and the GUI may also respond to events invoked by it.

--complicated figure—

← Older revision		Revision as of 18:07, 10 July 2017
Line 1:		Line 1:
−	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [~~http~~://www.slicer.org/~~slicerWiki/index.php~~/Slicer3:StatelessGUI here]</font></big>	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [https://www.slicer.org/wiki/Slicer3:StatelessGUI here]</font></big>

← Older revision		Revision as of 17:36, 20 May 2008
Line 1:		Line 1:
−	~~== Independent stateless GUI layer ==~~	+	<big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:StatelessGUI here]</font></big>
−
−	Its important to restrict application state to the MRML and Logic classes and to keep the GUI completely independent of these two application layers. This stateless GUI layer offers many benefits. For one, any MRML scene may be deleted or loaded and the GUI will automatically track that scene; for another, Slicer'~~s full functionality is available even when Slicer operates without the GUI layer, or with another GUI entirely.~~
−
−	To keep your module GUI stateless, all parameters your module GUI needs to know about should be stored in MRML; and MRML and Logic should know nothing about the GUI. Keeping the GUI in sync with MRML and Logic is accomplished using observers on GUI, MRML and Logic events and using mediator functions to process those events.
−
−	~~Since~~ this ~~approach is substantially different than that used in Slicer2, some sketches are shown below~~ to ~~illustrate how events are invoked and processed, and how~~ the ~~GUI tracks MRML and Logic, but remains stateless itself.~~
−
−	~~The first sketch is the simplest example, in which a GUI’s observed interface element invokes an event when a user enters a new value~~. The sketch shows how that event is observed, processed, and MRML is updated. This triggers a MRML event, which is observed by the GUI and processed to bring the GUI’s interface elements into sync with MRML state. In each case, before an element in the GUI or MRML is modified, a check is ~~performed to determine whether the new value and old value are different, in order to avoid infinite looping.~~
−
−	[~~[Image~~:~~StatelessGUISimple.png \| Simple example of event handling ]]~~
−
−	The second sketch is a more complicated example, showing an accompanying Logic class. This class may encapsulate pipelines and mediate access to data stored in a MRML node; it can also contain helper classes for the GUI to use. In this example, the GUI is observing MRML and Logic, as well as its own interface elements. The sketch shows a button being clicked in the GUI which causes a new “Thing” to be created. In response, the Logic class creates several new MRML nodes, adds them to the MRML scene and sets the Thing to be active in the MRMLSelectionNode. ~~MRML invokes several events (NodeAddedEvents and a ModifiedEvent)~~. ~~Both the Logic and the GUI may respond to these events~~. ~~The Logic may itself become modified, and the GUI may also respond to events invoked by it.~~
−
−	~~[[Image~~:StatelessGUI~~.png \| More complicated example, including Logic class ]~~]

@@ Line 1: / Line 1: @@
 == Independent stateless GUI layer ==
-Its important to restrict application state to the MRML and Logic classes and to keep the GUI completely independent of these two application layers. MRML and Logic should know nothing about the GUI. Keeping the GUI in sync with MRML and Logic is accomplished using observers on GUI, MRML and Logic events and using mediator functions to process those events.
+Its important to restrict application state to the MRML and Logic classes and to keep the GUI completely independent of these two application layers. This stateless GUI layer offers many benefits. For one, any MRML scene may be deleted or loaded and the GUI will automatically track that scene; for another, Slicer's full functionality is available even when Slicer operates without the GUI layer, or with another GUI entirely.
 Since this approach is substantially different than that used in Slicer2, some sketches are shown below to illustrate how events are invoked and processed, and how the GUI tracks MRML and Logic, but remains stateless itself.

← Older revision	Revision as of 17:37, 20 May 2008
(No difference)

@@ Line 7: / Line 7: @@
 The first sketch is the simplest example, in which a GUI’s observed interface element invokes an event when a user enters a new value. The sketch shows how that event is observed, processed, and MRML is updated. This triggers a MRML event, which is observed by the GUI and processed to bring the GUI’s interface elements into sync with MRML state. In each case, before an element in the GUI or MRML is modified, a check is performed to determine whether the new value and old value are different, in order to avoid infinite looping.
---simple figure--
+[[Image:StatelessGUISimple.png | Simple example of event handling ]]
 The second sketch is a more complicated example, showing an accompanying Logic class. This class may encapsulate pipelines and mediate access to data stored in a MRML node; it can also contain helper classes for the GUI to use. In this example, the GUI is observing MRML and Logic, as well as its own interface elements. The sketch shows a button being clicked in the GUI which causes a new “Thing” to be created. In response, the Logic class creates several new MRML nodes, adds them to the MRML scene and sets the Thing to be active in the MRMLSelectionNode. MRML invokes several events (NodeAddedEvents and a ModifiedEvent). Both the Logic and the GUI may respond to these events. The Logic may itself become modified, and the GUI may also respond to events invoked by it.
---complicated figure—
+[[Image:StatelessGUI.png | More complicated example, including Logic class ]]