Everything you see on an APEX page is the result of some template. Let that sink in for a moment.

We often decide on a template without giving it much thought. I say, that’s just fine. That is the elegance and beauty of APEX. You’re able to start building functional, responsive, and even (sometimes) beautiful web applications with little effort and not much concern for how all the HTML makes it into the page. However, if you’ve ever been asked to change the look of an element on your page, want to learn about other UI elements, take your applications to the next level, or simply understand what makes an application tick, this chapter is for you. (If you’re just learning about APEX, you should probably wait before reading this chapter, at least until you have a solid application or two under your belt.)

Themes and templates allow APEX to separate the application logic from the visual look and feel. This is why you’re able to start building web applications so fast without the need to get bogged down in color, fonts, and layout decisions. A theme is the all-encompassing collection of HTML, CSS, and JavaScript that gives your application a consistent look. Templates are part of a theme. Templates are the building blocks of all visual elements in an application. Everything you see on the screen is the result of a template.

Before APEX 5, if you didn’t know CSS, you were not going to get too far changing the font or colors of your application and making a lot of style changes. With the introduction of the new Universal theme and the Theme Roller, APEX 5 changes all that. APEX 5 goes as far as designating Theme 42 as the only standard theme. All the other 26 themes that came previously are now the “other” themes or legacy themes.

Don’t get me wrong. In previous versions of APEX, you could still control a lot of the layout on a page. I will attempt to show some techniques that can be used with all versions of APEX and any theme.

What Is a Template?

Within APEX you will see the following information about how templates are used:

Based on that information and since you know that web pages are made of basically three elements (HTML, CSS, and JavaScript), you can infer that templates are nothing more than a combination of these elements. I like to think of HTML as the structure, the scaffold, or the bones of a web page. The veneer and paint you apply to this structure will be the CSS. The pages, regions, labels, buttons, reports, lists, breadcrumbs, and so on, are the result of some data being applied and merged with a template or, at the least, content from a template.

What Is a Theme?

Themes are the skin of your application. They attempt to give your applications, as a whole, a consistent and uniform appearance. I will call this the look and feel of an application. I also like the definition that Application Express uses, shown here:

In addition to grouping templates under one umbrella, a theme also gives you a set of attributes that will drive the behavior of the theme as a whole. One of the many ways themes do this is by allowing you to define default choices within your applications. They will also have information about which templates will be the default. You can find these by going to Shared Components Themes and clicking your current theme. These attributes are as follows:

• Component Defaults
• Region Defaults
• Dialog Defaults

Component Defaults

Component Defaults is the section where you tell APEX which template to use by default for each of the possible elements. For example, in Figure 13-1, you can see that Page is set to Standard. Other options are Left Side Column, Left and Right Side Columns, Login, and so on.

In a different example, scrolling further down the list of component defaults, buttons can have a default too. You can see that Text is the default value, and the other possible values are Icon, Text, and Text with Icon. Text in this case means that the button will contain readable text (such as Save, Add, and Delete). This will probably be your most used button template. (See Figure 13-2)

Region Defaults

The Region Defaults settings are similar to the Component Defaults settings, but these apply to regions on the page. The distinction is subtle but still important. Many components in the Component Defaults section are elements that can be used only inside a region. That means that these regions apply an extra layer of styling to them. As a case in point, lists are both a region type and a component element. This is because you cannot display a list without a container for it, in other words, the region. The component is the list itself, and the region will contain the component. The List default setting for the component is Links List, and the default for List Region is 42. Standard. Translation, the component default for a list, will be Linked Lists, and it will be placed inside a 42. Standard region.

Dialog Defaults

APEX 5 introduced a new way of displaying pages, the Dialog page. In the past, I’ve called this type of UI element a modal page. A modal dialog, by definition, stops interaction with the calling page until it is dismissed. Dialogs, on the other hand, can be modal or nonmodal. The Dialog Defaults settings define the default type of template you want to use when you create new dialogs in your applications.

Out of the box, the Universal theme contains just a little over 50 templates. This number may be different as new releases come out. Regardless, this is a dramatic reduction from previous Application Express themes that would usually contain close to and upward of 100 (109 on Theme 26, for example).

All the magic from a theme happens in the templates. Template themselves have a powerful muscle to get things done called substitution strings.

The Substitution Strings

Have you ever seen the Russian dolls that fit one inside the other? Figure 13-3 shows a couple of sets of these dolls, and you can see how the different dolls in each set are sized in stepwise fashion.

Templates are somewhat similar to those dolls in that many of them go inside one another. Often, templates cannot be used without placing them inside another template. For example, as shown in Figure 13-4, you may have a button, inside a region, inside a page. All those three elements are templates. When you declare a button, you specify, at least, a label and usually an action. APEX will use that information, via substitution strings, to create the button. Then the completed button becomes a unit of information that will be placed inside a region. In this example, items are also part of that region. Once the region is generated, it also becomes a unit of information, and it becomes the substitution strings themselves that will be placed on a page.

Even more to the point, some elements, like regions, can also have subregions. The level of nesting can be even higher in these situations. I’ll talk more about subregions later in the chapter. Figure 13-5 graphically shows how elements get to be part of other elements. It starts to become clear why the Russian doll analogy makes sense.

You can see how APEX places some content inside more content and yet again inside even other content. That nested placement is accomplished via substitution strings. Substitution strings are like programming variables that take a value, and whenever they are referenced, their value becomes what is used. You’ll recognize them in a template because they are in uppercase and have hash signs at the beginning and end, for example #BODY#. #BODY# is one of the most popular substitution strings. It’s popular mainly because it’s often mandatory in many templates and because it corresponds to the Source section for many components. In Figure 13-6, you can see the Text field inside the Source section that will be used by the #BODY# substitution string.

Let’s turn some HTML into a template. Say you have the following HTML:

<div>Hello</div>

To turn this into a template, you can do this:

<div>#BODY#</div>

There, you’ve built your first template! The substitution string #BODY# will now take many different values, and the template doesn’t have to change. All the divs in Listing 13-1 can be outputs from the first template.

<div>Hello World!</div>
<div><ul><li>List 1</li><li>List 2</li></ul></div>

<div>
  <button onclick="apex.submit(’SAVE’);">Apply Changes</button>
</div>

Since APEX provides a mechanism for you to pass CSS classes to a template, you may want to add the #REGION_CSS_CLASSES# substitution string to accomplish that. The CSS Classes field shown in Figure 13-7 corresponds to this substitution string.

<div class="#REGION_CSS_CLASSES#">#BODY#</div>

Next, sometimes you want to reference a region by name within CSS or JavaScript. In a region’s attributes, in the Advanced section, you’ll see Static ID. The value entered here goes straight into #REGION_STATIC_ID#; let’s add that too.

<div id="#REGION_STATIC_ID#" class="#REGION_CSS_CLASSES#">
#BODY#
</div>

Finally, let’s add a handful more substitution strings to the first template: #REGION_ATTRIBUTES# and #SUB_REGIONS#.

<div id="#REGION_STATIC_ID#" #REGION_ATTRIBUTES# class="#REGION_CSS_CLASSES#">
#BODY##SUB_REGIONS#
</div>

Save for some other small changes, you have just replicated the Blank with Attributes region template. In previous APEX releases and in certain themes, you’ve known this template as DIV Region with ID. It’s an incredibly simple construct, with not a lot of visual footprint on the page, and yet, as you will see later, it’s a powerful tool for placing content.

Given the values in Table 13-1, after merging them with the template, you’ll have the following result:

<div id="clientRegion" class="">
This is the content for this region.
</div>

This example may seem simple, but the power of APEX is that the value of #BODY# could come from another completely different region. Or just as interesting, it could come from a report. Then, before you can see any of it on the screen, once APEX has produced the output for this region, it will all become part of the #BODY# attribute on a page. You end up breaking content into its most atomic form and placing it inside other elements in order to create a much more complex structure, just like the little Russian dolls.

Whenever you’re looking at an existing template or creating one from scratch, scroll down to the bottom of the definition page. You’ll see a table with all the substitution strings that are available to you for the specific type of template you’re in. The Referenced column lets you know whether the template is currently using the substitution. The one exception to this is report templates. Report templates don’t have a list of available and used substitution strings. Instead, I recommend looking at the help information for each field to learn what is available.

Finding Substitution Strings in the Application

Many components and application attributes have a clear relationship to certain substitution strings. Let’s point out some that are important or frequently used.

The substitution strings #THEME_JAVASCRIPT# and #THEME_CSS# are accessible when you edit your theme attributes. They correspond to a list of files that will be added to every page in your application. You should enter one file per line, with a fully qualified path, and you don’t need to use the <script> or <link> tag. If you reference a file uploaded to your application or workspace files, you can use #APP_IMAGES# or #WORKSPACE_IMAGES#, respectively, in the name. In the case of CSS files, you can optionally prefix each file with a condition like [if IE] or a media query. These substitution strings should be kept specific to making the theme function correctly as opposed to specific to the application. Put another way, this will be code that will be required across and used in all the applications that use this same theme.

The substitution strings #APPLICATION_JAVASCRIPT# and #APPLICATION_CSS# are similar to the previous two, but, as their name suggests, these are application specific. I find their placement, within APEX, hard to find at first. They are under User Interface Details. This means that if you’re using a desktop and a mobile user interface, there will be two places where you can enter application-specific CSS and JavaScript. Go to Shared Components User Interface Attributes. Then edit the Desktop user interface. At the bottom of the page, as shown in Figure 13-9, you’ll see a JavaScript and a Cascading Style Sheets section.

The substitution strings #PAGE_JAVASCRIPT#, #GENERATED_JAVASCRIPT#, #PAGE_CSS#, #HEAD#, and #ONLOAD# are specific to each page. Edit the page called Page Attributes to find them. Figure 13-10 shows which is which. Be aware that certain substitution strings may be required for a template. For example, in the case of a page template, #HEAD# and #BODY# are required. The #HEAD# substitution string is important because it will include certain meta and link tags, and it includes all the necessary CSS files required to correctly render the page.

There are placeholder fields for substitution strings all throughout APEX. Keep an eye out for them. Recognizing them and identifying their use in a template will go a long way in helping you understand and maximize their uses. I’m going to finish this section identifying those used in a list template. Lists are a powerful tool while building APEX applications, and they have almost unlimited applications.

The following SQL sample, for a dynamic list, shows which values are mapped to which substitution strings. If you were using a static list, you would find the same fields and mappings.

--     column                alias                      substitution string
------------------------------------------------------------------------------
select level,
       labelValue            label,                     #TEXT#
       [targetValue]         target,                    #LINK#
       [is_current]          is_current_list_entry,
       [imageValue]          image,                     #IMAGE#
       [imageAttributeValue] image_attribute,           #IMAGE_ATTR#
       [imageAltValue]       image_alt_attribute,
       [attribute1]          attribute1,                #A01#
       [attribute2]          attribute2,                #A02#
       [attribute3]          attribute3,                #A03#
       [attribute4]          attribute4,                ...
       [attribute5]          attribute5
       ...
from ...
where ...
order by ...

In the case of a Linked List template, #IMAGE# is used to optionally define a class name to specify an icon. #A01# is used as the badge value. This badge can be anything, but it’s often a count. Take a look at the following SQL:

select 1             lvl
     , ’Clients’     label
     , apex_util.prepare_url(
        ’f?p=’ || :APP_ID || ’:CLIENTS:’ || :APP_SESSION) target
     , ’NO’          is_current_list_entry
     , ’fa-user’     image
     , null          image_attribute
     , null          image_alt_attribute
     , null          attribute1
 from dual
union all
select 1             lvl
     , ’Providers’   label
     , apex_util.prepare_url(
        ’f?p=’ || :APP_ID || ’:PROVIDERS:’ || :APP_SESSION) target
     , ’NO’          is_current_list_entry
     , ’fa-building’ image
     , null          image_attribute
     , null          image_alt_attribute
     , 7             attribute1
 from dual

You can see, on Figure 13-11, how clients will have an icon defined by fa-user and providers will have an icon defined by fa-building and a badge value of 7.

The following is the actual HTML template of the list that is creating the previous list. As you can see, there are substitution strings for the #LINK#, #TEXT#, #A01#, and so on.

<li class="t-LinksList-item is-current #A03#">
  <a href="#LINK#" class="t-LinksList-link" #A02#>
   <span class="t-LinksList-icon">
     <span class="t-Icon #IMAGE#"></span>
   </span>
   <span class="t-LinksList-label">#TEXT#</span>
   <span class="t-LinksList-badge">#A01#</span>
  </a>
</li>

Theme Styles

Theme styles provide an easy way to change the look of an app without changing the theme or template. They define a set of CSS styles that your application will use. Applications can have any number of theme styles defined; however, only one can be current at a time. Different from themes, theme styles can be changed at runtime. Calling the following API from within your application will change the theme style at runtime and make a different, previously created theme style current:

apex_util.set_current_theme_style (
  , p_theme_number   => l_theme_number
  , p_theme_style_id => l_theme_style_id
);

You can obtain the two parameter values from apex_application_themes.theme_number, where is_current =’Yes’, and from apex_application_theme_styles.theme_style_id dictionary objects.

This is a powerful feature because you could even let your users change the look of the application. Imagine giving your end users the ability to switch the theme style of an application they use day-in and day-out. All of a sudden, they will have a renewed excitement using an application that has a new skin but whose functionality has not been compromised by them changing the style. This activity can be as simple as changing the wallpaper on their desktop.

In the initial release of APEX 5, the Universal theme has two predefined theme styles: Vita, which uses a blue color scheme, and Vita – Slate, which is a gray to dark gray color scheme. It is easy for developers to create new ones via a powerful new tool in APEX 5, the Theme Roller.

The Theme Roller

Another amazing new feature of APEX 5 is the Theme Roller. The Theme Roller is a tool that allows developers to customize many aspects of certain application components. It allows developers to pick styles and colors and see their effect on the application via an interactive tool. Figure 13-12 shows the Theme Roller button you will use to invoke it via the Developer Toolbar. Figure 13-13 demonstrates the Style select list available from within the Theme Roller. Finally, Figure 13-14 shows the end result of switching from the Vita style to the Vita – Slate style.

To create a new theme style from the Theme Roller, all you have to do is pick your starting style and start modifying attributes and colors. In addition to colors, some of the attributes that can be changed with the Theme Roller are border radius for several components, navigation tree width, actions and left-side column widths, and the maximum width of the body container. There’s also a Custom CSS field where you can enter any other CSS classes and attributes you need to override or reference.

When it comes to picking colors, however, I strongly recommend you seek the assistance of a graphic designer or at least use a tool to help you select colors that complement each other or provide a cohesive tonal range across all components of your application. Your favorite sport team’s colors will most likely not work well for an application (unless the application is for said team). Nothing damages the trust of your users on an application faster than a bad-looking UI.

Once you’re pleased with your new style, click the Save As button at the bottom of the Theme Roller. At this time, two things will happen. A new theme style will be created for your application, and a new CSS file with your choices will be generated and uploaded to your application and used by your new style. After this is done, use the Set as Current button to make your new creation the default for your application.

Template Options

I mentioned before that the number of templates is drastically reduced in the Universal theme (Theme 42) from previous themes. However, the flexibility and number of options to style your elements on the screen did not go down. On the contrary, I would argue it has increased. How is this possible when instead of 36 region templates (on Theme 25) you now have 13 (on the new Theme 42)? How is this possible when in the case of buttons the number has gone from 10 templates to now 3 in the Universal theme? The answer is Template Options settings.

Template Options settings add an extra degree of configuration (or styling) to just about any template. It’s an elegant, simple, and yet powerful approach to styling templates with developer-defined options. Take, for example, Figure 13-15. All variations from the default view were achieved by simply selecting the options Accent, Item Size Large, and Remove Borders. Figure 13-16 shows the dialog where the Template Options settings can be selected.

This was only a small portion of all the default Template Options settings available to the standard template used by this region.

At their core, think of a template option as a value pair, meaning a name and assigned value. The name is what you will see when you select the option, and the value is a CSS class (or list of CSS classes). In the previous example, the following CSS classes were added by APEX to the region as the options were selected: t-Region, t-Region--accent5, t-Region--noBorder, t-Region--scrollBody, t-Form—large. But, you don’t actually have to know the name of those classes. You only have to choose from friendly names and descriptions on the Template Options selection page. The actual magic, of course, is performed by the CSS behind those classes (and the effort of the APEX development team that thought about them). The classes themselves are defined as part of the Core.css file that comes with the Universal theme.

The definition of Template Options also allows specifying whether a “feature” can be used in conjunction with others or if it contains mutually exclusive options. For example, let’s take the Accent option. Since only one Accent color makes sense at a time, they are grouped under the Accent heading, and they are selected via a drop-down one at a time.

But you’re not limited to the options available out of the box. If you’re able to declare a CSS class, then you can extend the template option functionality. For example, let’s define a template option that will add a border to a Blank with Attributes template. If you recall, the template is a simple div, and it has no indication of where its borders are. The process is straightforward: define a CSS class, include the CSS code as part of the application, declare a template option that uses the new class, and use the option as needed from within the APEX builder. Let’s get started with the following simple class definition:

.c-Region--Border {
  border: 1px solid #DDD;
}

You can then define a With Border template option that will add a 1-pixel solid line all around in a light gray color. You’ll add this to the Blank with Attributes template. Go to Shared Components Templates Find and edit the Blank with Attributes template. In the Template Options section, click Add Template Option and use the values shown in Figure 13-17.

With the template option defined, you are ready to apply the new With Border Template Option setting to any of the Blank with Attributes regions. Select the region in the Page Designer, under Appearance find Template Options, and click it. Figure 13-18 shows where you can find this. Once you click the Template Options button, you’ll see a modal dialog, as shown in Figure 13-19.

You are almost ready to test your handy work, except for one important step. You need to add the CSS Class definition to your application. Normally, best practice would be to place it in a file and register the file as part of the user interface under “Cascading Style Sheets.” APEX will then add it as part of the #APPLICATION_CSS# mentioned earlier in the chapter. However, for this example, placing the CSS on the Page Attributes Inline CSS setting will do just fine.

Figure 13-20 shows the before and after effect of adding the new template option to a Blank with Attributes subregion.

When you create your own template options, make sure you select an appropriate group. Some options will not need one. Template options with no groups will be presented as check boxes. These are elements that can be compounded and used in conjunction with other visual elements. However, the correct group will go a long way in explaining to future developers what the option does. The groups will be presented as a select list.

As a bonus, template options can be used right away in all your previous applications and themes, not just with the Universal theme.

The Grid

Grid systems have become incredibly popular in web development. They have the power of neatly arranging and uniformly spacing elements. Yet, they have the ability to be nested and the property of becoming fluid and changing in size and arrangement as the web page (or the viewport) changes in size. What’s more, in small screens, like that of a mobile device, they can reflow the content in a completely different fashion from a desktop layout.

To put it simply and bluntly, a grid system is a bunch of HTML tags (usually div tags) where your (main) web content is placed and some carefully crafted CSS classes arrange it all. This grid governs the placement of the main content on a page. Regions are placed within the grid and then components (mainly labels, items, and buttons) are placed inside another grid that belongs to the region.

The Universal theme uses a 12-column grid. This means you can divide your available space evenly by 12. I think it helps to think of the screen as having 12 units or buckets, of equal size, to place your content on. First, you start by placing elements on the first row. Then, as you’re done placing elements on that row, you can move to the next one and so on. On every row, you once again have 12 columns to work with. As elements are placed, you need to make sure always to use (or account for) all 12 columns. When you need more control or your layout is complex, it’s also possible to nest one grid within another. If you were building web sites with a text editor or some other tool or framework other than APEX, I would now start talking about the row class, column class, first and last column classes, spans, offsets, nesting, and so on. However, APEX makes all this declarative and simple for you to use. (See Figure 13-21.)

The APEX Developer Toolbar provides a useful toggle button to show or hide the grid. In Figure 13-21, you can see the grid overlay just peeking behind the One Region area. You can count 12 columns, all exactly the same size. If you resize the browser, there will still be 12 columns of exactly the same size, only smaller in width.

In Figure 13-22 you can see the grid attributes that you can use to control the placement of regions and items (or elements within a region). As you can see, they are identical. This is because whether you’re placing a region or placing an item, you have the same rules to play with. Keep this in mind as I discuss each attribute. Start New Row means that the previous row in the grid, if present, will be closed, and a new grid row will start. This is important because the new row will once again allow for 12 columns for a layout. If you were working on the first row in your layout, then Start New Row would have no bearing. However, it is still a good practice to decide whether you want the Star New Row attribute to be Yes if you added a row above. In general, I think you want to start your first row with a Yes in this attribute to avoid future layout surprises. The Column option indicates in which of the 12 columns of the grid this element or component will be placed. The Automatic option allows APEX to calculate the column where the next element will be placed; of course, APEX will start from the left with column 1. When the Column calculation is changed from Automatic to a specific value, Column Span becomes available. Column Span indicates how many columns the element will use. When left as Automatic, APEX will simply fill out the rest of the row.

The Grid options shown in Figure 13-22 depend on specific values defined in the grid section of the page template. This means that each page could potentially use a different type of grid. However, unless you’re creating your templates, this will be of no concern for most users.

APEX will make every effort to avoid invalid grid value combinations that violate the limit of a 12-column grid. If your current column position plus the column span is greater than 12, APEX will generate an error because the placement will not be possible. For example, see Figure 13-23. If you specify placement on column 4 but indicate a column span of 10 (10 + 4 > 12), you will see an error.

You may already have noticed that APEX 5 by default will display either “common” component attributes or the most used attributes. When placing items there are three more attributes that you should know about and they are visible only when you click the Show All selector: Label Column Span, Column CSS Classes, and Column Attributes. Figure 13-24 shows what you’re looking for.

Label Column Span is a new APEX 5 attribute and a welcome enhancement. Its default value is specified at the page template level, and it can be modified for specific items. To edit the default, you simply edit the page template you’re using, go to the Grid Layout section, and find the Default Label Column Span attribute. The default value for the Standard page template is three. This means that every item placed on a row will require three columns for the label alone. Then nine columns are available for the rest of the item. (See Figure 13-25.)

When placing items in front of each other, you’ll want to keep the label span in mind. Otherwise, it can be frustrating trying to arrange a layout and not understanding where your 12 grid columns are being used. For example, if in addition to the One Item item in Figure 13-25 you add another item in front by specifying Start New Row as No and leave the Column as Automatic, then each item will use 6 columns of the 12-grid layout. However, by default each item will use three columns for the label, leaving three more columns for the item (3 + 3 and 3 + 3). If you added one more item also with Start New Row as No, now you’re looking at each item using four columns on the grid. If each item uses three columns for the label, that leaves only one column for each of the items (3 + 1, 3 + 1, and 3 + 1). At this point, depending on your layout, you may need to consider changing the Default Label Column Span attribute. (See Figure 13-26.)

The Default Label Column Span attribute can also be set to zero. This is a powerful layout technique when the label is not needed. Setting it to zero will place the item in the column exactly next to the previous item (or column 1 if this is the first item on the row).

When using Start New Row as No and New Column as No also, APEX will now place two items inside the same grid cell. However, in many layouts, as a default behavior, they will be placed below each other unless some extra CSS attributes (or custom template option) are applied to them.

Responsive Layout

The other powerful feature of the Universal theme’s grid layout is responsiveness. You call a layout responsive when it can change the placement of elements on the screen based on the space available. Put another way, if your browser screen is wide, you will get one view. If it’s small, you’ll get a different one, and if you’re on the smallest of screens, like on a mobile device, you’ll see yet another view. The Universal theme can accomplish this with flying colors. Your applications should be designed with this feature in mind. For example, Figure 13-27 shows three views of the same page and how it changes as the browser window changes in size. The interesting thing about this is that a responsive layout is handled exclusively on the browser side. Only CSS and JavaScript contribute to the transformation. The markup is the same for all three views, and no APEX processing is required for this to take place once the page has been rendered. It’s outside the scope of this chapter and book to explore responsive design. However, one of the techniques involved is what’s known as media queries. Media queries represent a CSS technique that allows you to define different sets of CSS to be used by your application based on the size of the screen (or the media like in the case of print). The smallest screen layout in Figure 13-27 uses a media query that is used on screens of 640 pixels (640px) or less. The size that determines when one set of CSS is used versus another is known as the breakpoint. The intermediate size takes place between 641px and 767px. Finally, the “normal” desktop size view takes effect at greater than 768px.

Subregions

It’s common to have several regions on one page, certainly more than one. If you’ve ever had to place more than a dozen items on one page or some items and a report, you probably placed multiple regions on a page already. However, did you know APEX supports regions within regions? Any time you place some region inside another one, I’ll call it a subregion. See Figure 13-28 for an example of placing several subregions inside each other. This example may not seem that useful, but it demonstrates the powerful ability to nest one region within another. This goes back to the substitution strings and the Russian dolls analogy I made before. You can always break down a layout into the smallest parts you can and then place them inside another to create much more complex designs.

I think subregions are usually an underutilized feature for placing content on the page. Consider the following standard layout from the APEX wizard, as shown in Figure 13-29.

If you ask me, it seems like this layout could better utilize space on the right side. Turn on the template option in the region called Stretch Form Fields to get the effect shown in Figure 13-30.

However, I think that sometimes a subregion could give you a nice end result. I left the Client region as a standard template. Then I added a new region, Client Info, as a subregion of Clients using the Blank with Attributes template and moved all the items except the comments to it. Then I added another subregion to Clients, also with a Blank with Attributes template, and called it Additional Info. I changed the grid attributes for this one, setting Star New Row to No and New Column to Yes. This way, both Client Info and Additional Info are side by side. You already know APEX would use six columns for one and six for the other (if you leave everything as Automatic). However, depending on your layout, you could try different settings with the Column and Column Span attributes. The Comments item gets moved to the new Additional Info region, and its label is changed to Above. Figure 13-31 shows the result.

Remember that inside each of the subregions (Client Info and Additional Info), you still get 12 columns inside each to work out a layout. Keep this in mind that these 12 columns will be significantly smaller than the 12 columns available to the parent Client region (roughly half the size to be exact). Optionally, you could also apply the With Border template option you defined earlier in the chapter to the Client Info subregion. This effect will give you a nice grouping of items, which something is important to draw the viewer’s eyes to a set of elements on the screen.

Let’s look at the new Tabs Container template. This new template in the Universal theme couldn’t be easier to use. You add a static region and select Tabs Container as the template. Then add regions inside it as subregions. Figure 13-33 shows the tab region with the following interactive reports that will be displayed as tabs: Orders, Contacts, Statements, and Batches. Finally, Figure 13-34 shows the end result of the Contacts tab selected. As the tabs are selected, the other tabs are hidden.

Theme Subscriptions

Theme subscriptions are a powerful feature that allow organizations to create applications that share a theme with a single application. This application becomes the keeper or the master for the theme. Said another way, if you want to change a template on a subscribed theme, you would need to either break the subscription or, better yet, change the master and refresh the subscription. By refreshing subscriptions, you ensure consistency across all applications.

In APEX 5, when you create a new application based on any theme, the theme will be subscribed to the master in the theme repository. Effectively, this means your application theme and all the templates within are locked from modifications.

However, don’t worry. If required, you can still add new templates to the theme, and these will be fully editable. Now, to make the whole theme fully editable, you can unsubscribe from the theme repository. When you attempt to unsubscribe a theme, you will see the following verbiage.

Note that subscribed themes can be extended by adding templates, styles, and files that are local to the theme, for example by creating a new template or copying a subscribed template. Templates, styles, and files added to a subscribed theme will be editable. However, subscribed components are read-only.

I wouldn’t call this action permanent, but it would take some work to resubscribe. There’s a good reason for this. This allows you and other developers to know that the theme and its subscribed templates are still pristine. I see two big benefits to this. You know there are no surprises left by other developers hidden in the templates, and it provides another layer to your peace of mind during APEX upgrades and patches. It will allow your applications to take advantage of template fixes that may be released in the future. It is strongly recommended, by Oracle, that you don’t unsubscribe the Universal theme. Doing so will prevent your theme from receiving future updates.

Summary

Themes and templates in APEX are a vast topic. There are many areas still left to uncover. However, it was my goal to demystify some core aspects and give you the foundation and tools that to give you the confidence to venture deeper on your own. I find the whole architecture and functionality of themes and templates within APEX fascinating and incredibly powerful.

For your next steps, I recommend investing time learning and understanding HTML and CSS. The more you know about CSS, the more you will understand the capabilities and tools at your disposal. The more you understand HTML, the better you can build creative and functional layouts.

Now go forth and make your applications your own; make them sing!