Bug #80490
closed
EXT:form compatibilityMode and documentation for form creation with fluid
0%
Description
While fixing a problem for a customer regarding the form extension I ran into a bug.
In typo3/sysext/form/Classes/Utility/CompatibilityLayerUtility.php:471, the variable $elementType is used in an if but has never been set before. The fix is to set the variable to the value returned by $element->getElementType().
How I found it, and why I think it's important to fix:
I tried to override the layouts for the form components SELECT, TEXTAREA, SUBMIT, BUTTON and TEXTLINE using the tt_content.mailform.20.form.layout settings for the corresponding objects with the goal of providing a uniform form layout that used certain HTML classes without the customer not having to specifiy the HTML classes in the wizard manually everytime when creating a new form. What I noticed was that when having a layout like
textarea (
<label />
<textarea class="some-class" />
)
the HTML class some-class would simply get lost in the rendering process. As I tried to find the reason for this behavior, I stumbled upon the TypoScript configuration for the FORM element, where in version 7.6.0 of EXT:form, the setting plugin.tx_form.settings.registeredElements.FORM.compatibilityMode is set to 1 by default. This leads to CompatibilityLayerUtility being responsible for setting the layouts for the rendered form.
In the method where this actually happens - setElementLayouts - the textarea tag first gets replaced by a marker, which later is replaced again by the real tag, after which the HTML class of the element is added again which happens on line 479. There, the HTML class is fetched by getting the corresponding tag from the layout DOMDocument. The tag name is determined based on the $elementType (line 471), which unfortunately never gets set in this method.
This leads for the CompatibilityLayerUtility to always believe that it has to fetch a class from an input tag, which simply is not present in the case of rendering a textarea or a select. The result is, as said above, that the class is not re-added to the tag.
Moreover did I notice that most of the methods in the CompatibilityLayerUtility, this method included are deprecated. The deprecation notice is valid for TYPO3 version 7 and the methods will be removed in version 8. This would mean that a fix for version 7 should be provided in spite of the deprecation.
So my next step was to follow the deprecation notice, where it's stated that .layout should not be used anymore as the functionality is done via fluid, which after further inspection of the code implies that the plugin.tx_form.settings.registeredElements.FORM.compatibilityMode has to be disabled.
I assumed that in the documentation for EXT:form version 8 the correct way using fluid would be documented, which is not the case. As stated there, the way to do still seems to be using TypoScript.
Now when I deactivate the compatibilityMode, the fluid templates of the extension are getting used, but I still see no possibility of configuring template-wide attributes in as initially intended besides from copying all of the templates I want to change to a user extension and adjust the attributes there.
I don't know if such functionality was intended or how it should be done with fluid, but as for the issue with the CompatibilityLayerUtility I could provide a pull request if desired.
Updated by Björn Jacob over 7 years ago
- Status changed from New to Needs Feedback
- Assignee set to Olaf Hoffmann
Hi Olaf,
it is a good decision to not use the .layout stuff anymore. We do not recommend using it. If you want, you can provide a patch. With version 8.5 a rewritten form extension was added to the core. The old one will be removed and available via TER or github.
Right now, I do not understand your problem with the fluid templates.
... but I still see no possibility of configuring template-wide attributes in as initially intended besides from copying all of the templates I want to change to a user extension and adjust the attributes there.
What do you want to achieve? Where do you need those attributes? Please describe your goal in more detail.
Updated by Olaf Hoffmann over 7 years ago
Hello Bjoern,
thank you very much for your answer, I will send in the patch shortly. I apologize, if I was being unclear. The goal I'm trying to achieve is the following: we use Bootstrap as CSS framework in our installation. Now if an editor wants to create a new form on a page and adds multiple inputs for example, they have to manually add the form-control class to every single input. With the .layout approach I can easily solve this by setting the layout of e.g. textline to something like this (simplified):
textline (
<label />
<input class="form-control" />
)
Now, if I want to achieve the same using fluid, the only solution I currently see is to create a new extension, add the Partials directory of that extension to plugin.tx_form.view.partialRootPaths, then copy the file of the form element I want to edit, so for my example EXT:form/Resources/Private/Partials/Default/FlatElements/Input.html to my extension and finally add the desired CSS class to the class argument of the f:form.texfield ViewHelper.
As you might have figured out, this is quite a tedious task when doing this for a number of elements, especially since the fluid layout of the forms is done with ol and li, which does not reflect the layout of the forms before. I can't imagine this is the right way to do as I would basically end up having to modify every single Template and Partial in my own extension.
Updated by Olaf Hoffmann over 7 years ago
- Assignee changed from Olaf Hoffmann to Björn Jacob
Updated by Björn Jacob over 7 years ago
- Assignee changed from Björn Jacob to Olaf Hoffmann
Okay, I do understand your problem now. I still recommend using Fluid instead of the old TypoScript based .layout approach. The old way of layouting was broken ever since.
The default template was ever since the relase of EXT:form ol li based. I do not see any problem in overriding some/ all of the needed partials. We will not change the partials for v7. With 8 LTS you will find totally different templates. For example, there is a partial for the whole field wrapping used for alle form elements (https://github.com/TYPO3/TYPO3.CMS/tree/master/typo3/sysext/form/Resources/Private/Frontend/Partials/Field). Furthermore, the templates of v8 are already based on Twitter Bootstrap.
Updated by Riccardo De Contardi over 7 years ago
- Status changed from Needs Feedback to Closed
- Assignee deleted (
Olaf Hoffmann)
I think it is safe to close this issue now:
1) TYPO3 version 7 enters the "priority bugfix mode" and the old version of ext:form has been decoupled from the current version into the external extension "form_legacy" (https://typo3.org/extensions/repository/view/form_legacy) if someone wants to dig into it.
2) The current EXT:form on TYPO3 8.7.x already uses the markup from Bootstrap.
If you think that this is the wrong decision or there is still work that should be done, then please reopen it or open a new issue with a reference to this one. Thank you.