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

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.

Error rendering macro 'jira'

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

 

Status

(tick) Level 1 was implemented in 5.0-alpha3, please find the details at the App theme documentation page.

(error) 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
    • 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
    • (error) 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

 

  • No labels