How does FluidStack

f: form-ViewHelpers

General information about the form elements

Perhaps you are wondering why a separate ViewHelper was programmed for each form element? Well, I think, because firstly you save time (thanks to the property property) and secondly you can reduce errors (thanks to the property property). Let's go through a few examples:

Example: Not Extbase / Fluid like

If we were to program a simple form without TYPO3 or without CMS, an input field could look something like this:

<input type="text" name="autoMarke" />

Within the programming, we would then access this value again after sending it with $ _POST or something similar. In the case of TYPO3, the TYPO3 API is used to access the form data:

$ brand = t3lib_div :: _ GP ('autoMarke');

But no matter how, you have to take care of the security yourself. You have to check yourself whether it is a text / string / int / bool or whatever.

Example: Forms with Actions

<input type="text" name="tx_sffluid_sffluid[autoMarke]" />

The name attribute indicates for which extension (the first sffluid) or which plug-in (the second sffluid) the contained value should be made available. If we send this form now, we can access this form field with all actions of the extension sffluid in the plugin sffluid:

/**
* @param string $ autoMark
* @return void
 */
public function createAction ($ autoMark) {
t3lib_utility_Debug :: debug ($ autoMarke, 'Marke');
the end');
}

No $ _POST, no $ _GET and no use of any TYPO3 API. Extbase does all of this for us, as long as we stick to the exact naming. A spelling error in the name attribute of the form field results in this example in an empty output

Example: Forms with Extbase (array)

Even if the action example works, Extbase goes one better. Because what if we had a large form with 30, 40 or even 50 form fields? Then we would have to expand the action accordingly and pass 50 parameters. That would be an eternally long and above all confusing action.

At Extbase, everything somehow belongs together and so we don't just want to send our autoMark, but also several data relating to a car. So you create a model that is called, for example, "car" and assign it the property "brand", among other things, and our form could look like this:

<input type="text" name="tx_sffluid_sffluid[auto][marke]">
<input type="text" name="tx_sffluid_sffluid[auto][farbe]">
<input type="text" name="tx_sffluid_sffluid[auto][ps]">

And the call within the action is also a whole lot shorter:

/**
* @param $ auto
* @return void
 */
public function createAction (array $ auto) {
t3lib_utility_Debug :: debug ($ auto, 'auto');
the end');
}

Example: Forms with Extbase (object)

Working with objects can save us a lot of paperwork, and the name attribute thing is a whole lot less error-prone. In our f: form-ViewHelper we use the name attribute to specify what our object should be called. This object name is later the variable name (parameter) that is transferred to the called action. So please no spaces or anything.

<f:form action="create" name="auto" object="{auto}">
<f:form.textfield property="marke" /><br />
<f:form.textfield property="farbe" /><br /> <f:form.textfield property="ps" /><br /> <f:form.submit value="Erstellen" />
</f:form>

After submitting the form, we will first receive an array again if Extbase did not precede us:

/**
* @param $ auto
* @return void
 */
public function createAction (Tx_Sffluid_Domain_Model_Auto $ auto) {
t3lib_utility_Debug :: debug ($ auto-> getMarke (), 'Brand');
t3lib_utility_Debug :: debug ($ auto-> getColor (), 'Color');
the end');
}

Extbase reads the parameters of the action to be called BEFORE calling each action and can thus determine the type of the variable. In the previous example I had written "array" in front of the parameter and could access the contents within the action as with an array. In this example, however, the type Tx_Sffluid_Domain_Model_Auto is in front of the parameter. Extbase now checks whether there is a class (model) with this type name and tries to write all values ​​of the array into the model. The key name of an array value must match the property name from the model. If not, the value is not included in the model.