Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
|Download • Git
|Forums • Blog • Twitter • G+
One of the key concepts in Scout is the strict separation of the business relevant user interface from its graphical representation. This is achieved by providing a custom component model which is represented to the user in form of a desktop application (SWT or Swing) or a web application (Rap).
That component model consists of typical components used in modern business applications. Beside the ability to separate the UI and GUI these components also enable automated and central control of recurring tasks like validation, parsing and other component specific behavior.
Strict subclassing of these abstract components leads to a strong typed application model where each application entity (Forms, Wizards, TablePages, ...) contains its component elements as inner classes, therefore entities are kept together as single unit.
Separation of UI and GUI
An important reason to create an own component model was to decouple the complex GUI code which needed to be implemented only once, as a result. So what we actually get is a separation of UI and GUI where the business logic for the UI is independent of any specific GUI implementation. This leads to the fact that you can easily switch between Swing, SWT, the web or any other upcoming GUI implementation if you like.
In the diagram you can see how the UI and the GUI of scout and your application based on scout work together. On the left there is the plugin org.eclipse.scout.rt.client (UI) and the plugin org.eclipse.scout.rt.ui.swt (GUI). The UI plugin does not have any dependency to the GUI plugin so that it stays independent. On the right side there are the counterparts of the scout plugins which form your applications client.
The same application rendered with different widget toolkit:
RAP GUI (Web application opened in Firefox)
Threading and Jobs
Another fundament of Eclipse Scout's simplicity is the Client Job Queue. Every logic processed on client side like calling services, opening a form, validating a field, etc. is run inside a ClientSyncJob and therefore synchronously. As soon the processing is finished and the data ready to be displayed the GUI Thread takes over and displays the data. This approach minimizes the execution time of the GUI Thread and therefore reduces the time of a blocking or freezing window.
How the fields are arranged on the form depends on the used form field container (composite). The default containers shipped with scout like GroupBox or TabBox use a so called body grid, which guarantees a uniform layout through the whole application. There are a lot of properties to control the layouting like vertical or horizontal span (gridH, gridW). If you still need more control you can create your own field composite with a custom layout manager. See Layout for a detailed explanation of the layout.
The Client Session is the main entry point for client-server communication.
The Desktop is the entry point of every Scout client application. It can (may) consist of top-level menus, active message box stack, set of available outline, active outline, active tableview, active detail form, active search form, form stack (swing: dialogs on desktop as JInternalFrames; eclipse: editors or views), dialog stack of modal and non-modal dialogs (swing: dialogs as JDialog, JFrame; eclipse: dialogs in a new Shell).
Typically a Desktop holds multiple Outlines. They represent different entry points for the navigation within the application. For every outline a tree is available which allows navigating within the application. The nodes of the tree are called Pages.
A Form is both a model structure of a ui concept known as dialog or view and also a model of a wizard page.
Every form is started by a Form Handler. Form handlers provide for a controlled form lifecycle. There typically exist at least a ModifyFormHandler and a NewFormHandler which are responsible for handling the modification respectively the creation of the form's data by calling the responsible services.
Form fields are the basic elements for user inputs fiels within a form. Examples are:
Futhermore there exists composite fields which are able to group normal fields:
The Menu component include all links, functionalities, etc... available within the application.
A Tool component is used for grouping or dividing different views. This can be used for building business views on datas or just structuring your own application.
A Wizard supports a user to work in a process driven approach on a task.