From text to model...

From Text to Model

We go through in some great details the kind of design decisions that were made for OpenSyllabus.

Only one Web page | Stateless server | Based on models | XSD schema

Only one Web page

We decided to move all the presentation layer to the GWT client side. So in fact the server will interact only with one page (by default the index.jsp page) where the JavaScript of the GWT client can be retrieved by the user's browser.

As for many Sakai's tool, for the moment the OpenSyllabus tool resides into an iFrame element which displays content. iFrame (Inline Frame) is an HTML element which allows to embed a Frame inside an HTML document. iFrame have their own source URL, distinct from their parent page. Using iFrame is a tradeoff, but in fact we should eliminate frames in the Sakai views and working toward a frameless architecture. Anyway, as a GWT application, OpenSyllabus could be easily integrated into a modern widget/gadget container/portal (or Portlet/Mashup) architecture. To learn more about those future trends you can check the Shindig project.

Stateless server

We also chose a stateless server architecture to avoid server state storage. The GWT Client will take care of that. It is also possible to manage client state with cookies, or with top frames GWT JavaScript.

One disadvantage of a stateless architecture within Sakai is the tool back issue. The use of iFrame for Sakai's tool prevents us from using the back button management built-in GWT. Therefore, when a user leave OpenSyllabus to get another Sakai tool, and when he returns back to OpenSyllabus, the user returns to the initial display of OpenSyllabus. So we lose the previous display of the OpenSyllabus tool. This problem can be simply bypassed by opening a new window for each new Sakai tool. However, this workaround involves some cumbersome windows openings.

Based on models

Another main feature of the OpenSyllabus architecture is in the nature of the communication, data exchanged are models and not HTML pages.

No wonder, since open XML standard and model-based syllabus are at the root of the project (see OpenSyllabus : Model-based Electronic Syllabi, or How to Share Electronic Course Syllabi). Syllabi are structured documents and Zone Cours, the forerunner of OpenSyllabus, is a traditional "page-based" web tool used to create and publish both simple and elaborate syllabi including web links and electronic documents based on XML templates representation and transformation. Zone Cours is currently used since 2004 at HEC Montréal.
 

 
In a previous implementation of OpenSyllabus there was a direct exchange of XML files between the server and the GWT client. Since this first proof of concept, OpenSyllabus has evolved toward an exchange of Java objects (POJO : Plain Old Java Objects) between the Sakai's server and the GWT client using a RPC protocol.

The main reason driving this evolution is to abstract and decouple the XML model from the user-interface using a simple high level POJO "bean like" access (GET/SET). This design is also motivated by the easy-to-use RPC mechanism built-in GWT which allows exchange of Java objects to and from a server using HTTP.

In ideal scenario, the client makes several updates on the model without requesting every time the server. The application should use the server only when persistence of data is needed.
 

 

XSD Schema

We currently used two XML files : one for the model itself and another XML file (OsylConfig) for the configuration of the model (Localisation, Personalization).

We are working now on a XSD which combines the two XML files and that will be used for validation purpose.

• View the whole OpenSyllabus XSD file here .
• Naviguate through the OpenSyllabus XSD schema here .