You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Abstract

Themeing and Styling need to be improved, especially the stylesheets are quite a mess as of 5.0-alpha2. Project structure needs to be reviewed to properly modularize styling and widgets, so that apps/views can be properly extended. We expect this concept to lead to proper themeing and styling guidelines, as well as reorganizing and cleaning up the stylesheets.

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

 

1. Themeing

Problem

  • 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 be applied in a more light-weight way

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
  • 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 rules
  • All 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
  • As Sasha pointed out, there may also be room for Optimizing the WidgetSet

Proposal

  • Consider dropping the gwt/public directory for client-side code, and aligning on vaadin7 package structure (client/server/shared)
  • Align naming of widget classes
    • can we 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

-

 

3. Extensibility

Problem

  • An app developers cannot define styles for her own app in its own module
  • It is not clearly specified how an app developer would add a custom widget to her app
  • There is no guideline either on how an app developer would add her own icons for her app and actions

Proposal

  • Evaluate the use of the @Stylesheet annotation

Decision

-

  • No labels