Concept - UI theming and extensibility, level 2

Abstract

Theming and Styling still needs to be improved, especially the legacy stylesheets are still quite messy as of 5.0-alpha3. We expect this second iteration of the concept to give the magnolia theme a broader scope, as well as to tackle the reorganization and clean-up of the stylesheets.

This concept still belongs to the following user story. Unable to locate Jira server for this macro. It may be due to Application Link configuration.

1. Theming

Problem

• Stylesheets are still a mess (legacy admincentraltheme)
  
  • They're not properly modularized
  • Some rules don't belong to the right stylesheet
  • Widget styles and app styles are also mixed up inside these stylesheets
• All vaadin standard UI components should look visually integrated into magnolia
• Styling could still be applied in a more light-weight way
• Any module should be able to add Sass compilation at build time

Proposal

• We complete theming for basic vaadin fields
  
  • Unable to locate Jira server for this macro. It may be due to Application Link configuration.
• We then tackle other subtasks in Unable to locate Jira server for this macro. It may be due to Application Link configuration.
• We could have Sass compilation in any vaadin-enabled UI module
  • For 3rd party modules, build-time Sass compilation could ultimately move to the bundle (same as widgetset)

Decision

-

2. Project structure and Widgetset

Problem

• It is hard to relate widget java classes - where style names are set - to their actual CSS rules
• We need to review the pattern for applying desktop vs. tablet styles
• Package structure of the common-widgets project could be clearer
• Naming of widget classes is inconsistent
  
  • Reevaluate usage of "v-" prefix in style names for magnolia widgets, this is not consistent right now
• As Sasha pointed out, there may also be room for Optimizing the WidgetSet
• There is always only one widgetset. It can aggregate as many other widgetsets (e.g. addons) but ultimately results into one compilation unit
  
  •  This is a critical issue because we need to recompile the whole widgetset after installing any module that comes with a custom widget (e.g. dam media editor)

Proposal

• We try to draw a meaningful separation for "shell-only" widgets
• Investigate a possibility to compile the widgetset during runtime. e.g during startup.
  
  • Need to investigate if it is possible to place compiled resources into a location that can be served

Decision

• We align on vaadin7 package structure (client/server/shared)
• We align naming of widget classes
  
  • we try to use *Widget / *Connector consistently
  • we drop client-side naming *View / *ViewImpl
  • we leave the v- prefix for standard vaadin component style names, we use m- prefix for magnolia widget styles
  • we don't use any prefix for application views
• We take the widgetset project to the bundle

3. Extensibility

Problem

• It is not clear how an app developer adds a custom widget to her app
• It is not clear how an app developer adds her own icons for her app and its actions

Proposal

-

Decision

-

Suggestion box

• The magnolia theme application could ultimately switch between expected screenshot and actual fields, to help on browser support
• Structure:
  
  • magnolia-ui-vaadin-theme
    
    • themes/magnolia includes base, commonbase, shellbase
  • magnolia-ui-vaadin-widgets-common
    
    • themes/commonbase
  • magnolia-ui-vaadin-widgets-editor
    
    • themes/pageeditor
  • magnolia-ui-vaadin-widgets-shell
    
    • themes/shellbase
• Enable SASS for STK themes