Using Webform View

Webform View is a module that allows you to embed a view as part of a webform. Form elements (checkboxes, quantity selectors) are inserted into each result row. Data in this view can then become part of the data submitted in the webform submission.

The primary use-case this was built for is to enable a webform to be used as an order form where a user can select  items displayed in the view, and request those resources or register interest in them in a way that the reciever of the submission can work with.

Desired workflow:

• A website administrator can publish information about resources (pamphlets, publications) or even products or topics as nodes on the website. This can be added to at any time.
• A view is created that lists these items. Full UI control of that layout uses normal view and template tools.
• A webform is created that displays that view, and includes either a checkbox or quantity field next to each item.
• When a user submits the form, their requests for each item are registered. Data on the submissions is managed using the Webform UI controls.

Execution:

Was hard. Webform doesn't natively support multiple/unlimited selections very well, and doesn't like the available options being dynamic very well. Although with recent developments in the webform+select+views options, a simple list of options can now be supported, anything more (item+quantity data) is still out of reach.

Instead, an extension to webform (described above) was developed. To work, it has to do some brain-surgery on both the display and the results processing. This is described here. Although there are now several moving parts that have to be configured, this was engineered to produce the desired result in a highly re-usable and configurable way.

Usage (overview):

• Create your resource content type.
• This content type should include an extra "can order" sort of field, which may be used to indicate where the per-row webform elements get inserted in displays. This is an additional field "render mode" called "webform placeholder" that will be available for some content fields Create it as a type:"Boolean" widget:"single on/off checkbox" field. Set its default value to TRUE. The flag and custom field is managed like this to provide maximum compatibility with normal UI-based display management and positioning options.
• Create a view that lists your resources. Configure its display. A 'page' type display will be fine. This view should be able to use either node display or fields, as well as alternate view modes or display_suite based displays as needed.
• Create a webform that users can use to order resources. This should contain contact details etc as needed.
• Embed the view into the webform (new functionality). This is done using a new webform element "Embedded view".
• Add additional webform fields as children of the view element (as if it were a fieldset). These fields will be propogated to create new webform fields for each item in the view.
• Go back and edit the view display to configure where these webform fields (the "webform placeholder") should be placed in the display of the view. This gives you maximum layout control in how your final form will look.

At this point, using the webform should merge all functions together. Viewing the webform should display the view, and include form fields in the layout location of the "webform placeholder". Submissions to this webform should save the values for each item in the view. Generated emails should list each selection.

Usage (full setup instructions):

1. Download/enable required modules.

   • Webform
   • Views
   • Field UI (core)
   • Options, and List (core) - for the checkbox
   • Webform View

   Though not required, for this demo I'll also use

   • file (core)
   • image (core)

2. Create a "resource" content type.

   

   Add some basic fields, eg file and image.

   Add our marker field. "Can order" as a Boolean checkbox.

   Under "Field Settings", set "On Value" to "Can Order" and "Off Value" to "Cannot Order". Then set the default value to "Can Order".

3. Add some sample resources.

   For variety, I'll show one that is available in hardcopy-only, one that is download-only, and one that is both. This is enabled by our "can order" checkbox field.

   

4. Create a view that shows these items.

   Just a view that filters on type:resource will do here. I'll use a table+fields view display for now, though I'd recommend using teasers (or view mode) display most of the time. 
   You don't need a 'page' display, and some views options like paging will not work in this context, so leave them out.
   
   
   
   With a small amount of adjustment, we get a view that produces this:
   
   Note our "Can order" field will be where the webform will do its thing soon.
   This is the view we will embed in our webform.

5. Create the webform.

   Add whatever normal fields you need in the webform for submission as usual.
   

6. Insert the view into the webform.

   Here use the new webfrom view webform component "Embedded view". I'll call it "Order"

   In the options for this field you should choose the "View" we just created. The "Master" display should be adequate.

   

7. Add webform fields as child elements to our embedded view.

   These fields will need to record at least
   A: the item name,
   B: the request submitted with this form.

   So add two fields. Importantly - they must be positioned as children of the view.
   The item name will already be apparent to users, and should not be displayed as a field, so make it hidden. (We will have to fill in data there ourselves, see below)
   
   I'll add a number "Quantity" field here too, though a checkbox would also work for some cases.
   

   A required field (eg quantity) must also be chosen. This is set in the settings screen for the embedded view component. When results are saved, any row with a blank 'quantity' will not be saved, only rows with options actually entered in them will. If we don't filter, then all the submission results list all rows each time, even if quantity was zero, and that looks messy on email notifications etc. You can only choose which field is required after adding all child fields to the parent container. This means visiting the same settings page twice.

8. Get the item description into the webform fields.

   Sorry, This is one extra fiddly step, used to ensure that the text in the submission results names the selected item appropriately.

   1. Edit the hidden "Item requested" field and get it to use a token that will be deduced from the view data it is being applied to.
   2. Set its "default value" to the string "[node_title]".
      

   This was required as various view_modes and views rows may have different data available. For example you may want to add a "[field_field_sku]" or "[nid]" there as well to better identify the resource in question. User-created fields are available as [field_${field_id}] so the syntax often is [field_field_something]. This is from the way views internals names its values. [node_title] is only available in field-based-views, not teasers or view-modes! Arg? This is because, internally, the view doesn't make that data available at this point in rendering.

   There is a work-around. This is not needed in field-based views, where the value of each rows field should be available as a token like this.
   If using teaser-based views, Add an extra "Sort criteria" to your view definition. Sort on "Content: Title". This is enough to make the above token have some data to work with, even if the sort cirteria is weighted lower than the "Post date" - effectively making it an ineffective sort.

9. Conceptual re-cap

   These fields, which we have defined using the webform UI, need to be displayed as part of a view, which is in turn being pulled in and displayed as part of a webform.
   So, when submitting the webform, the data for each item in the view will be submitted and saved as part of the webform submission.
   So far, we have used normal Views UI and normal Webform UI to set up all the pieces.
   What remains is to glue them together.

10. Here is how that works.

    1. Configure the view to embed webform components.
    2. Go back to the view configuration.
    3. Change the "Formatter" option of our "Can order" field to use "a webform placeholder" as a display option.
       
       This display option is provided by webform_view, and marks where the new fields will be displayed.
       Your view preview should now look like this:
       
       You will not see the complete webform in the Views UI preview - it will just show the placeholders. HOWEVER, when that view is embedded in a webform (as configured earlier) those placeholders should now be displayed as form fields:
       
       And we have WON!
        
11. Using that form should now produce meaningful submission reporting, emails and records in the webform data management tables.