Paketstruktur

Auf dieser Seite wird kurz die Grundstruktur des CMF beschrieben. Hilfreiche Ergänzungen und / oder Änderungswünsche sind jederzeit herzlich willkommen. Ansonsten dient diese Seite primär einer ersten Übersicht über den Aufbau und die verwendenten Packages / Klassen.

Anschauungsobjekte

verfügen i.d.R. mind. über eine eindeutige ID und einen Namen / Titel:

• Content: Beliebiger Inhalt
• Personen, die als Autor / Contributor von Content auftreten können und ggf. einer oder mehreren Organisationen zugeordnet
• Organisationen, die ggf. eine hierarchische Struktur haben können
• Konzepte, wobei diese entweder Kategorien (jeweils eine pro Objekt) oder Tags (beliebig viele pro Objekt) sein können

Ablauf einer CMF Applikation

Zum besseren Verständnis der grundlegenden Zusammenhänge des CMF, hier ein (möglicher) Beispielablauf einer CommunityMirror-Anwendung:

1. Einlesen (generischer) Daten über Contents, Personen und Organisationen aus CSV, XML oder DB in die interne (temporäre) Datenstruktur
2. Erzeugen der verwendeten Konzepte (da diese für die zu erzeugenden Objekte bereits benötigt werden) und bei ihrer Erzeugung aus Performance-Gründen bereits festgestellt werden sollte, wie häufig welches Konzept im welchem Kontext (Content, Person, Organisation) verwendet wird.
3. Erzeugen von “greifbaren” Objekten aus den generischen Tupeln der Tabllen, also Tuple -> Content, Person, Organisation
4. Erzeugen erforderlicher VisualObjects, d.h. in Form von HTML-Templates definierten Visualisierungen für die einzelnen Objekte, z.B. “Cards“, die in verschiedenen Kontexten am Bildschirm angezeigt werden können.
5. Erzeugen benötigter High-Level-Strukturen für die Visualisierungen aus den Objekten und ihren Zusammenhängen, z.B. Prefuse-Graphen.
6. Anzeige der VisualObjects bzw. der High-Level-Strukturen in verschiedenen Ansichten (Views), in denen definierte Navigationsmöglichkeiten sowie ggf. Interaktionsmöglichkeiten vorhanden sind (z.B. Bewertung)
7. Protokollierung aller relevanten Aktivitäten für spätere Auswertungen, z.B. lässt die Anzahl der Aufrufe eines Items (Clicks auf eine Card) möglicherweise Rückschlüsse über seine Bedeutung zu.
8. Zurückschreiben der während der Laufzeit erfolgten Interaktionen, z.B. geänderte Ranking-Werte, etc.

Wichtige CMF-Packages

cmf

• Constants: Interface für globale Konstanten
• StartUp zum Einlesen einer demo.properties-Datei und zum Setzen der Logging-Einstellungen
• Controller als Singleton, der alle weiteren Schritte koordiniert und als Schnittstelle zwischen Daten und GUI dient

cmf.data

• DataGenerator als zentraler Koordinator aller Datenoperationen. Wird von Controller erzeugt und übernimmt das Einlesen aller Daten sowie die Generierung von Tabellen, Graphen und Templates
• Search: Zentraler Zugriffspunkt auf alle CMFObjects (Content, Persons, Organizations). Stellt generische Suchfunktionen auf Basis der zugrundeliegenden Prefuse-Tabellen bereit.

cmf.data.core

Enthält alle CMFObjects (Content, Persons, Organizations) sowie die Verwendenten Concepts (Categories, Tags) als modellierte Klassenstrukturen.

cmf.data.importer

Nachdem Daten möglichst transparent aus verschiedenen Quellen eingelesen werden können sollen, stehen in diesem Package (erweiterbar) verschiedene Interfaces für z.B. CSV, XML oder DB zur Verfügung, die über eine DataImporterFactory für die DataGenerator transparent angesprochen werden können, so dass übergeordnete Schichten nichts mit dem eigentlichen Einlesen oder Schreiben der Daten zu tun haben.

cmf.data.tables

Nach dem Einlesen der Rohdaten werden diese von Prefuse automatisch in interne prefuse Tables konvertiert. Diese besitzen allerdings keine einheitliche Struktur, sondern enthalten z.B. die Namen und (ggf. nicht automatisch korrekt erkannten) Datentypen der Ausgangsdateien.

Zum Einlesen von Tabellen in eine intern einheitliche Struktur werden in diesem Package daher für jeden Tabellen- / Datentyp TableGenerators bereitgestellt, die die extern verwendeten Strukturen anhand der Angaben in den data.properties entsprechend transformieren, so dass beim internen weiteren Gebrauch der Tabellen nicht mehr darauf geachtet werden muss, wie eine Spalte heißt oder ob sie vorhanden ist oder nicht.

Alle eingelesenen Tabellen werden von DataGenerator automatisch in einer statischen TableLibrary registriert und stehen damit in allen CMF-Anwendungskontexten transparent zur Verfügung.

cmf.data.graph

Durch Verwendung der Objektstrukturen aus data.core lassen sich aus den relativ komplexen Daten mit relativ einfachen und im Vergleich zu Tuple-basierten Operationen klar nachvollziehbaren Schritten prefuse-Graphen für verschiedene Anwendungskontexte erzeugen. Hierzu stehen erste Methoden in der Klasse GraphGenerator zur Verfügung, die bei Bedarf flexibel erweitert werden können.

Wie bereits bei den Tabellen existiert eine GraphLibrary, über die alle einmal erzeugten Graphen von verschiedenen Views oder weiterführenden Operationen genutzt werden können.

cmf.data.templateparser

Um Datenobjekte sinnvoll und erweiterbar anzeigen zu können, wird ein Template-Verfahren auf Basis von Freemarker mit HTML-Templates eingesetzt. Die Templates können beliebige XHTML-/CSS-Formatierung enthalten, was im Vergleich zu den Formatierungsmöglichkeiten mit JAVA extreme Vorteile bietet (z.B. Floats). Die in diesem Package bereitgestellten Methoden dienen allerdings ausschließlich dem Parsen der Templates und füllen mit den zur Verfügung stehenden Attributen der jeweiligen CMFObjects. Die Darstellung (HTMLRendering) ist Aufgabe der GUI.

cmf.gui

• MainFrame: Zentrale Management-Instanz für alle GUI-Panels und -Operationen. Wird vom Controller instantiiert und koordiniert die Operationen über die verschiedenen Panels / Views / etc.
• SizeLibrary: Dient als Berechnungspool für Größenangaben und Positionen der verschiedenen dargestellten GUI-Objekte auf Basis der zur Verfügung stehenden Fenster- / Screen-Größe
• VisualObjekt: Kapselt alle Methoden, die ein (beliebiges) CMFObject für seine Darstellung mittels der verwendenten Template benötigt, also z.B. Rendering als BufferedImage, Anzeigen als “Card“, etc.

cmf.gui.theme

Dient der Verwaltung der Theme-Dateien und dem Einlesen der theme.properties. Stellen eine ThemeLibrary bereit, mithilfe derer statisch und gecached auf die vorhandenen Theme-Ressourcen zugegriffen werden kann.

cmf.gui.panels

Sammlung aller GUI-”Teile”, also z.B. Sidebars, Umschaltbuttonleiste für das ViewSwitching, etc. Die einzelnen Komponenten werden zentral beim MainFrame erzeugt / registriert und sollten nur so für den Controller sichtbar sein.

cmf.gui.buttons

Nachdem im CMF an verschiedenen Stellen Buttons für unterschiedliche Funktionen bereitgestellt werden, die meist optisch anspruchsvoll aufbereitet werden sollen, stehen in diesem Package Hilfsklassen zur Bewerkstelligung dieser Funktionalität zur Verfügung. Darunter u.a. auch vertikale und horizontale ButtonPanels.

cmf.gui.cards

Eines der Herzstücke des CMF. Die enthaltenen Klassen sind zuständig für die optische Darstellung der CMFObjects. Da die vollständige Formatierung mittels HTML / CSS über die Freemarker-Templates läuft, stellen die Klassen zwar selbst keine Formatierung bereit, übernehmen allerdings das sehr komplexe HTMLRendering sowie das eigens für das CMF umgeschriebene LinkEventHandling auf Basis des OpenSourceProjekts FlyingSaucer.

cmf.gui.views

Eigentliches Herzstück des CMF. Sammlung verschiedener Ansichten (Views), die jeweils für ALLE CMFObjects (Content, Persons, Organizations) einsetzbar sein sollten. Views definieren nach “außen” lediglich das Interface View, was in ihrem Inneren passiert, sollte aufgrund der zukünftigen Erweiterbarkeit für andere Klassen keine Rolle spielen (müssen). Jeder View wird in einem eigenen Package definiert und enthält alle für ihn relevanten Klassen, s. z.B. GraphView oder TagcloudView.

cmf.gui.utils

Global verwendete Hilfsklassen, u.a. auch ein PropertiesReader, der für das Einlesen und Verwalten der unterschiedlichen .properties-Dateien zuständig ist. Ansonsten Hilfsklassen zur Verwaltung / Bearbeitung von Farben, Arrays, Strings, etc.