How to change the page styles dynamically at runtime
[Edit 01/09/2001: Updated the sample to also override the colors in the popups]
Service Studio gives you a few good options to define style sheets for you pages and emails. Besides the global style sheet that applies to the whole eSpace, you can add a custom style sheet to each web screen and email, and you can even define a custom style sheet for each web block. The platform will take care of including all the style sheets in the html of the page/email according to the following order:
- The style sheet of all the web blocks directly or indirectly included in the page/email (including referenced ones), from the inner most blocks to the outermost blocks in case of nesting
- The eSpace style sheet
- The style sheet of the web screen or email.
In web screens, all those style sheets are deployed to separate files and referenced by the page, while in emails, their content is merged together and included inline in the html for optimal display in the majority of email clients. The platform also applies some post processing to the content of the style sheets to optimize their usage in content delivery networks.
All these style sheets are statically defined at design time and can’t be dynamically changed at runtime, but it’s possible to include more style sheets at runtime that override the static ones. That allows us to do cool things like giving a specific user a different style sheet, changing the color scheme to red when some critical situation is happening, or even letting the user choose the style sheet of his preference, like this:
To accomplish this, we need to do two things:
- Make sure the extra style sheets are deployed together with the application
- Manipulate the html returned to the browser to include a <link rel=”stylesheet”> tag in the <head> section
For #1, we can create the .css text files outside Service Studio and then import them as resources by using the Import Resource operation available in the eSpace tree context menu. However, that’s not a very manageable solution. An alternative way is to create a set of web blocks that we don’t use in any page, and use them just to define these style sheets. The platform will still deploy their style sheet files, even if the blocks themselves aren’t used, and we can then reference those files in the page.