Feature/initial implementation

[sitepark-veltrup]

See

• https://sitepark.github.io/atoolo-docs/develop/bundles/form/
• https://sitepark.github.io/atoolo-docs/develop/form/

[codecov]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[sitepark-schaeper]

First of all - I had to finish this up since it's getting late and github unfortunatly does not save pending comments. So some methods might not have gotten the attention they deserve, but with the rather architectual concerns I address here I think it's not worth investing too much time in these smaller chunks before those are settled.
With that out of the way, I wrote some (unstructured) thoughts down that I had while reading through your code and would like to discuss them with you:

I've ignored the translations so far, but is the .translation-cach directory intended to be checked in?

Why are Layouts Elements?

The names of email specific classes are a bit wordy in my opinon. For example, Dto/Email/EmailHtmlMessageRendererResult could just be Dto/Email/RenderingResult, right?

A few classes here include the term Model, which I don't quite understand what it means in this context. May it just be a Dto?

There are a lot of mutable properties in the Dtos which I did not find why. Do we really need to expose these (and if so, can we properly differentiate them)?

We might have gone a little bit overboard with the array typing here. It's really hard to review it and figure out what is a class, what is just an array structure and which of their properties are actually gurantieed to be typed as defined and which might not. As such I did "skip" some of the implementations (like FormDataModelFactory) because I did not have the time to comprehend them. I feel like this complexity and mental overhead is not neccessary and we could just type out most of these as classes.
This also applies to all the $options (for which it is also difficult to figure out what exactly is beeing configured and from where). I get that it's hard to declare these but having it as just array<string, mixed> but checking for explicit values seems like a red flag.

Another reoccuring theme seem to be nullable array types. I don't think there is a reason for an array that is allowed to be empty to also be nullable. an alternative would be something like ?non-empty-array<string, string> but that is even less intuitive.

Then there are classes with comments saying "not yet implemented". I get that creating them helps development but do they need to be checked in?

Lastly a couple of class comments could be nice. For example the Constraint interface might profit from a small sentence explaining what it is, why it exists and what it's used for. To be clear - I don't want to be pedantic and don't think it's too big of a deal, I just think someone that does not happen to have the context could have a hard time figuring this out where all it takes are 20ish words.

[sitepark-veltrup]

Why are Layouts Elements?

https://jsonforms.io/docs/uischema/layouts#elements

Layouts can be nested.

Layouts have an elements attribute in which further layouts or controls can be contained. Both are elements of the elements list.

[sitepark-veltrup]

@sitepark-schaeper thanks for the thorough review. Here is where the general points from your review stand:

• .translation-cache: intended. It is the hash cache of the automatic translation, so unchanged labels are not translated again.
• Layouts as Elements: this follows the JSON Forms spec, where layouts are UI schema elements themselves and can be nested.
• Wordy names: EmailHtmlMessageRendererResult is now EmailMessageRendererResult, matching EmailMessageRenderer (fef5c37).
• "Model": it means the template model passed to Twig, so I kept the term.
• Mutable DTO properties: the UISchema DTOs are readonly now (7177311). FormSubmission::$approved stays mutable, see the thread on SubmitProcessor.
• Array typing / $options: agreed, but replacing the array shapes with classes is too big for this PR. Tracked in Replace array shapes with typed classes #18.
• Nullable arrays: FormDefinition::$processors is no longer nullable. $data and $messages stay nullable, because the definition is serialized with SKIP_NULL_VALUES, and [] would change the JSON the frontend receives.
• "Not yet implemented" classes: removed SpamDetector, the MJML renderer and Role (c9edc5a).
• Class comments: added for Constraint, SubmitProcessor, FormReader and FormReaderHandler (171f503).