Hello and welcome to Themes and Styling in OutSystems. So what is a theme? The
theme is the definition of the look and feel of your application. Every module
that has any form of UI has a default theme. When you create screens within
these models they inherit not only the visual definitions, the aesthetics of the
theme, but also the capabilities that you coded in the theme. On the slide we have
an image that shows an application built using what we call a responsive theme.
This means that this theme is designed to adapt to the size of the device that
you're using, therefore you're able to use this application on a mobile phone,
on a desktop, or on the tablet. The most important characteristic of a theme is
that it provides the style sheet for the screens that use it. When you create a
theme, it normally is centralized to be used in multiple modules and while each
screen uses a theme, you can actually have multiple screens on your module
that use different themes depending on the objective of these screens. As you
can see on the right hand side of the slide, there's more to themes than just
the style sheets, even though the style sheets are the most important thing.
Another important thing is that it defines common layouts, and we'll talk
about these in a few slides. So how then do you write the style sheets in your
themes? There's a dedicated editor for style sheet editing in the OutSystems
platform and you can write standard CSS rules using a syntax highlighting editor.
You will see that, as you're writing your CSS, the effect on the screen that you
may have open on the editor will be immediate.
If you pay close attention to the right hand of the slide, you will notice that
the editor has several tabs, each of these represents a different style sheet.
As you probably know, style sheets
cascade, and that's where their name comes from, from one to the other.
This means that style rules that are closer or more specific take precedence
over rules that are further or more generic, when applied to a particular
HTML element or in our case widget. In the editor then the further right you go
in the tabs, the more generic that style sheet is. So, in our example, on the
rightmost tab we have the CSS from the London theme, that is then augmented by
the CSS in the LondonFixed theme, that serves as the base to our module's theme,
which is OSMDb. Finally, this module's theme can be fine tuned by the CSS that
is specific to this particular block called StarDisplay. While this
right-to-left order is simple to understand one subtlety worth noting is that, in
order to ensure that your applications have a consistent look and feel, the style
sheet of web blocks is the first to be loaded into the generated HTML by the
platform. This making it the most generic and the lowest in the inclusion order of
rule priorities.
This is because web blocks are very frequently used to create custom widgets
that you will want to reuse in several modules, and that way you retain the
possibility to customize their look and feel in a more specific style sheet. So
in our screenshots, assume that our screen HomePage is included in the
module that has the theme CSSLoadOrder and that the screen HomePage includes
the web block BlockContainer.
How does these rules apply and what order are they included? So the first CSS to be
included is the web block whereby the web block says "as far as I'm concerned
TestClass should be green".
However, since this web block is used in an application that decides that TestClass
should be yellow, the theme states
"no, no... over here TestClass is yellow" because it fits the style for this
application. This is normally where you will want to leave it, but if for some
reason the HomePage screen needs to have an override and say "look, locally to this
screen TestClass needs to be red", it can do so and this is the order of
inclusion that allows you to do these fine tunings. So you define your style
sheets.
How do you then actually go about using the styles that are defined there? The
simplest way really is to use the style classes property on your widget. There
using the drop-down you can select any of the rules that you've created in your
style sheets. Should you want to apply more than one rule to the same element
you can separate them using a space. If for some reason you want to have styles
that are applied depending on a certain condition, use the extended properties as
the right hand screenshot shows. So in this example we're overriding both the
style and the class attribute of the underlying HTML element and we're
setting it to a value depending on the situation being dangerous or not. For
your benefit,
here's a list of what is the underlying HTML object to each of our base widgets:
This will allow you to write the correct CSS rules for each one of these widgets.
As mentioned previously, themes go beyond the stylesheet. We also use it to define
common screen layouts. So over here in these properties that are highlighted you
can define what web block by default dictates the structure of standard
screens. That's the one pointed at by the layout property, the structure of info
balloons and pop-up screens, and the structures of emails that you'll be
sending from this application.
Furthermore, you can also select which blocks will be placed by default into
the placeholders for the header, the menu and the footer. These properties are very
handy
and are heavily used when creating screens via scaffolding accelerators
which is something that we'll come back to in another lesson. So let's have a look
at how these themed properties influence the layout of a freshly created screen.
Our HomeScreen on the right is a standard screen and as such has got the
layout block as its root widget. The standard layout has many placeholders
defined inside where the developer will then create the screen content, as you
can see from the widget tree. Notice however that the header, menu and footer
placeholders are immediately pre-filled with the appropriate blocks also from
theme properties. Of course, there's nothing keeping you, as the developer, to
then go over there,
remove or adapt any of these placeholders. In closing, there's just
time to mention the special Menu block. This block is designed to provide
built-in support for single level or even two level menus by working together
with two specific static entities called MenuItem and MenuSubItem. You can drag
and drop any screen on your module into the menu block, with or without opening
it in the editor, and an accelerator will kick in to create the appropriate links
and the static entity records that make the menu functional. Since the Menu block
is, as we've seen, by default included in all screens, every screen uses the input
parameters of the block to inform it which menu options should be highlighted
for that screen. This is a very powerful and very handy feature that greatly
accelerates your screen design. And that's it for the basics on themes and
styling in the OutSystems platform. See you in the next lesson.