Feature #73123
closed
Fill up Core/Forms with SignalSlots
0%
Description
Hello,
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.
Stefan
Updated by Christian Kuhn almost 9 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.
Updated by Riccardo De Contardi over 8 years ago
- Target version changed from 7.6.3 to Candidate for Major Version
Updated by Riccardo De Contardi over 6 years ago
- Tracker changed from Bug to Feature
Updated by Benni Mack over 4 years ago
- Status changed from New to Closed
Stefan, I will close this one now - as Christian stated: the FormEngine allows to hook into various places now. Although we'd love to add more Events (now), I guess the first goal would be to get rid of the arrays to coordinate the API better.
If you have more specific requests on what you need, I can re-open the issue.
Updated by Stefan Froemken over 4 years ago
I have solved it with two new renderTypes and a new Resolver. In the meanwhile I have accepted the new approach ;-) And there are 3 possibilities to attach wizards. So, yes, this ticket can be closed now.