-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RTM] add hook so you can modify the form #18
Conversation
Ah, now I know why :). Obviously you need to execute that after any |
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 |
I'm fine with your proposed change. Why did you choose to store the |
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 like! :) |
👍 Will you release it as |
Yep! |
Thank you! Released in |
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.