Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 78 Next »

Introduction

Sakai's community should be proud of the solid backend architecture (Java, Spring, Hibernate) that concurrent CLE like Moodle are very envious of.

However, Sakai project has been put in place just before what we must call the Ajax revolution and the Web 2.0
So, Sakais's frontend is based on old fashion « click and wait » web page paradigm.
This is imply to load a new web page for each action (the infamous HTTP round trip) which makes traditional web applications slow.
 

 
In a traditional 3 tiers Web application architecture, the server is playing a role for Data Access, Business logic and Presentation.
In fact, most of the work is done by the server. This is the classic design of tools in Sakai with technologies such as JSP,JSF and RSF.

The Sakai community has to go into the Ajax and Web 2.0 direction in order to improve the user experience (UX) with responsive and dynamic web interfaces.

People are also talking about RIA (Rich Internet Application) that should really have been called Rich Web application (RWA or Rich Webapp).
Rich Webapps are providing Rich UX with desktop-like functionalities, do not require software installation and are executed on the user's browser.

In the long term, Web 2.0 makes the transition from a document based Web architecture to an application-based Web.
This phenomenon has important implications for educational institutions as students increasingly expect such web interfaces.

As many of us already know, the secret ingredient of Ajax is the XMLHttpRequest JavaScript Object which allows asynchronous requests for data to the server and updates the web page without doing a full page reload.
In a nutshell, JavaScript client code manipulates the Document Object Model (DOM) of the web page using XMLHttpRequest and callbacks to send and receive data asynchronously.
 

 
With Ajax you can decide to move all the presentation layer to the client side.

Improving UX could also imply more complex GUI and a lot more work for developers. The challenge is to keep happy users, developers and software architects as well

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 architecture as the main design pattern for the OpenSyllabus GWT client.

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.

  • No labels