Would it be possible to store additional data in the properties information for an entity type? Currently the addProperty method (EntityType class) only allows to save name/label/type/behavior, and all this keys are hard-coded.

For example, I would like to store a required state and a default value.

Comments

fmizzell’s picture

fmizzell commented

In 3.x we allow a flexible schema, and we infer some of these information from the db schema. So, if the property is NOT NULL in the db, I would assume it is required, and defaults are also enforced at the db level. We could do something like that in 2.x, but I wonder, given all the work you are doing, if pushing 3.x to be stable enough for an alpha or beta would be a better option. Is that even a possibility for you @mihai_brb?

mihai_brb’s picture

mihai_brb commented

I did not followed updates and changes but from what I tested yesterday the 3.x is easy to extend and the place where I would add my settings is in the widget settings. However it's not as easy to understand/configure for a web builder perspective. The configuration is all over the place :) I think a unified UI to configure the behavior and widget settings will help a lot.

I have a sandbox with most-used behaviors for 2.x here https://www.drupal.org/sandbox/mihai_brb/2254845
As soon as we have a beta for 3.x I will update all behaviors/widgets.

What would be great is if we could have the same schema saving system in 2.x. I could then save settings there by simply altering the schema form.
For example one of the behaviors allows referencing entities. The entity that is referenced is actually stored in the property name (id_{entity_type}) but the "required" state or any other settings are stored in variables.

Do you think It would be a big effort to back-port the schema saving system from 3.x to 2.x ?

Thank you!

fmizzell’s picture

fmizzell commented

@mihai_brb Do you also need the widget stuff from 3.x? I think the schema stuff is fairly isolated, but if you also need the widget stuff, those 2 things are most of the major changes in 3.x.

You are one of the few people I know that are actively working on ECK stuff, so I do not want to discourage you from doing stuff. I am wondering whether there are any ways in which we can rearrange the roadmap so that pushing 3.x forward would be beneficial for you instead of backporting stuff to 2.x?

Let me know what you think, and hopefully we can work it out.

mihai_brb’s picture

mihai_brb commented

In my case the biggest benefit of storing additional data in entity properties (schema, or any other) for 2.x is for example to allow configuring reference properties from the UI instead of the non-flexible configuration that I have now, that is storing it in the property name. This will also allow referencing the same entity type in multiple properties. Plus, it will allow filtering by entity bundle.
Once the property data can be extended, I can inject whatever is needed, for example a required state, or a default value.
I guess it does not make sense to loose time and back-port other new features.

mihai_brb’s picture

mihai_brb commented

Would this be a backport of the existing schema/property edit from 7.3 or we could just make the setter for properties more abstract ? I will need it in 7.2 and would like to code it in a way that could be commited to avoid the upgrading problems ...

dieterholvoet’s picture

dieterholvoet commented
Status: Active » Closed (won't fix)

We're dropping support for Drupal 7 since it has officially reached end of life on the 5th of January 2025.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.