Creating Commands from Legacy Code
This notation, along with the one, described in this chapter can be used to define commands in PAK.
1. Basics
Services are often implemented by simple command implementations. The commands only inject the respective service and execute a method on it. This behaviour
is very repetitive and can be automized by using the following command notation.
The main difference between this notation and the other is that this notation turns the methods within a class
into commands and is an effective way to turn already existing legacy code into commands.
To be more specific: It turns them into CommandMetas (json-files, containing all command-specific information), while the other notation
processes a whole class and produces one command per class.
In order to process methods as commands, the class containing the methods must be marked with @JavaCommandService.
|
-
If all methods inside the given class need to be processed, then only use
@JavaCommandServiceon class-level. -
If only certain methods inside the class need to be processed. It’s required to additionally use
@JavaCommand. It must be used to annotate the specific methods and mark them as a command.
Only these methods will then be recognized as commands by the corresponding annotation processor.
Furthermore, it’s possible to inject services into the commands by using @LiteService above the attributes.
Allowing the class to be constructed as if it were in its original context.
1.1. Prerequisites
In order to use the new command notation. Make sure that the following dependencies are used within your build.gradle file:
/* Style the button that is used to open and close the collapsible content */
.collapsible {
background-color: transparent;
color: black;
cursor: pointer;
height: 30px;
width: 100%;
border: 1.5px solid black;
border-radius: 5px;
text-align: left;
outline: none;
font-size: 15px;
}
/* Add a background color to the button if it is clicked on (add the .active class with JS), and when you move the mouse over it (hover) */
.active, .collapsible:hover {
background-color: #ccc;
}
/* Style the collapsible content. Note: hidden by default */
.collapsibleDiv {
padding: 0 18px;
display: none;
overflow: hidden;
background-color: transparent;
border: 1.5px solid black;
border-top: none;
}
.collapsible:after {
content: ‚\1401‘;
font-size: 15px;
color: black;
float: right;
margin-left: 5px;
}
.active:after {
content: ‚\25B2‘;
}
pakVersion = '1.9.10'
dependencies {
[...]
annotationProcessor "de.asap.pak.jlcint:jlcint-processor:${pakVersion}"
provided "de.asap.pak.jlcint:jlcint-commandapi"
}
[...]
task metaJar(type: Jar) {
archiveClassifier = 'pakmeta'
from sourceSets.main.output
include 'meta/**'
include 'entities/**'
from sourceSets.main.java
include 'icon/**'
}2. Usage
The following two listings show how to correctly define methods in order to be converted into commands.
2.1. Processing of All Methods within the Class
If all methods within a class should be processed, the class only has to be annotated with @JavaCommandService.
@JavaCommandService (1)
public class CommandClass {
@Service (2)
private ICredentialRequester credentialRequester;
public CommandClass(final ICredentialRequester credentialRequester) {
this.credentialRequester = credentialRequester;
}
public void myCommand1(String str1, String str2) { (3)
int strLength = str1.length() + str2.length();
}
@Deprecated (4)
public int myCommand2(String myReadVariable) { (5)
return 42;
}
}| 1 | Usage of @JavaCommandService: @JavaCommandService on class-level, all methods inside the class-scope are turned into a command. |
| 2 | Service injection: The service ICredentialRequester is injected into the class, holding the means to the call the method. The injected service must not be inthe same package as the class using this service. Otherwise, GUICE can’t find the respective, and the injection fails. |
| 3 | Declaration of method: Methods must be declared as public, otherwise they will not be recognized as commands. |
| 4 | Deprecation of commands: Commands can be deprecated by annotating the corresponding method with @Deprecated. |
| 5 | Marking of read/ write-variables: In contrast to myCommand1, this method/ command (myCommand2) has a return-type,meaning it has a WRITE variable and one READ variable ( myReadVariable). While myCommand1 has two variables: str1(scope: READ) and str2(scope: READ). It’s important to keep in mind, that if a method has the return-type void,the command must not have any WRITE variables. |
Listing 2 produces two commands (myCommand1, myCommand2).
2.2. Processing of certain Methods within the Class
If only a certain selection of methods needs to be processed or if the user wishes to further configure his/her command, it’s required to mark those methods with @JavaCommand.
@JavaCommandService (1)
public class CommandClass {
@LiteService (2)
private ICommandRestService restService;
public CommandClass(final ICommandRestService restService) {
this.restService = restService;
}
/**
* This is the workflowDocumentation for my command
*
* @param myReadVariable Actual docu of my variable (3)
* @param noReadVariable This is the documentation for noReadVariable
* @return This is the workflowDocumentation for my write-Variable (myCommandResult)
*/ (4)
@Persistent(mandatory = false) (5)
@JavaCommand
@CommandGroup("myCommandGroup") (6)
public String myCommand(@Persistent(mandatory = false) String myReadVariable, String noReadVariable) {
return "hello";
}
/**
* Simple dummy method, not a command
*
* @param number some dummy parameter
*/
public int retNum(int number) {
return number;
}
}| 1 | Usage of @JavaCommandService: @JavaCommandService on class-level, in contrast to Listing 2 only the methods, which will be turned into commands are marked with @JavaCommand. |
| 2 | Service injection: The lite-service ICommandRestService is injected into the class, holding the means to call the method. The injected service must not be inthe same package as the class using this service. Otherwise, GUICE can’t find the respective service, and the injection fails. |
| 3 | Variable documentation: The text after the @param tag in the JavaDoc-block represents the documentation for the corresponding variable. |
| 4 | Workflow documentation: The workflow documentation for the command and/or variables can be fetched from the JavaDoc-block. The method-documentation is the workflowDocumentation for the whole command, while @param describes the docu for the READ variables and @return for the WRITE variables. |
| 5 | Marking of read/ write-variables: If @Persistent is above the method-body, variables with the scope WRITE are defined. @Persistent must be used within themethod parameters (only when @JavaCommand is used) in order to mark variables with scope READ(myReadVariable). Both READ and WRITE variables can also be not mandatory (as shown above). Method-parameters, which are not annotated with @Persistent will not berecognized as any command-relevant variables and do not have a scope (only when @JavaCommand is used). Furthermore, it does not matter if the parameters/ methods are declared as final or not. They will be recognized as READ or WRITE variables either way. |
| 6 | Grouping of Commands: It’s possible to group those commands, by using @CommandGroup. If @CommandGroup is missing, the name of the package is chosen as the command-group. |
Listing 3 produces only one command (myCommand).
The command-notation from above corresponds to the following CommandMeta:
{
"deprecated": false,
"group": "myCommandGroup",
"id": "stimuli.pkg5.CommandClass#myCommandByStringAndString",
"increment": 0,
"interpreter": "de.asap.pak.jlcint.pakbridge.JavaServiceInterpreter",
"liteServices": [
{
"id": "de.asap.pak.core.services.api.ICommandRestServices",
"key": "restService",
"name": "ICommandRestService"
}
],
"major": 2,
"mappings": [
{
"documentation": "Actual docu of my variable",
"isAllowedValuesSuggestion": false,
"key": "myReadVariable",
"mandatory": false,
"scope": "READ",
"type": "STRING"
},
{
"documentation": "This is the workflowDocumentation for my write-Variable (myCommandResult)",
"isAllowedValuesSuggestion": false,
"key": "myCommandResult", (1)
"mandatory": false,
"scope": "WRITE",
"type": "STRING"
}
],
"minor": 1,
"name": "myCommand",
"properties": {
"methodParameters": [
{
"dataType": "java.lang.String",
"mandatory": false,
"order": 0,
"parameterName": "myReadVariable",
"persistent": true
},
{
"dataType": "java.lang.String",
"mandatory": true,
"order": 1,
"parameterName": "noReadVariable",
"persistent": false
}
],
"methodName": "editDescription"
},
[...]
}| 1 | The name of the WRITE Variable gets constructed by taking the name of the method and adding the string Result. |
2.3. Overloading of Methods
It’s also possible to overload methods (commands). These commands can be distinguished
by the names as well as the types of the READ parameters of the command. The id of those commands
gets constructed by concatenating the READ parameter-types with the name of the method. While the name gets
constructed by concatenating the READ parameter-names with the name of the method. In order for the concatenation to look
prettier the keywords And and By are used between the different parameter-types.
@JavaCommandService
public class CommandClass {
[...]
public String myCommand(int myIntReadVariable, String myStringReadVariable) { (1)
return "hello";
}
public int myCommand(String myReadVariable) { (2)
return 42;
}
}| 1 | The name of this command: myCommandByIntAndString. The id of this command: CommandClass#myCommandByIntAndString. |
| 2 | The name of this command: myCommandByString. The id of this command: CommandClass#myCommandByString. |