Page History

Abstract

Themeing Theming and Styling need still needs to be improved, especially the legacy stylesheets are still quite a mess messy as of 5.0-alpha2. Project structure needs to be reviewed to properly modularize styling and widgets, so that apps/views can be properly extendedalpha3. We expect this concept to lead to proper themeing and styling guidelinessecond iteration of the concept to give the magnolia theme a broader scope, as well as reorganizing and cleaning up to tackle the reorganization and clean-up of the stylesheets.

This concept also still belongs to the following user story.

...

Problem

1. Theming

Problem

• Stylesheets are still a mess (legacy admincentraltheme)
• We don't have true themeing so far, only fields in dialogs have decent styles
  
  • If I add a TextField and a Button in my app, they should also have the Magnolia style
• Stylesheets are a real mess
  
  • 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
  • Some style rules are simply duplicated across several stylesheets (forms vs. dialogs)
• 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 can have a MagnoliaThemeUI vaadin application that looks like the old showcase app, featuring all UI fields from vaadin
  
  • except it does not run on Magnolia
  • ultimately it could switch between expected screenshot and actual fields, to help on supporting multiple browsers
• We start theme again by picking minimal rules from the existing stylesheets and bringing them into new Sass stylesheets
  
  • We can inherit the base theme so that we don't have to constantly override chameleon styles
• We try to give proper Magnolia themeing to standard vaadin widgets, e.g. error messages, loading indicators
  • Maybe we can drop a few custom widgets then
• complete theming for basic vaadin fields
  

  • Jira
    server Magnolia key MGNLUI-710

• We then tackle other subtasks in

  Jira
  server Magnolia key MGNLUI-704

• 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)
  We evaluate SASS

Decision

-

2. Project structure and Widgetset

Problem

• It is hard to relate widget java classes - where style names are set - to their actual CSS rulesAll stylesheets even for widgets are in the theme directory, which is not necessarly bad but should be reviewed
  We want these styles to remain dynamically loaded (not processed at GWT compilation time) so that it's easy to develop them
• We need to review the pattern for applying desktop vs. tablet styles as well
• 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

Proposal

• 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 Consider dropping the gwt/public directory for client-side code, and aligning on vaadin7 package structure (client/server/shared)
• Align We align naming of widget classes
  
  • can we try to use *Widget / *Connector consistently?when do we append the *Widget suffix? (e.g. client-side sub-widgets)
  • can we drop client-side naming *View / *ViewImpl stuff?

Decision

• • 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 clearly specified clear how an app developer would add adds a custom widget to her app
• There is no guideline either on It is not clear how an app developer would add 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