Posted by xlyz on April 29, 2011 at 5:58pm
10 followers
Jump to:
| Project: | Domain Access |
| Version: | 7.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Issue Summary
is there any plan to set domains as entities to leverage the entity api?
Comments
#1
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.
#2
you gain also partial / easiear integration with several non-core modules (e.g. rules or features), the possibility to bundle domains with other entities, and to leverage the entity api that get better every day.
#3
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.
#4
yeah.
I had a look at the code, but this module is complex enough that I'm not able to understand the impact of entity introduction in such a short time.
I wish I had more time to give you a coding hand.
#5
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.
#6
You got me :)
I was considering exactly domain rules integration (I need it for one of my project)
#7
What are you trying to do?
#8
Allow users to create an own domain/subdomain upon given conditions. For istance the purchase of a given product or the creation of a given node. Create / edit permissions has to be set for that single domain.
With nodes it's a trivial problem to solve using rules and content_access.
I'm still doing preliminary analysis. I need to understand better domain code to evaluate what could be the better approach. Afaik entities would have made it easier. But they are not there :)
#9
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.
#10
#11
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'?
#12
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 :)
#13
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.
#14
> * 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.
#15
I can see that, but it seems a half solution. I suspect this refactor is a D8 task.
#16
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?
#17
Only in 8.x ;-)
#18
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?
#19
Its on the roadmap for D8 and not before. The d8 version will need to be a ground-up rewrite.
#20
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?
#21
I think a sandbox would be fine, sorry.
#22
Domain 8 http://drupal.org/sandbox/agentrickard/1906300 Biggest changes: Domains as entities ...