About This Document
This document describes all relevant changes from Eclipse Scout 7.0 to Eclipse Scout 7.1. If existing code has to be migrated, instructions are provided here.
If you are upgrading from version 6.1, please also read the migration guide for the 7.0 (Oxygen preview) release: https://eclipsescout.github.io/7.0/migration-guide.html |
API Changes (Java)
Java 8 Required
The required Java Runtime Environment (JRE) to run an Eclipse Scout application has changed: Starting with Eclipse Scout 7.1, a Java 8 runtime is required.
The Scout 7.1 Runtime does not support Java 9 yet. The Java 9 support is planned for Eclipse Photon release (Scout 8.0) in summer 2018. |
To reflect this change, some existing Scout classes have been migrated to the newly available Java 8 classes:
Old Scout class: | Replaced with Java 8 equivalent: |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CalendarComponent
Removed deprecated method Date[] getCoveredDays()
on org.eclipse.scout.rt.client.ui.basic.calendar.CalendarComponent
.
Migration: Use Range<Date> getCoveredDaysRange()
instead with start and end date.
Deprecation of SequenceBox EqualColumnWidths
The methods SequenceBox#getConfiguredEqualColumnWidths()
, SequenceBox#isEqualColumnWidths()
and SequenceBox#setEqualColumnWidths()
have been deprecated. As this property was not used by Scout since several releases it can be deleted.
You can search for these method names in your code to find any usages. Alternatively your IDE may mark the usage of deprecated methods (depends on settings).
Removed Constants/Methods From ClientUIPreferences
Since the new Html UI was introduced with Scout 5.2 some constants and methods in ClientUIPreferences
had no effect on the UI anymore. Since Scout is now a browser application we don’t have any control over the application window anymore. The form bounds are stored in the local browser storage thus they’re not required in the Java model anymore.
The following constants/methods were dropped:
-
APPLICATION_WINDOW_MAXIMIZED
-
APPLICATION_WINDOW_BOUNDS
-
FORM_BOUNDS
-
getFormBounds()
-
setFormBounds(IForm form, Rectangle bounds)
-
getApplicationWindowMaximized()
-
setApplicationWindowPreferences(BoundsSpec r, boolean maximized)
Removed Property "focusable" From IFormField, AbstractFormField
Since the new Html UI was introduced with Scout 5.2 the property focusable
had no effect on the UI anymore. Instead the UI uses sensible defaults for each field type. For instance: a LabelField is never focusable, a normal StringField is always focusable, as long as it is enabled. Since the property was rarely used, we removed the related code:
-
Method
boolean IFormField#isFocusable()
-
Method
void IFormField#setFocusable(boolean f)
-
Field
boolean IFormField#PROP_FOCUSABLE
-
Method
boolean AbstractFormField#getConfiguredFocusable()
-
Class
AbstractNonFocusableButton
-
Class
AbstractNonFocusableRadioButton
Migration: Since there is no replacement for the focusable
property, remove all code that uses one of the methods/properties listed above.
Removal of Old "SmartField", Renaming of "SmartField2" Back to "SmartField"
In Scout 7.0 a new smart field implementation named SmartField2 was created. The old implementation was still available, but its use was discouraged. With Scout 7.1 the old SmartField implementation was finally dropped. The new implementation SmartField2 was renamed back to SmartField.
The following table lists the different names used in the past Scout releases. (The naming applies to all associated files, such as interfaces, abstract field classes, Java packages and JavaScript and LESS files.)
Scout <= 6.1 | Scout 7.0 | Scout >= 7.1 |
---|---|---|
SmartField (old implementation) |
SmartField (old implementation) |
— |
— |
SmartField2 (new implementation) |
SmartField (new implementation) |
Migration:
-
If you have already used the new SmartField2 in Scout 7.0 you must move / rename all references back to the (new) SmartField.
-
If you are migrating from an older Scout version (<= 6.1), you might have to adjust your code to the new implementation. See the corresponding 7.0 migration guide.
IContentAssistField Classes and Interfaces Removed
The base class and interfaces of the old SmartField implementation was IContentAssistField. With the new SmartField implementation this interfaces and all classes containing the word "ContentAssist" in their name, have been either removed or renamed to "SmartField". If your code references one of these classes you should simply try to rename all references. Since the API of the new SmartField is almost the same as the old, this should work and should cause no or few changes in your code. The following classes have been removed without replacement:
-
org.eclipse.scout.rt.client.ui.form.fields.smartfield.AbstractMixedSmartField
-
org.eclipse.scout.rt.client.ui.form.fields.smartfield.ContentAssistFieldEvent
-
org.eclipse.scout.rt.client.ui.form.fields.smartfield.ContentAssistFieldListener
-
org.eclipse.scout.rt.client.ui.form.fields.smartfield.ContentAssistFieldTable
-
org.eclipse.scout.rt.client.ui.form.fields.smartfield.IMixedSmartField
Since the new SmartField implementation does not have a proposal chooser model anymore these classes have also been removed. If you must have a special implementation of a proposal chooser, you must implement a proposal chooser in JavaScript (see: ProposalChooser.js), which renders the data and lookup rows it receives from the server-side SmartField. The following classes have been removed without replacement:
-
org.eclipse.scout.rt.client.ui.form.fields.smartfield.AbstractProposalChooser
-
org.eclipse.scout.rt.client.ui.form.fields.smartfield.IProposalChooser
-
org.eclipse.scout.rt.client.ui.form.fields.smartfield.IProposalChooserProvider
-
org.eclipse.scout.rt.client.ui.form.fields.smartfield.TableProposalChooser
-
org.eclipse.scout.rt.client.ui.form.fields.smartfield.TreeProposalChooser
GroupBox: Moved "minWidthInPixel"
The property minWidthInPixel
has been moved to LogicalGridLayoutConfig.
Migration: Instead of using getConfiguredMinWidthInPixel
you should now set the property as follows:
@Override
protected LogicalGridLayoutConfig getConfiguredBodyLayoutConfig() {
return super.getConfiguredBodyLayoutConfig()
.withMinWidth(400);
}
Adjusted Behavior of Widget Initialization
The goal was to harmonize all the init methods (initField
, initTile
, initForm
etc.) and to make sure, init()
is only executed once. This is important for dynamic widgets like accordion or tiles. These widgets initialize the newly added children by themselves so that the caller does not need to take care of it. For these cases it is important that init()
is not called multiple times.
But: there may be cases which require init()
to be called multiple times, like reseting a search form. For such cases, reinit()
has to be used from now on. Also, after the widget is disposed, init()
may be called again. So remember: execInit
may be called more than once in some circumstances. This is existing behavior!
We also renamed the initConfig guard of IFormField
from isInitialized
to isInitDone
to make clear what initialization has been done. It has furthermore been moved to AbstractWidget
so that individual widgets don’t have to care about it and to use the same pattern as for init
and dispose
.
These new methods (init()
, dispose()
and reinit()
) handle the whole widget tree including all child widgets recursively. Child items that need initialization and are NO widgets must be initialized explicitly as it is already now. All children that are widgets must NOT be initialized because this is done automatically by the AbstractWidget implementation. To modify that behavior use the methods initChildren()
or disposeChildren()
(e.g. if you want to exclude a child widget from automatically getting initialized). This also means that the methods ActionUtility.initActions()
, ActionUtility.disposeActions()
, FormUtility.postInitConfig()
, FormUtility.initFormFields()
and FormUtility.disposeFormFields()
have been removed because the corresponding method can be called directly on the instance instead. Use widget.init()
or widget.dispose()
instead of these utility functions.
Please note that the phase postInit
has been removed for the items that supported it. The corresponding code can be moved to the end of the initConfigInternal()
method instead.
We also renamed the initConfig guard of IFormField
from isInitialized
to isInitDone
to make clear what initialization has been done. It has furthermore been moved to AbstractWidget
so that individual widgets don’t have to care about it and to use the same pattern as for init
and dispose
.
Migration:
If you used one of the deprecated methods (initField
, initAction
etc.), replace them with one of the following methods: init
, reinit
or initInternal
.
-
Use
init
if you created a field and need to initialize it. -
Use
reinit
if you explicitly want to reinitialize an already initialized field. -
Use
initInternal
if your custom widget overridesinitField
.
GzipServletFilter
Replaced init parameters get_pattern
and post_pattern
with content_types
. If you set these init parameters in your web.xml, replace or remove them accordingly.
HttpCacheControl
The argument pathInfo
has been removed from the method HttpCacheControl.checkAndSetCacheHeaders
since it has no effect anymore.
Replacement for IActionVisitor, ITreeVisitor, IFormFieldVisitor
A new tree visitor engine has been added to the org.eclipse.scout.rt.platform.util.visitor
package. It contains classes to depth-first or breadth-first traverse any tree data structures. Use the class org.eclipse.scout.rt.platform.util.visitor.TreeTraversals
as entry point.
This new visitors can be used on any widget and tree node. It replaces the former IActionVisitor, ITreeVisitor and IFormFieldVisitor. The org.eclipse.scout.rt.client.ui.IWidget
interface also declares various overloads accepting java.util.function.Consumer
, java.util.function.Function
and the new org.eclipse.scout.rt.platform.util.visitor.IDepthFirstTreeVisitor
and org.eclipse.scout.rt.platform.util.visitor.IBreadthFirstTreeVisitor
. Depending on how much control and data you need for your visitor the matching type can be used.
Until now only pre-order visitors have been available on these items. Therefore the migration to the new visitor takes the following steps:
-
visitFields
oracceptVisitor
method on IFormField orIAction
have been replaced with thevisit
method on IWidget. -
The new visitor allows to control how visiting should be continued in a more detailed level. Instead returning
true
orfalse
to indicate if visiting should continue all options as defined inorg.eclipse.scout.rt.platform.util.visitor.TreeVisitResult
are available. A return value ofTreeVisitResult.CONTINUE
corresponds totrue
and a return value offalse
can be migrated toTreeVisitResult.TERMINATE
. -
If using the
IDepthFirstTreeVisitor
the methodpreVisit
must be overridden to have the same functionality as before. Consider also using theDepthFirstTreeVisitorAdapter
instead of directly using the interface. -
If the visitor should only be called for a certain type of input element and just continue visiting for all others the overloads defining a type filter can be used for widgets. Using this instanceof checks and type casts are often not necessary anymore.
-
There is a
org.eclipse.scout.rt.platform.util.visitor.CollectingVisitor
class to convert the items of a tree to a list. -
IFormField.visitParents takes a
java.util.function.Predicate<IFormField>
instead of an IFormFieldVisitor.
New Convenience Methods on IFormField
There are new methods for setting mandatory state (setMandatory
), status visibility (setStatusVisible
), field style (setFieldStyle
) and disabled style (setDisabledStyle
) that allow to specify if child form fields should be changed as well.
So if you have overridden one of these methods in your code, please override the new one instead. The method now takes an additional boolean flag to indicate if children should be processed as well.
Config Properties
Descriptions
Config properties based on org.eclipse.scout.rt.platform.config.IConfigProperty
include a description text. This description is stored in the new description()
method.
All properties must now implement this new method and return a description text of that property. The class org.eclipse.scout.rt.platform.config.ConfigDescriptionExporter
can be used to export these descriptions. By default an AsciiDoctor exporter is included.
Default value
Config properties based on org.eclipse.scout.rt.platform.config.IConfigProperty
include a default value. The default value is stored in the getDefaultValue()
method.
The method was moved from org.eclipse.scout.rt.platform.config.AbstractConfigProperty<DATA_TYPE, RAW_TYPE>
to the interface. Therefore the visibility has changed from protected to public.
Validation
The concreate implementation org.eclipse.scout.rt.platform.config.ConfigPropertyValidator
which validates the configuration of config.properties
files will also check if a configured value matches the default value. In case it does a info message (warn in development mode) will be logged but the platform will still start.
To minimize configuration files such entries should be removed from config.properties
files.
Renamed Config Property Keys
The following config property keys have been renamed (the old keys are no longer valid and must be renamed accordingly):
Old Key | New Key |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Customizing CSP Rules Via Config Property
The new config property scout.cspDirective
makes subclassing and replacing the ContentSecurityPolicy
class obsolete as you can configure all CSP settings with this property now. An example from the Scout Widgets application:
@Replace
public class WidgetsContentSecurityPolicy extends ContentSecurityPolicy {
@Override
protected void initDirectives() {
super.initDirectives();
// Demo app uses external images in html field and custom widgets -> allow it
withImgSrc("*");
}
}
This class was deleted and replaced by a config property in config.properties:
# CSP - Demo app uses external images in html field and custom widgets -> allow it
scout.cspDirective[img-src]=*
IUiServletRequestHandler
The methods handleGet
and handlePost
on IUiServletRequestHandler
were replaced by the single method handle
. This new method is called for all HTTP methods.
To retrieve the HTTP method, call getMethod
on HttpServletRequest
. When using AbstractUiServletRequestHandler
no migration should be required because AbstractUiServletRequestHandler
delegates to the Java methods for the common HTTP methods handleGet
, handlePost
, handlePut
and handleDelete
.
Methods proxyGet
and proxyPost
on HttpProxy
are replaced by the common method proxy
.
Table: Remove Obsolete "POPULATED" Event and Methods
We removed remnants of the long-obsolete "population" event in tables:
-
ITable.tablePopulated()
-
TableEvent.TYPE_TABLE_POPULATED
Migration: Remove any references to the removed method or event from your code. (This should not cause any change in behavior, as the event was not fired by Scout anyways.)
PageField: Status of Page Table Visible By Default
The table field contained in a PageField used to have statusVisible
set to false. This default was changed back to true to make it consistent with all other fields. Whether the status should be invisible can only be determined correctly by the programmer, because the PageField can not know about the status visibility in the inner forms (search form and search form).
Migration: To hide the status of a specific PageField's table field, override execInitField()
and set the desired status visibility:
public class MyPageField extends AbstractPageField<MyTablePage> {
@Override
protected void execInitField() {
getTableField().setStatusVisible(false); // <--
}
}
API Changes (JavaScript)
Rename of LESS Variables
If you created a custom theme, you might have to adjust some LESS variables.
-
Splitted
@group-title-padding-y
into@group-box-title-padding-top
and@group-box-title-padding-bottom
-
Splitted
@tree-node-padding
into@tree-node-padding-y
,@tree-node-padding-left
and@tree-node-padding-right
-
Renamed
@group-title-border-width
to@group-box-title-border-width
-
Renamed
@group-margin-bottom
to@group-box-body-padding-bottom
-
Renamed
@group-margin-top
to@group-box-body-padding-top
-
Added
@group-box-title-margin-top
-
Renamed
@tabbox-padding-x
to@tab-item-padding-x
-
Renamed
@tabbox-focus-arrow-width
to@tab-item-focus-arrow-width
-
Renamed
@tabbox-border-width
to@tab-area-border-width
-
Renamed
@compact-outline-node-padding-v
to@compact-outline-node-padding-y
-
Renamed
@box-margin-v
to@box-margin-y
-
Renamed
@outline-breadcrumb-node-padding-v
to@outline-breadcrumb-node-padding-y
-
Renamed
@tile-padding-h
to@tile-field-padding-x
-
Renamed
@tile-padding-v
to@tile-field-padding-y
-
Renamed
@planner-header-buttons
to@planner-header-button-height
-
Renamed
@calendar-header-buttons
to@calendar-header-button-height
-
Renamed
@logical-grid-height
to@logical-grid-row-height
-
Renamed
@applink-color
to@link-color
Widget.js: New Argument for clone()
The clone() function of any widget got an options
parameter. The options define what properties and events are synchronized between the widget and its clone.
Widget.js: addChild & removeChild changed to private
The methods addChild()
and removeChild()
have been renamed to _addChild()
and _removeChild()
. This means the methods are considered to have private
visibility now. Use the methods setParent()
, setOwner()
and destroy()
to connect or disconnect widgets. These methods will add or remove the child widget automatically.
FormField.visit renamed to FormField.visitFields
The visit()
method on all FormFields has been renamed to visitFields()
. This change is necessary to clarify what is visited and to distinguish between the visit methods available on widget level (e.g. visitChildren()
).
Tree._visitNodes & Tree.visitNodes
The argument order of the method scout.Tree.visitNodes
have changed from (nodes, func, parentNode) to (func, nodes, parentNode). So the func (the visitor) and the nodes to visit have changed positions.
The arguments of scout.Tree.prototype._visitNodes
have changed from (nodes, func, parentNode) to (func, parentNode). So the nodes to visit must no longer be specified. Instead always the root nodes of the tree are used. Furthermore the method is public now and has therefore be renamed to visitNodes()
.
Automatic Preloading of Web Fonts
Scout can now detect the Web Fonts (*.woff files) to preload automatically. It’s therefore no longer necessary to list the font names manually in the bootstrap argument of scout.App
.
Migration:
Remove the fonts
property from the bootstrap parameter object passed to the init() function of your Scout app.
For example, the default index.js file generated by the Scout "helloworld" archetype looks like this:
$(document).ready(function() {
var app = new scout.RemoteApp();
app.init({
bootstrap: {
fonts: ['scoutIcons'] // <-- this property is no longer required
}
});
});
If no other init options remain, the file can be simplified to:
$(document).ready(function() {
var app = new scout.RemoteApp();
app.init();
});
To find all files that need migration, search for the text bootstrap: { in all *.js files in your workspace. The files are called index.js by default and are usually located at your.project.ui.html/src/main/resources/WebContent/res. |
This migration is recommended but optional. Listing all fonts to preload manually still works. To disable font preloading entirely, set the fonts bootstrap property to an empty array []
.
Radio Button Group
-
The property
formFields
has been renamed tofields
to be consistent with the Java implementation and with other composites likeGroupBox
. -
The function
selectButton
now selects the button even if it is disabled. Only the user must not select disabled buttons but the developer should still be able to do it. If you use this function, you may have to insert a check for the enabled state.
Layout of fields in Radio Button Group and Sequence Box
Until now it was required to explicitly set grid positions for child fields of Radio Button Groups and Sequence Boxes. This was because the automatic grid layout was not yet implemented in the Scout JavaScript layer. This was no issue however if the fields have been used in connection with a Java model because then the Java layer takes care about the layout.
Now also pure JavaScript Scout applications have automatic layout for child fields of Radio Button Groups and Sequence Boxes. So if explicit grid positions (gridData.x, gridData.y) have been specified, it can be removed now as Scout takes care about it now (as it was in the Java layer already).
Other Changes
—
Do you want to improve this document? Have a look at the sources on GitHub. |