Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: updated proposals and added suggestion for project architecture

...

  • 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 use SASS
    • We cannot specify multiple themes in the @Themeannotation
      • But we can add @include SASS rules to use themes as mixins
    • We have a MagnoliaThemeUI demo 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
    • features UI components from vaadin, for theme development

 

    • is this acceptable within the magnolia_ui project? (ui-theme packaged as war)
  • We start theme again by , picking minimal rules from the existing stylesheets and bringing them CSS into new Sass SASS stylesheets
    • We can inherit the base theme so that we don't have to constantly override chameleon styles
    • We start with standard vaadin fields
  • Then we We try to give proper Magnolia themeing to other standard vaadin widgets, e.g. error messages, loading indicators
    • Maybe we can drop a few custom widgets then
    We evaluate SASS
    • cleanup our widgets a bit

Decision

-

 

2. Project structure and Widgetset

...

  • 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
    • 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

  • Consider dropping the gwt/public directory for client-side code, and aligning We align 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?
    • 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 add the magnolia-ui-theme project
    • we start taking vaadin field styles from widgetset to here, using properly modularized SASS files
  • We try to draw a meaningful separation for "shell-only" widgets

Decision

-

 

3. Extensibility

...

  • 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

  • We cannot use @Theme annotation for third party apps because theme is set on admincentral
  • We use CSSInject to dynamically load an @import rule which references a CSS stylesheet
    • optionally we try to reference a SASS one

Decision

-

 

Suggestion box

  • The magnolia theme application could ultimately switch between expected screenshot and actual fields, to help on browser support
  • Structure (base directory magnolia_ui):
    • magnolia-ui-admincentral
      • @Theme("admincentral")
        AdminCentralUI
      • themes
        • admincentral
          • include magnolia
    • magnolia-ui-theme
      • @Theme("magnolia-theme-ui")
        MagnoliaThemeUI
      • themes
        • magnolia
          • include base
          • include magnolia-widgets-base
        • magnolia-theme-ui
          • include magnolia
    • magnolia-ui-widgetset
      • themes
        • magnolia-widgets-base

 -