|PREV NEXT||FRAMES NO FRAMES|
|org.objectweb.fractal.gui||Provides a graphical tool to edit Fractal component configurations.|
|org.objectweb.fractal.gui.clipboard.control||Provides actions to modify the clipboard model, in reaction to clipboard view events.|
|org.objectweb.fractal.gui.clipboard.model||Provides a model for the clipboard.|
|org.objectweb.fractal.gui.dialog.control||Provides a controller to modify the dialog model, in reaction to dialog view events.|
|org.objectweb.fractal.gui.dialog.model||Provides a model for the dialog view, based on a configuration model.|
|org.objectweb.fractal.gui.dialog.view||Provides a configuration view based on editable fields and tables.|
|org.objectweb.fractal.gui.graph.control||Provides controllers to modify the graph model, in reaction to graph view events.|
|org.objectweb.fractal.gui.graph.model||Provides a model for the graph view, based on a configuration model.|
|org.objectweb.fractal.gui.graph.view||Provides a configuration view based on a graph representation.|
|org.objectweb.fractal.gui.history.control||Provides actions to modify the history model, in reaction to history view events.|
|org.objectweb.fractal.gui.history.model||Provides a model for the navigation history, based on a configuration model.|
|org.objectweb.fractal.gui.menu.control||Provides actions to modify the configuration model, in reaction to view events.|
|org.objectweb.fractal.gui.model||Provides a model for component configurations.|
|org.objectweb.fractal.gui.repository.api||Provides an API for configuration repositories.|
|org.objectweb.fractal.gui.repository.lib||Provides a basic configuration repository implementation.|
|org.objectweb.fractal.gui.selection.model||Provides a model for the selection.|
|org.objectweb.fractal.gui.status.view||Provides a configuration view that displays the status of components and interfaces.|
|org.objectweb.fractal.gui.toolbar.view||Provides a configuration view based on a toolbar.|
|org.objectweb.fractal.gui.tree.model||Provides a model for the tree view, based on a configuration model.|
|org.objectweb.fractal.gui.tree.view||Provides a configuration view based on a tree.|
|org.objectweb.fractal.gui.undo.control||Provides actions to modify the undo model, in reaction to undo view events.|
|org.objectweb.fractal.gui.undo.model||Provides a model for undo and redo, based on a configuration model.|
FractalGUI is a graphical editor for Fractal component configurations.
Figure 1: the Model View Controller pattern.
The basic MVC pattern used in FractalGUI involves three Fractal components:
A model component M1 can be synchronized with another model component M2 by using the Observer pattern (see Figure 2):
When M1 is modified, for example by a controller component for M1, M2 is notified through its M1Listener interface. It can then update its own state, which will notify its listeners, such as a view on the M2 model, but also the M1 component. At this stage the M1 component must ignore this notification, otherwise an infinite notification loop will occur between M1 and M2. Symetrically, when M2 is modified, for example by a controller component for M2, M1 is notified through its M2Listener interface. It can then update its own state, which will notify its listeners, such as a view on the M1 model, but also the M2 component. At this stage the M2 component must ignore this notification, otherwise an infinite notification loop will occur between M1 and M2.
This synchronization pattern is used in many places in FractalGUI, sometimes with a bidirectional synchronization, sometimes with a unidirectional synchronization (i.e. M1 updates itself when M2 changes, but M2 does not modify itself when M1 changes). For example:
This synchronization pattern can also be used for view components. For example the status view component listens to the graph view component, in order to update itself each time the mouse moves inside the graph view.
The benefit of using these architectural patterns is modularity: for example a model, a view or a controller component can be replaced with another one, whole features (such as the undo or history managers) can be removed without any impact on others, and so on. The FractalGUI browser illustrates this modularity: by reusing some components of the FractalGUI editor, and by configuring and assembling them in a different way than in the FractalGUI editor, one can obtain the FractalGUI browser, which, as its name implies, only allows configuration browsing, but not configuration editing.
Each component is represented by a Component object, each client interface by a ClientInterface object, each server interface by a ServerInterface object, and each binding by a Binding object. The configuration itself is represented by a Configuration object that references the root component of the configuration. Each component stores the list of its sub components, the list of external server interfaces, and the list of its external client interfaces (in addition to various attributes such as the component's name or type). Each interface has a reference to its complementary interface (both external and internal interfaces are always represented in the FractalGUI model, even for primitive components). Each client interface has a reference to a binding object (if this interface is bound), which itself has a reference to a server interface.
The model also contains all the inverse references: each component has a reference to its "owner" configuration, and a reference to its parent component; each interface has a reference to its owner component, each binding has a reference to the client interface that references it, and each server interface has the references of all the binding objects that reference it. This redundancy is useful to easily navigate from one element of the model to any other. It is also useful to undo some changes in the model. For example, if the client component is "deleted" (which also "deletes" the bindings to and from this component), only three references are really removed from the model (namely the reference to the binding object on the left, the inverse reference from the server interface of the server component to the other binding object, and the reference from the root component to the client component - see Figure 5). This deletion can then easily be undone (including the deletion of the two binginds), by reconstructing the removed references from the redundant ones (that were left unchanged during the deletion).
Although references between the elements of the model are redundant, the state of these elements is not redundant. For example the name of an interface, which is equal to the name of its complementary interface, is stored only in one of these two interfaces, namely in the external one. In other words the getName (resp. setName) method of an internal interface just calls the same method on the complementary interface, which itself returns (resp. modifies) the name stored in this external interface. The consistency of the two names is therefore always automatically ensured: there is no need to manually update both names when the name of one of the interface is changed.
This non redundancy principle is also applied to ensure the consistency of collection interfaces (see Figure 6). A collection of interfaces is represented by a master collection interface and several slave collection interfaces (and by the complementary interfaces of the master and slave interfaces). The external master collection interface contains the list of its external slave interfaces, and each external slave interface contains a reference ot its external master collection interface (this is an application of the reference redundancy principle; note however that the internal master and slave collection interfaces do not contain master and slave references to each other). The prefix of the names of the slave collection interfaces, which is equal to the name of the master collection interface, is stored only in the external master collection interface.
This master-slave pattern is also applied to ensure the consistency of shared components (see Figure 7). Indeed a shared component, i.e. a component that belongs to several parent components, in represented in FractalGUI's model by several Component objects, one per parent component of the shared component (therefore, in FractalGUI, by construction, any Component object has only one parent). In order to ensure the consistency of all these instances, the shared component's state is stored in only one of them, called the master component. All other instances are slave components of the master component. As for collection interfaces, the master component stores the list of its slave components, and each slave component has a reference to its master component. Each slave component has its own Interface objects, but only for external interfaces. Each of these interfaces references the corresponding interface of the master component, which is called its master interface (warning: this is not the same as the master collection interface). Indeed the state of these interfaces in not stored in these interfaces, but in the master interface (except the owner reference; in fact this owner reference is the reason why slave components must have their own interface objects).
The BasicXXX classes, in the model package, implement the interfaces of FractalGUI's model for normal components and interfaces, including collection interfaces. External, internal, master and slave collection interfaces are all implemented by the same BasicClientInterface and BasicServerInterface classes, which provide one constructor per interface type (i.e. external, internal or slave collection). The SharedXXX classes, as their name imply, implement the interfaces of FractalGUI's model for shared components, and for their interfaces.
|PREV NEXT||FRAMES NO FRAMES|