Data from external field

I'm afraid I don't have the time right now for such a request. I'm open to review patches though.

I wrote this module for the project I'm working on, but we don't need this feature, and I'm currently pretty busy with other stuff on that project. Then, I'm sure there will be more work on the road, so I don't thing I'll have the time for this feature request unless a bit of time can be scheduled for it. See the note about "Support/Feature requests" in my profile.

I figured a way to do it without any patch to this module. So I'm making this as won't fix.

Here's how:

1) Use the "Autocomplete for allowed values" widget.
2) Use PHP code to generate the allowed values list, and then this code can read the data from wherever you wish, including the DB tables where any other field is stored.

I am currently working on a patch which adds another widget to this module, allowing users to select which field the autocomplete widget looks up values from. I need this for a project I am working on because:

autocomplete_allowvals: restricts users input to the allowed values, and doesn't allow any new values to be added
autocomplete_flddata: allows new values to be added, but then looks up values from the same location

I needed a widget that is able to lookup values from a field that is maintained by us (i.e. not from existing user-supplied field data) while allowing new user data to be stored in the autocomplete widget field. I have disregarded the php allowed values hack as a viable option as it would be a pain to actively maintain that 'solution' across all field using the widget.

I will submit my patch after I have finished testing it...

Re: "I needed a widget that is able to lookup values from a field that is maintained by us (i.e. not from existing user-supplied field data) while allowing new user data to be stored in the autocomplete widget field."

You could use a freetagging taxonomy with prepopulated terms, while allowing users to create more tags. See Content Taxonomy module, and maybe Active Tags module.

Thanks for the suggestion. However, I have my reasons for storing values in a CCK text field (and not as taxonomy terms), and I need a widget that can lookup values from this external field... cheers :)

Committing such a side-edge feature makes the module more complex, while there's already a method you could use to get the same effect. You can use freetagging (telling "I have my reasons" does not invalidate this method), generate the Allowed values list using PHP, and your PHP can take the values from wherever you wish. You can also alter the form, or the callback used for the autocomplete request. So since your approach does not add value and makes the code base more complex to maintain, this is still "won't fix".

Wow, it sounds like you're dead against this idea. So here goes nothing...

The desired functionality for my request is a field widget that behaves in the same manner as the search field widget on http://www.youtube.com. This functionality is actually quite common, not side-edge as you put it. It makes autocomplete suggestions without restricting what a user can enter, it also doesn't expose unmoderated user input. For example, I can enter "nbluerwjgkb" into this field as many times as I like - it will neither reject the value, nor add it to the list of suggestions. I am not using this as a search field, but this is the best real-world example I can think of off the top of my head, so please don't get hung up on the context. I am going to explain why I don't think 'autocomplete widgets' and 'content taxonomy' provide this functionality. I will then explain my approach for a patch, and also why I think my solution is better than other approaches.

Autocomplete from allowed values

What this provides is a text field front-end to what is essentially a select list. It helps the user select a value, but doesn't behave like a text field which allows new user input. Values that aren't allowed are rejected. It doesn't make any difference whether the list of allowed values comes from a textbox or php code, user input that isn't allowed is rejected.

Autocomplete from existing field data

Now this behaves like a 'real' text field. Users can enter whatever they like. For example, if user #112 wants to enter "nbluerwjgkb" they can, however if user #845 types "blue" they are likely to get "nbluerwjgkb" as a suggestion (using a 'contains' match). This isn't really a huge issue, but what if user #112 entered something really offensive instead? Would we want to expose it to users? People enter rubbish. And I have cleaned enough data in my previous role as a DBA to state this as an irreputible fact.

Content Taxonomy

So we've given up on CCK text fields. We don't have a widget which provides the desired functionality, so we'll move all our CCK text field data over to taxonomy terms. Forget any CCK vs taxonomy arguments for the time being, apparently the reasons for using one over the other are irrelevant. We still need to use this field within CCK, luckily the Content Taxonomy module provides a way to do this, as well as its own autocomplete widget (also referred to as freetagging). This widget has two modes of operation:

1. Allow and insert new terms by the user into the vocabulary
2. Deny any new terms

So what we've ended up with now is the same functionality as before, except now we have taxonomy terms instead of CCK text fields. Let’s be sure though:

1. Allows a user to add new terms to the vocabulary. This is the same vocabulary that it looks up values from. So exactly the same functionality as 'Autocomplete from existing field data'.
2. Denies any new terms. Which is the same as rejecting allowed values. So exactly the same functionality as 'Autocomplete from allowed values'.

Try as I might, I can either restrict user input, or expose raw user input to other users. What I can't do is have a widget that makes autocomplete suggestions without restricting what a user can enter, that also doesn't expose unmoderated user input.

Here is my approach:

autocomplete_widgets.admin.inc
+ add a single element to the settings form - a select list with the same options as the existing field select list at admin/content/node-type/[type]/fields. A whopping 17 lines of additional code, but it IS just a form element - not a lot of complication here.
+ set the default value to comply with original 'existing field data' functionality (i.e. default to looking up values from same field that widget is attached to). 2 additional lines of code in form_alter.

autocomplete_widgets.common.inc
+ use the selected field for lookup function. 1 additional line of code.

If we disregard the complication of 17 lines of form element code (it'd be more like 5 lines if we didn't put each array element on its own line, but that’s just coding standard, not a lack of efficiency) we can say (as a benchmark for comparing other methods) the solution achieves the requested functionality in less than 10 lines of additional code.

As you say, it's possible to do this with PHP, using form alters and validation overrides. I would even say it MAY be possible to do it with less than 10 lines of code. However that solution is messy, not portable, and needs a programmer to administer. I believe I have taken the more viable option, and in doing so improved the functionality of the widget by making it more versatile. An administrator is able to select any existing field for autocomplete lookup, and both the original poster and I have reasons for wanting this functionality. I would appreciate it if you could review the patch (its pretty small) with an open mind, considering the needs of other users may not be the same as yours. If you decide its a waste of time thats fine.

Cheers :)

updated: please use this patch instead http://drupal.org/node/564648#comment-3670692

I support as well the request to be able to separate suggestions from user provided terms, while allowing the users to input new terms.

I would suggest two possible approaches:

1. quick and dirty:

add an option to autocomplete allowed values to bypass validation

2. more solid:

configuration options shall be:

         [ ] user is allowed to add new term

         suggestions source:
         ( ) existing field data
         ( ) list
         ( ) php
         ( ) ...

it should be possible to have only 1 widget, as Autocomplete from existing field data and Autocomplete from allowed values could be emulated choosing the appropriate options.

I will be happy to provide a patch, if interested.

I would love to see this also.

I have a node that is collecting information about a person, their current residence, where they were born, and their mother's and father's birth places.

So I have 4 different fields on the same node that is all collecting the name of a community / village. It would be cool if I could combine the auto-complete hints for all four fields.

Thanks!

@djroshi: Thanks for detailed explanation. The patch also seems pretty clean. Thanks. Let's see a bit from the feedback from others.

@xlyz and @phayes: Could you please test the patch and provide some feedback?

djroshi, thank you! that is a good new feature, I will test it.

When editing field with "autocomplete" I get an error, please see attached screen-shot.

I can enter new new value but autocomplete doesn't work.

Autocomplete takes values from another CCK as you suggested.

you could see here:
http://job.paris.kz/emploi/node/add/resume
at the bottom of a page there are fields:
test_autocomplete_3 and test_autocomplete_2.

test_autocomplete_3 takes data for autocomplete from test_autocomplete_2, but only "Astana" value could be autocompleted and 2 others "Almaty" and "Karaganda" don't autocomplete.

I 've forgotten:
user login: "jobseeker"
pass "test"

+  $lookup_field = isset($field['widget']['autocomplete_selected_field']) ? content_fields($field['widget']['autocomplete_selected_field']) : $field;

The invocation to content_fields() here may need to specify the content type, because the table where the field is stored could be different. ie. when the field is selected, you also need to select the content type, and that makes the UI of this feature a bit more complex.

is it patch? or what should I do, I am not too good in programming.

@clashar sorry I couldn't get to this sooner, am now working on a new patch

@markus_petrux thanks, I will try and work around this without complicating the UI - I have a few ideas...

...ok, I have found the cause of the warning (post #14)

The function I borrowed from CCK to populate the existing field select list is this:

/**
 * Return an array of existing field to be added to a node type.
 */
function content_existing_field_options($type_name) {
  $type = content_types($type_name);
  $fields = content_fields();
  $field_types = _content_field_types();

  $options = array();
  foreach ($fields as $field) {
    if (!isset($type['fields'][$field['field_name']]) && !$field['locked']) {
      $field_type = $field_types[$field['type']];
      $text = t('@type: @field (@label)', array('@type' => t($field_type['label']), '@label' => t($field['widget']['label']), '@field' => $field['field_name']));
      $options[$field['field_name']] = (drupal_strlen($text) > 80) ? truncate_utf8($text, 77) . '...' : $text;
    }
  }
  // Sort the list by type, then by field name, then by label.
  asort($options);

  return $options;
}

It is used primarily to populate the select list of the "add existing field" section of the "manage fields" form (CCK). The function requires an argument specifying a valid content type so that it can exclude fields already contained in the specified type from the options list (i.e. so you can't add an existing field to a content type which already contains an instance of that field). We don't need this check for the intent and purpose of autocomplete widgets, in fact we definitely want the fields of the current type included. As far as I can tell it doesn't do anything else with the argument.

I am still testing, but I suspect this warning is just that, a warning. It doesn't seem to break the functionality of content_existing_field_options (i.e. it still returns a correct and valid list of field options), and shouldn't break the functionality of the autocomplete widget.

I have suppressed the warning by passing an empty string as an argument to content_existing_field_options() and will do some further testing to see if this is stable. If it seems to be working I will include this in a new patch shortly.

@clashar apologies again for getting to this so late, I am trying to replicate the rest of your problem but have so far been unsuccessful. As above, I don't think the warning has anything to do with your autocomplete fields not working as intended. If you are still interested I would be happy to help with getting this to work for your site.

Ok, I have tested my fix for #14 and it seems to be working fine.

Regarding #17, the missing argument in the invocation of content_fields() will default to NULL, and won't break anything. Adding this argument would allow users to specify the context (content type) for their shared fields, but I don't anticipate any demand for this functionality (???)

Here is the updated patch:

djroshi, thank you for detailed and kind approach.

I applied your patch and it works great!

Great idea but couldn't apply the patch. This one's the same as #21 but rolled against CVS.

Updated status.

Thanks for that!

This is an incredible addition, djroshi - thanks a lot!

How to mix using more than 1 field? With some calculation like field A + 2* field B * 0.3 ?
How to make "searching value" contains several fields while array key still use 1 field?
From #20:
$options[$field['field_name']] = (drupal_strlen($text) > 80) ? truncate_utf8($text, 77) . '...' : $text;
How to make it to specific length (rather than > 80) ?
How to allow any shared field value except 1 or 2 value?
Drupal has issue with "/" when do searching, how to avoid this with simple replacement?

As I can see it is a complex one, so using PHP value more realistic, especially when we need to port this module and keep this module working with other modules.

Also you create a function into your custom module then use this function in PHP value.