Eine neue Version der Dataflow Workbench dWb+ ist verfügbar! Nach der an dieser Stelle bereits veröffentlichten Ankündigung einer größeren Überarbeitung ist das dort bereits erwähnte neue Feature nunmehr fertig gestellt.

Das System dWb+ erlaubt die Verbindung zwischen Aus- und Eingängen nur dann, wenn der Ausgang Botschaften eines Typs erzeugt, die der jeweilige Eingang verarbeiten kann. Dabei müssen die Typen von Aus- und Eingang nicht exakt aufeinander passen - das lässt sich vielleicht am besten an einem Beispiel erläutern: Ein Ausgang, der ganze Zahlen erzeugt, kann mit einem Eingang verbunden werden, der Zahlen entgegennimmt, da auch ganze Zahlen Zahlen sind. Umgekehrt ist es aber nicht möglich, einen Ausgang, der Zahlen erzeugt mit einem Eingang zu verbinden, der nur ganze Zahlen erwartet. Denn die Ausgangsspezifikation allgemeiner Zahlen könnte auch gebrochene Zahlen einschließen, mit denen der Eingang aber nicht umgehen könnte.

Seit Version 4.3pre1 ist es möglich, Ein- und Ausgänge, deren Typen eigentlich nicht zueinander passen dennoch zu verbinden: Hält man während des Drag'n'Drop die Taste Strg gedrückt, ist die im vorhergehenden Absatz beschriebene Validierung zueinander passender Datentypen von Ein- und Ausgängen außer Kraft gesetzt: Wenn nach Loslassen der Maustaste festgestellt wird, dass die beiden verbundenen Slots nicht zueinander passen, wird zwischen beiden autimatisch ein Konvertermodul in die neue Verbindung eingefügt. Es öffnet sich sofort das Parameterfenster dieses Moduls, in dem der Anwender mittels BeanShell die Konversion des Datenobjekts aus dem Ausgang in ein für den Eingang passendes Objekt spezifizieren kann. Dabei gelten die folgenden Konventionen: In dem BeanShell-Fragment sind zwei Variablen mit besonderen Bedeutungen reserviert: _input hält den vom Quellmodul über den Ausgang versendeten Wert und der am Ende der Ausführung des BeanShell-Fragments in _output gespeicherte Wert wird an den Eingang des Zielmoduls gesendet. Der _input wird ungefiltert in das BeanShell-Fragment übergeben - daher ist es angeraten, null explizit zu behandeln! Um die Arbeit einfacher zu gestalten ist es möglich, für Paare von Datentypen Default-Konversionen zu hinterlegen, die dann automatisch im Editor des Parameterfensters als Vorbelegung auftauchen. Das folgende Beispiel zeigt eine solche Datei:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Default conversion rules for automatically
inserted BeanShellConversionModules</comment>
<entry key="java.lang.Boolean::java.lang.Number">
_output_=_input_!=null?(_input_.booleanValue()?1:0):null;
</entry>
<entry
key="de.netsysit.dataflowframework.modules.common.ClockTypes::java.lang.Number">
_output_=null;
if(_input_!=null)
{
switch(_input_)
{
case CLOCK: _output_=1;break;
case POSITIVE_SPKIE: _output_=2;break;
case NEGATIVE_SPKIE: _output_=3;break;
default: _output_=0;
}
}
</entry>
<entry key="java.lang.Number::java.util.Date">
_output_=_input_!=null?new java.util.Date(_input_.longValue()):null;
</entry>
<entry key="java.lang.Integer::java.util.Calendar">_output_=null;
if(_input_!=null)
{
_output_ = Calendar.getInstance();
_output_.setTimeInMillis(_input_.longValue());
}</entry>
</properties>

Wichtig ist hierbei noch zu erwähnen, dass die Schlüssel aus dem voll qualifizierten Namen der Klassentypen des Aus- und des Eingangs verbunden durch "::" gebildet werden. Der Schlüssel muss nicht genau passen - beim Typen des Ausgangs besteht Spielraum - es wäre etwa möglich, eine Konversion für den Ausgangstypen java.lang.Number zu spezifizieren - diese würde (sofern der Typ des Eingangs passt) auch dann benutzt, wenn der Ausgangstyp java.lang.Integer ist, es aber für diesen und den jeweiligen Ausgangstyp keine explizite Konversion gibt. In der oben angegebenen Konfiguration wäre die Konversion unter dem Schlüssel java.lang.Number::java.util.Date ein Beispiel dafür.

Natürlich wurde das Handbuch entsprechend erweitert und angepasst.