Scout/Documentation

Architecture

Main Parts of a Scout Project

Client,shared,swt,server Equinox client server

Client / Server Communication

Service Tunnel

Proxy services, Service Factories Entry point server (servlet) Outgoing point client

Message Structure

Base64 encoded Serialized objects

Client Concepts

Separation of UI and GUI

Component Model

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

• GroupBox
• TabBox
• SequenceBox
• SnapBox
• RangeBox
• RadioButtonGroupBox

Menu

The menu component include all links, functionalities, etc... available within the application.

Tool

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

Wizards support a user to work in a process driven approach on a task.

Server Concepts

Server Side Equinox

Jetty, ServerApplication as Startup Point

config.ini

Inside of the config.ini in the server it is possible to override the member variables of services.

For example:

com.bsiag.mnet.server.services.common.sql.SqlService#directJ dbcConnection=true

If the service SqlService has a setter method for the member directJdbcConnection then the member has at runtime the value true.

With Scout Eclipse this works for all classes which extends AbstractService

For other classes it must be done by yourself for example with the class FilterConfigInjection at startup.

Security

Authentication and Authorization

JAAS

Granting

Describe the Permisssion Classes, the permission store, ACCESS....

Utilities

NLS-Support

Scout has moved to slf4j. slf4j is a logging facade, which is implemented by various loggers.

Logging

Usage

Scout code should only use the IScoutLogger.

  private static IScoutLogger logger = ScoutLogManager.getLogger(MyOwnClass.class);

The IScoutLogger-Interface is implemented by SLF4JDelegateLogger, which is returned by the above call to ScoutLogManager.getLogger(Class). This wrapps one of the various possible log implementations.

Logger Implementations

Logback

The native implementation and a successor to log4j

impl.simple

Redirection of slf4j calls to std-out

impl.Log4j

Redirection of slf4j calls to log4j

impl.jakarta.commons.logging

Redirection slf4j calls to jcl

impl.Java.util.logging

Redirection of slf4j calls to jul

impl.nop

Redirection of slf4j calls to "nothing"

slf4j also offers bridges that map calls to the "old" loggers to slf4j.

The development environment contains just Logback, impl.simple, impl.nop and the bridges.

Using slf4j/Logback

To use slf4j/Logback the following fragments / plugings are required. Include them as dependencies in your product-file.

• ch.qos.logback.core
• ch.qos.logback.slf4j
• org.slf4j.api
• org.slf4j.ext
• org.slf4j.jcl (optional)
• org.slf4j.jul (optional)
• org.slf4j.log4j (optional)
• a dedicated fragment: fragment.name.org

fragment.name.org

Additionally a dedicated fragment is required (the name is up to you of course). The fragment contains the configuration file for logback and a manifest.

MANIFEST.MF:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Logback Fragment
Bundle-SymbolicName: fragment.name.org
Bundle-Version: 1.0.0.qualifier
Bundle-Vendor: ....
Fragment-Host: org.slf4j.api;bundle-version="1.6.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6

logback-test.xml:

<configuration scan="true">
  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <!-- encoders are assigned the type
				ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
    <encoder>
      <pattern>%d{ISO8601} %-5level [%thread] %logger: %msg%n</pattern>
    </encoder>
  </appender>

  <logger name="org.eclipse.scout.commons.ConfigIniUtility">
    <level value="WARN" />
  </logger>
  <root>
    <level value="WARN" />
    <appender-ref ref="CONSOLE" />
  </root>
</configuration>

build.properties

bin.includes = META-INF/,\
               licence.html,\
               logback-test.xml

Logback Configuration

Automatically Rescanning the Configuration

The automatic scanning for configuration changes is enabled by the attribute scan="true" in the configuration xml.

  <configuration scan="true">

• TODO: Where does it look for the configuration?

Scout Services

Scout SDK

Architecture of Scout SDK

Describe how JDT and PDE is used

Back to Scout