Search the FirstSpirit Knowledge Base
Hallo zusammen,
mich würde es interessieren wie man in einem ExecutableToolbarItem-Plugin eine Executable aus einem anderen Modul aufruft.
Anwendungsfall:
Das FS Modul WebControlling
http://www.e-spirit.com/odfs52/dokumentation/zusaetzliche-dokumentation/firstspirit-webcontrolling/
liefert 6 Beanshell Scripte mit, diese können über das Kontextmenü aufgerufen werden.
In diesen Beanshell Scripten liegt eigentlich nur der Aufruf einer Executable Klasse.
#!executable-class
WebControllingEnableEtExecutable
Ich will aber das Skript nicht über das Kontextmenü ausführen sondern dafür einen eigenen Button in der Toolbar erzeugen.
Am den SourceCode des WebControlling Moduls kann ich das ja schlecht einbauen. Deswegen würde ich ein eigenes Modul bauen mit einem JavaClientEditorialToolbarItemsPlugin als einzigstem Inhalt welches dann die in dem Beanshell Script liegende Executable anstößt.
Aber ist es so einfach wie ich mit das vorstelle?
.....
.....
/**
* Define an executable toolbar item. When this item is clicked, the method {@code execute(ToolbarContext context)} is
* called.
*/
private static class ExampleExecutableToolbarItem implements ExecutableToolbarItem {
@Override
public void execute(@NotNull final ToolbarContext context) {
EnableEtExecutable executable = new EnableEtExecutable();
executable.execute();
}
.......
.....
Eigentlich müsste ich ja noch die Klasse importieren oder nicht?
import de.espirit.pm.modules.etracker.exec.EnableEtExecutable;
Vielleicht hat jemand das oder sowas in der Art schon einmal umgesetzt und kann mir einen Tipp geben?
Danke und Grüße
Olli
Hallo Olli,
das wird so einfach nicht funktionieren, weil der ToolbarContext ein sehr viel "schmaleres" Interface ist als der GuiScriptContext und in der Hierarchie auch "daneben" liegt.
Das Executable des Moduls darf ja davon ausgehen, einen GuiScriptContext zu bekommen (eben weil es als Kontextmenüscript eingebunden bzw. dazu gedacht ist). Auf welchen ggf. in der Hierarchie höher gelegenen Kontext dort intern tatsächlich gecastet wird und welche Methoden dann auch wirklich aufgerufen werden, weiß ich nicht.
Mit einigen Umwegen (=einem GuiScriptContext, den man selber implementiert usw.) würde man es wahrscheinlich zwar hinbekommen, es wäre aber eine recht "wackelige" Geschichte, d.h. es kann passieren dass es nach dem nächsten Update schon nicht mehr geht wenn das WebControllingEnableEtExecutable geändert wird (was ja erlaubt wäre). Außer Du implementierst den GuiSciptContext wirklich komplett - wenn das überhaupt möglich ist...
Viele Grüße
Michael
Hallo Olli,
Michael hat Recht. Theoretisch kann man sich den GuiScriptContext selbst implementieren, aber ob Du in dem Kontext des ToolbarItems an alle Informationen kommst, sieht man erst, wenn man es implementiert und ausprobiert.
Was spricht eigentlich dagegen, die Logik des Executables in eine externe Klasse auszulagern und diese dann im Executable und dem ToolbarItem zu verwenden?
Man könnte diese externe Klasse in ein eigenes Jar packen und in beiden Modulen verwenden.
Übrigens, das mit dem Impotieren klappt nur dann, wenn der Java-Compiler die Klasse statisch linken kann. Das bedeutet ja, du musst die Executable irgendwie lokal als Java-Klasse vorliegen haben. Einfach so mit importieren wird das nicht klappen. Da müsste man schon so etwas (verbotenes) wie Class.forName("..."); machen...
Und schließlich müsste man strenggenommen auf Ebene der module.xml einen dependency-Tag definieren, um anzuzeigen, dass man ohne das andere Modul nicht installiert werden kann...
Aus diesem Grund: Externe Klasse und eigenes Jar is the way to go...
Grüße Marian
Hallo zusammen und Danke für eure Rückmeldung.
Meine Einschätzung ist dass das ganze dann doch zu aufwändig und teuer ist, nur das der Redakteur das ganze über ein Button ausführen kann.
@Marian, dennoch würde es mich interessieren welche "Executables" ich deiner Meinung nach in eine externe Klasse auslagern soll? Die des WebControllingExecutables? Darauf habe ich doch gar keinen Zugriff.
Grüße
Olli