Theming, styling, look and feel

If you delete the pre-compiled styles.css, the application will auto-update the theme during development.

However, when deploying the application, you should make sure you have a compiled and up-to-date styles.css.

Please not that if you use an IDE, such as Eclipse, but edit files with an external editor (e.g Atom to edit SCSS), or use the command-line, you might have to 'refresh' your project (or the relevant folders) for your IDE to notice the changes.

This is the theme “entrypoint” that should generally not be touched. If you compile the theme manually, this is the file you want to compile.

This is the compiled CSS version of the application theme, to be directly used by the application. Note that if your project contains this file, no auto-compilation of the theme will take place, and you’ll have to trigger a compile after modifying the theme. I.e you might not want to have this file while developing, but you definately need this file when going to production.

This file contains styles imported from addons, if any. There is usually no need to touch this, except to check what styles an add-on might have out-of-the-box.

Here you can find styles imported from Vaadin Designer templates.

For clarity, it’s recommended not to modify these, and override things in your own theme files instead. However, this is just a guiding principle - as long as you don’t delete the “// Styles imported from xyz” comment, your modifications will not be overridden.

This is you main theme file. Here, you configure Valo parameters, as well as set up any global variable you might want to use in your application theme. You also import and include the various sub-parts of your theme.

In applications with really limited styling, you might just have one apptheme.scss, but usually it makes sense to split things. As a rule of thumb, put each independent part (view, component) that requires some amount of styling in its own file.

The scss files specific to this project start with underscore, and the name indicates the scope of the file. Each file consists of a mixin, that is then included in the appropriate place within apptheme.scss.

Styles for the Dashboard, which is implemented using Vaadin Board and Vaadin Charts.

The main things done here is 1) joining the first row into a joint “panel”, while the other rows’ content is styled as separate panels 2) making sure padding and spacing follows Valo parameters.

There is one responsive breakpoint, which reduces spacing and removes side-margins on narrow devices.

Styles for the responsive menu.

Because it’s responsive, styles for different screen-sizes appear in separate sections. Notice that Vaadin responsiveness works with regard to the parent element (as opposed to the browser size), so that components can adjust based on the space available to them, regardless of window/device size.

A responsive selector looks like this:

In this case, the rules within the block will take effect when the element with the app-shell class is up to 600px wide.

You can remove all styles in _menu.scss and still have a decent-looking application, as it is based on a Vaadin Designer template.

Styles for the grid that lists all orders, including the filters.

Most of the styling here applyes different colors and icons to depending on the order’s status.

Styles for the form that is used to input new orders, as well as display the details of the existing orders.

This particular view shows how to do a responsive layout “from scratch”, using mostly CSSLayouts and laying things out in CSS. This is a good approach if 1) you have a fairly small view, 2) specific behaviour in mind.

This particular view is set up so that fields (or a group of related fields) basically split the view in half, but on small devices the fields take up the whole width. It’s worth considering using Vaadin Board to achieve a similar effect - it can be seen in action on the dashboard view.

Note that ProductInfo is a separate component (defined in ProductInfoDesign) within the OrderEditView which uses the same responsive styles.

There is a favicon.ico which can be replaced; it will show up in the browser tab, bookmarks, and such, depending on the browser used.

The theme also contains two sizes of application icons; these are also used as logo on the login-screen, but the main use case is to be used as “homescreen” icons when added to the homescreen of a device. You can either just replace these two icons, or if you want to add different sized icons, or remove the icons altogheter, you can do so in ApplicationServlet.IconBootstrapListener.

Making the application work well on mobile devices of various sizes requires us to tell the device how we intend it to be shown. We can do this by adding a @Viewport annotation to the AppUI class.

Applications that are built for mobile tend to give a more robust feel if zooming is turned off, but you might want to turn it back on, if your application contains content that the user might want to zoom.

If you want your application to run full-screen - without any browser controls, just like a native app - you can add the mobile-web-app-capable meta-tag.

There is commented code ready to be enabled in ApplicationServlet.IconBootstrapListener

Remember that login.html is a stand-alone page, and has all the icons/viewport tags mentioned above added separately; please remember to update it as well.

In fact, you might want to start customising by setting up login.html so that it works as you wish, then modify the Java code to match.