Functions required:
drupal_hook_form_alter()
why? To check to see if fields are or are not null (note that "drupal" will be replaced with a suggested module name for anyone who thinks that this should be modulated)
dropdown()
Preferred/chosen method, due to its being concise. For larger sites, it would probably be best to use some kind of auto-complete function
foreach()
This is used to fill the drop-down with options (the variable $option will be used)
submit()
To initiate actions which will fill the form in question with the user entries made herein
preview()
For users to temporarily store their progress
cancel()
To funnel users back to the previous page
Variables:
string $name (more than one will be used per page; so, each drop-down menu will be named)
array $option (it is most convenient to list the options as an array)
string $selected (these are the values that will be passed upon submit)
$dropdown (the entire menu will become an object)
Dropdown selects that return strings.
Suggested variables and integers:
node ID
To know from where to pick up and send data
node ID_field(s)
To identify which fields are null via drupal_hook_form_alter(). The fields must be dynamic (readable from a database) for data mining
$option
To show a list of possible selections and keep consistent vocabulary ($option is the list of all elements of the drop-down list)
node ID_field #of field options
To restrict the number of maximum entries
2
Maximize the number of suggested fields
node ID_field Boolean_locked
To restrict users from editing or adding to locked fields
Boolean_subscribe
Do you want to be notified when your request is responded to?
Here's an example:
| Existing: common name | Existing: pitbull, dogface Link: suggest additional common names or values |
Edit |
| (Auto-completer) *All first-line items below this point happen within a one-line text field |
(Auto-completer) *All first-line items below this point happen in a one-line text field |
Submit |
| suggested option: genus | ||
| auto-complete option: coat type | ||
| selected: color | typed: b blue, brown array of all possible items to link-in, beneath, if less than 10, or 10 most likely items (i.e., if dogs were only rainbow colors and brown): red, orange, yellow, green, blue, indigo, violet, brown Link: Suggest additional values (auto-activated if the returned value does not exist in the colors array) |
|
| All values for the left-hand, if less than 10 are remaining, or a list of 10 suggested fields: number of teeth, tail length, height, spot patterns, endangered species rating, dispositions, favorite temperature, favorite bedding type, maximum age, favorite snack Link: suggest additional values |
And the "add new" page:
| What term(s) do you want to add on the left-hand side (one at a time, please) | gender eye color |
Remove Add |
|
| What terms would you associate with each field (one at a time, please) | genders
eye colors |
male female neutered red |
Remove Remove Remove Add Remove Add |
| Are you sure that another term won't work {click here to read more}? Where it is not self explanatory, why do you feel that these fields need to be added. | Because fields for gender and eye color do not exist, and even though they're dead obvious, it's strange not seeing them here. | No reason. |
Need a lot of work on the code. Sorry.
function nullFieldAddition_form_alter(&$form, $form_state, $form_id) {
if ($form_id == 'user_register', $element == null) {
echo $element;
}
}
if node ID_field !null {fill}
elseif !locked AND null {fill}
submit()
preview()
cancel()Thank you, for reading. I hope that you can see what I am working toward and why it would be incredibly useful for all types of sites and users. You can probably also see why it would be difficult to create this for an intermediate user, at best.
I appreciate any and all feedback, expansions, tutorials, thumbs up, fame, pushes in the right direction, refinement, examples, criticisms, humor, etc.
Comments
I don't understand most of
I don't understand most of the code (if that's what it is) in your post, but to answer your initial question… No, there is no simple way to allow users to add values to multi-value CCK field elements without fubaring other things. However, it is possible using Taxonomy module's free tagging option, though that may not be the functionality you're looking for.
The Boise Drupal Guy!
That's not the functionality.
That's not the functionality. Honestly, I worked on a lot of fresh code, and my girlfriend trashed it on accident. I'm just getting back to it, now.
Right now, there's something called "hierarchical select". I'd like to use hierarchical select on fields, as well as field values.
Yeah, it's a bunch of fubar code, right now, above. I thought it over some more.
I reworked some of the variables, and I came to realize that a text input box with an auto-complete function would be better because the drop-down lists could get quite lengthy. A list of acceptable terminology would need to accompany this.
As far as the "acceptable terminology list" is concerned, it would need to decrease and increase in phases and preferably auto-fill, on either side because A) some of the lists would be rather lengthy and B) some of the terms could not feasibly exist simultaneously on either side. I'm going to induce some assumptions about wildflowers/herbs and create an example for both sides in B: Left side gray out and auto-fill based on right-side criteria: ferns cannot have bark and reproduce by the "alternation of generations" life cycle; therefore, the "bark" criteria should be removed from the "acceptable terminology list" and auto-complete function, and the "life cycle/"alternation of generations" field should be auto-filled.
Prune and expand "acceptable terminology list"
The acceptable terminology list should begin with a short list of recommendations or be a complete list, if the list is concise. Otherwise, there should be a three-layer option with two buttons. Layers: show the entire list ("list all"), prune ("show recommended only", and "show none"). Buttons: "expand" and "prune".
This is necessary, and all of the following should be taken into account:
1) Having short lists only: Having a short list with no option to show the complete list may cause users to attempt to add terminology that already exists.
2) Having expanded only: Having multiple expanded lists with thousands of terms may overwhelm a user and slow down a user's machine, significantly.
3) Having no list: Users will try more frequently to add synonyms, resulting in additional work in revision reviews, additional work for the users, and fewer fields filled overall.
4) Storing complete lists on outside nodes: Users would be upset if they had to redirect, and it destroyed their progress. Users may have pop-up blockers. Lists on list-dedicated pages would be lengthy and require this functionality and other functionality that goes hand-in-hand with this technology, anyway, to add to the user experience by reducing manual search and page load times. For example, terminology-dependent terminology filtering.