Skip to main content
Jump to: navigation, search

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

m
(Layouting)
 
(14 intermediate revisions by 6 users not shown)
Line 10: Line 10:
 
[[Image:Scout gui representation.png|thumb|right|200px|Scout GUI Representation]]  
 
[[Image:Scout gui representation.png|thumb|right|200px|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 or any other upcoming GUI implementation if you like.  
+
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 picture 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.  
+
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 ===
 
=== Example ===
  
The same application rendered with SWT and Swing
+
The same application rendered with different widget toolkit:
  
 
<gallery>
 
<gallery>
 
Image:Scout_app_gallery_swt.jpg|SWT GUI
 
Image:Scout_app_gallery_swt.jpg|SWT GUI
 
Image:Scout_app_gallery_swing.jpg|Swing GUI (Nimbus Look and Feel)
 
Image:Scout_app_gallery_swing.jpg|Swing GUI (Nimbus Look and Feel)
 +
Image:Scout_app_gallery_rap.jpg|{{ScoutLink|Concepts|RAP|RAP GUI}} (Web application opened in Firefox)
 +
Image:Scout app gallery rayo.png|{{ScoutLink|Concepts|Rayo|Swing Rayo GUI}}
 
</gallery>
 
</gallery>
  
 +
== Threading and Jobs  ==
  
== Job Queue ==
+
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.
{{note|TODO|Add description}}
+
 
 +
== Layouting ==
 +
 
 +
How the fields are arranged on the form depends on the used form field container (composite). The default containers shipped with scout like {{ScoutLink|Concepts|GroupBox}} or {{ScoutLink|Concepts|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 {{ScoutLink|Concepts|Layout}} for a detailed explanation of the layout.
  
 
== Component Model  ==
 
== Component Model  ==
Line 41: Line 48:
 
=== Outline  ===
 
=== Outline  ===
  
Typically a Desktop holds multiple {{ScoutLink|Concepts|Outline|Outline}}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.  
+
Typically a Desktop holds multiple {{ScoutLink|Concepts|Outline|Outline}}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 {{ScoutLink|Concepts|Page}}s.
  
 
=== Form  ===
 
=== Form  ===
  
A {{ScoutLink|Concepts|Form|Form}} is both a model structure of a ui concept known as dialog or view and also a model of a wizard page. Wizard buttons are added automatically to the main box if missing.  
+
A {{ScoutLink|Concepts|Form|Form}} is both a model structure of a ui concept known as dialog or view and also a model of a wizard page.  
  
 
==== Form Handler  ====
 
==== Form Handler  ====
  
Every form is started by a FormHandler. A form handler is state less, the state is only held on the form itself. Form handlers provide for a controlled form lifecycle. Default operations are:
+
Every form is started by a {{ScoutLink|Concepts|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.
 
+
*execLoad: Before the form is activated, this method loads its data. All field changes done here appear as unchanged in the form.
+
*execPostLoad: Called after execLoad and before the form is activated. When field values are changed here, these appear as changed.
+
*execCheckFields: This method is called in order to check field validity. This method is called just after the IForm.execCheckFields() but before the form is validated and stored. After this method, the form is checking fields itself and displaying a dialog with missing and invalid fields.
+
*execValidate: This method is called in order to update derived states like button enabling. This method is called after the IForm.execValidate() but before the form is stored.
+
*execStore: When the form is closed using Ok, Save, Search, Next, etc.. this method is called to apply the changes to the persistency layer
+
*execDiscard: When the form is closed using cancel or close this method is called to manage the case that no changes should be performed (revert case)
+
*execFinally: When the form is closed in any way this method is called to dispose of resources or deallocate services
+
  
 
=== Form fields  ===
 
=== Form fields  ===
  
Form fields are the basic elements for user inputs fiels within a form. Examples are:  
+
[[Scout/Concepts/Field | Form fields]] are the basic elements for user inputs fiels within a form. Examples are:  
  
 
*{{ScoutLink|Concepts|Button}}  
 
*{{ScoutLink|Concepts|Button}}  
Line 72: Line 71:
 
*{{ScoutLink|Concepts|LongField}}
 
*{{ScoutLink|Concepts|LongField}}
 
*{{ScoutLink|Concepts|PageField}}
 
*{{ScoutLink|Concepts|PageField}}
 +
*{{ScoutLink|Concepts|PlaceholderField}}
 
*{{ScoutLink|Concepts|RadioButton}}
 
*{{ScoutLink|Concepts|RadioButton}}
 
*{{ScoutLink|Concepts|SmartField}}
 
*{{ScoutLink|Concepts|SmartField}}
Line 98: Line 98:
 
=== Wizard  ===
 
=== Wizard  ===
  
A {{ScoutLink|Concepts|Wizard|Wizard}} supports a user to work in a process driven approach on a task.  
+
A {{ScoutLink|Concepts|Wizard|Wizard}} supports a user to work in a process driven approach on a task.
 +
 
 +
== Templating ==
 +
 
 +
[[Scout/Concepts/Template]]
 +
{{note|TODO|Describe what template fields are}}
 +
 
 +
== Examples ==
 +
=== Forms ===
 +
*{{ScoutLink|Examples|SimpleForms}}
 +
=== Fields ===
 +
*{{ScoutLink|Examples|SequenceBox}}
  
 
== See also ==
 
== See also ==

Latest revision as of 04:09, 14 April 2014


Scout
Wiki Home
Website
DownloadGit
Community
ForumsBlogTwitterG+
Bugzilla
Bugzilla

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

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.

Component Model

Client Components

Client Session

The Client Session is the main entry point for client-server communication.

Desktop

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).

Outline

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.

Form

A Form 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 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

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 Menu component include all links, functionalities, etc... available within the application.

Tool

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.

Wizard

A Wizard 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


Examples

Forms

Fields

See also

Back to the top