Drupal 8: Approaching Content and Configuration Management

As a follow-up to heyrocker's great core conversations talk I'd like to share my thoughts on that topic. So is X content? Or configuration? As heyrocker pointed out: We shouldn't have to care.

So yes, the line between content and configuration is blurry - stuff being content on a site, would more fit the configuration bill on another site. Still this doesn't mean we have to treat content and configuration exactly the same way. We can and we need to build separate systems for configuration management and content deployment, but the point is: We need one and the same type of objects to be able to behave as content and configuration dependent on the actual requirements of the site. Not necessarily out-of-the box, but well, it should be doable such that people can implement their use-cases. To facilitate that, we need a foundational unified API, an API that deals with objects the same way regardless whether its configuration or content, an API that allows us to fetch any object, to export it, and to import and save it on another site.

As said in the core conversation, I think the entity API perfectly fits into that. That way, an entity would be basically any data object which is integrated into Drupal, such we have a unified CRUD API - and a unified way to import and export that data. It should be able to deal with machine names or auto-incremented numeric id, but as well we might want it to be able to deal with UUIDs out of the box. So we'd finally get a unified data API and exportability, the very much foundation for solving the configuration management and content deployment problems.
But for that to take off, we need to keep the entity concept slim and don't bake too much assumptions into it. Is it content or configuration? Is it user-facing? Is it fieldable or viewable/renderable? Well maybe, maybe not. So while it makes a lot of sense to build more APIs around entities, we should never actually require them. Instead, we could just provide the APIs such that any entity type is able to opt-in, if it fits the bill.

In addition to that, I'd like to share my thoughts on how the Entity API could help us to cover 2 more points Dries mentioned in his key-note: Web services, and information integration. I'll come back to that in a follow-up post.

Comments

The primary issue with making everything an entity is performance. That's a lot of extra overhead to access a variable, or load a text format.

Variables wouldn't be entities, but anyway I don't think this would significantly hurt performance. I don't see any overhead in using entity_load() except for some additional hooks, which are necessary for modularity and are cached since d7 anyway.

But yes, such changes definitely need benchmarking - as required anyway to pass the d8 performance gate.

Hey, I think your website might be having browser compatibility issues.
When I look at your website in Safari, it looks fine but when opening in Internet Explorer, it has some overlapping.
I just wanted to give you a quick heads up!
Other then that, great blog!

Also visit my weblog - Reup Daily

I fundamentally disagree. Entities for data objects are fine, data objects, configuration, and logic objects are different things and require different treatment:

http://groups.drupal.org/node/134569#comment-438399

I've replied to you on g.d.o., see http://groups.drupal.org/node/134569#comment-439404

Hi there, its good piece of writing concerning media print, we all be familiar with media is a great source of
facts.

Feel free to surf to my site; move to hawaii cost

Add new comment

Filtered HTML

  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Allowed HTML tags: <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.