Page History
...
- 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
- SASS needs to be compiled to CSS
- On-fly compilation is intended for development use only
- VaadinServlet processes SASS files and compiles them before HTTP request is returned
- Problem: Our static resources path is not handled by the VaadinServlet and compilation does not take place.
- Need script to compile .scss files into .css during production builds
Proposal
- We use SASS
- We cannot specify multiple themes in the
@Theme
annotation- But we can add
@include
SASS rules to use themes as mixins
- But we can add
- We have a MagnoliaThemeUI demo vaadin application that features UI components from vaadin, for theme development
- either we put it in an external sandbox, with a dependency to magnolia-ui-theme
- either we start getting theme outside magnolia_ui, because it has no dep here and can be built upstream
- widgets can also make the move in a second step
- We start theme again, picking minimal rules from the existing CSS into new SASS stylesheets
- We inherit the base theme
- We start with standard vaadin fields
- Then we try to give proper Magnolia themeing to other standard vaadin widgets, e.g. error messages, loading indicators
- Maybe we can cleanup our widgets a bit
...
- 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
- There cannot be parallel widgetsets. They must be defined inside a tree structure and all widgetsets must be compiled only once into one compilation unit.
- This leads to a problem if an App developer has to build the admincentral in order to have client side widgets.
Proposal
- 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 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
- 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
-
3. Extensibility
...
Overview
Content Tools