Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
# 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 **)**