Using TYPO3.Form with domain models?

kain0bi · September 15, 2015, 11:08am

Hi!

I wonder if it´s possible to use the form framework for domain model CRUD forms?
Looking at the documentation and searching through the code this seems currently impossible.

I think it would be nice, if all forms inside an application can use the same templates, regardless if they are standalone or bound to a model…

What do you think? Or did I simply miss somehing?

Cheers,
Kai

sebastian · September 15, 2015, 11:12am

Hey Kai,

you are right, currently this is not possible in a good way. We experimented a bit with this in TYPO3.Expose one or two years ago, but unfortunately this did not work out really well…

So, if you have some solution on how this could be approached, this would be very cool to see

All the best,
Sebastian

kain0bi · September 15, 2015, 11:52am

Hi Sebastian,

thx for the fast response

I´m really new to Flow so I do not have the big picture of the internals.

But I see form:form viewhelper allready extends the fluid:form viewhelper. So maybe you could implement another FormDefinition class which can be bound to a domain model class (or a concrete model object?) . Then you could automatically build the form definition from the given model properties and propterty validators and then pass the model object to the form (or pass it into the form viewhelper using the FormRuntime)? Maybe? I don´t know

Of course it should also be possible to modify the form action and the automatically built FormDefinition…

dfeyer · September 15, 2015, 12:10pm

This question made me think about the Django admin generator, that can build some automatic interface for your models … from my POV, it’s fast and easy for beginner but does not match real application needs. So for me spending tons of time building something that “automagically” create the backend of your application is a bit of a no go. This kind of tools need to be so flexible and configurable … it’s pretty impossible to build something useful for all use case (multi step, correct validation, …) with creating a monster and the Expose project show exactly that, yes it’s flexible but harder to use than writing some raw fluid template.

I’m more in favor of something like Symfony do:

This is just a kickstarter for the form configuration, based on your model. If we can do that and provide some generic controller for the CRUD operations (can/must be part of the API project) that should be enough. People can iterate over the the generated configuration.

Did we need to build a YAML form definition and something more based on raw fluid … I don’t know. In our projet we use more raw fluid, but we never try to replace this with the Form framework and that should work fine I think.

mneuhaus · September 15, 2015, 6:04pm

There was already a state of Expose quite far along that was based on
TYPO3.TypoScript and TYPO3.Form. In the end i abandoned that path because of the reasons i wrote about a while ago:

gist.github.com

https://gist.github.com/mneuhaus/586cb19bd9e856af9afa#file-1_intro-md

1_Intro.md

# Status of Expose
Currently i'd say that Expose is feature-wise at above 90% complete. There is little to no documentation currently aside from a little demo package i did to test + maintain it. One reason i didn't yet write documentation or shouted out to other people that they should use expose is my feeling, that we took a wrong direction. The introduction of TYPO3.Form and TYPO3.TypoScript added a flexibilty to the whole thing that you can't really find in other "admins". **But** it adds a huge amount of complexity. After using it extensively for 2 Customer projects this complexity feels plain wrong. It seems the direction expose went, got it to probably 70-80% on a [DRY](http://en.wikipedia.org/wiki/Don't_repeat_yourself) scale, yet we dropped well below 30% on a [KISS](http://en.wikipedia.org/wiki/KISS_principle) scale. The performance was an issue as well, which is improved through the TypoScript caching, yet that's one more thing that you need to configure and take care of :/.

Because of this i've had a brewing idea in my head for a while:

- remove TYPO3.TypoScript
- remove TYPO3.Form
- simple inheritance + fallback based controllers
- viewHelpers to make forms concise and easy to maintain
- processViewHelper to easily filter, sort, paginate, limit tables/lists without complex widgets

This file has been truncated. show original

2_ControllerInheritanceFalbacks.md

# Template-Fallback for ControllerInheritance

Currently, if you inherit from a controller that contains actions you need to copy over every template for that actions to your inheriting controller to use them. Imho the view of the controller should follow the same principles as the controller inheritance itself. E.g. use the template/layout/partials from the inherited controller, if it's not overridden in the extending controller.

## Usecase

```
Given you have an CrudController with an action "index" and an template inside "Templates/Crud/Index.html".
When you create a "PostController" that extends from that controller.
Then it should use the template "Templates/Crud/Index.html" for the index action.

This file has been truncated. show original

3_FieldViewHelper.md

# Form/FieldViewHelper

One general hassle the TYPO3.Form package tries to solve is the easy creation of forms, which it does pretty good
for static forms. But for Expose this seems to be one more abstraction that adds complexity, performance overhead
and quite some code to actually make that work together. And if you want to create a new form control you have
to Add it to the Settings.yaml, create a template for it and configure that template to be used in the Schema.ts.
After using Expose in customer projects this gets a nasty forest of configuration files that doesn't make any fun.

Instead i would proprose a new ViewHelper called "```<f:form.field/>```".
This ViewHelper composes a lot of boilerplate code like this:

This file has been truncated. show original

There are more than three files. show original

There is a currently pretty stable running version of expose in github+packagist called Flowpack.Expose which is built quite close to the basic ideas described in that gist document, aside from some specifics and different naming schemes.

You can find it at: https://github.com/mneuhaus/Flowpack.Expose
And you can find the docs at: http://flowpackexpose.readthedocs.org/en/latest/

imho it has a decent balance between easy of use and flexibility

kain0bi · September 21, 2015, 7:24am

Thanks for all the detailed answers, guys!

My main thought was that if I decide to use TYPO3.Form in my application, it would be nice to share the same markup/templates between all different forms, so I don´t have any duplicate code. But I understand that this would add much more complexity…

I like the idea of the f:form.field viewhelper mentioned by @mneuhaus as this would solve this perfectly. If I find some time, I will have a look into this…