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
Communication
Osyl Client needs to interact with the Sakai Server. OpenSyllabus used all the Sakai platform services we needed, in addition of our own services.
RPC
RPC (Remote Procedure Call) is the communication's workhorse of GWT.
OpenSyllabus server used GWT special RPC servlets to implement exchange of serialized Models Objects with the client application.
REST based SData
Osyl Client uses REST based calls to SData services on the Sakai server. REST (Representational State Transfer) is based on resources where each is referenced by a unique identifier, its URI (Uniform Resource Identifier). In REST, clients and servers communicate via standard HTTP and exchange representations of resources (the documents).
Thus, Sakai's SData services return JSON (JavaScript Object Notation) documents which are directly evaluated into Javascript objects by the browser.
Integration to the Sakai's platform
Exploring Differents Solutions
We want to talk about some of the concerns that we have about the integration of a GWT client to the Sakai's platform and how they have been addressed.
Firstly, we needed to prove the feasibility of the integration of a GWT client with the Sakai's platform. Hopefully, Sakai is based on the Spring framework and the integration of GWT to Spring has already been done by others George Georgovassilis . Anyway, Spring is well known for its integration capabilities, but we have to find the best way.
With the help of people from Sakai Québec (CRIM), we made a proof of concept of the integration of GWT and Sakai. What we did is pretty similar to the work of Luis Filipe Lobo, using servlet extension of GWT servlet, Sakai listener and tool registering into Sakai.
The role of the JSP entry page
Now, we will see what are the roles of the JSP entry page (index.jsp).
- First it gives access to the GWT compiled JavaScript.
Here is a sample of the script tag you have to put into your jsp page to give access to the GWT compiled JS.
<!-- This script loads our GWT compiled module. --> <!-- Any GWT meta tags must be added before this line. --> <script language='javascript' src='<%=request.getContextPath() %>/org.sakaiquebec.opensyllabus.OsylEditorEntryPoint/org.sakaiquebec.opensyllabus.OsylEditorEntryPoint.nocache.js'> </script>
- With JSP scriptlet you can use specific logic to choose between different compiled GWT applications
- Provides the CSS Link
<link rel="stylesheet" type="text/css" href="osylcoconfigs/default/skin/osylcore.css" />
- Initializes some META to set the language (I18N)?
...<%@ page import="org.sakaiproject.util.ResourceLoader"%> ... <% ResourceLoader rb = new ResourceLoader(); Locale sessionLocale = rb.getLocale(); String locale = sessionLocale.toString(); ... %> <html> <head> <meta name="gwt:property" content="locale=<%=locale%>"> ...
- Controls the tool display size
...
<html>
<head>
...
<!-- Headers from Sakai -->
<%= request.getAttribute("sakai.html.head") %>
<script> // Size of the JS application
function myLoad() {
setTimeout("<%=request.getAttribute("sakai.html.body.onload") %>", 500);
}
</script>
</head>
<body onload="myLoad()">
...
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.