Select/Textbox/Radio Field

Here is the install file that goes with it.

This was originally set up like the flexinode select field, i.e. it used a numeric key based on the sort order of the options in the textarea. This has a major weakness -- you can't add new options to the beginning or middle of the list once you begin using the field, since the key will change every time the option list changes.

Therefore, I completely re-wrote the field so you can set a key for each field. That way you can come back later and add new options to the list without goofing up data you already have saved.

I also made a number of other changes:

1) I added in validation for the option list to make sure it includes only alphanumeric data for option keys (the labels can contain spaces or any other value)
2) I added in additional validation when the list is changed to make sure an option that has been removed from the list is not currently being used in the database.
3) I created a way for the admin to decide how the data will appear in the form, i.e. in a label and div, in a definition list, in a table, plain, etc. using a selection option and a theme for each. I created these options in a way that I could scrape this whole part of the code out and put it into the content module to make these options available to all fields.

I'd be very interested in having other feedback on this module. I think it is far enough along now that I am going to try it with some live data.

For #3, I meant to say how the data will appear in the node view. The existing field modules just send back the data in a div, with no label. I wanted to give the admin some control over that so he/she could format it differently. Even with the views module (which is really great) to handle things like lists and tables of cck nodes, we still need to configure a way to format the display of the node itself.

I considered that when I started this, but couldn't see any way to shoehorn it into those modules. The whole process of creating, validating, and updating an options list is completely different than creating a text field where the user enters their own content, so it seems to me that this is a distinct module.

Or are you saying there would be another type of module for widgets, that would be called by the text and number modules? I can't quite visualize what you mean.

Another place where this type needs special treatment is in the views module. I set the view up so that it would pull the option value out of the database, but display the label that goes with it. This is again completely different from the way that text and number fields are handled in the view.

I think my other analogy is that a date field is a number, but it clearly is so different from other numbers that it needs its own field type.

I totally agree with the concept, just still having trouble seeing exactly how the code will work. I guess I need an example since the modules that already exist don't operate that way. I will play around with it a bit. What other changes would I make to make it operate the way you envision?

I was waiting a bit to be sure there were no more database changes coming, but am back working on this module. I think I can see how to make it work as a widget, except I need a "widget_view" hook to be called from the content module when viewing the data. (I assume that would not be hard to add.) My plan is to store the option list with the widget instance, which will allow me to do all the validation, etc. that is already in there. With the addition of a view hook, I can also take care of swapping the label back in for the field key when the node is viewed.

The only remaining issue is that the text field automatically has filtering options on it, which don't make sense when the options widget is used. Shouldn't those criteria be moved to the widget instead of the field? That way they will appear when you use a text field or text area widget where the user supplies the input, but will not appear when the data is constrained to a pre-defined list.

To clarify my thinking further...if content module called widget_view before calling field_view, I can have widget_view swap in a label (or labels if it is multi-select) into the $node object before field_view gets $node, then field_view can format the output as it does now.

I'm explaining my thought process as I go here in case anyone wants to jump in to tell me I'm headed in the wrong direction before I get too far down that path.

In working with this, I realize that the option list has to be linked to the field, not the widget, otherwise every time you want to change the widget (i.e. from a select list to a checkbox) you have to re-define the option list, which I'm sure is not what anyone wants to do.

That leads to some problems because the widget only has access to a limited amount of information and only has one or two places where it can take action, as things are currently defined. The widget will need to know what the available options are, if they are not defined by the widget, in order to create the user input form. Plus there will need to be plugins for text and number to give them the necessary functionality to create and validate an option list.

This is all doable, just not what I originally did, so I am backtracking and trying this again.

If anyone has any thoughts about how this widget should work as I work along here, jump in anytime!

OK, I've got at least the beginnings of something here. Thanks RayZ, your comments helped me clarify what I was struggling with. And thanks to others who offered ideas. Here's how I ended up.

The options widget is configured to work with both the text and number fields. If you use it in a text field, you configure a list of options that has text keys which are stored as text. If you use it in a number field, you configure a list of options that have numeric keys, and your selections are stored as numbers in the number field. In addition to being able to input a list of values and labels, I also added an alternative for the number field where you can have it create an option list automatically as a series of numbers from min to max, incremented by increment (you supply the min, max, and increment).

My widget needed to communicate with the field module in several places, so I altered the text and number modules slightly to call the options module, if it is enabled. If the options module is not enabled, nothing will happen. The options module then handles the creation and validation of the options list, alters the view to replace the option with its label, etc. I tried to keep the changes to text and number to a minimum so they aren't weighted down with extra code if someone just wants plain text fields.

I felt it was important to store the options list in the field rather than the widget for several reasons. First, that way you can define a long list of options one time and use it in several different content types (like the list of countries that needs to be used in several types that someone has already requested). Second, if the options list disappears every time you change the widget, I think non-programmers will be completely baffled and are likely to consider it a bug in the way the module (and cck) works. My thinking is that it is really important do things in a way that non-programmers will find intuitive, since that's who this is designed for. Lastly, you might create a list as a select list and later decide to present the same options as a radio list instead without wanting to re-create the options list. If someone really needs a field that has different options, I think it makes more sense for them to create a different field.

To keep the option list from disappearing if someone changes the widget to a text field and then tries to change it back (perhaps accidentally, not realizing what they are doing), I am storing the options list as a hidden field if the text widget is used, and revealing it if the options widget is used, so the value isn't lost if you change the widget. The hooks I put into text and number make that possible.

The validation is not yet thoroughly tested, and I'm sure there are other bugs, and I'm also sure others will have different ideas about how it should work, but anyway, here is what I came up with.

I'm attaching the module to this post, and will supply the patches for text and number right after this.

Here is the patch for number.

And here is the patch for text.

Actually there is also a css file to go with this (not critical, just formats some of the options in a way that I like better.) Here is it.

I agree that a more global way of including widget info would be better. One thought is to create a widget_override function for each field function that needs intervention (maybe using a pattern like widgetname_override_fieldfunctionname.) Then have the field or content modules check whether any widget functions exist with that pattern, and pass them the $form or $output or $node or whatever else is needed so they can do their thing. I initially was going to say only check for the currently-used widget, but that won't be sufficient to do things like maintain the option list if the widget is changed, so I think it needs to be invoked always and the widget can just do nothing if it is not the currently selected widget and it has nothing to change.

In the case of formatting a view, obviously the widget needs to jump in before the field info is themed and returned. In the case of a form, the widget needs to be able to add (and maybe alter) form elements after the field case created the ones it needs. In the case of validation, the widget needs to have a chance to validate the input, either before or after the field has done so, and in the case of update or save, the widget needs to be able to jump in and alter the input value before it is stored to the database. I think those are the times the widget needs access to what the field is doing.

Because some of these things need to take place during the time the field function has control, I think the patch has to go in the field module rather than in the content module, so it won't be quite as neat as it would be if the content module could just invode the widget function after the field function.

If I get a chance I will try to figure out what the patch could look like, but probably won't get to this until next week.

Here's a thought that might make this work with a minimum of changes in a way that should be globally usable by other widgets and fields.

So far I only see two functions that aren't already working fine -- the hook_field_settings function and the hook_field function. Only the field's version of those functions gets invoked, and nothing the widget needs to do in those processes gets done because the widget never gets called.

We could take care of this process by altering content.module when it invokes those two fields so that it checks to see if there is a similarly-named function in the widget as well as the field, and if so, invoke it, too. For instance, there is a function in the text field called text_field and there is a function in the options widget called options_field (I already set the options module up to use the those naming conventions). I then just need content.module to invoke options_field either before or after it invokes text_field, depending on the operation.

1) When creating an input form, call the field first, then the widget (that will allow the options widget to add a list of options to a select element, for instance).

2) When validating data, the order called probably doesn't matter.

3) When saving data, invoke the widget to make final changes necessary just before saving the data, then go ahead and invoke the field to save the data (just have to be sure it doesn't do anything to overwrite anything the widget may have added).

4) When viewing the data, invoke the field first, but have the field return the data it creates as an array or object with a label and a value for each field rather than as formatted output, then invoke the widget to allow it to change the label and value as necessary, then have the content module theme and format the individual fields, and the node as a whole. Think of it like the new form api handles the $form array -- just pass a $view array around to all the modules that need to do something with it, then sort it and process it at the end.

That's my 2 cents, anyway.