Content deleted Content added
No edit summary |
|||
Line 14:
== MVC Concept ==
<u>Model:</u> The model has to be implemented by the user or it exists already in case of a legacy software.
<u>Controller:</u> The EditPart acts as a controller. Usually a GraphicalEditPart is chosen. For each model element, including connections, a specific EditPart has to be implemented. Listeners for the model have to be registered in the function EditPart.activate() and have to be unregistered within EditPart.deactivate(). If a model change is detected the view has to be updated accordingly. The EditPart knows both the model and the view. The view has to be created within .createFigure().
<u>View:</u> For each element within the model, including connections, a View has to be implemented, using [[draw2d]]. In order to implement the view, an implementation of IFigure of the [[draw2d]] library has to be used.
=== Mapping of GEF aspects to MVC ===
* GEF Model maps to Model of MVC, definition of model is left to user. This is the semantic model.
* GEF EditParts map to Contorller of MVC, other controllers normally are: Graphical Editor in which model is shown, EditPoilicies and user defined listeners/controllers.
* GEF Figures (created using Draw2d or other renderes) map to View aspect of MVC.
GEF recommends one-on-one mapping of M-V-C, though it is quite possible to have more than one controller (editPart) for the same model. In such an event there is an additional responsibility of keeping controllers and model in sync.
=== EditPoilcies ===
The common behaviour across models is refactored into an editpolicy. There may be many behaviours for a given controller, so each "Editpoilicy" is assigned to a "Role". This helps us understand the behaviour contributed by the editpolicy. Editpolicies can be installed and removed dynamically.
=== Request, Response in GEF ===
<i>Authors' Note: For the following, knowledge of [[Design Patterns]] is definite aid to readers.</i>
Any user action can be seen as an example of request. The nature of request is understood by the context of invocation. For the discussion, One can safely say that the "context" is determined by the active "tool". Tool can be any entry in palette that is selected by user. In a sense we can say that User using tool generates "Requests". The request is handed over to and editpart which inturn returns an "Command".
This is achieved using [[Chain-of-responsibility pattern|Chain of responsibility]] over Editpolicies, the editpolicies determine if they can handle the request or not and pass on to the next. The order of declaration of editpolicies determine the order in which the request is handed over. The capable editpolicy creates a command. This command is handed back to the tool which initiated the "Request". Execution of the command causes the model to be modified (Response).
One another mechanism to achieve the same is to create Requests programatically and hand them over to Editparts. The Command generated can be subsequently executed on the "CommandStack".
== GEF Design patterns ==
| |||