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"

(→‎Samples)
(→‎Overview of the concept pages)
(15 intermediate revisions by 7 users not shown)
Line 2: Line 2:
 
{{ScoutPage|cat=Concepts}}
 
{{ScoutPage|cat=Concepts}}
  
−
{| class="FCK__ShowTableBorders" align="top"
+
The Concepts pages define concepts and elements used in the Eclipse Scout Framework.
−
|-
+
−
| __TOC__
+
−
|}
+
  
−
= Scout =
+
== Big Picture - Main Architecture of Scout ==
−
Scout is the base of applications that may be developed with or without the Scout SDK. As Scout is written in pure Java/J2EE and satisfies the OSGi paradigm, integration of 3rd party libraries or applications is fully supported. The Scout runtime both provides a large amount of reusable functionality and a library of abstract UI component models.
+
[[Image:Scout_main_architecture.png|thumb|right|200px|Scout Main Architecture]]
  
−
The extension point registry is reused to define Scouts extension points. An Eclipse compliant extension point defines the UI representation of every component model. This simplifies adding and changing of specific component representations as well as the application representation. With a Swing and a SWT/JFace representation Scout already provides two UI implementations.
+
Scout is a framework for creating modern business applications. Such applications are typically separated into multiple tiers where each tier is responsible for a specific part of the application like presenting information to the user or processing business logic and persisting data.
  
−
[[Image:Scout_architecture_overview.png]]
+
Scout solves these requirements by providing a separation of such tiers out of the box. The two main tiers of Scout are the client part and the server part.
  
−
= Client Component Modell =
+
Scout is also a framework, which is simple to use but yet flexible. This is achieved, amongst other things, by using a stable platform as base, namely Eclipse / Equinox. By using this base on both the client and the server side, it becomes possible to use the same technologies and tools for creating the server and the client part. Even though these tiers are separated, there is no need to use different Eclipse workspaces or even different developers for each tier. One developer is able to create a multi tier application in one Eclipse workspace and still has a strict separation of client and server thanks to OSGI/Equinox.
−
[[Image:client_components.png]]
+
−
== Client Session ==
+
−
The client session is the main entry point for client-server communication.
+
  
−
== Desktop ==
+
Another thing that makes it so simple is the communication between these tiers. There is no need to explicitly define webservice and exchange WSDLs in the same application, only to show some information on a dialog (not implying that it would not possible to do so, it actually is!). Instead OSGi services are used where only an interface is sufficient. That interface for a service including the data transfer objects (DTO) is known on client and server side. This is achieved by having these interfaces in a shared part. With that mechanism it is possible to provide a service tunnel, which actually is one webservice tunneling every OSGi service call from client to server.
−
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).
+
  
−
== Menu ==
+
=== Plugin-Set ===
−
The menu component will include all links, functionalities, etc... available within the application.
+
[[Image:Scout Client Shared Server.png|thumb|right|200px|Plugin-Set of a Scout Application]]
  
−
== Tool ==
+
A Scout project is composed of different Eclipse plug-ins (each plug-in is an Eclipse project).
−
Tool component will be used for grouping or dividing different views. This can be used for building business views on datas or just structuring your own application.
+
* Client Plug-In (eg <code>your.application.client</code>)
 +
* Shared Plug-In (eg <code>your.application.shared</code>)
 +
* Server Plug-In (eg <code>your.application.server</code>)
  
−
== Outline==
+
Since the Scout runtime relies on a strict separation of business code and presentation code, additional plug-ins are provided where GUI specific code is placed. Depending on the GUI implementation, these plugins can be one of the following:
−
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.
+
* SWT UI Plug-In for native desktop applications (eg <code>your.application.ui.swt</code>)
−
== Form ==
+
* Swing UI Plug-In for individual desktop applications (eg <code>your.application.ui.swing</code>)
−
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.  
+
* Rap UI Plug-In for web (2.0) applications (eg <code>your.application.ui.rap</code>)
−
=== Form fields ===
+
−
Form fields are the basic elements for user inputs fiels within a form. Examples are:
+
−
* TextField
+
−
* SmartField
+
−
* NumberField
+
−
* DateField
+
−
* FileChooser
+
−
* ListBox
+
−
* TreeBox
+
−
* CheckBox
+
−
* RadioButton
+
−
* ToogleButton
+
  
−
Futhermore there exists composites fields like:
+
The image ''Plugin-Set of a Scout Application'' shows how the plug-ins are organized. In the upper part of the image you can see the plug-ins of a typical Scout application: client, shared, server and a UI plug-in. At the bottom are the corresponding plug-ins of the Scout runtime framework. All these plug-ins follow strict dependency rules which are represented by the arrows. The application's server plug-in for example does not know anything about the client, it only knows the shared plug-ins and the server plug-in of Scout.
−
* GroupBox
+
−
* TabBox
+
−
* SequenceBox
+
−
* SnapBox
+
−
* RangeBox
+
−
* RadioButtonGroupBox
+
  
 +
=== Scout Project ===
 +
The Scout SDK relies on the following principles to recognize and display the structure of a Scout project:
  
−
=== Samples ===
+
* Each plug-in project is marked to be of "Scout Nature" in its <code>.project</code> file. This is handled by the Scout SDK for you if you create a new Scout project. You can also add an existing plug-in project to a Scout project  via the "Import Plugin..." menu in the Scout SDK. However, you then still need to handle the bundle dependencies and naming convention manually (see below).
−
* {{ScoutLink|Concepts|Forms/Example|name=Scout form}}
+
* Bundle dependencies: A plug-in project is represented as a client component (orange box) if it depends on the <code>org.eclipse.scout.rt.client</code> bundle. Similarly, a shared or server component depends on the corresponding Scout RT bundle. Also, both the client and server bundles should depend on the shared bundle. (See picture ''Plugin-Set of a Scout Application'' above.)
 +
* Naming convention: A Scout project has a project name (e.g. <code>your.application</code>) and an optional project postfix (e.g. core). The plug-in projects then follow the naming pattern <code>projectName.[client|shared|server].postfix</code>. The full name of the client bundle then would be <code>your.application.client.core</code>.
  
−
== Wizard ==
+
The [[Scout/HowTo/3.8/Create_a_new_project|New Scout Project...]] wizard in the Scout SDK will take care to correctly set up a Scout project for you.
−
Wizards will support a user to work in a process driven approach on a task.
+
 
 +
To delete an existing Scout project, simply delete all involved plug-in projects.
 +
 
 +
== Overview of the concept pages ==
 +
* General Concepts
 +
** {{ScoutLink|Concepts|Application Templates}}
 +
* {{ScoutLink|Concepts|Communication|Client/Server Communication}}
 +
** Service Tunnel
 +
** Session Handling
 +
* {{ScoutLink|Concepts|Client Plug-In|Client part}}
 +
** Separation of UI and GUI
 +
** Threading and Jobs
 +
** Layouting
 +
** Component Model
 +
* {{ScoutLink|Concepts|Server Plug-In|Server part}}
 +
** Providing data for the client
 +
** Accessing persistent data
 +
** Webservice (JAX-WS) support
 +
** Server Side Equinox
 +
** Transaction Handling
 +
* {{ScoutLink|Concepts|Shared Plug-In|Shared part}}
 +
** {{ScoutLink|Concepts|NLS-Support}}
 +
** {{ScoutLink|Concepts|Logging}}
 +
** {{ScoutLink|Concepts|Scheduler}}
 +
** {{ScoutLink|Concepts|Client Notification}}
 +
** Data transfert object: {{ScoutLink|Concepts|FormData}}, {{ScoutLink|Concepts|TablePageData}}, {{ScoutLink|Concepts|TableData}}
 +
* {{ScoutLink|Concepts|Security|Security}}
 +
** Security Principles of Scout
 +
** Authentication
 +
** Authorization
 +
* {{ScoutLink|SDK|name=Scout SDK}}
 +
 
 +
== See also ==
 +
*[[:Category:Scout_Concepts|All Eclipse Scout Concepts]]

Revision as of 08:18, 19 November 2013

The Scout documentation has been moved to https://eclipsescout.github.io/.

The Concepts pages define concepts and elements used in the Eclipse Scout Framework.

Big Picture - Main Architecture of Scout

Scout Main Architecture

Scout is a framework for creating modern business applications. Such applications are typically separated into multiple tiers where each tier is responsible for a specific part of the application like presenting information to the user or processing business logic and persisting data.

Scout solves these requirements by providing a separation of such tiers out of the box. The two main tiers of Scout are the client part and the server part.

Scout is also a framework, which is simple to use but yet flexible. This is achieved, amongst other things, by using a stable platform as base, namely Eclipse / Equinox. By using this base on both the client and the server side, it becomes possible to use the same technologies and tools for creating the server and the client part. Even though these tiers are separated, there is no need to use different Eclipse workspaces or even different developers for each tier. One developer is able to create a multi tier application in one Eclipse workspace and still has a strict separation of client and server thanks to OSGI/Equinox.

Another thing that makes it so simple is the communication between these tiers. There is no need to explicitly define webservice and exchange WSDLs in the same application, only to show some information on a dialog (not implying that it would not possible to do so, it actually is!). Instead OSGi services are used where only an interface is sufficient. That interface for a service including the data transfer objects (DTO) is known on client and server side. This is achieved by having these interfaces in a shared part. With that mechanism it is possible to provide a service tunnel, which actually is one webservice tunneling every OSGi service call from client to server.

Plugin-Set

Plugin-Set of a Scout Application

A Scout project is composed of different Eclipse plug-ins (each plug-in is an Eclipse project).

  • Client Plug-In (eg your.application.client)
  • Shared Plug-In (eg your.application.shared)
  • Server Plug-In (eg your.application.server)

Since the Scout runtime relies on a strict separation of business code and presentation code, additional plug-ins are provided where GUI specific code is placed. Depending on the GUI implementation, these plugins can be one of the following:

  • SWT UI Plug-In for native desktop applications (eg your.application.ui.swt)
  • Swing UI Plug-In for individual desktop applications (eg your.application.ui.swing)
  • Rap UI Plug-In for web (2.0) applications (eg your.application.ui.rap)

The image Plugin-Set of a Scout Application shows how the plug-ins are organized. In the upper part of the image you can see the plug-ins of a typical Scout application: client, shared, server and a UI plug-in. At the bottom are the corresponding plug-ins of the Scout runtime framework. All these plug-ins follow strict dependency rules which are represented by the arrows. The application's server plug-in for example does not know anything about the client, it only knows the shared plug-ins and the server plug-in of Scout.

Scout Project

The Scout SDK relies on the following principles to recognize and display the structure of a Scout project:

  • Each plug-in project is marked to be of "Scout Nature" in its .project file. This is handled by the Scout SDK for you if you create a new Scout project. You can also add an existing plug-in project to a Scout project via the "Import Plugin..." menu in the Scout SDK. However, you then still need to handle the bundle dependencies and naming convention manually (see below).
  • Bundle dependencies: A plug-in project is represented as a client component (orange box) if it depends on the org.eclipse.scout.rt.client bundle. Similarly, a shared or server component depends on the corresponding Scout RT bundle. Also, both the client and server bundles should depend on the shared bundle. (See picture Plugin-Set of a Scout Application above.)
  • Naming convention: A Scout project has a project name (e.g. your.application) and an optional project postfix (e.g. core). The plug-in projects then follow the naming pattern projectName.[client|shared|server].postfix. The full name of the client bundle then would be your.application.client.core.

The New Scout Project... wizard in the Scout SDK will take care to correctly set up a Scout project for you.

To delete an existing Scout project, simply delete all involved plug-in projects.

Overview of the concept pages

See also

Retrieved from "https://wiki.eclipse.org/index.php?title=Scout/Concepts&oldid=351873"

Back to the top