Page History
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.
Jira | ||||
---|---|---|---|---|
|
Table of Contents | ||
---|---|---|
|
Info | ||
---|---|---|
| ||
Level 1 was implemented in 5.0-alpha3, please find the details at the App theme documentation page. Installing modules which come with custom widgets needs to recompile the whole widgetset, this is a major blocker right now. |
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
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)
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
- magnolia-ui-vaadin-theme
- Enable SASS for STK themes
Overview
Content Tools