Page tree
Skip to end of metadata
Go to start of metadata

Introduction (copied from Referencing Fields by their names instead of Fully Qualified Classname)

Currently one has to type fully qualified classname in order to define a field in any configuration such as 

class: info.magnolia.ui.form.field.definition.TextFieldDefinition

However, fully qualified classnames are hard to remember and verbose. If we were to simplify/reduce the verbosity from the configuration, our configuration files would look much nicer and compact as well as It wouldn't be a hassle to remember which definition is coming from which class and hence its fully qualified class name. The ticket of  DEV-338 - Getting issue details... STATUS  is created to tackle this problem and  MGNLUI-3882 - Getting issue details... STATUS  to implement it. Perhaps for the time being It may seems like we are only targeting fields ,however, the solution which comes up from the discussion regarding the fields should/could be applied relatively easy to the other parts of Magnolia configuration such as actions.

 

Possible solution at the component provider level

Configuration
<components>
 <id>main</id>

 <type-mapping>
   <type>info.magnolia.ui.form.field.definition.TextFieldDefinition</type>
   <alias>textfield</alias>
 </type-mapping>
</components>

 

Required changes

  1. Add method to resolve alias to Component provider
  2. Adjust M2B and N2B.
  3. Add alias property to TypeMappingDefinition

Tooling

We currently don't have any tooling for module its components/implementations definitions so we could tackle this at the same time.

although I don't see a problem even without a tooling for now if we document it (in the end it's just alias per field here).

 

 
  • No labels

1 Comment

  1. To me it looks very similar to what I was proposing in this comment: https://jira.magnolia-cms.com/browse/MGNLUI-3882?focusedCommentId=135990&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-135990. The only major difference is that I was more inclined to not fuse this into the ComponentProvider but rather have a dedicated utility [and potentially, a separate property, e.g. type vs class]. With having this provided by the component provider and through the 'class' property, I reckon we will end with not the subtlest patterns like "try to resolve a class from this string, if it fails - then ask component provider to resolve an alias". If we would have at least a dedicated property - it would be easier to decide, how to get a class name.

    Another aspect that I would probably like to mention here are annotations. XML's good but providing similar or more powerful capabilities via annotations is even better. Some pointers that pop out from my head - we have the @Named annotation and we even have a Components#getComponentWithAnnotation utility, which looks like a thing of a similar sort to me.