Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-6649

Refactor NameDefinition <-> DefinitionMetadata name binding mechanism

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Neutral Neutral
    • 5.4.7
    • 5.4.6
    • None
    • None
    • Basel 42
    • 0

      The algorithm in question ensures consistency of the name of the definitions to which it is important (see NamedDefinition interface).

      Currently this mechanism consists of two parts:
      1) YamlConfigurationSource after producing the bean from YAML file checks whether name is set to the bean. If it is then the name is also pushed into the metadata.
      2) AbstractRegistry upon DefinitionProvider registration grabs the bean from the provider and creates a wrapper provider (SwappedDefinitionProvider) which returns the same bean, but proxied (GetsNameFromMetadataWrapper) so that it always returns the definition name resolved from metadata (thanks to part 1 - metadata surely has the correct value).

      What is bad here?

      • this is ridiculously complex. The solution is spread between two classes and is not obvious.
      • step 2) makes bold and generally wrong assumption about how provider works: the wrapper provider always returns all the same bean. But in general a DefinitionProvider does not guarantee that the result of it #get() method invocation is always the same. Hence, is a definition provider is dynamic and its underlying bean might change - such changes will be overridden by the SwappedDefinitionProvider which will always provide the same bean.

      Proposed solution: eliminate step 2) completely, do everything during step 1.

      • we shouldn't make promises of such behavior on AbstractRegistry level anyway - whoever produced the DefinitionProvider should be responsible of its correctness;
      • luckily for us, JCR configuration source already does that (N2B uses node name as a fallback for definition name);
      • in YAML case - it is pretty trivial to extend the step 1) of the initial algorithm to cover the whole story, just do everything before the bean is produced, i.e. - check the map produced by YAML reader and align its name property with metadata before any map-to-bean conversion happens.

      The solution is provided as a part of MAGNOLIA-6451 refactoring and the proposed algorithm would be located in a newly introduced YamlDefinitionProvider (it takes over the conversion chores from the config source).

      Related unit tests:
      YamlConfigurationSourceTest#nameComesFromDefAndIsAvailableOnMetadataAsWell
      YamlConfigurationSourceTest#nameFromDefHasPriority

        Acceptance criteria

              apchelintcev Aleksandr Pchelintcev
              apchelintcev Aleksandr Pchelintcev
              Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved:

                  Task DoD