APEX UI Defaults

Introduction

When it comes to user interface design, efficiency and consistency are paramount.

What if there was a way to predefine the look and feel of your application's forms and reports, saving you precious development time and ensuring a unified user experience? Enter UI Defaults, a powerful feature that streamlines your design process by allowing you to define UI settings on tables and columns that will automatically apply to your application as you build it.

How Does it Work?

UI Defaults act as an outline for your application's visual components, offering two distinct categories: the Table Dictionary and the Attribute Dictionary. These dictionaries serve as repositories of styling instructions, guiding the presentation of forms and reports.

The Table Dictionary focuses on defining defaults for specific tables and columns within your database schema. It provides granular control over how data is displayed, ensuring clarity and readability.

The Attribute Dictionary offers a broader approach. It allows you to establish defaults based on column names, making them applicable across all tables. This promotes consistency and reduces redundancy in your design efforts.

Furthermore, the Attribute Dictionary supports synonyms, enabling multiple attributes to share a common definition. This feature enhances flexibility and simplifies the management of your UI defaults. By leveraging these dictionaries, you can create visually appealing and user-friendly applications with ease.

Table Dictionary

To create UI defaults, you can either go to the SQL workshop utilities area or directly from the tables/views in the object browser. You may at first be prompted to synchronise defaults. This will create defaults for tables that do not yet have any, as well as add and remove columns from existing defaults in the table dictionary to match the database definition. This might be useful to run but can take a long time to complete.

In the example below, I went straight to a single chosen table in the object browser and selected the UI Defaults option. This takes you to the Table Dictionary setup, which will create defaults for that table only.

Once the creation process has run, we should see our chosen table listed in the table dictionary. Clicking the table name will show a list of the defaults created for each column. In this example, I have also added some supplemental information for the table, such as a description, singular label, and plural label. Giving the table a meaningful description allows AI interactions to better understand the contents of this table.

Nothing special has really happened so far. It has used basic information from the table to populate some default settings, such as labels and column alignments. Clicking a column name will open a detailed page where we can apply a variety of column default settings. It is worth noting that these settings will vary depending on the data type. A data type, for example, will have additional options such as setting minimum/maximum dates and other date picker attributes.

There are a few different sections here. Firstly, some general defaults that include the display label to be used in both reports and items associated with the column and a help text field.

The form defaults section allows you to set numerous attributes for the form items relating to the chosen column. The most notable here is the "Display As" option, which determines how the column will be displayed on the form. These cover all your typical items such as text field, display only, select list, etc.

The report and tabular form defaults section similarly has a collection of attributes to define how the column is displayed in reports.

Lastly, there is a list of values section. This is where you build a list using either SQL or static values to be used if your column has a "Display As" type that relies on an LOV, such as select list, radio group, etc.

Looking through these sections, many attributes have already been set based on the column database definitions. For example, the maximum width will be pre-set based on the column size, alignment will be set to right for number fields, and the value required set to yes for non-nullable columns. I am going to work through each of the columns and make some additional changes, such as:

• Setting meaningful labels for each column.
• Adding some basic help text for each column.
• Hiding any columns I do not want to be displayed, such as EMP_ID.
• Setting other ID columns to display the relevant lookup data from their respective tables.
• Setting suitable subtypes for email, phone, and URL columns.
• Choosing suitable "Display As" options to create a user-friendly report.
• Applying appropriate format masks.

With the changes made, if I now use the page builder wizard to create a form and report, based on this table, I should see my UI defaults applied to each of the pages.

Looks good! I can see the UI default settings have been applied to my newly created pages without having to apply anything at the page level. When I reference any of these columns elsewhere throughout the application, the same defaults will be applied, ensuring a regular level of consistency.

Attribute Dictionary

The attribute dictionary works similarly to the table dictionary, but rather than focusing on a single table, you can create a set of defaults that will be applied to any column with a given name across all tables in the schema. Furthermore, you can add synonym column names so that the same defaults will be applied to not just the base column but all other columns listed as a synonym. For example, if you created an entry in the attribute dictionary for a column named EMP_ID, you could give this entry some synonyms like EMPLOYEE_ID and STAFF_ID as well. Then, all of the UI defaults defined here will apply to columns with any of these names across your tables.

One point to be aware of is that the Table Dictionary takes priority over the Attribute Dictionary. So, if you have table dictionaries defined already, you may find that these supersede your attribute dictionary definitions.

Summary

This blog only demonstrates some basics of the UI Defaults functionality. There is a lot to it, and it has great potential to prove itself a valuable tool for streamlining development and ensuring consistency throughout your applications. This centralised control for defining default settings proves to be a great time saver, cutting out the need to repeatedly set the same attributes in many places.

However, there are a few limitations and potential inconsistencies. Some of the settings I created seemed to be completely ignored, and I ended up having to manually set them at page level anyway, which kind of defeated the purpose of this feature. You should also be aware that if you make any changes to your UI defaults after already building any forms and reports, then these changes will not automatically be applied. A recommendation for future releases could be to include a subscription feature that allows you to push your UI default changes to existing areas of an application. Either way, this is certainly an excellent development tool that I will continue to use regularly.

For more information, check out our Oracle APEX Services, and if you liked this blog, check out our other APEX blogs here.

Subscribe to Oracle APEX Insights if you want to stay tuned for more APEX updates.