Default values

This should be working right now. A general hook turned out to create too many problems because core field can contain no information to tell CCK whether it is handling the default value or whether some other module is. I ended up doing something very simple in core -- create an instance setting for the name of a function that will provide the default value and then use it to populate the default value in the form. There should be no reason for more than one function to be needed there or for one module to override another. And a module that creates a custom field via the API can insert its own function name, as can fields that want to handle their own default values. CCK then looks for fields with nothing in that setting and only provides default value handling for them.

CCK is now tracking some 'settings' that core doesn't care about, like the old 'default_value' hard-coded arrays and 'default_value_php' for the code snippets, so I created a simple table to store that information in. Then CCK acts on its default value function to look the information up and return the right value.

My intention was that if there is no function or the function doesn't return anything (like for a disabled module) there would be no default value, and that having no default value would be the default behavior.

- So a module can create a field via an API and populate that value with the function it wants to use (that much should be working right).

- A field module, say 'Date' module (the example I am trying to work with) can set instance values for CCK's API via hook_field_instance_settings_form(). Which should take care of fields created by the UI that need their own default value handling.

- Any if that setting is empty, CCK will assume it is supposed to handle it. Which should take care of all other fields.

Maybe I've missed something, but I thought I had everything covered. I also thought I'd try to get the Date module ported to D7 so I can have an example of a module that is outside CCK which wants to handle some of its own values to test this more, but I may not get this done right away.

The concept needs to be examined since it's a new way of handling things. The real challenge when I dug into it was to come up with a way for CCK to know when to step in and when not to, since the core code, and the core field modules, don't know or care about CCK, so they won't provide any clues.

Actually the next step I thought of was to add a textfield for the function name to the CCK UI. You could insert or remove a custom function as an alternative to providing an array or a PHP snippet. So there would be three ways to provide a default value via the UI. If you put a function name in there, CCK would just allow you to edit the function name, not do anything with it (no default value widget would be created).

Then if there is a function name used, that function will be called by Field, otherwise the CCK function will be used.

Argh, except if the field provides a default value function, it would want it to be 'locked', so adding a place where it can be changed would break that.

Such a simple thing can get very complicated.

Anyway, go ahead and make changes if you have ideas.

The 'Allowed values' code is handled in a similar way -- core has a setting for 'allowed_values' and 'allowed_values_function' and CCK provides a place to input PHP code and handling to return it in response to the core invocation. Most of that part was committed but I went ahead and committed everything else I had. Try both of these out and make suggestions on how to improve them. The issues for each will be the same:

- How will CCK know when to step in (currently by testing if the function setting is either empty or set to CCK.)
- How much of this belongs in core (possibly just the function name setting and nothing else, and core would do nothing but invoke that function if it exists).
- How do we allow other modules to set those values without creating problems for CCK?