Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Scout/Concepts/Client Plug-In"

(Separation of UI and GUI)
(Templating)
Line 98: Line 98:
  
 
== Templating ==  
 
== Templating ==  
 +
 +
[[Scout/Concepts/Template]]
 
{{note|TODO|Describe what template fields are}}
 
{{note|TODO|Describe what template fields are}}
  

Revision as of 13:48, 28 March 2012

The Scout documentation has been moved to https://eclipsescout.github.io/. 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

Scout GUI Representation

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.

Example

The same application rendered with different widget toolkit:

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.

Layouting

In order to guarantee a uniform layout through the whole application scout comes with a custom layout manager called The Scout documentation has been moved to https://eclipsescout.github.io/.. Whenever a scout component on a The Scout documentation has been moved to https://eclipsescout.github.io/. is used the The Scout documentation has been moved to https://eclipsescout.github.io/. takes care of the layout.

Component Model

Client Components

Client Session

The The Scout documentation has been moved to https://eclipsescout.github.io/. is the main entry point for client-server communication.

Desktop

The The Scout documentation has been moved to https://eclipsescout.github.io/. 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).

Outline

Typically a Desktop holds multiple The Scout documentation has been moved to https://eclipsescout.github.io/.s. 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 The Scout documentation has been moved to https://eclipsescout.github.io/.s.

Form

A The Scout documentation has been moved to https://eclipsescout.github.io/. is both a model structure of a ui concept known as dialog or view and also a model of a wizard page.

Form Handler

Every form is started by a The Scout documentation has been moved to https://eclipsescout.github.io/.. 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

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:

Menu

The The Scout documentation has been moved to https://eclipsescout.github.io/. component include all links, functionalities, etc... available within the application.

Tool

A The Scout documentation has been moved to https://eclipsescout.github.io/. 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.

Wizard

A The Scout documentation has been moved to https://eclipsescout.github.io/. supports a user to work in a process driven approach on a task.

Templating

Scout/Concepts/Template

Note.png
TODO
Describe what template fields are


See also

Back to the top