@ this elements contains all actions available in the add-on package. The complete structure of this second part is displayed below.
[...]
123
org.openecard.addon.openecarddummyaddon.DummyAddonStep
true
Test-ExtensionAction
Test extension action
Testbeschreibung
test description
Foo
bar
Test-ConfigurationEntry
Test configuration entry
Testbeschreibung
test description
FileEntry1
false
jpg;mp4;mp3;p12
File Entry
Test file entry description
FileListEntry1
false
jpg;mp4;mp3;p12
File list Entry
Test file list entry description
ScalarEntryBool
BOOLEAN
Scalar Bool
Scalar Bool description
ScalarEntryString
STRING
Scalar String
Scalar String description
ScalarEntryBigdecimal
BIGDECIMAL
Scalar BigDecimal
Scalar BigDecimal description
ScalarEntryBigInteger
BIGINTEGER
ScalarBigInteger
Scalar BigInteger description
ScalarListEntryBigInteger
BIGINTEGER
ScalarListBigInteger
Scalar List BigInteger description
ScalarListEntryBigDecimalr
BIGDECIMAL
ScalarListBigDecimal
Scalar List BigDecimal description
ScalarListEntryString
STRING
ScalarListStringl
Scalar List String description
h3. Types available in the configuration
h3. Configuration of an Add-on in the client
h2. Add-on Implementation
h3. IFD protocol implementation details
This section describes the add-on system from the perspective of a developer.
The implementation of the add-on system is located in the maven module with the group Id *org.openecard* and the artifact Id *addon*.
All classes are in a sub namespace of *org.openecard.addon*. The module is divided into the following five packages:
* *org.openecard.addon*
In this package are the main classes of the add-on system, for example the AddonManager or the different AddonRegistries.
* *org.openecard.addon.bind*
This package includes all classes representing the interface between an addon and a specific binding. That is to say, here are the classes needed to convert a specific request, for example a HTTP request that arrives via the localhost binding, into a generic request, which is independent from binding and vice versa for the response.
* *org.openecard.addon.ifd*
In here are the classes that specify the interface for an IFD protocol and the factory to instantiate such a protocol.
* *org.openecard.addon.manifest*
This package accumulates all classes needed to convert (automatically) between the XML represantation of the add-on description and it's java object pendants.
* *org.openecard.addon.sal*
In here are the classes that specify the interface for an SAL protocol and the factory to instantiate such a protocol.
h1. Types of add-ons
In the context of Open eCard App, the terms add-on, plug-in and extension are defined as follows.
Add-on is the generic term for a component that enhances the functionality of the Open eCard App.
Extensions are independent from the context. Moreover, they are included directly into
the user interface and can be executed by the user. For instance, an add-on that provides a
PIN change functionality for smart cards is classified as an extension.
Plug-ins depend on the context in which the user uses the application. Performing
an authentication to a service using a particular smart card, for instance, requires a plug-in
which is capable of providing such functionality. Subsequently, plug-ins require a communication
with bindings to interact with external applications and services. Furthermore,
we distinguish between IFD, SAL, and application plug-ins.
h1. Add-on development
This section describes the steps to take when developing an add-on.
As first step a new XML file called *Addon.xml* in the *META-INF* directory of the project should be created and the fields that describe the general part of the add-ons can already be filled.
An example file for a PIN Management addon could look like this:
PIN-Plugin
1.0
PIN Verwaltung
Verwaltung von PIN/ PUK und gegebenenfalls anderen Geheimnissen der Chipkarte.
PIN Management
Management of PIN/ PUK and possibly other secrets of the smart-card.
images/logo.png
As can be seen, some fields can be localized. That fields are: *LocalizedName*, *LocalizedDescription* and *About*
The next step is to think about what actions should be offerd by the add-on and of what type these actions are.
For the PIN management example there are two actions. An action to change a PIN and a second action to unblock a PIN.
These actions are not of type *ProtocolPlugin* nor *AppPluginAction*, but of type *AppExtensionAction*, as they expand the function of the Open eCard App independent from a context.
This means two classes implementing the *AppExtensionAction* interface need to be added to the project and the two AppExtensionActionDescription that belong to them need to be added to the XML description.
Assume we are working in the org.openecard.plugins.pinplugin namespace and the two actions are called ChangePINAction and UnblockPINAction, the resulting XML would now look similar to this:
PIN-Plugin
1.0
PIN Verwaltung
Verwaltung von PIN/ PUK und gegebenenfalls anderen Geheimnissen der Chipkarte.
PIN Management
Management of PIN/ PUK and possibly other secrets of the smart-card.
images/pin-management.png
ChangePINAction
org.openecard.plugins.pinplugin.ChangePINAction
PIN ändern
Mit dieser Aktion können Sie ihre PIN ändern.
Change PIN
With this action you can change your PIN.
UnblockPINAction
org.openecard.plugins.pinplugin.UnblockPINAction
PIN entsperren
Mit dieser Aktion können Sie ihre PIN entsperren.
Unblock PIN
With this action you can unblock your PIN.
For the actual implementation part of the add-on, the following has to be considered.
The actions need to implement the AppExtensionAction interface, which itself extends the FactoryBaseType interface.
Altogether, three functions are to be implemented:
* void execute();
the actual logic of the action, in this case the PIN change, will take place here
* void init(Context context) throws FactoryInitializationException;
initialization of the action; the given Context allows access to components of the Open eCard App like UserConsent or Dispatcher
* void destroy();
closing resources and further cleanup.