Search code examples
typo3typo3-11.xtypo3-form

Typo3 Forms framework and frontend overlay

I was browsing the typo3 core Forms framework documentation but with no relevant answer to my requirements which are:

  • The form has to be displayed in a frontend overlay.
  • The filling process involves multiple steps where the user would be able to go back and forth.
  • The form fields must still be editable by a redactor.

I'm not sure about how the form framework behaves, so far I remember I think that multiple steps are configurable from the backend module but I don't know if it sends request to the controller after each step or if it sends everything only on submit.

I have an idea about how to implement it though, it's based on this question how to get a typo3 form framework html via ajax. Which would just let me provide the whole html content to the frontender and let him split the whole form into steps. The separation would be based on the addition of some special tags via the editor that would surround the fields you want in each step.

What do you think about that approach?

Solution

  • The form framework proceeds each form step seperately. So without developing your own form runtime, you have to keep proceeding every step seperate.

    I see two possibilities:

    1. Send each form step from frontend to the form controller and replace the response (html form) in the frontend.

    That is the fast and easy way, as you use the existing form runtime.

    • Prepare a page which returns the rendered form as html
    • Fetch this page by JavaScript
    • Send the form data back to the given form action
    • The form controller proceeds the form with all its validators, rules and finishers and returns the next step, previous step, the current step with existing errors or the finishers response on success
    • Replace your form in the frontend with the already rendered html response of the form framework

    The advantage of this way: Less effort and you can rely on the already existing validators, as you get an already validated response. The disadvantage of this way --> it is more difficult to implement frontend validation, as you have a mix between frontend and server side validation.

    2. Make the form framework kind of headless and work json based

    In my opinion the better approach, but with a lot more effort to take. You have to extend / overwrite the controller and the form runtime. This allows you more flexibility in handling the form by JavaScript and e.g. return the errors in a json object. It makes life easier when you want the form render and handle with a JS framework like react or vue.

    To your question:

    What do you think about that approach?

    If I got it right, you want to keep ONE form step in the backend, but let the editor divide this form step into multiple steps by adding tags? You can try, but I don't see any real advantage in keeping the original form steps and proceed every step by sending the step to the controller and handle the response (like mentioned in 1.)

    Summary: In the past, I was thinking a lot about handling forms by JavaScript and came to the conclusion: Keep the form framework's behaviour completely untouched with server side processing or make it frontend driven, with an own runtime. All mixtures between client and server side rendering will sooner or later run into bigger problems or at least a high effort. The form framework is pretty complex with a lot of possibilities, hook driven behaviour, etc. From my experience, you have to know it pretty good to develop without loosing control. In smaller projects with just one or two basic forms, I would try to avoid special cases with lots of JS. In bigger projects (with more budget), I would definitely go with my second mentioned approach (currently, I'm developing vue.js based rendering and handling of the form frontend). But these are just my five cents...