Child pages
  • Client based on the MVC design pattern
Skip to end of metadata
Go to start of metadata

GWT Client based on the MVC design pattern

We are big fan of the MVC (Model View Controller) design pattern. Problems invariably occur as user-interface becomes more complex.
That complexity forces us to design an architecture that decouples the Model (the data), the View (the presentation) and the Controller (the processsing logic).
So we used MVC design pattern as the main design pattern for the OpenSyllabus GWT client.

Separated Presentation

In a nutshell, we have tried to separate the View (the presentation of data) from the data itself (the Model) and from the business logic (the Controller) that manipulates both.

To be honest, we only succeeded to separate clearly the Model from the VC (View-Controler) couple. Our MVC approach is more a Separated Presentation approach where the Presentation layer (V&C) is separated from the Model. We have successfully discoupled the Model part from the rest. But by simplification and in order to not surcharge the source code, we've merged View and Controller part in a Presentation layer.

Hierarchical M & VC

Due to the hierachical nature of our data (xml or trees) we have a Hierarchical MVC (HMVC) approach with a cascade of views. Osyl Views are using GWT Composite components which aggregates other GWT Composite components (other Osyl Views) and so on.

Many of those Views are are based on a sub-model part of the model.

Update events coming from the Model help to keep the synchronization between the View (visual output) and the Model.
So, there is a tight relation between Model update and related Views update (thanks to events)?

Extract from
public class OsylTreeView implements OsylTreeModelUpdateHandler {
 public void onOsylTreeModelUpdate(OsylTreeModelEvent event) {
   OsylTreeItem treeItem = event.getOsylTreeItem();
   // update the view with the new OsylTreeItem

Multiple Views

OpenSyllabus is made of multiple views which interact with each other and are refreshed accordingly.

Tree View

We have a "Tree View" that allows browsing among different parts of the course outline.

Editor Toolbar

The "Editor toolbar" with all the buttons needed to create, import, add, save, publish the Syllabus

Workspace View

The "WorkSpace View" where all the text processing work is done.

Configuration View

Finally the "Configuration View" where non textual parameters are set or put into a specific state
With OSYL you can edit & modify the content

You can also add ressources

  • No labels