The OLATServlet is the main entry point for user requests from the browser. This servlet uses Dispatchers to further process a request. This is done by the class DispatcherAction. Furthermore, the OLATServlet is responsible for initializing and configuring OLAT. This is done by calling the ConfigurationManager at startup.

DispatcherAction analyzes the first part of the incoming request URI and decides which Dispatcher is repsponsible for further dispatching the request. These Dispatchers are namely:

Besides OLATServlet, there are a few more servlets used within OLAT. Find a brief description of the functionality they provide below:

Each User has a UserSession which stores the windows amongst other things. The Windows contains at least one Window. A window is the server-side representation of a browser window. A window has a content-pane (like Swing) to store the "real" content. Each window is owned by a ChiefController which is responsible for the navigation the windows offers, but not for its content. So e.g. after logging in, the tabs on the top ("home", "groups", ...) are controlled by the chiefcontroller.

A Controller is a responsible for a certain business logic / workflow

Each controller must provide an initialComponent, which is the visual representation of the controller at any given time. The component will be rendered later into a HTML fragment which is part of the whole HTML page. You could think of a Swing Panel which is embedded into some place in the webbrowser window. The code creating a controller and asking for its initialComponent can determine where to visually put the component

Managers within OLAT, by definition, are classes that implement basic services useful for implementing the actual business logic. The OLATResourceManager for instance provides the basic functionality for handling OLATResources such as creating, reading, updating and deleting. Any Controller within OLAT that has to deal with an OLATResource should use the OLATResourceManager and not directly imlement basic functionality. In particular, Managers wrap all database access.

OLAT provides its own implementation of a filesystem abstraction layer, called Virtual Filesystem (VFS). The VFS represents a tree structure with folders and files within folders much like a regular filesystem. Folders are called containers and files are called leaves. There are different implementations of containers and leaves serving different purposes. These offers the flexibility to change the implementaion of the file and folder classes and may switch to an other storage solution (like database) without rewriting code in the file handling classes.

Both VFSContainer and VFSLeaf inherit from VFSItem with generic attributes and methods common to both such as a name, methods to query wether delete or write is allowed and others. The most important method defined on VFSItem is resolve(String name). This method allows to query a VFSItem to resolve a path (i.e. /home/user/readme.txt). A path is much the same as a path on a regular filesystem. Resolve() returns a VFSItem which can be either a VFSContainer or a VFSLeaf.

The second most important feature of VFSItem is its VFSSecurityCallback. A security callback defines what operations are allowed on the item. VFSSecurityCallback defines whether read/write/list/copy and delete operations are allowed. If a specific item has no VFSSecurityCallback defined, all operations are allowed by default. VFSSecurityCallbacks get inherited by all children attached to an item. So for example, if a container has a security callback set that denies write operations, the container itself and all of its children would not be writable. VFSSecurityCallback also allows to define quotas on a object. The VFSSecurityCallback is checked by the VFS implementation. I.e. if you perform a write operation, the security callback is checked and an exception is thrown if the security callback denies write opertaions on the specific item.

There are various implementations of VFSContainer and VFSLeaf already in place. The most handy probably are LocalFolderImpl and LocalFileImpl which are an abstraction of a local filesystem. These are probably the place of start for all your VFS tasks. Simply create a LocalFolderImpl with a File pointing to a local folder as constructor asgument. You can then resolve any file or folder within this local folder through the resolve() method as described above. You can create new folder or files through the respective methods of VFSContainer (createChildContainer and createChildLeaf).

A special type of implementation are all implementations based on AbstractVirtualContainer. Those will be described briefly below.

With these implementations, you are quite flexible in presenting a filesystem the way you want. Note that you may also combine different implementations of VFSContainer or VFSLeaf. The WebDAV implementation in OLAT makes use of most of the features provided by VFS. At its root there is a merge source. The merge source combines VFSContainers which themselves are wrapped by NamedContainerImpls. This way, the different types of directories exposed by WebDAV can be presented in a sensible way to the user.

See javadoc of the package org.olat.core.util.vfs to get some code examples on the general usage

See VFS javadoc for more information.

OLAT uses the hibernate relational persistence framework to map objects to relational database tables. See the hibernate documentation to learn how to use this framework.

Every persitable class in OLAT inherits from or extends org.olat.persistence.PersistentObject . This guarantees that every class has the following common attributes:

To make a class persistable by the hibernate layer one needs to implement getter and setter methods for every attribute added to the class; this is a hibernate convention. Getters and setters can be private if they should not be used by code outside the class.

Every class must also have an interface if it wants to use the lazy initialization options. See the hibernate documentation for more information on this. These are the naming conventions when using interfaces:

Every persistable class must have a hibernate mapping description. This mapping file (an XML file) must be stored in the same package as the mapped class. See the hibernate documentation to learn how to write the mapping file. There are several strategies how to write the mapping.