in the issue "Introducing %value (previously %submitted) token to load submitted values", the original resquestor wanted to use values from the completed pages of an unsubmitted form for calculating default values on subsequent pages. Similar to this, I would like to use values from completed pages to pass as view arguments in the "Webform View Reference" component. Because I want to use the values from a select options component with "multiple" checked, I also need to be able to handle value arrays in the token filter. In my testing, the %value token did not work with unsubmitted forms.
I have created the code to introduce two new tokens:
- %pendingvalue[<form_key>]
- %pendingkey[<form_key>]
I have also added code to handle the following multiple value handlers:
- %implode(<delimiter>) - (I think I would like to rename this one to be more end user friendly)
- %element(<element_key>)
- %first
- %last
We might also want to add %min and %max
So in my case, if I want to create a "Webform View Reference" component showing nodes filtered by the selected values of a field called node_type on page one, I could pass the view argument:
%pendingkey[%implode(+),node_type]
This would result in a valid view argument such as:
page+story+blog
I am new to Drupal so I need to figure out how to create a patch. As soon as I do this, I will upload the code changes as a patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | webform_module.zip | 30.51 KB | johnnydigit |
| #2 | pendingvaluetokens-1241986-4835538.patch | 6.45 KB | johnnydigit |
Comments
Comment #1
johnnydigit commentedI've created a patch. I hope this is correct;
Comment #2
johnnydigit commentedHere is the patch. I seem to need to create the comment before I can get the comment number for the recommended file naming convention.
Comment #3
johnnydigit commentedI'll also include the modified file, in case my patch isn't correct
Comment #4
johnnydigit commentedI should add that I changed %implode to %separateby
Comment #5
quicksketchI don't plan on adding any of the described functionality to the Webform project. I would suggest helping review #428982: New hooks for additional token replacements, which would allow you to create your own tokens in a separate module.
Comment #6
johnnydigit commentedI'm not sure that that issue will help. Most of the discussion in that issue seems to be around creating support for tokens from other modules, especially the token module. What I need specifically is new webform tokens.
There are two reasons why a hook module would be unlikely to work:
To do what I need, I would need access to the $form_state array and I doubt it would be included in any hooks that were created.
I suppose that there are really two different issues. 1) I need access to entered values (keys actually, at the moment) before the form has been submitted, and 2) I need a few basic array extensions for tokens. I have already thought about a different implementation for the array handling and I suspect that I could probably figure out how to change the syntax ro look more like a subscript. i.e: %pendingkey[%element(0),node_list] could look like %pendingkey[node_list][0] (I'm pretty sure I can nest this functionality) and %pendingkey[%separateby(,),node_list] could look like %pendingkey[node_list][%separateby(,)] I just need to play with my regular expressions more.
Assuming that I could contain my code in a hook module, I could implement my array handling in that module, specifically for my tokens. I have seen at least one other issue, though, where the ability to navigate an array in a token has been requested. I don't actually need any array handling other than %separateby() right now, but I thought I would build everything that I might eventually need. To implement a generalized hook module for array handling, I would need access to both the $safe_replacements array and the passed string in _webform_filter_values.
Comment #7
quicksketchHmm, in which case I simply don't think this feature will ever be available in Webform. I think that the edge-case need of the tokens you're describing would be better off handled by custom coding rather than end-user tokens.
Comment #8
johnnydigit commentedActually, I see that I could have access to the $submission object if I turn on Autosave. What are the chances that a token hook would include access to the $string variable?
I have volunteered to maintain a website where, it turns out, the existing data collected in webforms is semi-permanent in nature and the effort in processing the data in spreadsheets ins defeating the purpose of collecting it.
Professionally, I support the use of a vendor supplied 5th normal form RDBMS. Using the Webform MySQL Views, Data and Views modules, along with a modified version of Webform View Reference Component, I have almost all the functionality I need to allow various volunteers to select the data that they want to process.
The point of using 5th normal form in the vendor package is to support the rapid design and modification of data models and supporting data entry forms. I want to continue using the Webform module for these same reasons. The use of these tokens would allow the recognition of inherent relationships between a Webform and other Webforms or tables inside the Webform module itself.
I suspect that this is not a direction that you have considered for the Webform module, but you are 90% there already.
Comment #9
quicksketchYou can do any token filtering you like in the theme layer if you're comfortable with the performance impact that may have. In any case, this question has gone outside the scope of support in the Webform issue queue, as I don't help with custom coding and this isn't going to be a feature implemented directly in the module.
Comment #9.0
quicksketchEdited to show content encapsulated in angle brackets