[TYPO3-core] Flexforms + IRRE

[Christian Kuhn]

Hey.

On 30.04.2015 10:27, Bernhard Kraft wrote:
> I already tought much about how the whole FormEngine stuff could get
> refactored to more modern approach. But one of my first questions would
> always be whether to use extbase/fluid for it or not? If those should
> get used I guess the first step would be to create a
> EditDocumentController which is based on extbase. It could still call
> the old FormEngine code but then piece by piece of the FormEngine layers
> could get replaced by extbase/fluid based code - from the top to the
> bottom. I guess it should be one of the last steps to recreate the
> individual form elements (text, select, group, inline, etc.) by modern
> replacements.
>
> Is this already planned so or in a somewhat similar fashion?

Well, we have a vision where the FormEngine work leads to and what it 
can be used for as soon as it is flexible and encapsulated well enough.

At the moment we're in the phase of getting rid of tons of code smell in 
the current implementation. We will see further patches in this area 
over the next weeks, for example the "required" handling currently 
undergoes a major rework.

Currently, we're concentrating on the FormEngine classes and don't 
change too much in the calling code like EditDocumentController and 
others. It may happen that the one or the other element or container of 
FormEngine will be rendered by fluid, but that is not the main goal. The 
highly coupled architecture "look up somithing in tca / user uc / 
tsconfig / elsewhere to decide which html element has to be rendered 
next" does not allow a clever separation to fluid at the moment. I guess 
this situation will stay for a while, at least until further 
architectural cleanups have been applied to the code base to further 
separate concerns.

For the individual form elements: The "element" classes are currently 
bound 1:1 to [config][type]. There is a basic factory around those 
already that could be easily extended to allow registering of own types. 
But the main issue is that element != type. This can be seen in 
SelectElement for example that does all the type=select stuff leading to 
4 different main cases. This should be split further and I'm thinking 
about some ElementTypeResolver or similar that encapsulates the "what 
element to render" code based on different things and then instantiates 
the final element ... so, there is still lots of work to do in this 
area, but we're on the right track. Furthermore, it would be very 
helpful if some areas of TCA itself could be changed / disentangled. For 
example I'd love to have the RTE as own type and not as some funny 
special thing of type=text. We have a plan to achieve that keeping 
backwards compatibility.


Regards
Christian