Fix links

hugo/content/_index.html

@@ -21,7 +21,7 @@ <h2 class="text-sprottyTeal text-center font-medium text-4xl tracking-wide pb-10
             Fully customizable · Server and client-side diagramming · Easy integration · Powerful timesaver
         </p>
         <div class="flex flex-row gap-10 justify-center items-center pb-10">
-            <a href="./docs/getting_started" class="bg-sprottyMidBlue bg-opacity-50 rounded-xl px-8 py-3 text-sprottyDarkBlue shadow-md">Get started</a>
+            <a href="./docs/getting-started" class="bg-sprottyMidBlue bg-opacity-50 rounded-xl px-8 py-3 text-sprottyDarkBlue shadow-md">Get started</a>
             <a href="#what-is-sprotty" class="text-sprottyDarkBlue">
             <div class="flex flex-row gap-2">
                     <p>Learn more</p>

hugo/content/docs/custom-interactions.md

@@ -26,7 +26,7 @@ const container = new ContainerModule((bind, unbind, isBound, rebind) => {
 ```
 
 A button handler is a simple injectable class with a `buttonPressed(button: SButton): Action[]` method.
-The actions that this method returns are passed to the [`ActionDispatcher`](../overview#action-dispatcher) to be handled there.
+The actions that this method returns are passed to the [`ActionDispatcher`]({{< ref "/docs/overview" >}}#action-dispatcher) to be handled there.
 
 ```Typescript
 @injectable()
@@ -41,7 +41,7 @@ export class CustomButtonHandler implements IButtonHandler {
 ## Mouse and Keyboard Listeners
 
 Sprotty also offers the ability to attach mouse and keyboard listeners by registering `MouseListener` or `KeyListener`.
-This can be simply done by binding the custom listener to the respective listener type in your [DI-container](../dependency_injection) like this:
+This can be simply done by binding the custom listener to the respective listener type in your [DI-container]({{< ref "/docs/dependency-injection" >}}) like this:
 
 ```Typescript
     bind(CustomMouseListener).toSelf().inSingletonScope();

hugo/content/docs/dependency-injection.md

@@ -2,7 +2,7 @@
 title: 'Sprotty configuration and dependency injection'
 --- 
 {{< toc >}}
-As seen in the [getting started](../getting_started) guide, Sprotty relies heavily on dependency injection (DI) through [InversifyJs](https://inversify.io/) for the configuration of its various components. This chapter will take a closer look at how to work with this.
+As seen in the [getting started]({{< ref "/docs/getting-started" >}}) guide, Sprotty relies heavily on dependency injection (DI) through [InversifyJs](https://inversify.io/) for the configuration of its various components. This chapter will take a closer look at how to work with this.
 
 ## Why dependency injection?
 
@@ -40,7 +40,7 @@ export const createContainer = (containerId: string) => {
 
 The container is built from multiple modules. Through `loadDefaultModules()` all modules are loaded for default Sprotty functionalities. We can also load other optional modules like the `edgeIntersectionModule` for extra functionality.
 
-Most important is our own module where the core of the configuration happens. Here we can configure singleton scope classes like our [model source](../model_sources) or rebind default Sprotty components (for example the logger) to a custom implementation. We use Symbols for bindings instead of using classes directly. All Symbols can be found in the `TYPES` object.
+Most important is our own module where the core of the configuration happens. Here we can configure singleton scope classes like our [model source]({{< ref "/docs/model-sources" >}}) or rebind default Sprotty components (for example the logger) to a custom implementation. We use Symbols for bindings instead of using classes directly. All Symbols can be found in the `TYPES` object.
 
 Using `configureModelElement` we can link our model to specific view components through the type property. Meaning if we have the following SNode,
 in our model, Sprotty will try to convert this data structure to an instance of the actual `SNodeImpl` class and render it with the `TaskNodeView`.
@@ -59,7 +59,7 @@ Lastly, we need to configure our viewer options. Here we configure all the DOM e
 
 ## Features
 
-Model elements can further be configured through [features](../features).
+Model elements can further be configured through [features]({{< ref "/docs/features" >}}).
 
 ```typescript
 configureModelElement(context, 'task', SNodeImpl, TaskNodeView, {

hugo/content/docs/features.md

@@ -17,7 +17,7 @@ export class SNodeImpl extends SConnectableElementImpl implements Selectable, Fa
 }
 ```
 
-It is possible to fine-tune the behavior in the [dependency injection container](../dependency_injection/#the-container) by enabling or disabling features for a given model element type.
+It is possible to fine-tune the behavior in the [dependency injection container]({{< ref "/docs/dependency-injection" >}}#the-container) by enabling or disabling features for a given model element type.
 
 ```typescript
 configureElement('my-node-type', SNodeImpl, RectangularNodeView, {enable: [layoutableChildFeature], disable: [moveFeature]})

hugo/content/docs/introduction.md

@@ -16,7 +16,7 @@ Some selected features:
 
 ## Where to start?
 
-If you are new with Sprotty, we recommend taking a look at our [Getting Started](./getting_started) section before diving further.
+If you are new with Sprotty, we recommend taking a look at our [Getting Started]({{< ref "/docs/getting-started" >}}) section before diving further.
 
 ## Want to contribute?
 

hugo/content/docs/micro-layout.md

@@ -12,7 +12,7 @@ Any model element that implements or extends the `SNode` or `SCompartment` inter
 * `hbox`: children elements are arranged horizontally
 * `vbox`: children elements are arranged vertically
 
-The `layout` property aims at arranging children elements that do not have a meaning in terms of graph hierarchy (i.e. labels, buttons, ...). Please note that children [that are instances of `SNodeImpl`](../dependency_injection#the-container) do not respect the `layout` property by default (more on that [later](#layouting-nested-nodes)).
+The `layout` property aims at arranging children elements that do not have a meaning in terms of graph hierarchy (i.e. labels, buttons, ...). Please note that children [that are instances of `SNodeImpl`]({{< ref "/docs/dependency-injection" >}}#the-container) do not respect the `layout` property by default (more on that [later](#layouting-nested-nodes)).
 
 First and foremost, the micro-layout engine needs to be activated in the inversify container. This is done by setting the `needsClientLayout` property to `true` in the inversify container configuration:
 
@@ -115,7 +115,7 @@ This results in the following visuals:
 
 ![layout-configuration](/assets/docs/layout-configuration.png)
 
-If you want different layout configurations, you can implement your own micro-layout engine and inject it via [Dependency Injection](../dependency_injection).
+If you want different layout configurations, you can implement your own micro-layout engine and inject it via [Dependency Injection]({{< ref "/docs/dependency-injection" >}}).
 
 ## Layout Options
 

hugo/content/docs/model-sources.md

@@ -16,14 +16,14 @@ ModelSource --- LocalModelSource
 ModelSource --- DiagramServerProxy
 DiagramServerProxy <-.->|Action| DiagramServer
 {{< /mermaid>}}
-Regardless of where your model-source is located, Sprotty handles them in a similar fashion. All communication between `ActionDispatcher` and model source is always through [actions](../communication_and_protocols) and is bi-directional.
+Regardless of where your model-source is located, Sprotty handles them in a similar fashion. All communication between `ActionDispatcher` and model source is always through [actions]({{< ref "/docs/actions-and-protocols" >}}) and is bi-directional.
 This is a powerful feature of Sprotty as it allows both flexibility regarding where and how the Diagram is generated, as well as changing or updating and reacting to interactions with the diagram simultaneously.
 
 The following sections will explain how to use and work with the different types of model sources.
 
 ## General usage
 
-Regardless of the model source we are using, the first thing we have to do is to register our model source in the front-end [DI-container](../dependency_injection) like this:
+Regardless of the model source we are using, the first thing we have to do is to register our model source in the front-end [DI-container]({{< ref "/docs/dependency-injection" >}}) like this:
 
 ```Typescript
 bind(TYPES.ModelSource).to(ModelSourceClassOrProxy).inSingletonScope();

hugo/content/docs/smodel.md

@@ -64,7 +64,7 @@ This is the base class for **all** elements of the diagram model. This ensures t
 
 * `type: string`: The type of the element. This value is used in the Sprotty configuration to specify the corresponding view for all elements of this type.
 * `id: string`: The globally unique identifier of the element.
-* `features: FeatureSet` - *optional*: A set of [features](../features) that are enabled on the element. The list of features can be further configured in the [dependency injection container](../dependency_injection/#features).
+* `features: FeatureSet` - *optional*: A set of [features]({{< ref "/docs/features" >}}) that are enabled on the element. The list of features can be further configured in the [dependency injection container]({{< ref "/docs/dependency-injection" >}}#features).
 * `cssClasses: string[]` - *optional*: A list of CSS classes that should be applied to the element.
 
 ### SParentElementImpl
@@ -142,15 +142,15 @@ Model element for **Nodes**, which are the main entity in a graph. A node can be
 
 *Default features:*
 
-* [connectableFeature](../features#connectablefeature)
-* [deletableFeature](../features#deletablefeature)
-* [selectFeature](../features#selectfeature)
-* [boundsFeature](../features#boundsfeature)
-* [moveFeature](../features#movefeature)
-* [layoutContainerFeature](../features#layoutcontainerfeature)
-* [fadeFeature](../features#fadefeature)
-* [hoverFeedbackFeature](../features#hoverfeedbackfeature)
-* [popupFeature](../features#popupfeature)
+* [connectableFeature]({{< ref "/docs/features" >}}#connectablefeature)
+* [deletableFeature]({{< ref "/docs/features" >}}#deletablefeature)
+* [selectFeature]({{< ref "/docs/features" >}}#selectfeature)
+* [boundsFeature]({{< ref "/docs/features" >}}#boundsfeature)
+* [moveFeature]({{< ref "/docs/features" >}}#movefeature)
+* [layoutContainerFeature]({{< ref "/docs/features" >}}#layoutcontainerfeature)
+* [fadeFeature]({{< ref "/docs/features" >}}#fadefeature)
+* [hoverFeedbackFeature]({{< ref "/docs/features" >}}#hoverfeedbackfeature)
+* [popupFeature]({{< ref "/docs/features" >}}#popupfeature)
 
 ### SPortImpl
 
@@ -168,11 +168,11 @@ A port is a connection point for edges. It should **always** be contained in an
 
 *Default features:*
 
-* [connectableFeature](../features#connectablefeature)
-* [selectFeature](../features#selectfeature)
-* [boundsFeature](../features#boundsfeature)
-* [fadeFeature](../features#fadefeature)
-* [hoverFeedbackFeature](../features#hoverfeedbackfeature)
+* [connectableFeature]({{< ref "/docs/features" >}}#connectablefeature)
+* [selectFeature]({{< ref "/docs/features" >}}#selectfeature)
+* [boundsFeature]({{< ref "/docs/features" >}}#boundsfeature)
+* [fadeFeature]({{< ref "/docs/features" >}}#fadefeature)
+* [hoverFeedbackFeature]({{< ref "/docs/features" >}}#hoverfeedbackfeature)
 
 ### SEdgeImpl
 
@@ -190,11 +190,11 @@ These are the connectors for the diagram model. An edge has a source and a targe
 
 *Default features:*
 
-* [editFeature](../features#editfeature)
-* [deletableFeature](../features#deletablefeature)
-* [selectFeature](../features#selectfeature)
-* [fadeFeature](../features#fadefeature)
-* [hoverFeedbackFeature](../features#hoverfeedbackfeature)
+* [editFeature]({{<ref "/docs/features" >}}#editfeature)
+* [deletableFeature]({{<ref "/docs/features" >}}#deletablefeature)
+* [selectFeature]({{<ref "/docs/features" >}}#selectfeature)
+* [fadeFeature]({{<ref "/docs/features" >}}#fadefeature)
+* [hoverFeedbackFeature]({{<ref "/docs/features" >}}#hoverfeedbackfeature)
 
 ### SLabelImpl
 
@@ -221,11 +221,11 @@ A label represents some text to be displayed and attached to a node, compartment
 
 *Default features:*
 
-* [boundsFeature](../features#boundsfeature)
-* [alignFeature](../features#alignfeature)
-* [layoutableChildFeature](../features#layoutablechildfeature)
-* [edgeLayoutFeature](../features#edgelayoutfeature)
-* [fadeFeature](../features#fadefeature)
+* [boundsFeature]({{< ref "/docs/features" >}}#boundsfeature)
+* [alignFeature]({{< ref "/docs/features" >}}#alignfeature)
+* [layoutableChildFeature]({{< ref "/docs/features" >}}#layoutablechildfeature)
+* [edgeLayoutFeature]({{< ref "/docs/features" >}}#edgelayoutfeature)
+* [fadeFeature]({{< ref "/docs/features" >}}#fadefeature)
 
 ### SCompartmentImpl
 
@@ -242,10 +242,10 @@ A compartment is used to group multiple child elements of a node or compartment,
 
 *Default features:*
 
-* [boundsFeature](../features#boundsfeature)
-* [layoutContainerFeature](../features#layoutcontainerfeature)
-* [layoutableChildFeature](../features#layoutablechildfeature)
-* [fadeFeature](../features#fadefeature)
+* [boundsFeature]({{< ref "/docs/features" >}}#boundsfeature)
+* [layoutContainerFeature]({{< ref "/docs/features" >}}#layoutcontainerfeature)
+* [layoutableChildFeature]({{< ref "/docs/features" >}}#layoutablechildfeature)
+* [fadeFeature]({{< ref "/docs/features" >}}#fadefeature)
 
 ### SGraphIndex
 

hugo/content/docs/svg-rendering.md

@@ -33,7 +33,7 @@ export class NodeView extends RectangularNodeView {
 }
 ```
 
-The class `NodeView` extends `RectangularNodeView` which is a default `View` in Sprotty, ultimately implementing `IView`. Don't forget to add the class decorator `@injectable()`, which is necessary for the [Dependency Injection](link-to-dependency-injection) mechanism.
+The class `NodeView` extends `RectangularNodeView` which is a default `View` in Sprotty, ultimately implementing `IView`. Don't forget to add the class decorator `@injectable()`, which is necessary for the [Dependency Injection]({{< ref "/docs/dependency-injection" >}}) mechanism.
 
 The `render()` method is the core of the `View`. It takes `node` -- that is the model element to be rendered - as an argument, a `RenderingContext`, and an optional `args` object. View implementations should first check whether the `node` should be rendered at all. This is an optimization step, as we only want to render SVG elements that are inside of the visible viewport and not hidden by some other user-defined filter.
 Eventually, the `render()` method returns a `VNode` which is [Snabbdom's](https://github.com/snabbdom/snabbdom) virtual representation of a DOM element. This `VNode` can hold one and only one *root element*, therefore we need to group our SVG elements inside of a *container element* `g`.
@@ -63,7 +63,7 @@ The micro-layout is computed in two phases:
 1. A `RequestBoundAction` is received and the model is rendered invisibly (e.g. by assigning a width and height of zero to the elements). The locally used fonts and CSS styles are applied during this rendering phase. The resulting size information is used to invoke the selected layouts and the updated bounds are written into a `ComputedBoundAction`.
 2. The bounds stored in the `ComputedBoundAction` are applied to the model and initiates the visible rendering of the updated model with `SetModelAction` or `UpdateModelAction`.
 
-In depth documentation about the micro-layouting can be found [here](../micro-layout)
+In depth documentation about the micro-layouting can be found [here]({{< ref "/docs/micro-layout" >}})
 
 ## Server Layout