Closed fritzmg closed 6 years ago
However, what does not work is stuff like this:
$objForm->getWidget('SALUTATION')->label = 'Foo';
Though I do not really get why.
Ah, now I know why :). Obviously you need to execute that after any addFormField
calls for example, or more accurately anything that marks the form as "dirty", since this will cause a regeneration of the widgets later on.
I think about to use events instead of an old hook (at least for the version for Contao 4). What do you think about?
Fine by me :). Haven't worked with events yet as a replacement for Contao Hooks.
I have updated the PR using events instead of hooks.
Usage example:
# src/AppBundle/Resources/config/services.yml
services:
AppBundle\EventListener\MailChimpModifyForm:
tags:
- { name: kernel.event_listener, event: contao_mailchimp.modify_subscribe_form, method: onModifySubscribeForm }
// src/AppBundle/EventListener/MailChimpModifyForm.php
namespace AppBundle\EventListener;
use Oneup\Contao\MailChimpBundle\Event\ModifyFormEvent;
class MailChimpModifyForm
{
public function onModifySubscribeForm(ModifyFormEvent $event)
{
$objForm = $event->getForm();
$objForm->removeFormField('submit');
$objForm->addFormField('lorem', [
'inputType' => 'explanation',
'eval' => [
'text' => '<p>Lorem ipsum dolor.</p>',
'class' => 'lorem-ipsum'
]
]);
$objForm->addFormField('submit', [
'label' => $GLOBALS['TL_LANG']['tl_module']['mailchimp']['labelSubmit'],
'inputType' => 'submit',
]);
}
}
Yeah 🎉
One additional thought: I added setter methods to the event object. This would allow you to set a completely new form object in the event listener. However currently it would not be used. The following would need to be added:
// event: modify form
+ $event = new ModifyFormEvent($objForm, $this);
System::getContainer()->get('event_dispatcher')->dispatch(
ModifyFormEvent::SUBSCRIBE,
- new ModifyFormEvent($objForm, $this),
+ $event
);
+ $objForm = $event->getForm();
@bytehead what do you think?
// edit: Also may be the setter method for the Module
object does not really make sense
I'm fine with your proposed change. Why did you choose to store the Module
object in the event in general?
Why did you choose to store the Module object in the event in general?
You could have several different signup and unsubscribe modules and you might want to only modify specific ones, using the module id, or module css class etc.
I have ultimately decided to remove the setters altogether ;). I couldn't think of a good use case where you would want to return a completely new form. I want to keep things simple and straight forward.
@bytehead any comments? Otherwise I'd consider it RTM
I want to keep things simple and straight forward.
I like! :)
👍 Will you release it as 4.4.0
?
Yep!
Thank you! Released in 4.4.0
.
This would allow you to modify the form to your needs. Example:
However, what does not work is stuff like this:
Though I do not really get why.