Page Comparison

...

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.

...

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 .