Servoy offers a layered mechanism of styling the UI of solutions, with the options slightly differing for Smart Clients and Web Clients.
Smart Client: Java Swing Look And Feel > Look And Feel Theme (optional, depending on the used Look And Feel) > Styling within the solution
Web Client: Default StyleSheet > Web Client Template modification > Styling within the solution
This chapter describes the various levels of Styling options for a solution in Servoy. First the Smart and Web Client specific Styling options are discussed, after which Styling options that are applicable to both Clients within the solution are presented.
NG Client: see Styling in the NGClient
In This Chapter
Smart Client Specific Styling Options
Servoy Smart Clients are Java Swing applications and Java Swing has the concepts of Look And Feels (LAFs) that can be applied to all Swing components.
Servoy supports using Java Swing Look and Feels out of the box.
About Java Swing Look and Feels
Java Swing Look and Feels come in two variaties:
- Cross platform Look And Feels
- Platform specific Look And Feels
Cross platform Look And Feels aim to provide the exact same UI regardless the platform, for example Windows, OSX or Linux, on which the LAF is used.
Platform specific Look And Feels will only work on the platform they are designed for.
Java on each platform ships with at least a platform specific LAF, that is the default LAF used by the Servoy Smart Client. Java also ships 2 cross platform LAFS, Metal and Nimbus, of which Nimbus is the more modern LAF.
Themes
Some LAFs support multiple themes.
Adding Additional Look and Feels
Besides the LAFs that are shipped with Java itself, additional third party LAFs can be added to Servoy, by placing the LAF library in the {servoyInstall}/application_server/lafs directory.
A word of caution on third party Look And Feels
There are many third party Look And Feels around for Java, both free/open source LAFs and commercial LAFs. The quality of these LAFs differs, so when opting to use a third party LAF, make sure to properly test the LAF in combination with the developed solution in Servoy. A public listing of the majority of the available third party LAFs can be found on http://www.javootoo.com/
Creating Custom Look and Feels
Creating custom Look and Feels requires detailed Java knowledge and is in general a lot of work.
Servoy partners with Centigrade, a company that provides User Interface Design services and products, one of the products being a customizable Look and Feel that is fully compatible with Servoy. For more information, see the Centigrade website.
Specifying the Default Look and Feel for Smart Clients
The Smart Client Settings on the Servoy Application Server allow the configuration of the default LAF for all Smart Clients, through the selectedlnf property. This property needs to be set to the className of the Look And Feel class. When the className is unknown, it can be retrieved by calling the following function in a Smart Client, after manually selecting the LAF in the Smart Client Preferences:
var laf = Packages.javax.swing.UIManager.getLookAndFeel() application.output(laf.getClass().getName())
Not every LAF is supported on every platform. Notoriously the OSX platform is limited in the supported LAFs. It is therefor possible to exclude the Smart Clients started on OSX from getting the supplied LAF, using the pushLnfToMac setting.
If the LAF supports themes, the default theme to use can be specified through the lnf.theme setting.
Manually Changing the Look and Feel in a Smart Client
Through the Preferences panel in the Smart Client, users can select the Look and Feel of their liking. The Preference panel is accessible through Edit > Preferences > Look and Feel.
Access to the Preference panel by the user can be removed using the window plugin, that allows to remove the Preference menu item from the Edit menu.
Web Client Specific Styling Options
Web Client Default StyleSheet
The default styling of forms and element in the Web Client is determined by a default stylesheet that can be customized. See Customizing the Web Client for more info.
Pushing Servoy Element Class into DOM Element
Servoy allows the style classes of the Servoy elements that have styleClass property to be pushed into the DOM elements.
For this, the webclient setting servoy.webclient.pushClassToHTMLElement needs to be set to true. The styleClass set on the Servoy element will be pushed into the DOM hierarchy, on the first element of the hierarchy corresponding to the Servoy element.
Example This is an example of how the styleClass of a TEXT_FIELD is pushed into the DOM element
The styleClass property set on the field is: 'fieldStyleClass', and is defined in the StyleSheet like this:
field.fieldStyleClass {
background-color: #F00;
}
The DOM element will be:
<div servoy:id="sv__82335AC7_C903_46F1_8F36_9B44AA4615E3_wrapper" id="sv____82335AC7__C903__46F1__8F36__9B44AA4615E311_wrapper" class="fieldStyleClass" style="position:absolute;height:16px;min-width:130px;width:130px;left:150px;top:130px;"> <input servoy:id="sv__82335AC7_C903_46F1_8F36_9B44AA4615E3" name="10" class="field" type="text" value="3" id="sv____82335AC7__C903__46F1__8F36__9B44AA4615E311" autocomplete="off" onkeydown="onKeyDownConsumeEnter(event, '?x=u1ooTww5c8GP17GlZDvgUmxY17mD3BWf5ccGjoUMzTveUu0Mi2G1wRitV1MI28ok', 'sv____82335AC7__C903__46F1__8F36__9B44AA4615E311')" onkeypress="return Servoy.Validation.numbersonly(event,false,'.',',','$','%',this,-1);" style="margin:0px;" tabindex="4" onblur="postEventCallback(this,'blur','?x=JZec7WTy2t8cdQ*ePrREbjfGUSFMI- ZQ8HNJMnJl7JuYaifcsWmWShVmxcd1w*8w',event,false)"> </div>
Web Client Template Modification
Each form created in Servoy Developer results in a customizable HTML and CSS template which are at runtime utilized to create the HTML markup of the Web Client. See Customizing the Web Client for more info on template customization.
Solution Styling Options
Within a solution, regardless of whether the solution will run in a Smart or Web Client, Servoy provides 2 layers of designtime styling options and 2 layers of runtime dynamic styling options
Designtime Styling Options
The two levels of designtime styling options are StyleSheets and designtime properties of all the UI components.
StyleSheets
Servoy provides the ability to separate the Styling from the solution's code through CSS StyleSheets. These StyleSheets can be created and managed inside the Servoy Developer IDE (Solution Explorer > Resources > Styles).
A StyleSheet is linked to a form using the form's styleName property.
The StyleSheet can define default styling for each UI objects within Servoy (forms and elements) and provide any number of additional StyleClasses for each UI object. These additional StyleClasses can be set on individual UI objects through their styleClass property.
In addition to providing styling for specific UI objects, the StyleSheet can also provide odd/even/selected for the rows in the grids of forms in TableView and Portals.
When creating a new StyleSheet in Servoy Developer, the New StyleSheet wizard provides a option to insert a StyleSheet sample in the newly created StyleSheet. This sample provides a good overview of the available options.
The CSS Editor in Servoy Developer provides full code completion for the supported CSS properties and their values.
For an overview of the supported CSS properties, see Supported CSS style properties
Switching StyleSheets
At designtime, forms can be designed to use a specific StyleSheet. In order to facilitate skinning the solution, for example for different customers, Servoy provides the option to dynamically switch the StyleSheet use at runtime using the following code:
application.overrideStyle('baseStyle', 'customerXStyle');
When this code gets executed, any form that was designed to use the StyleSheet 'baseStyle' will instead start using the 'customerXStyle'. Note that this will only take effect on forms that are loaded after performing the switch.
Designtime Properties
While the StyleSheet support provides generic styling options, with the option to differentiate on individual UI objects through additional StyleClasses, all the UI objects also support several styling related properties, like borderType, background and fontType for example.
As long as these properties are set to default the styling of the element will be according to the applicable StyleSheet and StyleClasses. When specifying a a custom value for the property, it overrides the Styling inherited through the StyleSheet.
Runtime Dynamic Styling Options
At runtime there are 2 levels of dynamically changing styling:
- Updating UI component properties through their scripting API
- Conditional styling using the onRender event
Updating UI Component Properties through Their Scripting API
Each UI component provides a scripting API and that API provides methods to alter the appearance of the UI component dynamically at runtime.
For a complete overview of the runtime API of all UI components see RuntimeForm for form instances and the child nodes of elements for all the different element types.
Conditional Styling Using the onRender Event
The onRender event on forms and elements provides a way to conditionally change the appearance of the UI component.
The onRender event is available on forms, portals and elements. This event allows changing display properties of supporting components just before they are shown or updated. As such it can be used for conditional formatting for example.
On forms and portals the event is fired not only for the form/portal itself, but also for all the standard Servoy elements on the form/portal, if the element does not have its own onRender event handler. The form/portal level onRender event will not fire for beans.
The onRender event handler is called with a parameter of type JSRenderEvent, that provides the following functions:
getRecord(): the record of the rendered objectgetRecordIndex(): the index of the rendered objectgetRenderable(): the rendered object
The returned object is of typeRenderable. ARenderableobject can be an instance of aRuntimeForm,RuntimePortalor any of the otherRuntimeXxxxelements.
TheRenderableclass exposes all the properties that can be set in theonRenderevent and also utility functions to get the rendering element type and its dataprovider.
TheRenderableclass is a generic class and some of the properties and methods are not applicable on the actual object being rendered. For example, if the object being rendered is an instance ofRuntimeForm, the propertytoolTipTextor the methodgetDataProviderIDare irrelevant. When these are set/called anyway, they will fail silently .hasFocus(): whether or not the rendered object has the focusisRecordSelected(): whether or not the record of the rendering object is selected
Any updates made in the onRender event to the rendering object are persistent within the client session until changed through the runtime API of the element or in a consecutive onRender event. This means that in the onRender logic, both states of a property need to be handled. This means that if the onRender is used to set the fgcolor of a field depending if the dataprovider's value is negative or not, the fgcolor needs to be explicitly set for both negative and positive numbers. When the same foreground property is also set in scripting and should overrule the onRender, the developer needs to take care of this inside the onRender logic.
Example Making negative values in a column red and zero values orange
/*
* Called before the form component is rendered.
*
* @param {JSRenderEvent} event the render event
*/
function onRender(event) {
/** @type {JSRecord<db:/udm/orders>}*/
var rec = event.getRecord()
if (rec && rec.amt_tax == 0) {
event.getRenderable().fgcolor = '#ff6600';
} else if (rec && rec.amt_tax < 0) {
event.getRenderable().fgcolor = '#ff0000';
} else {
event.getRenderable().fgcolor = '#000000';
}
}
About performance: The onRender event will be fired often. It's therefor advised to keep the logic inside the onRender event handler method as optimized as possible, for quick execution. It's advised to refrain from calling any code outside the API of the JSRenderEvent or the Renderable class.
Overview
Content Tools
Activity