<snip>
Also, we should examine the four after_build calls that remain. I suspect they can be replaced by other constructs now and if so, we should mention in the doc that this is deprecated.
Finally we should make it clear when to use _value and when #process. The question is, can we do everything we do in _value with #process ? I think the answer is yes however it still looks like a healthy split -- if you just want to assign #value then use _value , if you want to split your element after #value is in place, use #process.
</snip>
Yes, it is confusing to know when to use _value and when to use #process, and yes you can do everything you can do with _value in #process and much more, so it might be useful to figure out when to use which. Actually I had the same question and eaton and I went back and forth in IRC on the reasons, and he finally said he figured _value and #value_callback were screwdrivers while #process is a jackhammer, and that is a pretty good analogy.
The advantage of _value is its simplicity if all you want to do is set the value. You don't need to know anything about how the form or form_state are configured, you just test if there is a submitted value to know whether you are working with a posted value or not and return whatever you want the value to be.
#process is more powerful and more complicated -- you get the whole $form_state and you need to know how to extract out of it the information you want. If you want to alter the element itself or do anything other than set the value, you must use #process, _value won't work for that.
Maybe I should add something like that to the tutorial?
On the 'four after_build calls that remain', which four are you talking about. Do you mean #after_build, #pre_render, and #post_render? I can't think of a fourth. And yes, if we want to deprecate anything, it would be good to mention it here.
Karen
