Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Scout/NewAndNoteworthy/3.9"
(→Support for Scout Mobile UI) |
(→New SDK Features) |
||
Line 77: | Line 77: | ||
== New SDK Features == | == New SDK Features == | ||
+ | |||
+ | === Scout Explorer Changes === | ||
+ | |||
+ | [https://bugs.eclipse.org/bugs/show_bug.cgi?id=394132 Bug 394132] | ||
+ | |||
+ | |||
=== Support for Scout Mobile UI === | === Support for Scout Mobile UI === | ||
Line 149: | Line 155: | ||
We have changed the sorting and presentation of the NLS proposal field so that the list behaves more intuitive and that it is more clear why a match is included in the list. This includes separation of the matches depending on type and sorting according to relevance. | We have changed the sorting and presentation of the NLS proposal field so that the list behaves more intuitive and that it is more clear why a match is included in the list. This includes separation of the matches depending on type and sorting according to relevance. | ||
− | [[Image:Org.eclipse.scout.3.9.newAndNote6.png|700px|NLS Field Changes]] | + | [[Image:Org.eclipse.scout.3.9.newAndNote6.png|700px|NLS Field Changes]] |
== Bugfixes == | == Bugfixes == |
Revision as of 04:44, 18 March 2013
This page shows what you need to know about the new Eclipse Scout 3.9 release shipped with Eclipse Kepler.
General
Scout Sources moved to GIT
For Kepler, Scout has moved to GIT: http://git.eclipse.org/c/scout/.
For more information see Getting_the_Scout_Sources.
Scout EPP Changes
Egit features added to EPP
CVS features removed from EPP. If CVS is needed, it has to be installed manually.
New Runtime Features
Form Field Filter for FormData Import
Besides a IPropertyFilter the FormData import (method importFormData() in AbstractForm) now also allows to specify a IFormFieldFilter. With this overload it is now not only possible to influence which properties that are imported, but also which form fields that should be filled. A default implementation is available that allows to exclude some fields from the import (org.eclipse.scout.rt.client.ui.form.fields.ExcludeFormFieldFilter).
Multiple Swing Scout features in a single Eclipse application
The extension point org.eclipse.scout.rt.ui.swing.appextensions allows running multiple swing Scout features in a single Eclipse application.
Example: Create multiple applications extensions (e.g.):
public class App1 extends AbstractSwingApplicationExtension { public App1() { super("App1"); } @Override protected IClientSession createClientSession(UserAgent userAgent) { IClientSessionRegistryService service = SERVICES.getService(IClientSessionRegistryService.class); return service.newClientSession(ClientSession.class, userAgent); } @Override protected ISwingEnvironment createEnvironment() { return new SwingEnvironment(); } }
Register ExtensibleSwingApplication as application and the previously created applications extensions
<?xml version="1.0" encoding="UTF-8"?> <plugin> <extension id="app" name="Application" point="org.eclipse.core.runtime.applications"> <application> <run class="org.eclipse.scout.rt.ui.swing.ExtensibleSwingApplication"/> </application> </extension> ... <extension point="org.eclipse.scout.rt.ui.swing.appextensions"> <swingApplicationExtension class="test.helloworld.ui.swing.App1" ranking="1"> </swingApplicationExtension> </extension> ...
SWT: Visual Marker in editable cell
Bug 395673 A marker icon is now displayed in an editable cell in an SWT table (similar to the swing table).
The icon can be changed by setting the extension org.eclipse.scout.rt.ui.swt.scouticons for the cell_editable icon.
New SDK Features
Scout Explorer Changes
Support for Scout Mobile UI
Bug 394127 and Bug 378151
Scout 3.9 comes with an enhanced web user interface (RAP) that is optimized for smartphone (mobile) and tablet devices.
By creating a new Scout Project using the Scout SDK you automatically get the mobile support when choosing to create a RAP user interface bundle. In the default setup you get four servlets prepared:
- web for normal personal computers or laptops
- mobile for smartphone devices
- tablet for tablet devices
- root entrypoint for all browsers that will autodetect your device and dispatch to the best of the servlets above.
Furthermore you get a client.mobile bundle prepared that includes all modifications to your client that should apply to mobile and tablet devices only (e.g. if you want to hide or replace some features).
Default Super Classes are Customizable
Bug 395006 and Bug 397268
In Scout 3.8 when creating a new object using a wizard you already have the possibility to choose from a list of possible super classes. But the super class selected by default is always the same. So if you e.g. have defined a project specific template for forms called 'AbstractMyProjectForm' you always have to remember to change the selected super class when creating forms.
With Scout 3.9 you now have the possibility to configure the super classes that should be used by default for each Scout project independently: Go to Window -> Preferences -> Scout -> Default Super Classes. There you can specify the default super class to use for each object type and Scout project.
This configuration is also considered if you don't explicitly have the possibility to choose a super class in the wizards: E.g. when creating a new Form by default there are also 'Cancel' and 'OK' buttons created. If you now modify the default super class for OK buttons, this is automatically used by the new Form wizard as well.
This mechanism also respects the new extensible Scout objects defined in 'org.eclipse.scout.rt.extension.client': If your project has this dependency, the Scout SDK prefers those objects over the standard ones (unless you have modified the defaults).
The settings are stored in the project preferences so that you can share them with your team using e.g. a team provider like SVN, CVS or Git.
Variable Local RAP Target Location
If you are using a local RAP target (instead of a P2 update site) you may want to share your target definition with other developers using a team provider like SVN, CVS or Git. But there may be differences in the local path pointing to the RAP target (because you have a different setup or operating system). Or you may not yet have a local RAP target at all. This makes it hard to use a target definition in a team.
In Scout 3.9 you now have a new Eclipse environment variable called 'scout_rap_target'. So instead of using the local path directly in the target definition you can use the ${scout_rap_target} variable as a palceholder and each developer can then point this variable to the path where to find the plugins locally. The value of the 'scout_rap_target' variable is stored in the workspace and can therefore be different for each instance.
The Scout SDK also detects if you are using (or importing) a target definition containing this variable. And if you have not yet defined a location for the variable will ask you to define one or create a new RAP target location.
More Flexible Project Structure
In Scout 3.9 the SDK does no longer rely on a specific package structure.
This affects the Scout Explorer which now searches for objects in a whole plugin instead of specific packages. As a consequence the folder 'Process Services' and 'Outline Services' have been merged to a general 'Services' node containing all services except lookup and the common ones. This gives you more flexibility in usage and design of your services.
Furthermore you have the possibility to specify the target package when creating new Scout objects using the Scout SDK Wizards. The packages where new objects are created by default can be configured using the preference page: Window -> Preferences -> Scout -> Default Packages.
These settings are stored in the Scout project preferences and can therefore be shared using a team provider like SVN, CVS or Git.
Improvements for the NLS Field
We have changed the sorting and presentation of the NLS proposal field so that the list behaves more intuitive and that it is more clear why a match is included in the list. This includes separation of the matches depending on type and sorting according to relevance.
Bugfixes
The following list shows all bugs which have been fixed for this release. The list also contains all new enhancements.
Migration Guidelines
Some features and bugfixes sometimes require a change of the api. If this has been the case for the new release then you'll find behind the link below a guideline how to migrate your scout application to the newest release.
The Scout documentation has been moved to https://eclipsescout.github.io/.