Improve the typed data API usage of configuration schema

Well, reality is the schema system takes any defined CMI key as a type that can be and is referenced later on. See image effects and views for examples. Not sure typed data would be scalable for registering all CMI keys defined. See http://drupal.org/node/1905070 under Types supported and Dynamic type references.

As for 'str' that looks like a mistake and validate() is not actually used anywhere in the code yet (neither the Parser class I think), so that can be removed AFAIS.

I think having general usable unknown+mapping/map types in the typed data API makes sense anyway, the config system can then make use of them as appropriate. That would solve the problem of having unregistered types.

Well, maybe not really? The config schema makes extensive use of back-referencing types (such as in image effects and all through views) that were previously defined using the schema for plugin based data types. Everything eventually resolves to basic types of course but the reusability of display controller config or image scale effect logic is implemented by defining types for them in the schema and then using those types. I'm not sure you want to have each CMI key as a typed data type to be registered too? Sounds like too much overhead for types not used in Drupal elsewhere.

As for custom types via classes, when writing the docs I figured out that we don't really have clear guidelines as to what a class implementing a custom type would need to have. That would be great to clean up :)

As for lists, the list = TRUE thing was in the prior metadata patches and *nobody* liked it at all. The unanimous feedback was list is conceptually a type.

Let's start with removing the unused Parser (that you noted above had incorrect type fallback and used typed data validation incorrectly - that was not even in the goals - and the also an unused required property (given that we don't validate). The Parser also attempts to use the nonexistent config_definition(). Fun stuff.

Fix any and str in the create() method of the typed data factory too. "any" got renamed to undefined in the patch but it was not reflected here.

@fago: I'm not well versed at all in typed data, so this is about as far as I can go into cleanup. Carrying in some of the types to Typed Data sound good to me as well as attempting to clean up so that types are properly registered. Although I'm not sure of that as said above in light of config schema reusing schema defined structures as types extensively for plugin handling.

Patch looks like a good clean-up but it does not really related to the issue title - maybe we should move it in its own issue?

The patch is based on your review in the issue opener, specifically str? I've not seen that elsewhere, maybe wrong?. It is true str and any are not valid types even in the current schema system. Also, you complained about the validation stuff, which is not used either, and the two issues appeared in the same unused code snippet, so it was directly logical to remove the unused code here. Also, I found the same str and any at one more place, and fixed that to use actual schema defined types. Since these were undefined types, I think they are directly related to this issue.

The Parser is not actually required by any current code neither it is needed for locale integration (#1905152: Integrate config schema with locale, so shipped configuration is translated). The required property can be removed, since we don't do validation and that was the only place it was used. Superfluous.

Also need to test with a simple yml file in a test module that the defaults are properly applied.

adding the test is doable for someone new, or maybe at one of the sprints coming up. (see http://drupal.org/node/1468170 )
#1866610: Introduce Kwalify-inspired schema format for configuration shows sample yml files, but sounds like what we need here is a much simpler one "to test that the defaults are properly applied"

looks like Gabor answered the question about needing more review. so setting to needs work.

So what we need here is looks like:

- 1 data .yml file (not schema!) in one of the config test modules
- have at least one or more string keys and one mapping or sequence

In sum, something like (name the file eg. "test.noschema.yml"):

testitem: "Should be detected as string"
testlist:
 - "Should be detected"
 - "as undefined"

Now since we don't define a schema for this, the default logic should kick in, and testitem should be detected as string, while testlist itself should be detected as "undefined". The tests in #1866610: Introduce Kwalify-inspired schema format for configuration show how concrete files are tested and how their types are checked in tests. In this case we'd check what happens if there is no schema for a file. (Because all core .yml files should eventually have schemas, we need a dummy config .yml file for this).

@fago: also sorry that this might look like your issue is taken over, but we agreed this is part of the fix needed. Maybe we'll need to open yet more issues for other parts of the fix or return to the rest once we have this covered.

I don't think this qualifies as Novice.

Got started with the tests, however it seems like the schema system will not delve into values that it does not know about, so we cannot really get below the main config key level. Using chained get() calls, I can only get Unknown types for any other key (which should individually be detected as a string theoretically). Here is an initial pass at the tests which detects that unknown CMI keys and known CMI keys without schemas will resolve to the same Unknown type on the main level.

Here are full tests. A file without schema will not recognize any items so delving into detecting types for them will not work obviously. Once we define some schema for the top level, the second level items are properly detected as string or unknown. Now included test coverage for that too and made the .yml files explain their purpose better. :)

I think this is as complete as the cleanup can go for the type detection. IMHO this should be committed and other cleanups worked on in followups / other issues. Please review!

Looks good to me, this is a needed cleanup.

#19: typed-data-config-schema-19.patch queued for re-testing.

Committed to 8.x. Thanks.

Thanks!

Add tag.