The channels must be created in the corresponding repository:

The code of the channel is mandatory. Typically it is used conventional syntax, with lowercase and underscore between separate words. As usual, it is preferable to give a meaningful name to the channel.

The Description field allows a more detailed description without any pre-established format. Although the program assigns a random name if this field is empty, it is important to note that this description will be necessary to select the channel if you want to add it to the desktop. That's why it is recommended to provide a meaningful description too.

The channel data will refresh in the predefined interval of seconds (minimum 60) defined in the Autorfresh (sec.) field, unless the user has configured it for the desktop where the channel is found.

The DB Server field indicates whether the channel will run the SQL on the primary or secondary server database. For channels that do not require a database such as obtaining data from a SOAP service, None should be indicated here.

Tags are usually used to identify the channels. These should have been previously defined in the wic_pt_channel_tag repository.

There are multiple formats to present data so that it can be viewed in a more systematic and summarized way. Axional Studio has a wide range of available layouts to choose the best visualization based on the data that we want to show. These possible layouts for the channels are List, Superlist, Catalist, Blob, Html, Single value and Favourite. For further information see Channel types section.

The Light view indicator is linked to the channel appearance of List and SuperList Channel types. For further information see Styling.

In other cases, the best way is to represent the data using graphs. The graph representation is restricted to the channels type list. The selection of the Render will determine the type of graph. The system allows you to define different types of charts: Cartesian, Map, Trends, Radar, Piew view, Heatmap, Treemap, Heatmap chart and Funnel. Maps are used when the list contains geographical data. For further information see Charts and Maps sections.

The data displayed in the channel is configured via the SQL Statement text area box. The statement may consist of a SQL query or an XSQL-Script returning a result set.

An SQL statement might be written in XSQL, SQL Native, or might be an XSQL script call.

Each SQL statement may include the following injections:

1. $COLUMN: This injection allows the user to create a column that will change automatically from the desktop channel when the user chooses to change it. Its possible values will be defined in the "SQL Column" tab. For further information see SQL Column section.

2. $0: This injection allows the user to configure and filter their channels by selecting values.

   The list of values will be injected in the $0 clause. Therefore, when value filters are enabled, the WHERE clause must follow this format: [name_of_column] IN $0.

   The range of values that the user can choose from is configured by adding symbols to the channel in the

   Data Selection

   box. Using Channel Options on the desktop, and Edit symbols, the user will be able to select the row that wishes to filter by. For further information, see the section Channel symbols.

3. $METAQCOND: This injection allows the user to add quick filters to the channel. Permitted filters will be defined in the "SQL Filter" tab. For further information, see section Filter conditions.

In this section, the developer can define a variable column that will change dynamically on the desktop when the user chooses it. That is, different columns can be defined to perform the data selection.

To implement this variable column properly, the string $COLUMN must first be written around the conditions of the column in the SQL Query. The program will replace that string for the desired columns.

Then access the SQL Column tab and define the columns that will replace de $COLUMN string.

One of the columns must be defined as the default column, so the system defines the first one defined as the default one, although this selection can be modified.

The system will look for the column properties in the column definition of table + real column. On the contrary, if real columnit is not defined, the system will look for the properties in table + column.

When the channel is executed for the first time, the Output fields will be automatically created by the system, including the variable column named _column_.

Users are allowed to apply certain preconfigured conditions to a channel. In the SQL FILTER tab, a list of SQL conditions can be programmed. These conditions will be injected in a $METACOND clause that must be defined in the SQL statement. If no filter is selected by default, the $METACOND clause will be replaced by "1 = 1".

Through the definition of symbols, the user is allowed to edit the channel in order to filter the information based on certain elements. Filters are defined in the corresponding repository:

Having a repository allows the same symbol to be reused in more than one channel. At the bottom of the screen, in the Channels box, the system shows all the channels where this symbol applies.

• The channel Code is mandatory and unique: use conventional syntax, with lowercase and underscore between separate words.
• Although the Name field is not mandatory, it is shown in the channels, so it is preferable to give a meaningful and short name.
• The Multiple choice flag will allow a single or multiple selections of symbol items.
• The status shows if the symbol is used in a channel (used), or on the contrary if it is not used in any channel (unused).
• The statement: by agreement, it has been defined that the first column will be the ID and the second the description of the symbol elements.

Once the symbol has been defined in the repository, it will be necessary to access the channel and add the code of the symbol in the corresponding field. It is important to remember that the list of values will be injected in the $0 clause and defined according to [name_of_column] IN $0.

To access the Attributes options, use the drop-menu Dictionary / Physical / Attributes.

The palette feature allows us to use the Table Colorizer feature to parameterize the way of colorizing grid cells depending on its content, generally to emphasize the importance of a cell among a group of cells.

Table Colorizer are mainly focused on the colorization of grids.

Its use is interesting when:

• The dataset contains numeric values to be classified
• The dataset contains discrete values (numbers or strings) from which we want to obtain the frequency of appearance

The best thing of Color Palette is that it's very easy to colorize the grid, just by indicating a palette of colors and one of the defined algorithms we have enough. At the same time, it can be added complexity to the colorizer with the use of ranges.

There are two methods to define the way to colorize the table:

If the method defined in a color rule definition is 'Simple distribution', 'Quartiles distribution' or 'Repetitions'. To define the colors that will be use we need to define the palette with:

wic_jdic_color_rule_def	wic_jdic_color_palette

The color of the cells will be selected with a series of rules defined:

To define the rules, a series of variables may be used:

Upon clicking the "Column Header" button, the following screen will be shown:

As can be seen in the following image, the upper panel contains a button labelled "Series of Headers". This option allows the user to correlate multiple headers, with the goal of representing values from multiple graphs all in one.

In the "Series of Headers" input field, the user must indicate the header to which the current header will be connected.

The channels that will render a Table (List and SuperList Channel types), have two styling methods, the normal one and the light view mode. This one can be selected with the checkbox:

The channels that have this flag will render the table in a much more light view giving clarity to the channel information. This channel will be displayed without headers, with the minimum borders possible to make it easy to read the data, the text font will be bigger. On the other side, these tables won't allow to sort the data on the client side.

Default view	Light view

It is possible to override default CSS styles via wic_styles_app_cssdata_v2 in wic_conf.

More information about how to override default CSS may be found here.