WO2016013942A2

WO2016013942A2 - Declarative theming

Info

Publication number: WO2016013942A2
Application number: PCT/NZ2015/050097
Authority: WO
Inventors: Alex DYER; John Martin; Lindsay Smith; Michael GANNON
Original assignee: Core Technology Limited
Priority date: 2014-07-25
Filing date: 2015-07-27
Publication date: 2016-01-28
Also published as: WO2016013942A3

Abstract

A method and system is provided for theming for visual components of applications that comprises providing a theme declaration comprising at least one class describing a theme for a visual component, providing a theme interface for each visual component that allows a user to alter at least one attribute of the class contained in the theme declaration, storing the theme declaration and theme interface in persistent storage, providing a template able to produce style sheet code for the visual component from a theme declaration, processing the template using a computer process to produce style sheet code for the visual component from the theme declaration, and saving the style sheet code to persistent storage.

Description

TITLE

Declarative Theming

FIELD OF INVENTION

This invention relates to a definition and implementation of a declarative mechanism for defining styles for visual components, independent of their implementation; and the generation process used to output the styles

BACKGROUND

Visual components are used in computer processes to display information to a user. Examples of visual components include buttons, radio buttons, text boxes, sliders, check boxes, and drop-down menus. Typically these components can be styled in different ways to allow re-use of the components in different situations. Visual components in a computer process are often referred to as widgets. Widgets are often associated with the user experience of software programs. They are used to communicate and represent information to a user executing a computer process.

Widgets can have a theme associated with them. For example, all visual components in a software application will use the same font, be in the same font size and have consistent background colour(s). A theme is a configuration of the visual style of the component. This theme can either be supplied with the widget, i.e. the default visual configuration, or custom themes can be created by an application developer. The purpose of the theme is to control the visual appearance of the application by customizing the look and feel of widgets.

Cascading style sheets (CSS) is a style sheet language that can be used with any markup language. It is generally used to describe the look and formatting of web pages, user interfaces for web applications and user interfaces for mobile applications. CSS allows the separation of the content of a web page and the look and feel of the web page. CSS if often used to describe the style or theme of a web application or web page.

In the current state of the art, the configuration of a style or theme is tightly coupled to implementation of the visual component; any change to the style necessitates a deep knowledge of how the component is implemented. Any changes to the implementation of the component are likely to break existing style configurations.

Additionally the language used to specify the style (for example CSS) is highly implementation specific; any tools that need to provide a simple user interface for changing style need to understand both the syntax for style configuration, as well as the impact on the visual component implementation.

It is an object of a preferred embodiment of the present invention to go at least some way towards addressing the problem of providing a way of declaratively specifying a theme for a visual component, or widget, or a whole set of widgets at the same time. While this object applies to the preferred embodiment, it should be understood that it is not intended to limit the scope of the claims. This is because the object of the invention perse is simply to provide the public with a useful choice.

Throughout the specification the terms widget and visual element are used interchangeably. A widget is a visual component.

The term "comprising" and derivatives thereof, e.g. "comprises", if and when used herein in relation to a combination of features should not be taken as excluding the possibility that the combination may have further unspecified features. For example, a statement that an arrangement "comprises" certain parts does not mean that it cannot also, optionally, have additional parts. SUMMARY OF INVENTION

In broad terms in one aspect the invention comprises a method for providing theming for visual components of applications comprising the steps of:

providing a theme declaration comprising at least one class describing a theme for a visual component,

providing a theme interface for each visual component that allows a user to alter at least one attribute of the class contained in the theme declaration,

storing the theme declaration and theme interface in persistent storage, providing a template able to produce style sheet code for the visual component from a theme declaration, processing the template using a computer process to produce style sheet code for the visual component from the theme declaration, and

saving the style sheet code to persistent storage. Optionally the theme declaration may contain more than one theme for a visual component.

Optionally the theme declaration may contain classes for more than one visual component.

Optionally the template can be used multiple times to produce style sheet code for one or more visual components.

Optionally the step of processing the template using a computer process to produce style sheet code for the visual component includes the steps of:

retrieving the visual component to be processed,

reading all theme files matching the visual component

applying the template to each matching class to generate the style sheet code, and

if a class is found with a name matching a previously processed class, omitting the class.

In another embodiment the invention comprises a system for allowing properties of a visual component theme to be altered by a user comprising:

a theme declaration section comprising at least one class describing a theme for a visual component,

a theme interface for each visual component that allows a user to alter at least one attribute of the class contained in the theme declaration,

persistent storage for storing the theme declaration and theme interface, a template able to produce style sheet code for the visual component from the theme declaration,

a computer process to cause the template to produce style sheet code for the visual component from the theme declaration, and persistent storage to save the style sheet code.

Optionally the theme declaration may contain more than one theme for a visual component.

Optionally processing the template using a computer process to produce style sheet code for the visual component includes:

retrieving the visual component to be processed,

reading all theme files matching the visual component

BRIEF DESCRIPTION OF DRAWINGS

Some preferred forms of the invention will now be described by way of example and with reference to the accompanying drawings, of which:

Figure 1 shows a theme interface and theme declaration file

Figure 2 shows a theme interface, theme declaration file and template file; and Figure 3 is an algorithm showing how code to implement the visual aspects of a visual component can be generated.

DETAILED DESCRIPTION The declarative theming method and system provide a layer between a software developer and the software code used to implement visual aspects of visual components. This code may be CSS (cascading style sheets) or any other suitable code. The declarative theming provides a theme interface, a theme declaration and a template.

Figure 1 shows a theme interface 1 and theme template 2. The theme interface contains a description of the parts of the widget that can be modified through theming. The theme declaration provides default options and in some embodiments a range of custom options for the widget. The template (shown in figure 2) is used to generate the code to implement the visual components (widgets) for each option provided for the widget.

THEME INTERFACE

Each visual element has a theme interface. The theme interface defines a set of areas, with each area containing a set of properties or attributes that can be configured by a particular class. The theme interface may also show attributes or properties of the theme that cannot be altered. The theme interface allows a later user to alter some parts of a theme for a widget. The theme interface may be present to the user with a graphical user interface (GUI). The theme interface is saved to persistent storage.

The following is one example of the form it might take:

<attribute name background-glyph", type

<area name = "sub-border"> <attribute name = "background-colour", type =

"colour"/>

</area>

</area>

</widget>

The theme interface is able to specify, at the top level, any attributes of the widget that can be modified though a theme. Within the interface, additional areas can be defined that describe distinct regions within the widget that can also be modified through theming. These areas can be nested. This interface describes the general layout of the widget in broad area terms, which should correspond to visual parts of the widget. It may be that some of these areas are mutually exclusive in that only one is visible at a single time. Attributes may directly map to widget specific visual properties e.g. CSS, but are not required to. Also, the values for the attributes may be used in multiple places in the final widget specific visualisation e.g. across multiple selectors in the final CSS. A user of the theme interface would see a visual representation of the theme interface. For example the user may be presented with drop down menus for selecting font and a visual colour picker for choosing widget colours may be provided. These features will make the theme interface more intuitive for a user without requiring a deep knowledge of CSS. When a user alters part of a theme using the theme interface the changes are made in a corresponding theme declaration for the widget.

Widget States

A widget may have a number of different possible states. These states may include disable, mandatory, invalid etc. The theme interface for the widget can provide a list of possible states for the widget and allow the interface user to change how the widget is displayed for each of the different states. For each class, and for each widget state used in that class, in a theme declaration the system outputs the style configuration.

An example implementation of a theme interface might be:

</states>

</area>

</widget>

The above example shows three different states (invalid, mandatory and disabled). The user can select or specify different features for each state using the theme interface. Again a user of the theme interface will see a more intuitive representation of the theme interface and be able to modify various settings for each of the possible widget states.

The user may also be able to specify outside resources (for example images) for some properties or attributes of the widget.

Reusability

It is also possible to group a set of attributes together under a named unit, in order to re-use this common pattern of attributes and areas across multiple widgets e.g. a text area that has a common set of attributes like colour, font etc. An example usage might simply look like:

In this way common patterns can be provided into the theme interfaces of new widgets automatically. In some embodiments the user may be able to create new classes in a configured theme for a given widget. The user may also be able to create a new theme for an application from a base set of widgets. Information provided by the user through the theme interface is saved to a theme declaration. The user may be able to see a list of all possible themes and classes for a widget using the theme interface. The theme interface can show all the available themes for a visual component regardless of the number of theme declarations that may have been created for the visual component or may include a class for the visual component. The theme interface and theme declarations are saved in persistent storage. The theme declarations are computer processed to provide data for the theme interface. In some embodiments a theme interface can be provided for a set of visual components. In this embodiment the theme interface allows the user to alter attributes of the theme for a set of widgets as described by one or more theme declarations that include a class or classes for the set of widgets. THEME DECLARATION

A theme declaration 2 is a mapping of values to attributes in the specific areas; this may be specified in one or more files. The widget may provide the default theme declaration for the widget, and may also provide an optional range of semantic classes as well. Classes may have defined dependencies with each other. The theme declaration for a widget class binds values to the available attributes in the theme interface. The application developer specifies theme classes in one or more theme declarations. As part of the theme declaration the developer can specify any part of the theme that can be altered using the theme interface. There may be more than one theme declaration for a widget and a theme declaration may cover more than one widget. For example a general theme declaration may be made to describe the overall theme of widgets in an application. This may follow a theme like "danger". All widgets will automatically have this theme but some features of individual widgets may be customisable. As development continues new theme declarations may be created that describe new themes or new semantic classes so that there may eventually be multiple theme declarations relating to a single widget. All theme declarations are saved to persistent non-transitory storage.

The theme declaration also declares attribute values in the various states defined by the theme interface. It is also possible to declare particular areas as pseudo-state areas; only certain pieces of the widget will be affected by the pseudo-state, so the widget developer must define which attributes are changeable during those pseudo- states. Examples of pseudo states include hover, focus etc.

As one example, specifying the theme for the 'primary' class may be defined like this:

ottribute name="background-colour" value="#00FF00" />

</area>

Ottribute name="font-family" value="Font2" />

</area>

ottribute name="background-colour" value- 'pink" />

</area>

</class>

In the example above the class name is specified, primary, along with the attribute values for any of the properties that may be editable for the widget. It is not required that values are specified for every attribute, or for every area. The base class**** may be specified in a similar way; this could be specified with a base element that has no name attribute.

One implementation may allow multiple widget classes to be declared in a single theme declaration file. The widget may keep a single file of all the available classes, or define each class in an individual file. Each theme declaration file is saved to persistent storage.

One example of a theme file declaring multiple classes inside a widget definition may take this form:

<theme>

<base>

... base class specified here ...

</base>

... primary class ...

</class>

<class name="secondary"

... secondary class ...

</class> <class name="invalid">

... invalid class ...

</class>

</theme>

This theme declaration file may be quite general, in that it may not need to specify the theme name or version, since it may be declared within a widget. Theme files for applications or for separate themes may take a similar form, or they may provide more specification to say which widget the classes might be applied to.

Theme Locations

As well as provided with the widget, theme declarations may be provided as part of the application, or configured across multiple applications. These theme declarations may contain declarations for multiple widgets, or multiple groups of widgets. The system will generate the resulting CSS that is a combination of these theme declarations. The precedence and combining logic will be described later.

Variables

Variables can be defined in theme declarations that can be used across many classes. These variables can be defined at any layer within the theme system e.g. per class, per widget, per application etc. This provides the ability to configure a property of a whole set of widgets in a single place, rather than customizing each widget individually. For example, this may be used where a set of widgets all share a colour or font for any text within them. In order to change the colour or font for that whole set of widgets, you may be able to set a single variable somewhere in the theme that applies to all those widgets.

Specific Overrides

When a visual component author creates a widget, they need to define the theme interface and define the specific set of properties that are configurable through the theme. It may be that not every possible style configuration is considered from the beginning, so the theme declaration provides a mechanism by which theme developers can augment the generation process and provide widget specific visual definition. This may take the form of CSS override files where the theme developer can specify additional CSS files that are output as part of CSS generation process, and allow the theme developer to take deeper control of the final output. These overrides could also be configured per user-agent too e.g. different overrides for different browsers. Resources

Many style configurations will require the use of resources e.g. images to define the styles. The theme declaration can include references to these included resources, and these resources must be available as part of the final generated visual output. These resources can be specified directly, or through the use of variables, and can be defined in many locations e.g. alongside the theme declaration in the widget, the configured theme etc. It is also possible to override the resource in a more specific theme declaration without updating anything else about the class(es) that uses it.

The system provides a mechanism for referencing resources in particular locations, and the system will create the correct URL for the user-agent (browser) during generation of the final output. An example of this might include referencing the location of the namespace folder for images:

.{$} div {

} Combined Classes

Theme declarations have the ability to provide combined class instructions that send differing style instructions because two or more certain classes exist on the widget. In some situations, a theme designer will need to explicitly handle some class combinations. As an example, a widget may have two classes applied - 'primary' and 'link'; a theme developer may want to have a different style configuration generated for the combination of these two classes, distinct from the resulting style

configuration that would be applied if the system just processed both classes and added the result together.

It may also be possible to create shorthand names for combination classes e.g. a theme developer could define the class collapse-all to be equivalent to specifying four classes in combination:

</class>

Re-usability

As theme declarations across an application grow in size, it is necessary to provide a layer of re-use across themes at a lower level than using classes, and with more power and control than variables.

One method of doing this is through class templates; these templates can be used to group patterns of attribute settings into a single place, with the ability to parameterise with specific values when used in different places. An example implementation might look like:

<class-template name="changeColour">

<selector>span. button-disabled-span span.button-bottom-right</selector> <set-attribute name- 'background-image"

value="url({$resourceLocation}button.png)"/>

<set-attribute name- 'colour" value="{$colour}"/>

</declaration>

</class-template> <class type="custom" template="changeColour">

<parameter name="resourceLocation"

value=''url(url(.7urn:aviarc:widget:com.aviarc.toronto.widget.core:2.0.0:screen/pri y/pseudo/button.png)" />

</class>

TEMPLATE

In order to generate a widget specific visual representation, it is necessary to provide computer process instructions that map attribute values to a format that that widget will understand and use to render itself appropriately. One implementation of this involves the use of a CSS template file; this would allow the mapping of theme declaration values into CSS selectors.

Figure 2 shows the theme interface 1 and theme declaration 2 along with a template file 3 to provide style sheet code from the theme declaration 2. Values from the theme declaration (and in some embodiments from the theme interface) are used by the template in a computer process to produce style sheet code for a class of the widget. The theme interface, theme declarations, template and style sheet code can all be stored in non-transitory persistent memory.

The template file could be used to define how to generate CSS for a single theme class of the widget. The widget framework may use this template repeatedly, for each class (base and custom) required to be turned into CSS.

The benefits of this potential implementation include:

• Removing the complexity of choosing a unique selector name

• Providing the ability to substitute attribute values from the theme definition

• Providing some rudimentary conditional logic for CSS (or other style code) generation.

One example of a format for this template file might be as follows:

■{$} {

background-colour: {@background-colour}; }

.{$} div {

}

.{$border} {

border-width : {@border/border-width};

}

.{$border/sub-border} {

... more properties here ....

} .{$} div:hover {

}

This file could include a number of specially replaced tokens, two examples might be:

Selector tokens

These tokens might take the form {$<area selection>} which may reference some area in the theme interface. An empty selection may indicate the root of the widget.

These tokens may be substituted for a selector for that widget, version, and area. The framework may take care of appending the widget namespace, version, name, and potentially area name to form a unique selector.

Attribute tokens

These may take the form {@<attribute selection>} which may reference the attribute value for some attribute in the theme. The attribute selection may include prefix paths that direct the attribute search to areas within the widget theme interface. E.g.

{@border/border-width} denotes the attribute border-width of the border area.

GENERATION OF STYLE CODE

When the system needs to render a widget - generate its final output - it will use a combination of the information defined in the widget (theme interface, declaration etc.) and any theme declarations that are currently associated with the application, to generate any visual styling artefacts for the widget. CSS generation algorithm

One implementation of a CSS generation algorithm is the following (shown in Figure 3):

• Input:

5> The fully qualified name of the widget

o The current application instance

• Retrieve the named widget

• Read all matching theme files, in the following order:

o Theme files found in the widget definition

Q> Configured theme (one of):

Application theme files that may relate to the widget Theme files in the theme configured against the input instance that may relate to the widget.

• Each time a matching class is found, use the widget to generate the CSS5 specified by that class.

• If a class is found with a name matching a previously output class, omit this class.

Figure 3 shows the algorithm graphically. In step 5 the name of the widget is provided along with the current application instance. In step 6 the named widget is0 retrieved. All theme files that match the widget are retrieved in step 7 and read. As there may be many theme declaration files for a single widget and order of precedence is established for these files. This order is discussed in more detail below. In step 8 the template is used to generate a style sheet for each class defined for the widget. As the theme declaration files are processed in a specific order if a5 theme class has been processed by the template and the same theme class occurs for the widget in a later file the later class (with the same name) is omitted in step 9. In step 10 the output code is saved to persistent storage. The output code is in style sheet form. In one embodiment the output code is CSS. The algorithm is computer processed to produce the style sheet code. The style sheet code can be saved into0 persistent storage.

Template processing

One computer implemented implementation may use the idea of a template specification, which may be designed to allow top-down, single pass parsing and streaming of the resulting CSS. The computer processor may read lines from the template one at a time, and output the translated CSS immediately to a result stream. In this example implementation, this may mean that each line may need to be able to be processed on its own, only referring to environment information (such as the theme information), or information declared higher in the file.

Theme output order

If generating CSS, property ordering may need to be preserved - one example of appropriate output order used by the computer processor might be:

The default class must be output first

Custom classes must be output in the following order:

Widget classes

Theme classes - from least specific location to most specific location

Theme precedence

Multiple theme declarations can define the same set of classes; when generating the final output using the computer processor, it is necessary to have a specified sequence of locations to look up, in order to define precedence of these classes. This way theme developers can configure overrides in a well-understood and expected way.

Theme file specificity

When looking for theme files for a given widget, one computer-implemented implementation might be to provide a folder structure that the themes adhere to, to indicate which files are intended for a given widget. The above example algorithm implies some way of determining which files may contain classes for a given widget. In this example design it is possible for widget classes to be set in multiple places. For example options include:

A single theme file for all widgets

A single theme files for all widgets in a given namespace

A theme file for a particular widget

Multiple files for a single widget, so that custom classes can be declared separate files The example theme generation algorithm identifies which files might apply to a given widget, and read through each in turn. Ordering

The system will use the configured theme for a particular application. The final output will use a combination of classes and variables defined in this theme, as well as the default styling specified in the widget. Widget classes and variables defined in the configured theme override the classes defined with the widget.

Note that this overriding mechanism is at a class level, not a file level. So, a theme may add a single new class to a widget, but all the classes available through the widget itself would still be available. When overriding a class, any new class definition overrides the entirety of the previously defined class.

Theme declarations can specify theming for widgets with varying levels of specificity e.g. a widget name, a widget grouping, a specific version of a widget grouping.

Classes defined using more-specific references to widgets to override classes defined in less-specific.

More Complete Example

One possible example of a theme layout, assuming a button widget in widget grouping (namespace) 'com.aviarc.toronto.widget.core', version 1.0.0, might be:

<theme root>/

*.xml <- applies to all widgets, can contain global variables that apply to all widgets

button/ <-- button folder, applies to all 'button' widgets

*.xml <- Any .xml files in this folder can contain classes for the button widget

com.aviarc.toronto.widget.core/ <-- specifies the namespace

*.xml <- all widgets in this namespace, can contain global variables for widgets in this namespace

button/ <- button folder, any 'button' widget in this namespace, matches all versions

*.xml <-- Any .xml files in this folder can contain classes for the button widget

1/ <-- partial version - matches all versions 1.*.*

*.xml <- all widgets in this namespace matching the version, global variables for widgets in this namespace

button/ <-- button folder, any 'button' widget in this namespace, matching this version *.xml <-- Any .xml files in this folder can contain classes for the button widget

1.0.0/ <- specific version of the namespace

*.xml <- all widgets in this version of the namespace

button/ <- button folder, any 'button' widget in this version of the namespace

The algorithm identifies all files that might relate to a given widget, and the computer process goes over them looking for matching classes, starting from the least specific file and then moving onto more specific files. Files in each location might be read in case-insensitive alphabetical order.

This example layout is both for the theme structure for a widget, and for the structure found within the configured theme for an application.

Sample search order for classes

Given an example request for the CSS for widget com. namespace: 1.1.2:button, then the following locations within a single theme location might be read in the following order to read class definitions and global attributes:

theme/*.xml <-- global attributes

theme/button/*. xml <-- read all xml files for classes, applying any global attributes

theme/com. namespace/*.xml <-- global attributes for this namespace theme/com. namespace/button/*.xml <-- global attributes for this namespace theme/com. namespace/1 /*.xml <— global attributes for this namespace version (matched loosely)

theme/com. namespace/1 /button/*. xml <- read all xml files for classes, applying any global attributes for this location

theme/com. namespace/1.1/*.xml <- global attributes for this namespace version (matched loosely)

theme/com. namespace/1.1/button/*.xml <~ read all xml files for classes, applying any global attributes for this location

theme/com. namespace/1.1.2/*.xml <-- global attributes for this namespace version - exact match

theme/com. namespace/1.1.2/button/*.xml <-- read all xml files for classes, applying any global attributes for this location The computer process might read all classes in the widget, then the configured theme (either application or engine). The theme generation process might then ensure that the most-specific base class is output first across all locations, followed by the custom classes in ascending specificity order, but where the presence of a more-specific class with the same name it might prevent the less specific one from being output.

Example search order for images

Given an example, where there is a request for the image

com.namespace:1.1.2:button/image.jpg, within a theme, then the following locations might be read within a single theme location in the following order to find the image. In this example, the first match is returned

theme/com. namespace/1.1.2/button/image.jpg

theme/com. namespace/1.1/button/image.jpg

theme/com. namespace/1/button/image.jpg

theme/com. namespace/button/image.jpg

theme/button/image.jpg

The search might start in the configured theme, then the widget theme. In this example, the first match would be returned.

Theme file syntax

Any xml files at the upper levels might be read for all widget theme requests. In i example, it may provide global variables, and also declare classes for particular widgets. It might also narrow the specificity down to particular widgets e.g:

<theme>

... These apply to all widgets requested through this theme, but may be shadowed in an earlier file ...

</variables>

<!-- all widgets named 'button' will match this section ->

... Apply to all widgets named 'button' ....

</variables>

<class>

</class>

</widget>

<!- only applies to widgets in this namespace. Optionally add version number here too -->

... Apply to all widgets in this namespace ...

</variables>

<!-- all widgets named 'button' in this namespace will match this section

->

... Apply to all widgets named 'button' in this namespace ....

</variables>

</widget>

<namespace-version version="1.0.0">

... variables, widgets, classes etc ....

</namespace-version>

</namespace> </theme>

More specific files

More specific files, such as those found in namespace folders stored in persistent storage, or under the widget name, might omit some of these levels of specification because they might already have a constraint applied when they are being read.

E.g. the 'theme.xml' file in the 'button' folder at the top level of a theme - the widget name is already implied, so namespace and version constraints might be used, or might be omitted.

<theme>

... These apply to all button widgets requested through this theme, but may be shadowed in an earlier file ...

</variables>

<base>

</base>

<class>

</class>

... Apply to all button widgets in this namespace ...

</variables>

<!-- these classes will be emitted for any 'button' widget requested in this namepace ->

<base>

</base> <class>

</class>

<!-- further restrict to a specific version ->

<namespace-version version="1.0.0">

... variables, classes etc ....

</namespace-version>

</namespace>

</theme>

Even more specific files, such as those found in the namespace or version folders of a theme, might omit the associated constraint elements as the constraint is implied when they are read.

At the most specific level, when the name, version, and namespace of the widget are all known, then the theme file may be specified as per the earlier section on theme file syntax. While some preferred forms of the invention have been described by way of example it should be appreciated that modifications and improvements can occur without departing from the scope of the appended claims.

Claims

WHAT WE CLAIM IS:

1. A method for providing theming for visual components of applications comprising the steps of:

storing the theme declaration and theme interface in persistent storage, providing a template able to produce style sheet code for the visual component from a theme declaration,

processing the template using a computer process to produce style sheet code for the visual component from the theme declaration, and

saving the style sheet code to persistent storage.

2. A method for providing theming for visual components of applications as claimed in claim 1 wherein the theme declaration may contain more than one theme for a visual component,

3. A method for providing theming for visual components of applications as claimed in claim 1 or claim 2 wherein the theme declaration may contain classes for more than one visual component.

4. A method for providing theming for visual components of applications as claimed in any one of claims 1 to 3 wherein the template can be used multiple times to produce style sheet code for one or more visual components.

5. A method for providing theming for visual components of applications as claimed in any one of claims 1 to 4 wherein the step of processing the template using a computer process to produce style sheet code for the visual component includes the steps of:

retrieving the visual component to be processed,

reading all theme files matching the visual component

applying the template to each matching class to generate the style sheet code, and if a class is found with a name matching a previously processed class, omitting the class.

6. A system for allowing properties of a visual component theme to be altered by a user comprising:

a computer process to cause the template to produce style sheet code for the visual component from the theme declaration, and

persistent storage to save the style sheet code.

7. A system for allowing properties of a visual component theme to be altered by a user as claimed in claim 6 wherein the theme declaration may contain more than one theme for a visual component.

8. A system for allowing properties of a visual component theme to be altered by a user as claimed in claim 6 or claim 7 wherein the theme declaration may contain classes for more than one visual component.

9. A system for allowing properties of a visual component theme to be altered by a user as claimed in any one of claims 6 to 8 wherein the template can be used multiple times to produce style sheet code for one or more visual components.

10. A system for allowing properties of a visual component theme to be altered by a user as claimed in any one of claims 6 to 9 wherein processing the template using a computer process to produce style sheet code for the visual component includes: retrieving the visual component to be processed,

reading all theme files matching the visual component applying the template to each matching class to generate the style sheet code, and

A.J. Pietras & Co Attorney for the Applicant