|
|
| (11 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| − | {{ScoutPage|cat=Concepts}}
| + | Moved to Scout documentation at https://eclipsescout.github.io/scout-docs/23.2/technical-guide/user-interface/extensibility.html |
| − | | + | |
| − | == Overview ==
| + | |
| − | {{important|Required version|The API described here requires version 4.2 or newer.}}
| + | |
| − | | + | |
| − | Since December 2014 and Scout 4.2 or newer a new extensibility concept is available for Scout. This article explains the new features and gives some examples how to use them.
| + | |
| − | | + | |
| − | When working with large business applications it is often required to split the application into several modules. Some of those modules may be very basic and can be reused in multiple applications. For those it makes sense to provide them as binary library. But what if you have created great {{ScoutLink|Concepts|Template}}s for
| + | |
| − | your applications but in one special case you want to include one more column in a table or want to execute some other code when a pre-defined context menu is pressed? You cannot just modify the code because it is a general library used everywhere. This is where the new extensibility concept helps.
| + | |
| − | | + | |
| − | To achieve this two no elements have been introduced:
| + | |
| − | * Extension Classes: Contains modifications for a target class. Modifications can be new elements or changed behavior of existing elements.
| + | |
| − | * Extension Registry: Service holding all Extensions that should be active in the application.
| + | |
| − | | + | |
| − | == Extensions - Changing behavior ==
| + | |
| − | | + | |
| − | Extensions contain modifications to a target class. This target class must be extensible. All elements that implement <code>org.eclipse.scout.rt.shared.extension.IExtensibleObject</code> are extensible.
| + | |
| − | And for all extensible elements there exists a corresponding abstract extension class.
| + | |
| − | | + | |
| − | Examples:
| + | |
| − | * <code>AbstractStringField</code> is extensible. Therefore there is a class <code>AbstractStringFieldExtension</code>.
| + | |
| − | * <code>AbstractCodeType</code> is extensible. Therefore there is a class <code>AbstractCodeTypeExtension</code>.
| + | |
| − | | + | |
| − | Target classes can be all that are <code>instanceof</code> those extensible elements.This means an <code>AbstractStringFieldExtension</code> can be applied to <code>AbstractStringField</code> and all child classes.
| + | |
| − | | + | |
| − | Extensions contain methods for all Scout Operations ({{ScoutLink|Concepts|Exec_Methods}}). Those methods have the same signature except that they have one more input parameter.
| + | |
| − | This method allows you to intercept the given Scout Operation and execute your own code even though the declaring class exists in a binary library. It is then your decision if you call the original code or completely replace it.
| + | |
| − | To achieve this the [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain Pattern] is used: All extensions for a target class are called as part of a chain. The order is given by the order in which the extensions are registered. And the original method of the Scout element is an extension as well.
| + | |
| − | | + | |
| − | [[Image:Scout.extensibility.chain.concept.png|600px]]
| + | |
| − | | + | |
| − | The following example changes the initial value of a {{ScoutLink|Concepts|StringField}} called <code>NameField</code>:
| + | |
| − | | + | |
| − | <source lang="java">
| + | |
| − | // extension to intercept e.g. execInitField()
| + | |
| − | public class NameFieldExtension extends AbstractStringFieldExtension<NameField> {
| + | |
| − | | + | |
| − | public NameFieldExtension(NameField owner) {
| + | |
| − | super(owner);
| + | |
| − | }
| + | |
| − | | + | |
| − | @Override
| + | |
| − | public void execInitField(ExecInitChain chain) {
| + | |
| − | chain.execInitField(); // call the original exec init. whatever it may do.
| + | |
| − | getOwner().setValue("FirstName LastName"); // overwrite the initial value of the name field
| + | |
| − | }
| + | |
| − | }
| + | |
| − | | + | |
| − | | + | |
| − | // register extension so that it becomes active
| + | |
| − | SERVICES.getService(IExtensionRegistry.class).register(NameFieldExtension.class);
| + | |
| − | | + | |
| − | </source >
| + | |
| − | | + | |
| − | The extension registration can be done e.g. in the Activator of your plugin or in the startup of your Application.
| + | |
| − | | + | |
| − | == Contributions - Add new elements ==
| + | |
| − | | + | |
| − | The section before explained how to modify the behavior of existing Scout elements. This section will describe how to contribute new elements into existing containers.
| + | |
| − | | + | |
| − | This is done by using the same mechanism as before. It is required to create an Extension too. But instead of overwriting any Scout Operation we directly define the new elements within the Extension. A lot of new elements can be added this way: {{ScoutLink|Concepts|Field}}s, {{ScoutLink|Concepts|Menu}}s, {{ScoutLink|Concepts|Column}}s, {{ScoutLink|Concepts|Code}}s, ...
| + | |
| − | | + | |
| − | Some new elements may also require a new [http://en.wikipedia.org/wiki/Data_transfer_object DTO] ({{ScoutLink|Concepts|FormData}}, {{ScoutLink|Concepts|TablePageData}}, {{ScoutLink|Concepts|TableData}}) to be filled with data from the server.
| + | |
| − | | + | |
| − | == Move elements ==
| + | |
| − | | + | |
| − | == Migration ==
| + | |
