Goals and Benefits:

• Less boilerplate; some of our definitions inherently require too much boilerplate to get started.
• Easier onboarding with YAML configuration
• Easier to remember snippets to achieve common tasks
• Less overhead to learn about Magnolia-specific app components

Discussions:

We need to revisit the idea for whom we are trying to simplify the config. Depending on who the users are and what are their common use case they may never need the aliases we planned to create for them.

• E.g. when using content types, aliases like those in MGNLUI-5945 wouldn't bring benefit.
• We might also want to change one of our apps to a content type app so we give a better example to follow.
• We can discuss also with PM what are the use cases we want to help out with for users
  • non-content type based apps are still going to be here for the next 3 years or so along content-type apps, so we can adjust
• Sang mentioned we'd want to rather try to simplify e.g. action bars definitions (permutations of action bar views based on state)  [file ticket] which might be too complex and lengthy at the moment 
  • Sang: I prefer keeping explicit definition/class in Yaml, developer/user can easier and faster find the implementation, or know which class/definition are using

• MGNLUI-4949
• see also this Further app descriptor flattening exercise (used to be an adjacent discussion point when we introduced type-aliases) https://wiki.magnolia-cms.com/display/DEV/Generic+TypeResolver+for+annotated+implementations
  • not a high prio, since we have content type apps in place to cover a big portion. 
  • moving to cloud might need additional disconnect from the implementation (moving to a DSL approach) soon