universelle Komponente selbst implementieren

[Michael Hönnig]

In Layouts kann man ja „universelle Komponenten“ einfügen und eine spezielle Typklasse angeben.

Auf diese Weise kann man auch eigene UI-Komponenten implementieren. Dies habe ich erfolgreich gemacht. Noch liegt diese Komponente aber in einer Nuclos Entwicklungsumgebung.

Gibt es einen vorgesehenen Weg, wie solche Komponenten extern entwickelt werden können? Das zu implementierende interface org.nuclos.client.ui.collect.component.CollectableComponent liegt ja nicht in der offizielen API.

Danke für Tipps!
… Michael

[Frank Pavlic]

Hallo Michael,
die APi enthält ein Interface org.nuclos.api.ui.layout.LayoutComponent. Wenn ich den nuclos-Quellcode nicht komplett missverstanden habe, müsste dies der Einstiegspunkt sein.

Gruß
Frank

[Michael Hönnig]

Hallo allerseits,

ich bin nun endlich dabei, meine in Nuclos entwickelte Komponente auf org.nuclos.api.ui.layout.LayoutComponent umzustellen. Dazu habe ich zunächst die Nuclos test-extension gebaut und installiert. Die Anleitung passt leider nicht mehr und die Test-Komponente auch wohl nicht. Ein Konstruktor ohne Parameter reicht wohl nicht mehr, der wurde also ergänzt.

Aber es scheint noch mehr falsch zu sein, denn als nächstes will Nuclos die Komponente auf ein internes Interface casten:

java.lang.ClassCastException: extension.test.TestLayoutComponentExtension cannot be cast to org.nuclos.client.ui.collect.component.CollectableComponent
at org.nuclos.client.ui.collect.component.DefaultCollectableComponentFactory.newCollectableComponent(DefaultCollectableComponentFactory.java:80)

Oder gibt es irgendwo eine aktualisierte test-extension, die zu Nuclos 4.3 passt?

Oder werden org.nuclos.api.ui.layout.LayoutComponent anders als über die Typklasse in Layouts integriert?

Grüße
… Michael

[Michael Hönnig]

Zum Protokoll aus Telefonsupport: Diese LayoutComponent Implementierungen sollten direkt in der UI-Komponenten-Liste erscheinen (vorausgesetzt sie sind richtig annotiert), „Komponentenklasse“ wird dabei also nicht benötigt. Kann’s leider erst in ein paar Stunden ausprobieren.

[Michael Hönnig]

Super, die Komponente ist auswählbar. Doch nun bin ich auf der Suche danach, wie man diese
1. auf ein Feld der Entität binden kann
2. an die Entität bzw. das Feld herankommt

Angeblich (Workshop) funktioniert letzteres über die LayoutComponentListener Events. Dort bekommt man aber nur eine Object-Id, obwohl der Aufruf-Kontext auch die ganze Entität hat, wie ich im Debugger sehe. Und eine API zum Holen der Entität über die Object-Id finde ich im Client auch nicht.

Langsam frage ich mich, ob überhaupt schon einmal jemand erfolgreich eine eigene UI Komponente für Entitäten-Feld-Bearbeitung implementiert hat.

Grüße
… Michael

[Frank Pavlic]

Hallo Michael,
vielleicht wäre es sinnvoll, wenn Du deine extension-Entwicklung posten könntest, dann kann man konkret nachschauen. So gestaltet sich das Helfen etwas schwierig 🙁

Gruß
Frank

[Michael Hönnig]

Das ist bisher nur die test-extension, nur mit Versions-Anpassung auf nuclos 4.3 in der pom.xml. Leider ist das ein sehr leerer Rahmen, der nicht einmal einen Zugriff auf die zu bearbeitende Entität, bzw. dessen Feld aufzeigt – und genau für diesen Schritt finde ich auch keine Doku.

Grüße
… Michael

[Thomas Pasch]

Hallo,

prinzipiell gibt es in Nuclos 2 verschiedene Möglichkeiten, eigene GUI Komponenten einzubinden:

• Als Universelle Komponente (ab jetzt UK), die org.nuclos.client.ui.collect.component.CollectableComponent implementiert (oder von org.nuclos.client.ui.collect.component.AbstractCollectableComponent o.ä. ableitet) oder
• als (custom) layout component (ab jetzt LK), die org.nuclos.api.ui.layout.LayoutComponent implementiert.

Die UKs sind direkt an ein Feld des BOs gebunden, auf dessen Layout sie verwendet werden. Im Wiki gibt es ein paar mehr Informationen.

Die LKs sind dagegen von dem BO, das dem Layout zugrunde liegt, weitgehend unabhängig. Daher muss man hier sehr weitgehend alles selber machen. Zur Zeit ist es nicht möglich, mehr als ein LK pro Layout zu verwenden. Oft ersetzt ein LK das gesamte Layout, d.h. es wird nicht zusammen mit Komponenten aus dem Layouteditor verwendet. Leider sind LK im Wiki z.Z. nicht beschrieben. Ferner ist es recht schwierig, eine LK für Datenänderungen zu verwenden und unmöglich, sie im Multiedit Modus vernüpftig zu benutzen. Eine reine Darstellung (View) ist jedoch möglich und sogar recht einfach.

Beiden Komponenten ist gemein, dass man sich im Code von Nuclos Core recht gut auskennen muss, um erfolgreich eine neue Komponente zu erstellen. Normalerweise werden UKs und LKs im Rahmen einer Extension zur Verfügung gestellt. Die LK erweckt vielleicht den Eindruck, man könnte dies im Rahmen einer Regelerstellung bewerkstelligen, da LayoutComponent Teil der (Regel-)API ist. Dieser Eindruck ist jedoch falsch.

Beide Komponenten können über den Layouteditor benutzt werden, UK werden jedoch nicht ‚richtig‘ angezeigt (es erscheint lediglich ein Platzhalter). LK können ‚richtig‘ angezeigt werden, dies benötigt aber zusätzlichen Aufwand. Meiner Erfahrung nach ist dieser nicht gerechtfertigt, da LKs meist für dynamische Teile des GUI verwendet werden – im Layouteditor lässt sich daher höchstens ‚beispielhaft‘ etwas darstellen.

Gruß,
aanno

[Frank Pavlic]

Hallo Michael,
bist Du weitergekommen? Falls nicht, sag Bescheid, ich habe mich mit dem Thema mal am Wochenende befasst und habe eine Beispiel-Komponente umgesetzt sowie eine universelle Komponentenklasse implementiert. Mehr als ein showMessageDialog tun beide nicht, aber es funktioniert 😛

Gruß
Frank

[Michael Hönnig]

Danke allerseits. Meine Komponente funktioniert nun als universelle Komponente.

Was noch fehlt, ist der Zugriff auf die umgebende Entitäten-Hierarchie. Bei einer der Komponenten muss ein Dateipfad abhängig von Art der umgebenden Entitätenhierarchie und z.B. deren fachlichem Schlüssel festgelegt werden. Leider kommt man maximal an die Object-ID heran, obwohl der Kontext die Entität ja geladen hat.

Zumindest die erste Stufe (also die Entitäteninstanz in der das Feld liegt, auf die die Komponente gebunden ist) wird wohl benötigt, denn wenn man sie aus der Datenbank liest, könnte der Stand schon wieder veraltet sein.

Dafür habe ich leider noch keine API gefunden.

Grüße
… Michael

[Franz Holzer]

[quote=“f.pavlic“ post=7135]Hallo Michael,
bist Du weitergekommen? Falls nicht, sag Bescheid, ich habe mich mit dem Thema mal am Wochenende befasst und habe eine Beispiel-Komponente umgesetzt sowie eine universelle Komponentenklasse implementiert. Mehr als ein showMessageDialog tun beide nicht, aber es funktioniert 😛

Gruß
Frank[/quote]

Schaffst du das als Beispiel fürs Wiki ?
oder anderwertig als Doku ?
(gerne auch hier)

ich kann den Part mit dem Wiki gern danach übernehmen.

lg

[Frank Pavlic]

Hi,
ich bin gerade dabei, ein sinnvolles Beispiel zu implementieren,welches ich dann auch gerne hier im Forum zur freien Verfügung stellen werde. Ich hoffe, bis in zwei Wochen alles fertig zu haben. Ich melde mich dann auf jeden Fall.
Noch ein wenig Geduld.

Gruß
Frank

[Michael Hönnig]

Ich bin gespannt und vorab einem Stichwort (Klasse/Methode) nicht abgeneigt, wie man von der Komponente an die Entität herankommt 😉

[Thomas Hempel]

Hallo Frank,

wir hätten an der Lösung auch Interesse.. Gibt es schon was zu sehen?

Gruß
Thomas

[Frank Pavlic]

Hallo,
die angekündigten zwei Wochen sind nun vorbei :whistle: …
Ich habe eine kleine Layout-Komponente als Extension implementiert, welche ich hier als zip Datei zur Verfügung stelle. Die Zip enthält zwei Java-Dateien, BrowseButton.java und BrowseButtonFactory.java sowie 3 Screenshots. Diese beiden Dateien kopiert Ihr bitte in den client-Teil eures mvn-Extensionbaumes, z.B. test-extension-client/src/main/java/de/evice/extension/client und denkt dabei an die Anpassung des Package-Names in der jeweiligen ersten Zeile einer jeden java-Datei.
Was macht das Teil?
Nach dem Bauen und Einspielen der extension-jar wird im Layout-Editor eine neue Layout-Komponente sichtbar „BrowseButton“ (browsebutton-lk.png).
Es ist ein Button, welcher bisher nur den Pfad, welcher in einem Feld „ordnerpfad“ hinterlegt ist, im Datei-Explorer öffnet (Screenshot browsebutton-beispieleinsatz.png). Wenn bspw. ordnerpfad „C:temp“ enthält, so wird beim Klick auf den Button der Ordner c:temp im Datei-Explorer geöffnet. Konfiguriert wird das Ganze wie im Screenshot „browsebutton-eigenschaften.png“. ordnerpfad ist einfach nur ein Feld, was ich im BO-Wizard erstellt habe. Hier tragt ihr einfach das Feld ein,was Ihr nutzen wollt. FileExplorer ist letztendlich das Kommando, was der Extension sagt, dass es den Datei-Explorer öffnen soll. Für den Ausbau bzw. Lernen bietet sich hier an, ein zweites Kommando umzusetzen, bspw. OpenWebBrowser. Ich habe für das Beispiel jetzt kein Drop-Down-Feld bzgl. Feldauswahl implementiert, da es für den Einstieg nur unnötigen Code darstellt. Einfach den internen Feldnamen eintragen, fertig. Der Button arbeitet rein Client-Seitig, führt also keine Server-Regel aus, so wie Ihr es vom bisherigen Button in nuclos kennt.
Gebaut wurde es gegen nuclos 4.3.1.

Das ist letztendlich ein erstes konkretes Beispiel für die Implementierung einer Layout-Komponente. Also bitte beginnt hier keine Diskussion über Sinn und Unsinn der Extension. Ich muss einer meiner Vorredner hier absolut zustimmen, es benötigt sehr viel nuclos-Quellcode Recherche, um da durchzusteigen. Aber es ist auf jeden Fall auch nicht so kompliziert. Mit ein paar Beispielen mehr bzw. Dokumentation ( :whistle: ) würde der Einstieg sicher einfacher. Allerdings muss ich zugeben, dass eine allgemeine Dokumentation sich schon etwas schwierig gestaltet, da die Nutzung von internen nuclos-Objekten doch sehr von der Aufgabenstellung abhängig ist. Was aber nicht heissen soll, dass es nicht geht 😉

Viel Spass beim Lesen/Testen/Jammern 😉

Gruß
Frank

Attachments:

• BrowseButton.zip

[Autor]

Beiträge