Skins

Skin architecture

The skin holds the presentation settings for your application or your portal, but includes no content, only the rules that govern how that content is styled. This approach helps you save time while building your UI, because no matter what components you use, or how many times you change their configuration, the application always draws presentation settings from the skin as a single source.

By default, a portal points to the skin that is specified in the application, which ensures that all portals in your application have the same look and feel. You can associate each of your portals with a different skin, but having a single skin for the entire application is the best practice. If you do not specify a skin for your application, the application defaults to the pyEndUser skin.

Skin inheritance

You can use skin inheritance to pass down settings from a parent skin to a dependent skin. For example, a bank application can use a skin that defines the shape, color, and font for the buttons. If the bank's mortgage division uses a different color in branding, you can create a skin for the mortgage division that defines the color of the button but inherits the rest of the settings, including the font and shape, from the parent.

When to use a CSS helper class instead of a skin

If the skin in your application has many sets of settings that define the same type of a component, and these sets vary only slightly, you might benefit from using Cascading Style Sheet (CSS) helper classes to adjust layouts and cells. For example, you can use standard CSS helper classes to center elements or change their standard margins.

For more information, see CSS helper classes.