Skip to content
Snippets Groups Projects
common-data-structures.md 3.65 KiB
Newer Older
# Common Data Structures

Bennenung der Datentypen nicht notwendiger Weise final.

**Frage:** Gibt es einen eleganten Weg, die Datenstruktur _Graph_ und den Force-Graph _Renderer_ namentlich zu unterscheiden? Momentan gibt es _GraphData_ und _NodeData_, was auf die reine Datenstruktur hinweist, und dann aber _GraphNode_ was auf den Renderer deuten soll, aber eher verwirrt. Vorschläge:

-   Renderer
    -   _RendererNode_
-   Canvas
    -   _CanvasNode_
-   UI
    -   _UINode_
-   Force (Allerdings auch irgendwie irreführend, oder? Ergibt aber Sinn im Hinblick auf die Simulationsattribute vx, vy, ...)
    -   _ForceNode_

## Reine Daten

Alle URLs sollen absolut als string angegeben werden.

### GraphData

-   **Nodes**: _NodeData_[]
-   **Links**: _LinkData_[]
-   **Types**: _NodeTypes_[]

### NodeData

-   **Id**: number
-   **Label**: string
-   **Description**: string
-   **Type**: _NodeType_
-   **Icon**: string
    -   URL für Bild für Knoten im Graphen
-   **Banner**: string
    -   URL für Bild in der Detailansicht
-   **Video**: string
    -   URL für Video in Detailansicht
-   **References**: string[]
    -   Liste an weiterführenden URLs
    -   Werden im Backend dann nicht ordentlich gespeichert, sondern in einer Zelle, Komma-separiert o.ä.
-   Folgende Attribue führen über die reine Datenstruktur hinaus, können aber beim laden entsprechend ergänzt werden
    -   **Links**: _LinkData_[]
    -   **Neighbours**: _NodeData_[]
    -   Es sei angemerkt, dass die idealerweise dynamisch über eine Verbindung zum Graphen und einem Getter erstellt werden sollten, damit man die nicht manuell aktuell halten muss. Inbesondere interessant für den Editor.

So könnte eine dynamische Implementierung der verbundenen Links für eine Node aussehen, wobei `graph` dem zugehörigen Graphen entspricht:

```ts
public get links(): Link[] {
    const links: Link[] = [];

    // Collect all links that are connected to the current node
    this.graph.links.forEach((link) => {
        // Contains() returns true, if node is part of link
        if (link.contains(this)) {
            links.push(link);
        }
    });

    return links;
}
```

### LinkData

-   **Source**: _NodeData_
-   **Target**: _NodeData_
-   Zur Einfacheit vielleicht noch folgende, da nicht immer das gesamte Node Objekt geladen sein wird
    -   **SourceId**: number
    -   **TargetId**: number

### NodeType

-   **Name**: string
-   **Color**: string
    -   Als Hexcode? Datentyp hier noch offen

## Force-Graph Erweiterungen

@Matthias, da hattest du doch bereits einiges rausgesucht. Die bisherigen angaben zu _GraphNode_ sind Attribute die ich benötige.

### GraphNode : _NodeData_

-   **index**
-   **x**
-   **y**
-   **vx**
-   **vy**
-   **fx**
-   **fy**
-   ...

### GraphLink : _LinkData_

-   **material?**

## Erweiterung um grundlegende Funktionen

### JSONGraph

Ich weiß nicht, ob _JSON_ ein guter Name dafür ist, doch mir schien _parse_ und _serialize_ teilweise etwas undefiniert.

-   **toJSON()**: any
-   **fromJSON(** any **)**: GraphData

### DisplayGraph

-   **view(** nodeFilter, linkFilter **)**: GraphData

### EditorGraph

-   **addNode(** _NodeData_ **)**: boolean
-   **deleteNode(** _NodeData_ **)**: boolean
-   **addLink(** _LinkData_ **)**: boolean
-   **deleteLink(** _LinkData_ **)**: boolean
-   Sollte von _ManagedData_ erben, welches im Brachn `typescript-graph-object-from-editor` bereits in seiner TypeScript Form in `knowledge-space-wp-plugin/src/editor/js/structures/manageddata.ts` gefunden werden kann. Es enthält neben einigen Attributen auch folgende Funktionen:
    -   **undo()**: boolean
    -   **redo()**: boolean
    -   **storeCurrentData(** description: string **)**