 |  |
| | |
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 links, 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 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
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
TODO: outdated with switch to YAML GUI framework
A Component is a visual representation of e.g. a Link, 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.
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
The GUI Framework has mainly two things to do upon each browser-click from a user:
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
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.
With the release 5.2.0 OLAT introduced a significant improvement in case of user experience and architectural change. The component architecture allowed us to easily switch to a mode where the components come in play up to the browser client.
In non ajax mode all components where rendered on the server and concatenated to a big html file and delivered to the client which rendered the whole page for each click. The ajax mode allows now to just send the components that are dirty to the client and the client renders the html fragments into the GUI by dom replacement. As we do this on component level the whole process is transparent for the developer and therefore very little special effort is needed by the developer to achive this.
To make sure everyone gets the best OLAT experience the ajax mode only gets automatically enabled for fully tested browsers. See the olat-config.xml file for a list of supported browsers. The not supported browser get just the normal request based full layout page with each click.
The ajax mode has a polling feature where you can send
periodically a request to the server to check for dirty
components, that need to be rerendered on the user
screen. This is e.g. used in the
InstantMessagingMainController
to inform users about new incomming messages even if
they did not click in the OLAT GUI. See the
JSAndCSSComponent
constructor for an argument called pollintervall. If
several pollivervalls are requested by controllers the
server sets the poll intervall to the lowest available
value which can be changed in the livetime of the
controller by calling setPollIntervall. If you enabled
the Instant Messaging feature you will have a polling
channel for the whole GUI as the
InstantMessagingMainController
is always present in the upper right corner.
In OLAT ajax mode all requests to the server are send to an hidden iframe target. The answer comes back to this target as well and is processed by javascript (see: a_invoke in functions.js file). The transport between the server and the client is handled by json a lightweight data-interchange format. Json was choosen to further minimize the amount of data that gets interchanged between the server and the client.
So you have your controller which handles you clicks and
form events, but how can you listen to external events
like an incoming instant message from an other server?
There is a interface called
GenericEventListener
which you can implement for such purposes. This
interface offers you an additional generic event method
you can call yourself from outside your controller. See
again the
InstantMessagingMainController
which has the generic event interface implemented. The
generic event method for this controller gets called by
the
ClientManager
which handles connections and message listeners for all
the instant messaging clients and sends events to the
contollers.
Basically nothing special has to be done to make your
controllers work in ajax mode but by a good design you
can increase the user experience a lot. E.g. while
chatting, you may type and receive messages at the same
time. With a good design you can decouple both actions
so the user GUI gets updated while still typing. To do
this you have to split you interface into panels which
can be easily updated independently as a panel is a
component which can be adressed and setted dirty. If you
study the
InstantMessagingMainController
and the velocity files you will get an idea how to do
this.
There are a few limitations that you have to keep in mind when programming for the ajax mode.
When opening a new window by a link, you
should disable the ajax mode for this link
otherwise the link gets posted to the
background into the iframe. See
Link
component for how to disable the ajax mode
for a single link.
The polling feature is not yet available in new opened browser windows. This feature will be available with OLAT 5.3.
If you like to debug the ajax mode to see what is sended
between the server and the client use either firebug
firfox extensio where you can capture the net traffic or
the linux util tshark or wireshark which is a
packetsniffer. In OLAT code have a look into the
org.olat.core.gui.control.pushpoll
package where you find the
AjaxController
or the
JSServerController
which server the json answer by calling the
extractMediaResource method.
OLAT supports starting with the release 5.2 to support a few web 2.0 ajax libs which will be present for a longer time period, which means you can depend on and use it in your code.
Prototype from prototypejs.org . Prototype is a JavaScript Framework that aims to ease development of dynamic web applications.
script.aculo.us
is build on top of prototype and delivers very
nice effects for autocompletion and drag and
drop.
effects.js
dragdrop.js
controls.js
Extjs
(Extend the web) is our rich client javascript
Framework which offers very nice widgets like
floating panels. Extjs is also build on top of
prototype. Currently we only use tooltips and
floating panels from the ext library. See the
testing->GUI demo tab for examples of the
tooltip stuff. If you want a nice floating panel
like in the instant messaging you have to create
instances of
FloatingResizableDialogController
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 3.1, “GUI debug stack” . 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 3.2, “GUI debug listeners box” , 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.
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 3.3, “Red screen of an unchecked exception.”
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.
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.
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 |
+---------------+
create 2 security groups -> ownerGroup, -> partipiciantGroup
create a buddyGroup with name, description, introMsg and the 2 security groups
2 policies, ownerGroup -> PERMISSION_ACCESS -> buddygroup. partipiciantGroup -> PERMISSION_READ -> buddygroup
| |  | |
 |
