domains as entities

Not at this time.

I'm of two minds with regard to entities. While they are very useful, not everything needs to be an entity. Also, the entity API (as such) isn't entirely finished in D7 core.

What do we gain by making domains entities?

Fieldable data that is extensible through the UI.

What do we risk?

I'm not sure the gains outweigh the risks caused by introducing database abstractions to the logic.

I'm not rejecting the idea. I also don't have the 40 hours it would take to re-implement the entire module using entities.

And we're not getting much patch review and support these days, so I'm not feeling confident 7.x.3 will ever get finished, let alone if it's delayed until I write entity support.

The problem (in a nutshell) is that the module was originally written in Drupal 5, and I had to decide between Objects and Arrays for the $domain variable.

Drupal was (is) more array-centric, so I went that direction. Changing that now is a big deal, and without a really good reason, not worth the time.

Since domains are not updated frequently, the way nodes and users are, I don't see free Rules integration as being very important.

Now, if we move to entities and we can drop Domain Views entirely, that's a nice little win.

This might have to go into the D8 port.

What are you trying to do?

The bigger problem there is that domain "ownership" support really isn't there. In D6 we had http://drupal.org/project/domain_user to create vanity domains, but that doesn't give the user any real administrative control and has been abandoned.

I would recommend that you might want to adopt that module in D7 and make it work.

I was thinking one benefit would be a situation where the domain entity could have fields holding content such as its logo and so on. Or would that make more sense with an entity that's a helper associated with the domain rather than it being the domain configuration itself?

Could we reopen this as postponed, even if that's understood as 'possibly until D8'?

I personally think entities as domains would make total sense.

Work is being done on feeds so that it can import/update any entity without any custom work, and also so that feed importers can attach to any entity. That means that domains can be updated by feeds, and other feeds can be attached to domains. Even id both modules drastically change, there'll be less custom work involved in keeping these integrations working

Just wanted to give a use-case here:
We're working with an organization with multiple "banners" (basically, side of the organization with different branding). Each gets a domain. Each has it's own catalog of products, available through a differnet endpoint of an external XML service. We will be populating the domains with products from each catalog using feeds and feeds_xpathparser.

If domains were entities, we could attach banner metadata to the domain itself and treat it as the canonical datastructure for banners, instead of creating another entity called "banner". Also, being an entity, we could update this metadata with a standalone feeds importer, using data from the XML service. Kinda cool.

We could also attach a product importer to each domain entity, and attach a field which stores the banners "shortname" identifier. Now we can set the http fetcher with a token to pull from www.xmlserviceurl.com/service/[field_banner_shortname]/products

Anyhow, we're going to be able to get most of this done without domains as entities, but it would stitch it all together much better. I'm just starting to grasp all the bonuses of entities myself :)

We can re-open as active, with the proviso:

* I'm not working on this.
* You have to solve the "how to bootstrap load the domain code" before converting anything else.

This would necessitate either a 7.x.4 branch, or, more likely, 8.x.4.

> * You have to solve the "how to bootstrap load the domain code" before converting anything else.

If that turns out to be too hairy, there's a halfway house where we have domain entities that are tied to the domain but loading the domain itself for bootstrap stuff doesn't need to have the entity.

I can see that, but it seems a half solution. I suspect this refactor is a D8 task.

Maybe a first task to help pave the way for this would be to convert domains to be objects instead of arrays. Anyone up for that?

Only in 8.x ;-)

I think another huge benefit to using entities with the domain module is the relation module. Right now if I want to associate a domain with a group, it's a lot of custom code with very little extensibility. I real use case I'm working on right now is using the domain module with the Redhen CRM.

If a domain were listed as an entity, then any relation can be drawn to any other entity, (user, contact, organization, etc) and then that relation could be fieldable as well.

I think the half solution in #14 is worth it, does anybody think there is any sense in making a sandbox project out of that?

Its on the roadmap for D8 and not before. The d8 version will need to be a ground-up rewrite.

I was talking about me personally, not the maintainers. I would imagine it's more worth your time to focus on d8. My current scenario is D7 + Domain + Redhen because the site will be done in March and D8 won't be an option, so either way I'm going to have to write this.

I can either use the custom code I already wrote in D6, which just saves an nid to the settings variables in the domain_settings module, or I can create an entity object for each domain and link them via relations. My question was if I create this functionality to use domain with entities, would that be worth a sandbox project or not?

Are there challenges too that make that an unwise task?

I think a sandbox would be fine, sorry.

Domain 8 http://drupal.org/sandbox/agentrickard/1906300 Biggest changes: Domains as entities ...

Re: #14:

If that turns out to be too hairy, there's a halfway house where we have domain entities that are tied to the domain but loading the domain itself for bootstrap stuff doesn't need to have the entity.

Looks like someone's pretty much started this:

https://drupal.org/project/domain_fieldable

The module defines a "domain_fieldable" entity where the entity_id corresponds to the domain_id. Instead of maintaining its own {domain_fieldable} base table, though, it uses the existing {domain} table. It doesn't make any modifications to the table schema.

We have a use case here, looking to add taxonomy reference fields to domains as a simple, Core API compatible way to "group" domains for custom UI improvements.

Would be amazing to see domains working as entities, I suspect that using the Entity API module would likely make this easier to achieve in D7.

@Les Lim - Thanks for the link to that module, we will check it out.

Needed still?

It's simply not going to happen for D7.

In D8, Domains are config entities.

Makes sense. Thank you for the info.