Feature #73123

Fill up Core/Forms with SignalSlots

Added by Stefan Froemken over 3 years ago. Updated about 1 year ago.

Should have
FormEngine aka TCEforms
Start date:
Due date:
% Done:


PHP Version:
Sprint Focus:



since 6 hours I try to add a requireJSmodule to $jsonArray['scriptCall'], but there is no Hook or SignalSlot to do so. I have created my own wizard which comes with a RequireJSmodule, but a wizard has no access to change the $resultArray. Argh!
I have debugged the full rendering multiple times. It is not possible to break in and attach my Module to PageRenderer (SingletonInterface). There are only 2 Hooks within the Inline-Process, but they don't have access to $jsonArray nor $renderArray.

OK...last option: I create my own renderType, but I want to append a generatePassword wizard to the password field of be_users. And you know: The renderType will change if rsaauth is installed or not. So I have to override the original InputElement AND the RsaInputElement. I don't think that this is a very good process to be compatible with further versions. Right?

Maybe it would be good to have something like a boot()-Method before render() will be called or a SignalSlot in SingleFieldContainer.

In general: The complete Form environment should be more expandable.



#1 Updated by Christian Kuhn over 3 years ago

The wizard rendering was not fully refactored and thus misses access to $result. IIRC, there was/is a pending patch by tom that goes into the right direction and the wizards in turn receive $result afterwards.

For the password field: It would probably be a good idea to extract the password stuff from Input element and create an own element from it in the core. This would simplify for instance the integration of a password strength system, too. I'm unsure however how this could / should be done in combination with rsaauth again. Apart from that, neither rsa nor input should get a hook/signal, this would introduce b/w compat issues into these classes again and gives us headaches if we change these classes later.

So yes, for the time being, registering own renderTypes for your case is probably the best solution, this will resolve if the wizard api improves, but there shouldn't be hooks/signals in the single renderTypes again since we do have a clean api to exchange a whole renderType and that shouldn't be spoiled and is the way to go.

So, -1 for hooks/signals at this place, registering own renderTypes is more powerful and flexible, is the proper api to handle own hacks in this area and does not introduce b/w compat issues.

#2 Updated by Riccardo De Contardi about 3 years ago

  • Target version changed from 7.6.3 to Candidate for Major Version

#3 Updated by Riccardo De Contardi about 1 year ago

  • Tracker changed from Bug to Feature

Also available in: Atom PDF