Hi,

I'm currently creating new Webform components for a project. For one of them I'd like to allow the editor to add an unlimited number of options (for a kind of selectlist) with an "Add more" button -- that button should add one new row with AJAX in the Edit component page.
Look the attached file, there is a (very) simple example. In this mockup I've only added one textfield for each row, but I hope to add more fields, for example an upload field to attach picture for each name.

The problem is that I can't really do that (AFIK) because in _webform_edit_component() hook, only $component is available as parameter, no $form_state.

I've hacked my local instance of Webform module, in includes/webform.components.inc line 577 I have added this:

  // Add the fields specific to this component type:
  $additional_form_elements = (array) webform_component_invoke($component['type'], 'edit', $component, $form_state);

And, of course, now the hook implementation in my custom module starts like this (note the 2nd argument):

function _webform_edit_mycustomcomponent($component, $form_state) {

Unfortunately, if doesn't go as well as expected, maybe because $form_state and $component are not updated. My example code is based on the Example project.
What could be done to allow AJAX (and $form_state ?) in the "Edit component" form? Is there a good reason for not passing $form_state in this pseudo-hook?

Thanks in advance

CommentFileSizeAuthor
Capture du 2015-08-18 11:39:53.png43.95 KBTAT_Audaxis
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

TAT_Audaxis created an issue. See original summary.

DanChadwick’s picture

Category: Feature request » Support request
Status: Active » Fixed
Issue tags: -components, -custom hooks

If I understand your need correctly, try the technique used in the new markup component's support of tokens -- install an after_build handler. The after_build handler has access to the $form_state as a reference argument so that you can change it.

If this doesn't meet your needs, please reopen this issue with your analysis.

TAT_Audaxis’s picture

Thanks for your answer, Dan!
I didn't know the #after_build handler, and I spent the afternoon playing with that.

Unfortunately it also has downsides: I've noticed it breaks JavaScript; even a simple field with "#type" => "managed_file" isn't correctly rendered when it's moved from main "form()" function (here, _webform_edit_component() hook implementation) to the function called by #after_build.

Now, two solutions for me:

  1. Try to play with form_alter on "webform_component_edit_form", even if I'm not sure if it will work and how to distinguish one component form from another.
  2. Always display 30 rows of options and hope that the editor will never need to add more than 30 options ;)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.