Search the FirstSpirit Knowledge Base
Hallo,
gibt es eine Möglichkeit, bei einem DataAccessPlugin den Baum-Knoten zu ermitteln, in dem sich die Eingabekomponente befindet?
Konkret möchte ich eine Eingabekomponente entwickeln, die in den Metadaten bei Struktur-Ordnern eine Liste von Datasets anbietet. Das ist mir dank des DataAccessPlugin (und dem hervoragenden Techinar dazu) bereits geglückt. Allerdings besteht die Anforderung, dass die Auswahl der Datasets abhängig zum Strukturknoten sein soll.
Mit freundlichem Gruß
Thorben Hischke
Hi,
das ist leider aktuell nicht möglich. Die Kontext-Information zur Einbettung der Eingabekomponente wird bislang nicht durchgereicht.
Beste Grüße
Stefan
Guten Morgen,
vielen Dank für die prompte Antwort.
Das ist echt schade, dass würde das Plugin um einiges bereichern. Dann werde ich mal einen Feature-Request stellen, oder ist dies zufällig schon eingeplant?
Mit freundlichem Gruß
Thorben Hischke
Moin,
Nein, hier ist aktuell nichts geplant. Danke für das Erstellen eines Feature-Wunschs.
Beste Grüße
Stefan
Hallo Thorben,
Stefans Antwort stimmt - direkter Zugriff auf das "aktuelle Element" ist nicht ohne weiteres möglich.
Über einen kleinen Umweg sollte es trotzdem funktionieren wenn ich nichts übersehen habe.
Im CC besteht über den WebeditUIAgent schonmal die Möglichkeit, an die aktuelle Seitenreferenz zu kommen, da sollte es also direkt gehen.
Im SA ist es etwas schwieriger. Die Idee ist folgendermaßen:
Erstellung eines JavaClientPermanentPlugins, das in seiner setUp-Methode sowohl einen ModelListener (Modeltyp SelectionModel#EDITORIAL) als auch einen selbst zu implementierenden ClientService registriert (per ClientServiceRegistryAgent). Der ClientService wäre dabei ganz einfach gestrickt und fungiert dabei als eine Art "Clipboard", in den der ModelListener jeweils das aktuell im SA selektierte Objekt "hineinlegt". Im DAP kannst Du dann über diesen ClientService das selektierte Objekt abfragen und entspr. auswerten.
Mal ein paar entsprechende Codeschnipsel (musst Du natürlich auf die entsprechenden einzelnen Klassen aufteilen):
//PermanentPlugin - to be referenced as <public>component in module.xml
public class MySiteArchitectPermanentPlugin implements JavaClientPermanentPlugin {
@Override
public void setUp(BaseContext context) {
ClientServiceRegistryAgent clientServiceRegistryAgent = context.requestSpecialist(ClientServiceRegistryAgent.TYPE);
MyClipboardService clipboardService = new MyClipboardServiceImpl();
clientServiceRegistryAgent.registerClientService(MyClipboardService.class, clipboardService);
ModelService modelService = context.requireSpecialist(ServicesBroker.TYPE).getService(ModelService.class);
modelService.addModelListener(SelectionModel.EDITORIAL, new MySelectionModelModelListener(clipboardService));
}
}
...
class MySelectionModelModelListener implements ModelListener<SelectionModel> {
private final MyClipboardService clipboard;
public MySelectionModelModelListener(MyClipboardService clipboard) {
this.clipboard = clipboard;
}
@Override
public void modelChanged(SelectionModel selectionModel) {
clipboard.setCurrentElement(selectionModel.getElement());
}
}
}
...
//Interface for the self implemented "clipboard"
public interface MyClipboardService {
void setCurrentElement(IDProvider element);
IDProvider getCurrentElement();
}
...
// clipboard implementation
public class MyClipboardServiceImpl {
private IDProvider currentElement=null;
public void setCurrentElement(IDProvider element){
currentElement=element;
}
public IDProvider getCurrentElement(){
return currentElement;
}
}
...
//Accessing the currently selected element from other places - like DAP:
IDProvider currentElement = broker.requireSpecialist(ServicesBroker.TYPE).getService(MyClipboardService.class).getCurrentElement();
Siehe auch hier.
Um einen einheitlichen Zugriff im DAP zu haben (und dort keine Fallunterscheidung zwischen den Clients machen zu müssen), bietet sich noch eine minimale Implementierung eines WebEditPermanentPlugins an, das denselben Service registriert - allerdings mit einer sehr viel einfacheren Implementierung, die letztlich nur an den WebEditUIAgent delegiert (also ohne ModelListener usw.). Dadurch greift das DAP dann einfach immer auf den ClientService zu.
Wichtig ist, dass die beiden PermanentPlugins dann in getrennten Klassen implementiert werden, weil sonst im CC die Klassen des ModelListeners nicht gefunden werden (die dort ja auch nicht benötigt werden).
Viele Grüße
Michael
Hallo Michael,
für den aktuellen Anwendungsfall haben wir erst einmal eine FS_LIST vom Typ Database gewählt, die per FS_BUTTON vorbelegt wird, im Skript-Context erhalte ich ja das aktuelle Element. Und der Redakteur kann jederzeit selbst eine Vorbelegung anstossen, was für unseren Anwendungsfall sogar hilfreich ist.
Aber vielen Dank für den vorgeschlagenen Lösungsweg, auf den werde ich bestimmt mal zurückgreifen!
Ein schönes Wochenende!
Gruß
Thorben
Hallo zusammen,
wir haben Dein Beispiel mal bei uns integriert für den Anwendungsfall eines ValueProvider und stellen uns die Frage - Warum muss der Service als ServerService registriert werden?
Viele Grüße
Marcel
Hallo Marcel,
falls Du mein Beispiel meinst: Da ist kein ServerService im Spiel.
Viele Grüße
Michael
Hi Michael,
wenn ich in meinem ValueProvider
IDProvider currentElement = broker.requireSpecialist(ServicesBroker.TYPE).getService(MyClipboardService.class).getCurrentElement();
einfüge und diesen im CMS_INCLUDE_OPTIONS via type public anrufe, erhalte ich folgende Meldung:
de.espirit.firstspirit.access.ServiceNotFoundException: Service 'xx.yy.zz.MyClipboardService' not found
Mache ich hier was falsch?
Viele Grüße
Marcel
Hallo Marcel,
hast Du den Service im PermanentPlugin registriert? Das PermanentPlugin muss als <public>-Komponente in der module.xml stehen.
Viele Grüße
Michael