Developers

Development

In Brasato, we develop code in controllers.

Each controller is normally in an own java package.

A controller represents a "business ui case" and has control over the component it generates and the subcontrollers (normal controllers again) which it needs to do its work.

A controller has an initial component.



Have a look at the ch.goodsolutions.demo.basics Java package:

It contains all files which constitute the workflow, that is: java source code (SimpleDemoController.java), i18n files (_i18n folder), velocity templates with html-fragments (_content folder), and static files like css and images (_static folder).



Below we see the files which are needed for the code to work.

Click on the parts to see them enlarged.

Java code (SimpleDemoController.java)



Main HTML fragment for the "Demo A"



HTML fragment for the panel bottom-left when you click on the "a simple button" - button



The internationalization (i18n) files



This leads to the part of the screen marked in red.

What you have now is an independant ui workflow / controller which can be reused on and on if this makes sense.

You try to code controllers in such a way that they represent reusable flows, e.g. a user search, a group management, a forum, a wiki and so on.





Architecture

Here you see an architectural overview of Brasato

Here is a whitebox of the layers of brasato.



Dispatching

Here is an example of a dispatch cycle.



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 by the user in the browser
Find the component (with the component-id of the url) in the component tree of the content pane of the window.

Call dispatchRequest(UserRequest ureq) of the component, so that it can update 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 or "Form submitted").

The controller(s) which receive the event update their internal state, which means most of the times to call business logic and

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 when a user was chosen.



2. Prepare a response to the client by either
2.1. Render the new state in HTML.

The rendering is done by collecting the render output of each individual component registered in the render tree.

It is only after the complete render tree has been traversed that a response is sent to the client's webbrowser.

This has the advantage that a user never sees those half-baken screens in case of an error during the render process.

The resulting page will either be sent as a whole or a decent error screen is produced with a reference number for support staff to further track down errors.

2.2. Deliver a resource such as a PDF-Document or any data that can not be rendered in HTML



To avoid building URIs by hand, the concept of an URLBuilder class has been introduced. This class is responsible for building all links for the whole application and encodes necessary parameters which are internal to the framework such as window id, component id, timestamp, ajax mode, etc. transparently into the final URI.