Christian Hausknecht

Update 11ty to reduce security issues

2

We should update 11ty version, as dependabot marks some issues related to 11ty.

The `ease-in` and `ease-out` classes are interchanged. We should fix this in order to get a smoother animation. We can burrow the correct values from some internal component's animation.

- update to 2.0.x - evaluate KSP version (needed tweeks for 1.9 upgrade iirc)

As time goes by the Kotlin coding conventions got stricter an now there is the convention for `PascalCase`Names: https://kotlinlang.org/docs/coding-conventions.html#source-file-names So we should follow this guideline!

Improve export-API so it cannot throw anymore

1

#### Problem Until this PR, the `export` function was not safe to use: ```kotlin class Exporter(initialize: Exporter.() -> Unit) { lateinit var payload: T // this is bad and dangerous!...

#### Problem Currently the `export` function is not safe to use: ```kotlin class Exporter(initialize: Exporter.() -> Unit) { lateinit var payload: T // this is bad and dangerous! fun export(payload:...

Obviously fritz2 misses the following events in its listener definitions according to this [list](https://www.w3schools.com/jsref/dom_obj_event.asp): - animationend - animationiteration - animationstart - error - mousewheel - transitionend We should add those...

Introduce automatic Generation of Delegating Lenses: Improves Validation Support for Sealed Class Hierarchies

1

#### Motivation Currently the support for validating sealed class hierachies is rather limited, as our provided mechanisms wont work as the following example shows: ```kotlin import dev.fritz2.core.Lens import dev.fritz2.core.Lenses import...

> [!IMPORTANT] > During the work on this issue we found a different solution. So don't be confused, that there is no `GetterLens` at all. Refer to the description of...

Improve Validation Support for Sealed Class Hierarchies by Providing a new Annotation and Automatic Validation-Dispatcher Implementation

1

In addition to the problem described in #874 there arises another problem with validation in sealed class hiearchies: Using a `ValidatingStore` managing such types! Consider the example hierarchy from #874...