Provide a way to define default values for entity fields

#1803064: Horizontal extensibility of Fields: introduce the concept of behavior plugins gives an example use-case of "prepopulating" values.

Question is whether the default value method should go into entity-interfaces or typed data interfaces.

Doing at typed-data level would make it possible to easily have default values for entity.field_text.0.format or so as well, so I guess it would be valuable to do so.

I think we have a really huge Drupalism/DrupalWTF problem if an essential OO concept like default class property values ceases to work. Replacing all object properties with class instances is a very weird concept already, but it is borderline acceptable as long as PHP developers only need minimal adjustments to cater for it.

Destroying the native concept of default values of class properties, however, is really too much IMHO. It's the tipping point at which PHP developers will reasonably blame Drupal for "Re-inventing OO in user-land PHP code" and a PHP class is no longer a PHP class. That's definitely detrimental for Drupal's health and future. A lot of the TypedData abstraction essentially exists to work around PHP's lack of primitive data type support, and PHP developers will already blame us for inventing and doing that; one doesn't have to look very far to find answers from PHP developers who strongly recommend to NOT do what we've done, for plethora of very good reasons; performance being a major one, and as you know, we're experiencing the consequences in various benchmarks already. Also, following the entire logic, one can only guess that one of the next steps is to invent polymorphism and mixins in this user-space OO layer (because, really, what prevents us from doing it? Nothing!) - ultimately rewriting PHP's native C code for OO support in PHP code.

I believe that this should ring all available alarm bells, and instead of abstracting even more, we should try hard to scale things back where possible.

Why can't we do something like this?

Re-inventing OO in user-land PHP code

I don't think we are re-inventing it - we are leveraging it and we are OO-ifying stuff that's not OO-ified in the language. But yes, I fully agree that we should avoid making typed data an abstraction layer above PHP-classes, but embrace them. See related #1867880: Bring data type plugins closer to their PHP classes.

However, PHP lacks a way to define an object as default value for a class property. Thus, we have to care about that ourselves somehow.

The patch suggested in #6 has the following problems:
- It suggests a simple value for a property, e.g. 'string', where it will be an object holding the string. Thus, the specified default there is wrong as an entity field will never be simply that value. But moreover it implies to devs that the object property / entity field would be just a plain string, what's not TRUE and so a DX WTF.
- We need to support dynamic values also, e.g. to support field API default values or simple cases as date fields defaulting to NOW. That could be solved via hook_entity_create() as discussed at #1253820: It's impossible to submit no value for a field that has a default value, but having it in a class method would be more straight-forward imho.

Default values can be at different levels, e.g. we can have

$entity->langcode have the default of array(0 => array('value' => und)) or we can have $entity->field_text->format default to the default formatter *if* a new item is created.

So it makes sense to specify the default value for the fields of the entity as well as for the values of an item, such that those are created when the whole structure is created. But it does not make sense to have default values for an individual item or a list. If you create an individual item, e.g. $string you either provide a value for it or not - I do not see it useful to have a $string to default to anything ;-). It only makes sense if a property is created as part of a complex data structure and no value for a property is provided.

added tests for default language & uuids.

re #13, yeah I just copied this comment over together with the uuid-related code borrowed from UuidUnitTest

#12: d8_default_value_12.patch queued for re-testing.

Re-rolled patch and fix the comment at both places.

The last submitted patch, d8_default_value.patch, failed testing.

The last submitted patch, d8_default_value.patch, failed testing.

Updated the patch since the latest changes (notify+term-ng). I slightly improved the approach such that field item classes can define their own default value, i.e. moved language defaults to the language item and analogously for uuid-fields.

The patch triggered some problems of #1869562: Avoid instantiating EntityNG field value objects by default, so I debugged this and fixed those. Looks like there are quite some fails left with node-ng and term-ng related issues - let's track them down too.

The last submitted patch, d8_default.patch, failed testing.

Raising to major because of #27. It's a major (if not critical) bug for non-form-based creation of nodes to throw errors.

#1957888: Exception when a field is empty on programmatic creation is already major

See the interdiff's in #1818570-38: Convert users to the new Entity Field API and comment #40 for a fix for the failing forum tests.

Also, most probably not for this issue, but I'm a bit perplexed at the "default NULL values for all field items" behavior - i.e, an "empty field" is a Field *with* a FieldItem, that happens to have NULL properties - why is that exactly ?

"empty field" is a Field *with* a FieldItem, that happens to have NULL properties - why is that exactly

We've an empty field item object by default such that this gets cloned during prototyping the field object, thus speeds up getting further field objects.

Besides that, does this patch extend the behaviour to initialize a single field item as an array with NULL properties on entity_create(). I think having one field item by default is reasonable, as that way you can easily add a field item class with a given default - see the language reference field in the patch for example. Still, you can define defaults having multiple field items using the 'default_value' setting or by overriding applyDefaultValue() of the Field class.

(+ may I bikeshed that maybe 'filter empty" is more explicit than "clean" as to what the function does ? filterEmptyValues() maybe ?)

Good suggestion! I re-named the method and added in your more stream-lined implementation :-) Also fixed the remaining test fails and updated the patch.

The last submitted patch, d8_default.patch, failed testing.

#39: d8_default.patch queued for re-testing.

Isn't here a return $this; missing? According to the function documentation it should allow chaining.

Shouldn't that be "Only do a shadow copy if this is not a new node."?
The word "check" seems to be a leftover from an earlier sentence.

That's all I've found so far :)

As discussed in #1957888: Exception when a field is empty on programmatic creation, the check there is actually correct. And this issue will need a re-roll once the other one is in :)

It's not an improvement :)

The previous comment is correct as explained in the other issue, in case the node is not new, we are *checking* if we have to create a shadow copy.

Talking about applying a default value for UUID is a bit weird as we're actually generating a new one here but can't do much about this.

This would allow to both set the default for the first field item and also multiple values. Not very intuitive, should we document this better here?

In case of configurable text fields, it depends on the configuration of the field if it should be NULL (check_plain(), or filter_default_format(). Should we respect that here?

We can also do it in a follow-up, but then @todo should be slightly reworded I think.

Patch nicely shows the code duplication of entity reference/term/file/image fields. There's an RTBC patch that converts term to extend from entity and use target_id and a green needs review patch for files/images. Would be nice if that could go in first I think, I hope that happens soon.