GSoC 2019 Coding Period Week 5

Last week, I try to show mentor the demo of property. So, I add a new field to the thing bundle. When the mentor saw that there was no Thing property to add a new field, he asked me: why is there no Thing property? I said Property is in Other of Reference category. But he said it should be shown on the outside, and I insisted there was no difference. Finally, of course, I need to research how to make the Property display on the Other… of Reference. Because he thinks Property in Other… is hard to understand and also Thing property is easier to understand than Property. That’s a reason to convince me.

At first, I thought I might need to implement a Field type myself. The first thing I did was implement a Field type according to Creating a custom field. When I finished the project of example code, I felt that I was not right, or I misunderstood the meaning of the mentor. Because my original purpose of creating this field type was to create a Thing property when creating a Thing instance. However, this feature can be completely completed by using the Inline entity form. The example code on Creating a custom field is extended FieldItemBase, I need to create an EntityReference Field Type and I probably need extends EntityReferenceItem?

I did search the answer by Google: how to create an entity reference field type? Or extends EntityReferenceItem? Then I read an article. Extending a Field Type in Drupal 8. I copied the example code as a simple module.

/**
 * @FieldType(
 *   id = "entity_reference_quantity",
 *   label = @Translation("Entity reference quantity"),
 *   description = @Translation("An entity field containing an entity reference with a quantity."),
 *   category = @Translation("Reference"),
 *   default_widget = "entity_reference_autocomplete",
 *   default_formatter = "entity_reference_label",
 *   list_class = "\Drupal\Core\Field\EntityReferenceFieldItemList",
 * )
 */
class EntityReferenceQuantity extends EntityReferenceItem {}

I get something like this.

I don’t know why Content, User, Taxonomy term is displayed twice. Maybe it’s because of incomplete code. But even though I created the FieldWidget and FieldFormatter as an example, it still doesn’t change the display here, maybe the example code was created too long ago, and some interface behavior has changed. Not only that but if I implement a field type myself, I won’t be able to use Entity Reference’s FieldWidget and FieldFormatter any more. If I don’t create a FieldWidget, I won’t be able to use it.

.

What makes me most curious about the example pictures is why the three options of Content, User, Taxonomy term are different from file and image. I spent a lot of time looking for similarities and differences. I use xdebug to find the information I want.

I see what this method does.

/**
 * Indicates whether this entity type is commonly used as a reference target.
 *
 * @return bool
 *   TRUE if the entity type is a common reference; FALSE otherwise.
 */
public function isCommonReferenceTarget();

And found very important information.

/**
 * Indicates whether this entity type is commonly used as a reference target.
 *
 * This is used by the Entity reference field to promote an entity type in the
 * add new field select list in Field UI.
 *
 * @var bool
 */
protected $common_reference_target = FALSE;

This is why they appear on Reference the top of ‘Other…’. I added this line of code to the code @ContentEntityType().

common_reference_target = TRUE

I don’t have to create a Field type. The effect looks something like this.

We also discussed whether Thing property should be hard-coded. To do this, I have to find a file like IETF RFC. Because it will use key words “MUST”, “MUST NOT”, “REQUIRED”… More accurately inform what implementations need to be done. So I created an issue Define which members are mandatory vs. optional for the wot project on github.com.The reply from the maintainers of the wot specification is:

I’m afraid the unofficial specification we maintain at https://iot.mozilla.org/wot does not yet have these kinds of formal definitions like an IETF RFC might have, although we should probably at least specify which members are mandatory (I’ve updated the title of this issue to reflect that).