Spin-off from #1648930: Introduce configuration schema and use for translation. This patch just does what the issue title says. It uses the file format I suggested in #1851498-21: Polish file format of configuration metadata (for translation). Still a work in progress, but CNR for bot and initial human review.

Files: 
CommentFileSizeAuthor
#4 config-definition-lookup.patch7.42 KBeffulgentsia
FAILED: [[SimpleTest]]: [MySQL] 49,347 pass(es), 1 fail(s), and 0 exception(s). View
config-typeddata.patch19.58 KBeffulgentsia
FAILED: [[SimpleTest]]: [MySQL] 48,900 pass(es), 3 fail(s), and 0 exception(s). View

Comments

Status: Needs review » Needs work

The last submitted patch, config-typeddata.patch, failed testing.

Gábor Hojtsy’s picture

Issue tags: +D8MI, +language-config

To summarize your proposal, the file naming placement would be: modules/contact/contact.config-definition.yml (where contact is the module name both times). And file content would be including all structures defined by the module, eg from image module:

+image.style.%:
+  name:
+    label: 'Machine name'
+  label:
+    label: 'Label'
+    translatable: true
+  effects:
+    label: 'Style effects'
+  effects.%:
+    label: 'Image effect'
+  effects.%.weight:
+    type: integer
+    label: 'Weight'
+  effects.%.ieid:
+    label: 'IEID'
+  effects.%.name:
+    label: 'Machine name'
+  effects.%.data:
+    label: 'Data'
+    include: 'image.effect.[%parent.name]'
+
+image.effect.image_crop:
+  width:
+    type: integer
+    label: 'Width'
+  height:
+    type: integer
+    label: 'Height'
+  anchor:
+    label: 'Anchor'
+
+image.effect.image_resize:
+  width:
+    type: integer
+    label: 'Width'
+  height:
+    type: integer
+    label: 'Height'
+
+image.effect.image_rotate:
+  degrees:
+    label: 'Rotation angle'
+  bgcolor:
+    label: 'Background color'
+  random:
+    type: boolean
+    label: 'Randomize'
+
+image.effect.scale:
+  width:
+    type: integer
+    label: 'Width'
+  height:
+    type: integer
+    label: 'Height'
+  upscale:
+    type: boolean
+    label: 'Upscale'
+
+image.effect.scale_and_crop:
+  width:
+    type: integer
+    label: 'Width'
+  height:
+    type: integer
+    label: 'Height'

In efffect no "OO-support" to extend existing metadata from base classes, etc. but people would copy those over by hand and maintain it if the base module/class ever updates, right?

Gábor Hojtsy’s picture

Issue tags: +sprint

Raise to D8MI sprint board (also on http://www.drupal8multilingual.org/issues/focus) as well so we can keep close track of the progress here too, much like #1861640: Provide config metadata solely for translation.

effulgentsia’s picture

Title: Introduce configuration definition format and API for getting values as TypedData objects » Introduce configuration definition file format and API for reading it
Status: Needs work » Needs review
FileSize
7.42 KB
FAILED: [[SimpleTest]]: [MySQL] 49,347 pass(es), 1 fail(s), and 0 exception(s). View

The test failures are random, not real, but in working on this, I realized that we can decouple the reading of definitions from the instantiation of TypedData objects. I still think the TypedData integration has value, but I'd like to scope this issue down to just the file format and reading/querying it, and then do the TypedData work in a follow up.

So here's just that.

In efffect no "OO-support" to extend existing metadata from base classes, etc. but people would copy those over by hand and maintain it if the base module/class ever updates, right?

The DefinitionLookup class in this patch does not yet process includes, so this still needs work on that. That will complicate the class a bit, because includes might not be in the same module as their prefix. For example, a fancy_image_effects module needs to be able to define image.effect.fancy_effect_1 within fancy_image_effects.config-definition.yml, not within image.config-definition.yml. However, back to your question, once includes are working, we should allow "include" to operate at the "group" level like so:

// Within image.config-definition.yml
image.effect._base:
  width:
    type: integer
    label: 'Width'
  height:
    type: integer
    label: 'Height'

// Within fancy_image_effects.config-definition.yml
image.effect.fancy_effect_1:
  _include: image.effect._base
  custom_setting_1:
    ...

Note, the above is just an example: we do not actually have a base class defining shared properties for image effects specifically, but for other plugins, we might.

yched’s picture

Yeah, the includes were an absolute requirement, not so much for "OO-like inheritence", but for cases where:
- module A (e.g. image) provides the metatdata for the wrapper file (e.g image.style.%),
- but at some point in the tree the metadata for a given entry (e.g the settings of a given wizz_bang_effect within the style), will be provided by a different module (e.g the wizz module that ships the image effect)
Which is typically the 'plugin-based subsystem' case.

To do that routing, the only data we have *in the config file, without some runtime PHP* is the value in a given key (here, the 'name' entry that happens to hold the effect plugin id). That's just a plugin id, not the name of a module.
So we can route to any arbitrary agreed-upon string based on that plugin id, like for instance image.effect.wizz_bang_effect.config-definition.yml (with 'image' here being a pure convention, stemming from the fact that the 'image effect' plugin type is defined by image.module - that module also defines image styles but that's a coincidence)
But we cannot route to [owning_module].effect.wizz_bang_effect.config-definition.yml, we don't have that info in the config file.
(#1862600: Entity type names/IDs are not properly namespaced by owner (e.g., taxonomy.term vs. taxonomy_term), which, despite it's current title, actually discusses forcing all plugin ids to [owner_module.plugin_id], might change that, but there's currently no buy in over there)

Additional constraint being that image effects only know that they are image effects (and thus need provide the code & data that's in the contract), *not* that they are "typically included in a config entity for something called image styles". There are different config entity types that might include configuration for a field formatter, and field formatters cannot need to care.
A plugin cannot make assumptions about where it's used - it's the other way around, the config entity type knows it refers to plugins of a given type at some place in its yaml trees.

Status: Needs review » Needs work

The last submitted patch, config-definition-lookup.patch, failed testing.

Gábor Hojtsy’s picture

@yched, @effulgentsia: in short that means we don't know which module might define that CMI key pattern, so we need to read all of the definitions and look through them (or have a lookup cache) as far as I see?

Gábor Hojtsy’s picture

Posted this request for reviews in the Core group (also should be on Drupal Planet): http://groups.drupal.org/node/273268

fago’s picture

image.effect.fancy_effect_1:
_include: image.effect._base
custom_setting_1:

To me, an include seems to be the same as an entity refernce in typed data. Problem is for that to work out on a static basis we need to have a static way of finding/loading this file - what means we have to re-invent functionality of Drupal outside of it (e.g. finding modules, loading the right CMI files, ..).

As explained at https://drupal.org/node/1648930?page=1#comment-6845200, my feeling is that this static parsing makes things unnecessarily complex. Why not do this work in PHP and export the translatable things in a file?

Gábor Hojtsy’s picture

@effulgentsia: Any progress on this one? @Dries postponed #1648930: Introduce configuration schema and use for translation in part on this issue a week ago today :)

effulgentsia’s picture

@Gabor: Nope. The next step here would be to implement the 'include' handling, but per #9, heyrocker and others have renewed interest in replacing that with PHP logic that exports files with everything inlined. I want to give them a little more time to post a patch with their ideas, then see how that relates to what I wanted to achieve here.

Gábor Hojtsy’s picture

@effulgentsia: thanks, I think some discussion of the file format would be useful nonetheless. :) I think interested parties are holding back until they see a working system. However, in any case, a working system will probably be considerably more complex in some way (the merge rules need to be defined somewhere, if not in metadata then disconnected in PHP somewhere).

chx’s picture

Assigned: Unassigned » chx
Category: feature » task
Priority: Normal » Critical
Jose Reyero’s picture

A fully working one, which has a few things in common with this one (like a single schema file per module) is here , just in case you can reuse some code (factory, discovery, etc...) #1866610: Introduce Kwalify-inspired schema format for configuration

Gábor Hojtsy’s picture

Issue tags: +epic

Tagging as epic.

heyrocker’s picture

@efflugentsia I would encourage you to continue work on your side rather than delay for me or anyone else. We never know if they will ever get to a solution, and then time has been wasted for nothing. So please, keep working and we'll see where we end up.

webchick’s picture

Priority: Critical » Normal

We don't need two critical tasks about this.

chx’s picture

Assigned: chx » effulgentsia

Sorry for not taking over and not advancing for almost a week. IMO image.effect.scale this should be image.effect.image_scale just based on name: image_scale in core/modules/image/config/image.style.thumbnail.yml. But this raises an interesting question: how will we know that image_scale is provided by image module? This approach definitely requires this knowledge and if another module provides an image effect, how will we find it?

chx’s picture

Also, I am willing to work on this just not sure right now what to do because of #18.

Gábor Hojtsy’s picture

@chx: see #7, which is hopefully a good short summary of #5, where this is better explained with examples.

chx’s picture

Hrm, I see , definitely @effulgentsia's code is moving towards a full-blown cache lookup and it constructs the offset name like + include: 'image.effect.[%parent.name]'... tricky. very tricky. So any file can contain the image.effect.wizz-bang definition and we read them all. I will take a quick look but leave this assigned to effulgentsia so I am not holding htis up any more.

Jose Reyero’s picture

@chx,

But this raises an interesting question: how will we know that image_scale is provided by image module?

#1862600: Entity type names/IDs are not properly namespaced by owner (e.g., taxonomy.term vs. taxonomy_term)

effulgentsia’s picture

Sorry I haven't made progress here in a while. I plan to come back to it soon, but I support others in working on it or the related issues in the meantime.

I chatted briefly with chx about this, and I think the next logical thing to do here is figure out how to optimally cache the metadata (possibly in the k/v store). That's especially necessary if we don't do #1862600: Entity type names/IDs are not properly namespaced by owner (e.g., taxonomy.term vs. taxonomy_term) (for all plugins, not just entity types), and may be a good idea even if we do.

Gábor Hojtsy’s picture

Cross-quoting @heyrocker from #1648930-346: Introduce configuration schema and use for translation:

I would like to establish a deadline for deciding how we're going to proceed with this. If we don't, we are going to go back and forth on these decisions in a circle until feature freeze comes and then we're screwed. My feeling is we will probably need about a month to implement any new proposal and get it to RTBC, so I'd like to lay down January 15 as our deadline or deciding what to do. If we haven't agreed on any new proposal, then we reroll the original RTBC patch from #285 and get it in. We have to get this done, and right now I don't see any light at the end of the tunnel which scares the crap out of me.

I very much agree we need to get out of our lack of agreement here, because we are dealing with things we absolutely much do even if only to avoid sizeable regressions in Drupal 8.

In light of this, reviews pro or against the above proposals are more than welcome.

Gábor Hojtsy’s picture

Priority: Normal » Critical

@webchick: re #17, although we do have #1648930: Introduce configuration schema and use for translation, that is marked postponed, and therefore is not visible in active issue lists neither is counted against queue limits, so I'm not seeing why it is a problem that we have at least one active critical task about this. It is definitely not normal overall to solve this problem and #1648930: Introduce configuration schema and use for translation has no visibility while postponed.

Gábor Hojtsy’s picture

Posted this call for feedback on the Core group (also going to Drupal Planet): http://groups.drupal.org/node/275008

effulgentsia’s picture

Priority: Critical » Normal

Swapping criticals with #1866610: Introduce Kwalify-inspired schema format for configuration, because that patch is farther along. Will post a review there shortly.

effulgentsia’s picture

In case anyone here isn't following the other issue, I'm tempted to "won't fix" or "duplicate" this one in favor of that one. Any objections to that?

beejeebus’s picture

i agree with #28, the other patch looks better.

chx’s picture

Status: Needs work » Closed (won't fix)

Who cares, there is no way we get a good solution. Let's pick the least bad.

Gábor Hojtsy’s picture

Status: Closed (won't fix) » Closed (duplicate)

Thanks for the feedback!

Gábor Hojtsy’s picture

Issue tags: -sprint

Also, removing sprint tag.

Gábor Hojtsy’s picture

Issue summary: View changes

Added info about file format.