Skip to main content
Jump to: navigation, search

Scout/Concepts/Client Plug-In

< Scout‎ | Concepts
Revision as of 11:07, 2 November 2011 by Claudio.guglielmo.gmail.com (Talk | contribs) (Form fields: linked fields)


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

Job Queue

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.

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. Wizard buttons are added automatically to the main box if missing.

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:

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

See also

Back to the top