Auf dieser Seite:

Auf eigenen Unterseiten:

Architekturbasis

Java

JDK11 oder höher (wir versuchen aber von Anfang an alles auf die neueren Konzepte - insbes. Modularisierung - anzupassen).

CommunityMashup

Über MashupConnector wird DataSet geladen (in Klasse org.soziotech.cmf3.CommunityMirror)

In den View-Klassen werden dann über das DataSet-Objekt InformationObject-Objekte geladen (konkret Objekte der Klassen Person, Organisation und Content); zusätzlich wird in den View-Klassen (konfigurierbar) ein DataSetChangeObserver instantiiert (TBD: Wie bekommen VisualItems von Änderungen mit?)

Zu klären/dokumentieren:

• Wie genau werden Medienobjekte (insbes. Images) aus dem Mashup geladen / gecached etc. - Hier gibt es vermutlich noch das ein oder andere Speicherleck

Siehe hierzu auch CommunityMashup

Grafik/Touch: JavaFX

JavaFX 11 - https://openjfx.io

Siehe auch JavaFX für CMF 3.0

Sonstige Bibliotheken

Apache commons-configuration2

• Zur Konfiguration des CommunityMirror - wie bisher
• Konfigurationsdateien
  • Defaults in mehreren Dateien unter resources/META-INF/configuration
  • Überschreiben durch eine Datei, deren Name beim Start angegeben wird (normalerweise unter resources, aber auch anderswo)
  • Überschreiben durch Umgebungsvariablen (Eclipse Run Configuration, -D beim direkten Start) 

SLF4J und Logback

• nur noch für Debug-Logging
• das Event-Logging für Evaluation und Dashboards wird über ein eigenes Evaluationsframework abgewickelt (siehe dazu separater Punkt unten)

Eigentliches CMF

Allgemeines

• Views - Vollbildschirmdarstellungen von visuellen Objekten und Interaktionsmöglichkeiten
  • beinhalten
    • Objekte (VisualItems), die Informationspartikel aus CommunityMashup darstellen
    • Objekte (VisualComponents oder davon vererbt) ohne Verbindung zum Mashup
  • liest Konfiguration und generiert passende Objekte daraus (Nicht-Informations-Objekte aber bei Bedarf auch Informationsobjekte)
  • holt Informationspartikel vom Mashup und generiert Objekte daraus - konfigurierbar (neu)
  • Objekte sind organisiert in mehreren Gruppen von VisualComponents (organisiert in VisualGroups) - von denen jeweils eine Gruppe die andere überdeckt (Vordergrund/Hintergrund-Beziehung) - innerhalb einer VisualGroup gibt es keine klar definierten Vordergrund/Hintergrund-Beziehungen
  • Erst mal nur FlowView (wie bisher) - Später weitere Views, zwischen denen umgeschaltet werden kann
• VisualItems
  • sozusagen "VisualInformationObjects" - Visualisierung gekoppelt an ein InformationObjekt aus dem CommunityMashup
    • Klassen für Person, Organisation, Content und Unterkategorien von Content - konkret erst mal: EventItem, PictureItem, LongMessageItem (BlogPost, News), ShortMessageItem (Microblog)
  • in Bewegung (Animation - eigentlich nur gleichmäßige Bewegung in verschiedene Richtungen), an fester Position
  • verschiebbar, nicht verschiebbar
  • vergrößerbar, nicht vergrößerbar
  • Darstellungsmodi: inMicro (normal, in FlowView), inDetail (Detailansicht), inTeaser ("Plakat")
  • Definition über FXML und CSS
• VisualComponents
  • in Bewegung, an fester Position
  • VisualItems sind von VisualComponents abgeleitet
  • Drawing wird über eigene Klasse realisiert, hier auch User/Interaction-Logging-Methoden und Interaktion
  • Definition von Aktionen, die bei Klick/Touch ausgelöst werden (Öffnen anderer Objekte, Schließen des aktuellen Objektes, ...)
  • Beispiele: Wetteraussichten, Busabfahrtszeiten, Speiseplan, Video-Fenster in andere Räume, Buttons, ....
• Generell
  • Sinnvollerweise konsequente "Sparation of Concerns" bzgl. FXML, CSS und Controller (MVC-Pattern) - u.a. auch bzgl. Klassenbenennung und Paketierung, vgl. z.B. http://accelconf.web.cern.ch/AccelConf/icalepcs2017/talks/thapl02_talk.pdf

  • Styling möglichst durchgängig nur noch per CSS (vgl. u.a. https://docs.oracle.com/javase/8/javafx/user-interface-tutorial/apply-css.htm für Grundlagen sowie https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html als Referenz), vgl. hierzu auch Diskussion im ehemaligen CSCM-Blog aus JavaFX-CSS-Diskussion.pdf

  • überarbeiteter CMF-Theming-Mechanismus zum Überschreiben von Default CSS + FXML im Bedarfsfall (z.B. ein einzelnen Views)

• CommunityInteractionFramework - wird gestrichen - Event-Handling direkt in VisualComponents - basierend auf JavaFX/TUIOFX-Events
• Explizite Berücksichtigung Distributed Display Environment (DDE), also mehrere an unterschiedlichen Orten aufgestellte Displays mit ggf. identischer Datenbasis
  • Filterung von zu ladenden/priorisierenden InformationObjects konfigurierbar (To-be-Specified) 
• Remote Management Schnittstelle (z.B. aktueller Screendump etc) - für Management-Cockpits / Dashboards
• Laufender Export von Log-Daten für Management / Evaluation (Benutzer/Interaktions-Logging)
  • über Interface
  • Abspeicherung in Log-Datei möglich
  • direkte Abspeicherung in zentrale Datenbank möglich
  • "Sensoren" in View, VisualInformationObjects, VisualComponents
  • jedes Objekt/Component hat dazu eindeutige (konfigurierbare) ID
  • rudimentäres Auswertungstool enthalten; zusätzliche Nutzung / Auswertung der Daten in Dashboard / Cockpit-Implementierungen
  • Distrubuted Logging Unterstützung (zentralisiertes Logging mehrerer Deployments mit verschiedenen Großbildschirmen sowie ggf. unterschiedlichen Mashup-Datensätzen)
  • Framing: Möglichkeit zur (teilautomatisierte) Definition von "Interaktionsslots" inkl. Kommentarfunktion, z.B. InfoPartikel wird angezeigt, Nutzer bleibt davor stehen, interagiert aber nicht, Offline-Erfassung des Grundes durch Ex-Post-Befragung und Eintrag in Kommentarfeld durch "Beobachter".
  • Einbindung Kinect als weiterem "Sensor" für datenschutztechnisch unbedenkliches teilanonymisiertes Nutzertracking; TBD: Library dafür, vgl. auch Kinect-Logging nach Jan Schwarzer oder anderer Ansatz, z.B. http://www.tutego.de/blog/javainsel/2015/04/xbox-360-kinect-unter-java-ansprechen/
  • mehr Details auf separater Architektur/Konzeptseite: Logging-/Evaluationsframework

Noch unklar

• Graph ... was nehmen wir zum Browsen ... eventuell bisher genutztes Framework weiterverwenden / oder woanders entwickeltes / gepflegtes Framework (2D-Physik-Engine ...) nutzen

Dokumentation

Package/Klassen-Struktur

• org.sociotech.cmf3.
  • CommunityMirror.java - Basisklasse
  • .view.*
    • View.java
  • .components.* - VisualComponents
    
    • VisualComponent.java
    • VisualItem.java
  • .view.flow.
    • FlowView.java
    • .components
      • FlowVisualItem.java
  • .context - ContextManager und andere Komponenten zur Verwaltung von Information zur lokalen Instanz des CM
  • .configuration
  • .logging - User/Interaction-Logging
  • .remote - Remote Management Funktionalität

Ableitungsstruktur der zentralen VisualComponent und VisualItem-Klassen:

• javafx.scene.Node - https://openjfx.io/javadoc/11/javafx.graphics/javafx/scene/Node.html
• -> javafx.scene.Parent - https://openjfx.io/javadoc/11/javafx.graphics/javafx/scene/Parent.html
• -> javafx.scene.Group -https://openjfx.io/javadoc/11/javafx.graphics/javafx/scene/Group.html
• -> org.sociotech.cmf3.components.VisualComponent | ->org.sociotech.cmf3.components.view.View
• -> org.sociotech.cmf3.components.VisualItem
• -> org.sociotech.cmf3.view.flow.components.FlowVisualItem

Wie und wo werden VisualComponent-Objekte erzeugt:

• FlowView.onInit()
• - javafx.scene.Group-Objekte für die verschiedenen Ebenen
• - addStickyVisualComponents() - Objekte nach Konfiguration, erzeugt/eingefügt über addVisualComponentToView(classname, posX, posY, scaleX, scaleY, layer, aname);

Handhabung der Interaktion:

• "ganz normal" mit JavaFX-Mitteln - d.h. es könnten mit den Funktionen von JavaFX.scene.Node wie z.B. setOnTouchMoved Event-Handler registriert werden
• Einfacher:
  • VisualComponent.makeTouchable
  • VisualComponent.makeDragable
  • dadurch Registrierung von Event-Handlern, die dann Methoden handleMouseEvent(), handleTouchEvent() in der Klasse aufrufen (können überladen werden)

Programmstart

Ablauf beim Programmstart

• org.sociotech.cmf3.CommunityMirror.main()
• - doStaticInitialization()
• — loadConfiguration()
• --  Initialize RemoteManager (if mirror.remote.enable = true)
• - Application.launch(args); — damit wird JavaFX gestartet und es geht weiter mit
• org.sociotech.cmf3.CommunityMirror.start()
• - connectToCommunityMashup()
• - manageScreenSetup()
• - createMainView()
• — new main view class: org.sociotech.cmf3.view.TestView
• — view.init() -> onInit() in der View-Klasse

FlowView

• in onInit():
• ...

Alles weitere erfolgt ereignisbasiert …

In der Basisklasse CommunityMirror wird Mittels eines JavaFX TimelineBuilders ein JavaFX Timeline-Objekte erzeugt und dann .play() darauf aufgerufen. Die handle()-Funktion ruft dann auf allen Controller-Objekten und View-Objekten die Funktion update() auf, welche wiederum die Funktion onUpdate() aufruft.

Benötigte Bibliotheken

.. sind im Eclipse-Projekt (mit allen Abhängigkeiten) direkt enthalten.

Folgende Bibliotheken werden benötigt: (und sind im modulepath enthalten und in module-info.java angegeben)

• commons-configuration2 2.4
  • commons-logging 1.2
  • commons-beanutils
  • commons-text-1.6.jar
  • commons-lang3-3.8.1.jar
• logback-core 1.3.0
• logback-classic 1.3.0
• slf4j-api 1.8.0-beta4
• json-20160810

CommunityMashup ...

Für das CommunityMashup werden folgende drei Bibliotheken benötigt: (ebenso im modulepath enthalten)

• org.sociotech.communitymashup.core.jar
• org.sociotech.communitymashup.data.DataObservers.jar
• org.sociotech.communitymashup.framework.CommunityMashupApplicationFramework.jar

Ausserdem werden von diesen Bibliotheken (teilweise erst zur Laufzeit) weitere Klassen / Bibliotheken nachgeladen (diese sind größtenteils im classpath enthalten):

• httpclient-4.2.2
• httpcore-4.2.2
• org.eclipse.emf.common-2.9.2
• org.eclipse.emf.ecore-2.9.2
• org.eclipse.emf.ecore.xmi-2.9.1
• Common-1.0.0
• Lpg.runtime.java-2.0.17
• Org.eclipse.core.contenttype-3.7.300
• Org.eclipse.core.jobs-3.10.300
• Org.eclipse.core.runtime-3.15.200
• Org.eclipse.emf.query-1.2.100
• Org.eclipse.equinox.app-1.4.100
• Org.eclipse.equinox.common-3.10.300
• Org.eclipse.equinox.preferences-3.7.300
• Org.eclipse.equinox.registry-3.8.300
• Org.eclipse.ocl-3.2.1
• Org.eclipse.ocl.ecore-3.2.ß
• Org.eclipse.osgi-3.13.300

Todos

• Testen von TouchEvents auf geeigneter Hardware
• StickyComponents wieder einbauen (Weather, Bus)
• Bei Sticky Components noch mehr auf FXML bauen
• VisualItems: FXML-Rendering weiter machen
• SelectionStrategyDefault weiter implementieren (aktuell wird nur nach metatag selektiert)
• Laden VisualItems basierend auf Context (Location etc.) - Regeln in Konfiguration einstellbar
  
• Log-Framework/Factory etc erstellen um Log-Meldungen an konfigurierbare Quelle abzusetzen
• Möglichkeit zum Anmelden/Abmelden von Benutzern über Remote-Schnittstelle einbauen; Benutzer dann als Teil des Kontextes verfügbar
• Build-Prozess: Klären, wie man mit JDK 11 und JavaFX 11 in Eclipse ein "Fat-JAR" erzeugen kann - also ein JAR, das alles enthält, was man zum Starten der CommunityMirror-App braucht - insbesondere die JavaFX-Bibliotheken/Modul - siehe z.B. http://rimdiary.com/javafx-on-jdk-11/ für einige Hinweise, wie das gehen könnte ...
• Check in wie weit JavaFX Multi-Touch und Multi-Displays (neue Hardware) unterstützt; dabei insbesondere: wie funktioniert Screen-übergreifendes Multi-User-Multi-Touch bei einem Großbildschirm bestehend aus einer Display-Matrix (mehrere Einzeldisplays)
• Check 2D-Physik-Engines für JavaFX, z.B. Phys2D vgl. dazu u.a. auch https://books.google.de/books?id=D0Ml8WugPm8C&lpg=PA114&ots=BiHa9fhaCX&dq=Phys2D%20javafx&hl=de&pg=PA114#v=onepage&q=Phys2D%20javafx&f=false
• Check Behandlung von Image-Objekten in Mashup und das Durchreichen zu JavaFX
• Check Logging-Framework für Java, ggf. SL4J + Logging-Server? Vgl. z.B. https://stackify.com/slf4j-java/ oder https://tech.europace.de/eine-migration-auf-slf4j-und-logback-lohnt-sich/