2.1. Architectural overview

2.1.1. Introduction

The OLAT Application is primarily a servlet application which simply needs a servlet container (e.g. tomcat) to run. It uses a lot of opensource frameworks to get its job done. The most wellknown are

  • hibernate for the o/r database mapping

  • velocity for the layouting process

  • spring for configuration issues

The GUI framework is a self-developed framework, which is component-based, follows the MVC (Model-View-Controller) paradigm, and focuses on reuse of component and also of workflows. It is a lot like Java Server Faces, but more powerful. Programming the GUI is very similar to developing with SWING or SWT. We have panels, Containers with layouting, pre-built components like forms, tables, and so on. The workflows are grouped into reusable controller classes, so that e.g. a user search (a search form, then a list of found matches) can be reused all over the places

The framework can support any language (currently implemented: English, German, French, Italian) since it saves both localization and user data in utf-8. Even mixed content (content packaging with some encoding other than utf-8) works fine. There is an online translations tool within olat so that translating into a new language is a piece of cake (but still a lot of work!!) See Customizing

2.1.2. System boundaries

2.1.3. Programming concept

The OLAT programming concept can summarized as follows: Swing like - Component based (MVC), Business task (Controllers), Business logic (Managers), use of well established open source libraries

2.1.4. Component based

A Component is a visual representation of e.g. a Form, a Table and so on. One ore more Controller can listen to Event which are fired when the user e.g. submits a form. Each component must provide its HTML-Renderer (method getHTMLRendererSingleton (interface ComponentRenderer) which know how to render its state in HTML.

2.1.5. Separation of logic and layout

Business logic is encapsulated in Controller classes (and the Manager classes they use), whereas the layout can be controlled by mainly modifying CSS. Almost all images can be configured using CSS also. In case you really would like to dig even more into the layout, you can easily change the HTML-Fragments which is HTML-Code with some Velocity commands in it

2.1.6. Event dispatching

The GUI Framework has mainly two things to do upon each browser-click from a user:

  1. Dispatch the request to the component which was clicked in the browser

    • find the component (with the component-id of the url) in the component tree of the contentpane of the window

    • call dispatchRequest(UserRequest ureq) so the component can adjust its state

    • the component will fire an event to the listening controllers if appropriate (e.g. "Treenode-clicked" with the id of the clicked node)

    • the controller(s) which receive the event update their business logic

    • as a result, the controller updates some of the components it owns (e.g. advance in a wizard step) and might fire an Event to listening "parent" controllers. (e.g. an UserChosenEvent

  2. Render the new state of the screen into HTML.

    Or deliver the Resource to the browser if it is e.g. a PDF-Document or such (non-html)

    The rendering is done by accumulating the output of the components in a StringBuffer while traversing the whole component tree. At the end, the whole StringBuffer is sent to the client's webbrowser. This uses some temporary memory, but has the advantage that the user never sees those half-baken screen in case of an error. The page will either work completely or produce a decent error screen with a reference number for the support staff.

2.1.7. Ease of developing and debugging

OLAT helps the developer with several built-in features. These should be disabled in a productive environment.

  • enable the GUI debug mode, see GUI debug mode

  • refresh localized strings

    this is enabled by setting

    localization.cache=true

    in the build.properties.in

  • configure velocity engine to refresh files

    this is enabled by setting

    velocity.cache.pages=true

    in the build.properties.in

  • online translation tool, see online translation tool

The GUI debug mode helps in understanding the GUI stack structure. It is then easy to find out why something does not show up where it was intended to, see Figure 2.1 . Refreshing the velocity pages and the refreshing localized string properties enable the developer to change/fix broken layouts and translation keys on the fly. The yellow highlightend component, visible in Figure 2.2 , produces a floating box with additional information:

  • type, the java class name of the component.

  • listeners, a list of event listeners attached.

  • cListeners, a list of controller event listeners

  • translator, shows where the keys come from and in which language. Clicking on the link brings up a new browser window with the possibility to interactively fix translation keys.

  • nesting level, a counter for nested div's tables respectively.

Figure 2.1. GUI debug stack

GUI debug stack

Figure 2.2. GUI debug listeners box

GUI debug listeners box

The OLAT framework works with the unchecked exception principle. This means that the developer should not care about exceptions in general. Exceptions go there long way up to the top level of OLAT, where they are catched and translated into a red screen, see Figure 2.3

In a productive environment a user only gets the Error code and the Date and time information, which she should present to the support. The system administrator can retrieve within OLAT the associated stacktraces and errormessages for further measures.

Figure 2.3. Red screen of an unchecked exception.

Red screen of an unchecked exception.

2.1.8. Authentication and Authorization

2.1.8.1. Authentication: Supported providers so far are: Normal Formbase username/password login, and Shibboleth 1.3 login

2.1.8.2. Authorization:

  • The basesecurity is a little like Java Security.

  • A policy protects olatresources allowing permissions (e.g. access, read, hasRole, etc.) to given securitygroups

  • No permissions to users, if they aren't in securitygroups.

  • Rights are positiv and additiv.

2.1.8.2.1. Instance rights versus type rights

If you have no type rights at all and someone assigns you as owner of a certain resource, you have instance rights for only this resource. Addionaly you can create other resources of this type. But if all resources to which you have instance rights are deleted, you are not more able to create one. In the opposite if you have type rights to a kind of resource, you always can create instances of this kind.

existing rights in the system:

       +---------------+
       | permission    |
       +---------------+
       | hasRole       |
       | access        |
       | admin         |
       | nologin       |
       | coach         |
       | participant   |
       | read          |
       | bgr.archive   |
       | bgr.assess    |
       | bgr.editor    |
       | bgr.groupmngt |
       +---------------+
      

2.1.8.2.2. How security is used explained by creating a new instance of a buddygroup

  1. create 2 security groups -> ownerGroup, -> partipiciantGroup

  2. create a buddyGroup with name, description, introMsg and the 2 security groups

  3. 2 policies, ownerGroup -> PERMISSION_ACCESS -> buddygroup. partipiciantGroup -> PERMISSION_READ -> buddygroup

Figure 2.4. creating a new instance of a buddygroup

creating a new instance of a buddygroup