| Project: | Webform |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
Hi,
I'm working on a new component called "nodelink". What it will let you do is select nodes via an autocomplete dropdown, which are included in results. It's going to be used so that users at a conference can get contact information from perspective clients, select a few pages, and have them emailed to them. The output of each selection when rendered will be the title, teaser, and link (though it will be themable).
I'm using some code from the CCK Link module, which I noticed you maintain as well. The code is for a "more links" button to use AJAX to add more links. I've got it mostly working, but additional nodes aren't being included in the submission. I think it's because of #parents not being set up. Would you mind explaining the following from link.module so I can adapt it as needed - it's confusing me :).
// Assign parents matching the original form.
foreach (element_children($form) as $key) {
$form[$key]['#parents'] = array($field_name, $delta, $key);
}I should hopefully have some mostly-functional code soon which I'll post in this issue. Feel free to message me on IRC if you're around.
Thanks!
--Andrew
Comments
#1
I'm not sure how I feel about adding anything with "more" button to Webform. I ultimately wrote the "more" button functionality in Poll module, then helped adapt it for CCK which we now have in Drupal 6. This was based of link.module's implementation. I say this just to put forth the credentials that I know how to setup "more" links in Drupal, but it's still seriously a pain every single time. So I'm hesitant to add a "more" link to Webform, since it's quite a challenge and difficult to automate testing (since Drupal's simpletest.module doesn't support JavaScript testing). It also doesn't make sense that only one field in Webform would support a "more" link but others wouldn't.
While I'm glad that you're putting together this component, I don't think I'll be able to include it in Webform. Webform's API for fields is still very limited and it's not really meant to be expanded much beyond it's current ability. I'd still appreciate if you upload it here to share with others, but maintaining the 12 components Webform has currently is already a difficult task.
#2
I'm now at the point where everything is posting properly, but the values aren't making into $form_values. You're right, a real pain.
Any alternate suggestions then for a UI which allows selection of multiple items? The whole reason I've been going this route is that a long select box can be really difficult for users to select multiple items with, and it's easy to accidentally nuke their selections.
With other modules (views, cck, etc), I'd be able to do this entirely as a custom module. Would you be open to adding / changing the components system so that the include files could be in other modules? That would solve the problem of AJAX callbacks requiring hook_menu (I patched webform.module for that), and mean that you wouldn't actually have to support the code :).
If anyone else is interested in this, please speak up so I can have an idea of how much work I should put in.
--Andrew
#3
I would be *very* keen on switching to a module-based approach to fields. I think it'd be fine to have webform keep its prebuilt .inc files for the bundled fields, but I'd love if everything went through hooks instead (and webform would just implement it's own hook and pull in .inc files for it's own implementation).
It's been on my todo list for a long time and I'd hoped at one point that it'd be in the 2.x version of the module. But things got delayed and I couldn't continue to support the 1.x version, so I axed that portion of functionality (along with improved submission APIs) to get 2.x stabilized and build support for Drupal 6. So I'd be very excited to build better APIs for Webform in general, just keep in mind with such API changes that it'd most certainly be a 3.x branch (really I'd hope to drop support for Drupal 5 in 3.x and prepare for Drupal 7, but if someone is supporting Drupal 5 does the porting then that's fine by me).
#4
Well, I may as well post the code I've done to this point. Unfortunately, it requires a patch to webform so that the include file can add menu items for the autocomplete JS. This would be solved by having it in a separate module that defines it's own menu hook. I still am going to be working on this fairly heavily, but once it's done my goal will be to use it to test porting a component to whatever module based architecture is used.
To use, patch webform.module with the included patch, and add nodelink.inc to the components directory. When adding a nodelink component to a form, you can select the content types able to be searched, as well as choose weather to use the teaser or the body in the display. The search is an improved version of the search in Node Reference. It allows words to be searched in any order, words to be partial matches, and bolds the matches in results so you can see quickly what matched.
#5
@quicksketch: we'd like to be able to extend webform without adding .inc files to the components directory, which is I think what you're talking about when you mention the module-based approach (which isn't *quite* what deviantintegral is after). Adding .inc files to webform's own directory hierarchy is too much like forking the codebase for our liking! It means that upgrading webform becomes difficult because we have to remember what .inc files we added, and feels to me like - if not bad practice, then suspect practice!
Do you think that the key is to crack open i.e. hookify
webform_load_components? If so then we're going to need this fairly soon, so with a pointer or two from you I'd be happy to have a look at producing a patch that could go into 2.x i.e. not change existing behaviour.#6
Possible implementation of
hook_load_webform_componentsnow in this issue here: http://drupal.org/node/340241 .#7
Nice additional feature! Could we include, as a part of this submodule, a simple url or path validation, like what webform does for e-mail, but for a weblink? Either way, this is great, and I'm looking forward to using it in the near future.
#8
I'm not sure what you mean - validate what? The URL is pulled directly from the path tables, so it should be valid all ready.
#9
That sounds right. But could there be an option to have a simple, validated URL as a component for webform? Maybe this should be an entirely different feature request (I didn't mean to hijack your thread, but also wanted to thank you for the new feature).
#10
@bomarmonk, I think what you want would be a different field. Just as for CCK we have nodereference and extlink, I think the same would make sense for Webform.
I'm bumping this to postponed and 6.x-3.x as it's dependent on #340241: Provide hook_webform_component_info() to allow 3rd-party components or similar.
#11
Let's merge this with #308449: User and node reference fields, which I believe is the same request.