Problem/Motivation

All config translation mappers are usually loaded all together in an array ($container->get('plugin.manager.config_translation.mapper')->getMappers(), but we may need to treat them differently in contrib or core.

Proposed resolution

Add a categorization property. The three groups (in core) could be "Simple configuration", "Configuration entity", "Fields"

Remaining tasks

Verify this is acceptable for 8.1 and not considered an API break.

User interface changes

None.

API changes

API addition TBD.

Data model changes

None.

Comments

penyaskito created an issue. See original summary.

tstoeckler’s picture

Chatted with @penyaskito about this one in IRC.

Just some random thoughts for now:
- I think this makes sense.
- ConfigNamesMapper does a lot of stuff. It might even make sense to turn this into multiple traits if there is some way to group this naturally. Might not make sense at all, just thinking out loud.
- Like the issue summary says, we should totally have an interface for ConfigEntityMapper::getEntity(). Not sure if ConfigFieldMapper has any additional methods that would warrant an interface. Separate issue, though.
- We also talked about providing a category to mappers á la CategorizingPluginManagerInterface. The three groups (in core) could be "Simple configuration", "Configuration entity", "Fields". We have a couple of methods to for the overview UI (getGroupLabel() or something like that?), so we might even be able to make that a little bit less strange. Also, separate issue.

Gábor Hojtsy’s picture

Issue tags: +D8MI, +language-config

Well, the philosophy was that in config everything is a config name. Entities happen to have a pattern to their names, which the entity mapper manages, but otherwise they are just names as well. :) Maybe your use case would be served well enough with categorization as explained by @tstoeckler?

penyaskito’s picture

Title: Replace inheritance in config translation mappers with a trait » Add categorization to config translation mappers
Issue tags: +Needs issue summary update

That justifies the inheritance then, let's add the categorization.
Needs issue summary update with #3.

penyaskito’s picture

Issue summary: View changes
penyaskito’s picture

penyaskito’s picture

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.