5 Advanced Techniques for Customizing Your App Extension

The dynamic layout templates (field templates, display templates) expose components to their programming model (layout model), so you can bind components in templates to events, action chains, variables and functions defined within its model. This enables you to add more advanced custom behavior to your app extension.

For example, if you add a new button component to a layout template, you might need to edit variables, events and actions to define what the button does.

Advanced Layout and Dynamic Component Editors

While working with your app extension's field or display templates, you can use the advanced editors (Actions, Event Listeners, Events, and Variables) to add more advanced features to the extension:



Here's what each of the editors do:

Editor Description
Actions Create and edit action chains describing the behavior of components.
Event Listeners Create and edit event listeners that start your action chains.
Events Create and edit custom events used in action chains.
Types Create and edit variable types.
Variables Create and edit variables and constants.
JavaScript A JavaScript editor.
JSON Edit the JSON metadata files.

Editors have access to elements in its own layout scope only. If you're editing a page, for example, the editors can access only elements defined on that page. Elements defined in a dynamic layout or the containing flow would not be available for editing.

Customize Your App Extension with Variables and Constants

Variables and constants store static values and expressions that are used to define how pages and components in your app extension behave. For example, if the base app stores the color of a heading in a variable, you can change the value of the variable (and thus the color) in your app extension. The base application developer or a team member might have already specified some variables and constants that you can extend, but you might also want to add others. When a page is open in the Page Designer, editable constants used in the page are listed in the Properties pane.

Both variables and constants are used to store values. Specifically:

  • Variables are typically used to store values used within a page's UI or an action chain. For example, you would use a variable for an input text or a total when performing an action in the page like adding items to an order, but variables can also be used for property values like a text color or font size.
  • Constants are typically defined in the base app, and their values don't change after they are set by the app extension. For example, the base app might define a heading that uses the constant itemDetailHeading for setting the heading text. Your app extension can write a value to the constant, and that value will be used to set the heading text every time itemDetailHeading is used in the app extension. The default value of constants might refer to expressions that contain variables.

Variables and constants have a scope that defines its lifecycle. The scope is defined by where the variable or constant is defined, so if you create a variable in a page artifact, it would have a page scope. In your app extension, most variables and constants will have one of the following scopes.

Scope Description
Page

Variables and constants with a page scope can be used by components and actions within the page, including display templates, but are not accessible from within dynamic forms and tables. These are typically defined in the base app and are listed in a page's Variables editor if they are editable. For example, the base app might define an editable constant that you can use to toggle the display of a dynamic component.

Layout (dynamic forms and tables)

Variables and constants with a layout scope can be used by components and actions within dynamic forms and tables, for example, within field templates. These are typically defined by you, and you create and edit them in the layout's Variables editor. For example, you might use a variable in an expression in a field template.

Dynamic containers use page-scoped variables and constants.

Action Chain

Variables that are created in an action chain can only be used in the action chain where it is created. Variables with this scope are listed in the Variables editor of the action and are not listed in the Variables editor for layouts or pages.

You can view, create and edit variables and constants in the Variables editor of a page or layout. If you want to use any special characters (period, colon, dash and space) when creating field names for variables, you'll need to enclose it in bracket notation. For example, an object variable that contains a field called 'child.field' will need to be referenced as $variables.objVar['child.field'].

For each variable you must specify a Type property to define the type of data that is stored in the variable. Types are also either page-scoped or layout-scoped. When defining the type for a variable, you'll usually want to choose one of the standard built-in types used to specify data that are a primitive type, a structure or a simple array or collection. If the built-in types don't meet your needs, you can create custom types and types based on an endpoint in the Types editor of your page or layout.

Note:

If the base app defines types that can be used in app extensions, they will also be displayed in the Types editor, and you can select them in the Type dropdown list when you create a variable.

For more details about using variables, constants and types, see Work with Variables and Types in Building Responsive Applications with Visual Builder Studio.

Change the Default Value of an Extendable Constant

Constants may be used in the base app to determine app behavior such as which cards are displayed or hidden in the app. If the base app developer makes these constants available to your app extension, you can overwrite the default values to change the behavior as needed.

If a constant can be modified in the app extension, you can set its value to a static value, another constant, a variable, or an expression. A simple example of how a constant might be used in an extension is to store a text string, say for a Heading component. If the heading's value is set to an extendable constant, you can use your extension to set a value for the constant, which will be used as the text rendered by the component.

Another way a constant might be used is to configure the behavior of components. For example, a base app developer may define an element in the page, and allow you to hide or display the element using an extendable constant. In the example below, the showEloquaProfiler is a Boolean constant and takes either "true" or "false" as a value. If you don't want to display the Eloqua profiler element in your app, you can hide it by setting the showEloquaProfiler constant to "false".

Rather than setting the constant to a static value of "true" or "false", you may instead choose to use another constant or variable in the app to set this value. For example, suppose you want to show this element on mobile devices only. In that case, you can use the $responsive.smOnly system variable to set the value of your constant. On mobile devices where the $responsive.smOnly value is true, the value for showEloquaProfiler is set to "true" and the Eloqua profiler is displayed. On desktops where the variable is false, the element is hidden.

You also have the option to set a constant based on the value of an expression that you create. The expression can include constants and variables as well. Using the same example, if you instead want to hide the Eloqua profiler on mobile devices, you can create a simple expression using the $responsive.smOnly variable with the Not operator (!$responsive.smOnly).

You can create more complex expressions using one or more constants and variables and include text. For example, you may want to modify a link on a page to point to different web pages depending on the user's country. In this case, you may need to build an expression that resolves to a particular national web site depending on the value of a variable for the user's country.

In this scenario, you might build your expression using a constant for the company name, a new string variable set to a regional top-level domain based on the user's country (".com" for the US or ".co.uk" for the UK), and text to fill out the URL:

[[ 'http://www.' + $companyName.value() + $regionalDomain.value() + '/support/docs/index.html' ]]

For a user in the US, this expression resolves to "http://www.example.com/support/docs/index.html".

Note:

Make sure the value you enter matches the type of the constant: text for a string constant, "True" or "False" for a Boolean constant, and so on. The Page Designer does not validate the value or expression you enter, and you may experience problems during runtime if the type doesn't match.

You can change the value of a constant using either the Page Designer or in the Variables editor tab. The Properties pane in the Page Designer lists all constants used by the selected page; the Variables editor lists all constants defined in the page or layout, including those that are not currently in use. From the Variables editor, you can open each constant and set a new value. In this topic, we will show you how to change the default value from the Page Designer, but the procedure is the same when you use the Variables editor.

To overwrite the default value of a constant in a page:

  1. Open the page in the Page Designer.

    Editable constants used in the page are listed in the Constants tab in the Properties pane:



    In this example, you can see that the page has two editable constants.

  2. In the Constants tab, select the constant you want to edit to see more details about it.


    In this example, in the Constants tab you can see details about the showEloquaProfiler constant. The developer has provided a description telling you that you can use the constant to show or hide the Eloqua profiler element in the page. The constant is used by a Bind If component (which uses a Boolean value), and the value of the constant is set to false.

    There is also a link to open the constant in the Variables editor tab.

  3. Do one of the following:
    • Set a static value for the constant by typing a new value in the Value field.

      In this example, if you type "true" in the Value field, the Eloqua profiler element will be displayed on the page during runtime. If you open the Variables editor, you'll see that the default value for the constant is now "true".

    • Use a constant or variable to set the value of the constant by clicking the arrow above the Default Value field to open the Variables picker and select a variable.

    • Create an expression by clicking fx to open the Expression Editor.

      Select field variables in the Variables pane to add them to your expression. You can also add text strings to your expression by typing in the editor. Click Save.



      The expression you create in the editor is added to the Value field, for example, [[ 'http://www.' + $companyName.value() + $regionalDomain.value() + '/support/docs/index.html' ]].

Create or Edit Variables and Constants

You can create or edit variables and constants in a page or layout using its Variables editor. Each page and layout has a Variables editor. The editor lists the defined variables and constants, and contains an Add Variable button for creating new variables and constants.

To edit a variable or constant in the editor:

  1. Open the app extension page or layout in the Designer.
    Editable variables and constants used in a page are listed in the Properties pane when you open the page in the Page Designer.
  2. Open the Variables editor and select the constant or variable.

    The editor lists all the editable variables and constants, even the ones that are not currently used.



  3. Edit the attributes in the Properties pane.

Variables and constants that are defined in the base app are badged with base, and have fewer editable attributes than those you create in your app extension.

For variables you create in your app extension, you can edit the attributes in the General tab in the Properties pane, and add event listeners in the Events tab if you want to trigger an action chain.

To edit the JSON file where a variable is defined, you can right-click the variable name in the Variables editor and choose Go to Code in the menu:



Define the Behavior of Your App Extension with Action Chains

The behavior of each component in your app extension is determined by an action chain, a sequence of actions started by an event listener when an event occurs in a page. For example, when you click a button on a page, what happens next is determined by an action chain. To configure the button's behavior, you could define an ojAction event for the button, create an event listener that listens for that ojAction event to occur, and select the action chain that the event listener will start. When the button's ojAction event occurs, the event listener starts the action chain.

An action chain might be a short sequence of a few actions, but it could contain many actions as well as logic for determining what happens in the sequence. An action chain might contain actions such as assigning data to a variable, sending data to a database, navigating to another page, and even starting other action chains. This image shows what an action chain that opens a URL might look like.



Action chains can be defined in your app extension and in the base app. You can't edit action chains defined in the base app, but you can create and edit action chains in your app extension using the Action Chain editor. You can create action chains used in pages and in a layout, and, like variables and constants, the scope of the action chain depends on where it's created. An action chain created in a page's Action Chain editor can only be used in that page, and can only access variables defined in that page. For details on how to create and use action chains, see Work with Actions and Action Chains in Building Responsive Applications with Visual Builder Studio.

Though you can't edit the action chains, events and event listeners defined in the base app, the base app might allow you to use them in your app extension.

Define Events in Your App Extension

An event occurs when something happens in your app extension. Some examples of common events include when a page loads (a lifecycle event), a button is clicked (a component event), and when the value stored in a variable changes (a variable event). There are different event types, and the type depends on how it is triggered. For example, changes in a button component would trigger a component event.

For some event types, for example, component events, there are many pre-defined events you can choose from, and the events that are applicable will depend on the component. An event like ojAction that is applicable to a button might not be applicable to a text field. For other event types, for example, variable events, you can only define one event (onValueChanged) for the variable.

The base app might also define events that you can use in your app extension. If an event is designated as "listenable" in the base app, you can create an event listener for it in your app extension.

Types of Events

How you define events and event listeners in the Designer will depend on the type and scope of the event. This table describes how to define the different types of events.

Type of Event Description How to Define
Variable event

A variable event occurs when the value of a variable changes. The only applicable event for a variable is onValueChanged.

You define a variable's event and create its event listener in the Variables editor. See Start an Action Chain When a Variable Changes.
Component event

A component event occurs when a component in a page (including components in dynamic components) triggers an event, for example, an ojAction event for a button. You can choose which events a component triggers.

You define a component's event and event listener in the component's Properties pane in the Page Designer or Templates editor. See Start an Action Chain From a Component.
Custom event

A custom event is triggered by the Fire Event action (fireCustomEventAction) in an action chain.

You can create a custom event in the Action Chain editor or in the Events editor of a page or layout. You create event listeners for custom events in the Event Listeners editor. See Use Events Defined in the Base App.
Lifecycle event

Lifecycle events are pre-defined events that occur during a page's lifecycle. You can create event listeners for these pre-defined events: vbEnter, vbBeforeEnter, vbExit, vbBeforeExit, vbAfterNavigate.

Lifecycle events are pre-defined, but you can create event listeners for them in the Event Listeners editor. See Start an Action Chain From a Lifecycle Event.

Create Event Listeners for Events

When an event such as a button click occurs in a page, it can start one or more action chains if an event listener is "listening" for it. When you create an event listener, you select the event it should listen for and the action chains you want it to trigger. You can create event listeners for events that you define, and for events defined in the base app which are designated as "listenable". You can also create listeners for the pre-defined lifecyle events.

An action chain can be started by multiple event listeners, so you might have a SaveData action chain that can be started by two different event listeners listening for two different events. For more, see Start an Action Chain with an Event in Building Responsive Applications with Visual Builder Studio.

To create an event listener:

  1. Open the Event Listeners editor in the layout or page, then click Add Event Listener.
  2. In the Create Event Listener wizard, select the event you want to trigger an action chain. Click Next.

    The Select Event step in the Create Event Listener wizard displays a list of listenable events. The events in the list will depend upon where you are creating the listener, and might include page events, custom events and component events, in addition to lifecycle events.



  3. Select the action chain you want to trigger. Click Finish.

    The Select Action Chain step in the wizard displays the action chains that can be triggered by the listener. If you want to create a new action chain now, you can click New Action Chain and enter an ID for the new action chain, which you can edit later in the editor.



    Note:

    An event listener can trigger multiple action chains, however, you can only add one action chain at a time in the wizard.

You can add additional action chains to an event listener at any time by clicking Add Action Chain for the event listener in the Event Listeners tab. Moving your cursor over the name of an action chain in the tab displays a link you can use to open the Action Chain editor.

If you want to delete an event listener, or remove an action chain triggered by an event listener, you can select it in the list in the Event Listeners tab and then click Delete in the options menu in the Properties pane. Deleting an action chain in the Event Listeners tab means it will no longer be triggered by the listener, but it won't delete the actual action chain.



Start an Action Chain From a Component

When you add a component to a field template, layout template or container, you'll need to create a component event and component event listener if you want it to trigger some behavior, for example, to open a URL. The Quick Start option in the component's Properties pane can help you create them.

There are various pre-defined events that you can apply to a component, and the events available are usually determined by the component. For example, the ojAction event is triggered when a button is clicked, so you would typically apply it to a button component (and you couldn't apply it to a text field component). Each button will have a unique event and an event listener listening for the button's ojAction event, and the listener would start an action chain (or multiple action chains) when the event occurs. Each component event will usually have a corresponding component event listener.

Note:

You can only create a component event from a component's Properties pane. You can't create one in the Events tab of a page or layout.

To start an action with a component.

  1. Select the component in the template or container section.
    You can select the component on the canvas or in the Structure view.
  2. In the Events tab in the Properties pane, click New Event and select the suggested Quick Start option in the list.

    In the New Event dropdown list, you can choose the Quick Start option or you can create a custom event. The Quick Start uses the suggested type of component event for the component, but you could choose the custom event option to use a different event.



    When you add the new event using the Quick Start, an action chain is created for you and the Action Chain editor opens automatically. For details on how to use the Action Chain editor to create action chains, see Work with Actions and Action Chains in Building Responsive Applications with Visual Builder Studio.

The Events tab in the Properties pane shows the properties of the component event, and you can edit the properties in the tab, for example, to add input parameters that you might want to use in the action chain.



The Quick Start creates a component event listener for the new event, and maps the listener to the action chain it created for you. If you open the Event Listeners editor, you'll see it listed under Component Event Listeners, and the action chain that it will trigger. This image shows the Event Listeners editor with the list of all the event listeners defined in a page.



Start an Action Chain When a Variable Changes

You can start an action chain when a variable changes by adding an event to the variable. For example, you might use a variable in a template to store an amount, and an action chain is triggered when a user changes the amount. You can add the event to variables defined in your app extension, and also to extendable variables defined in the base app.

To start an action chain when the value of a variable changes:

  1. Open the Variables editor of the page or layout.
  2. Select the variable in the list, then open the Events tab in the Properties pane.
  3. Click Add Event Listener in the Events tab.
  4. Select an action chain from the list. Click Select.
    If you want to create a new action chain, click Add and type the name of the action chain.

When you add the event to the variable, a variable event listener is automatically created that listens for the onValueChanged event on the variable. The variable's Events tab displays the action chain the event listener will trigger, and you can change or remove the action chain, assign input parameters, and add more action chains.



Note:

Events and events listeners for variables are not listed in the Events or Event Listeners editors.

Start an Action Chain From a Lifecycle Event

Lifecycle events are pre-defined events that occur during a page's lifecycle. You can start action chains when these events occur by creating event listeners for them. For example, if you want to initialize some dynamic component variables when the page opens, you can create an event listener in your artifact that listens for the vbEnter event. You could then set the event listener to trigger an action chain that assigns values to the component's variables.

This table describes the lifecycle events you can use.

Lifecycle Event Description
vbEnter Triggered after page-scoped variables have been initialized. Commonly used to trigger data fetches.
vbExit Triggered when navigating away from the page. Commonly used to perform cleanup.
vbBeforeEnter Triggered before navigating to the page, optionally allowing navigation to be canceled.
vbBeforeExit Triggered before navigating away from the page, optionally allowing navigation to be canceled.
vbAfterNavigate Triggered after navigation to the page is complete.

To start an action from a lifecycle event:

  1. Open the Event Listeners editor in the layout or page, then click Add Event Listener.
  2. In the Create Event Listener wizard, expand the Lifecycle Events category and select the event you want to trigger an action chain. Click Next.
  3. Select the action chain you want to trigger. Click Finish.

Start an Action Chain From an Action Chain

You can start an action from within another action chain using a custom event, which is triggered by the Fire Event action in an action chain. Typically you would use a custom event when you want to trigger a notification, like displaying a popup window with a message, or perhaps when you want to transform some data. After creating a custom event, you need to create an event listener for it to start the action chain.

Each custom event has a Behavior property, which you can use to set whether action chains run serially or in parallel. The default behavior is "Notify", which allows the action chains to run in parallel. For more about setting an event's Behavior property, see Choose How Your Custom Events Call Event Listeners.

To start an action chain with a custom event:

  1. Open the Actions editor in the layout or page.
    The editor shows a list of action chains that are available in the current scope.
  2. Select the action chain in the list you want to edit. The action chain opens in the action chain's Diagram editor.
    If you want to create a new action chain, click Add Action Chain.
  3. In the Diagram editor, drag the Fire Event action from the palette and drop it in the action chain where you want the event to occur.
  4. Select the Fire Event action in the action chain and specify the Event Name in the Properties pane.

    If you are using the Fire Event action to trigger a new event, click Create and type an Event ID and specify the event's scope. If you want to trigger a custom event that already exists you can select it in the dropdown list.



    After creating or selecting the event, you can click Go to Custom Event in the Properties pane if you want to edit the event's Behavior or Payload properties in the Events editor.

  5. Open the Event Listeners editor and click Add Event Listener to open the Create Event Listener wizard.
  6. Select the custom event you added to your action chain. Click Next.
  7. Select the action chain you want the event to trigger. Click Finish.

Choose How Your Custom Events Call Event Listeners

Each custom event has a behavior type that defines how the event listeners will be called in relation to each other, whether the result for the listener is available, and what form the result would take. The behavior type is used for listeners defined in base apps as well as extensions, and is not specific to events defined in the "interface".

The behavior type does not define the order in which listeners are called, but whether the listener is called serially or in parallel, that is, whether the action that raised the event waits for a listener resolution, and what the "result" of the listener invocation looks like. So in this case, "serially" means:

  • For a single event listener (in a container), all the event listener chains are called sequentially, in a declared order. This means that a listener action chain is not called until the previous action chain has finished (and resolved, it returns a Promise)
  • The event listeners for the next container's listeners are not called until the listener action chains for any previous container's event listeners have finished (and resolved, it returns a Promise)

You can choose the behavior type of a custom event in the Properties pane of the Events editor.



A custom event will have one of the following behavior types.

Behavior Type Description
Notify

Parallel - The event is triggered but the application does not wait for the extension to process it.

Chain results are not available to the Action (or helper) that fired the event (because the listeners are called without waiting). This is the default behavior.

NotifyAndWait

Serial - Each action chain listener must complete (and resolve any returned Promise, if any), before another event listener action chain is called.

Chain results are not available to the Action (or helper) that fired the event.

CheckForCancel

Serial - Each action chain listener must complete (and resolve any returned Promise, if any), before another event listener action chain is called.

If any of the listeners Chains returns a "success" with a payload of { "stopPropagation": true }, the application will stop calling event listeners.

Chain results are not available to the Action (or helper) that fired the event.

Transform

Serial - Each action chain listener must complete (and resolve any returned Promise, if any), before another event listener action chain is called.

The "eventListener" will have access to a new context variable, $previous, which is a peer of "$event". This will be the result of the previous listener invocation's chain result, or undefined for the first invocation. The "eventListener" for a "transform" event can also have a "returnType" declaration, analogous to the "payloadType", but corresponding to the $previous value. If the event declaration has a "returnType", $previous should match the type, otherwise, it will be coerced to the type.

When calling listeners defined in both extensions and the base application, the listeners in the "base" are called first. In other words, the base fires an event with a value, and the extensions may optionally modify that value. (This convention is the opposite order of the "cancel" behavior). The final result, "returnType", when all the listeners have been called, will be returned as the result of the fireCustomEventAction that initially raised the event.

If the application wishes to use the "transform" mode, the convention it should follow is:

  • For any listeners for an event with a "transform" behavior that reference more than one Chain, the Chains are called in array order.
  • All listeners for an event with a "transform" behavior should pass the $previous as an argument to their Chain (and this will typically be wired by the design-time).
  • All listeners for an event with a "transform" behavior should define a "returnType", which matches the "returnType" for the event declaration.
  • The Chain variable argument that corresponds to $previous should have an argument that matches the "returnType" of the event, and the Chain should also have a "returnType" that matches the listeners "returnType" (note that "payloadType" and "returnType" cannot currently reference defined Types, because of restrictions on types used in the "interface" section).
  • The Chain should have a "returnType" defined, that matches the "returnType" of the event (this is currently not used by runtime.).

The parameters for the listener, and the inputs for the Chain, to provide $previous can be added by the design-time, just as it provides the $event.

Here is an example:

"events": {
   "myTransformEvent": {
      "payloadType": {
         "foo": "string"
      },
      "returnType": {
         "bar": "number",
      },
     "behavior": "transform"
   }
}
"eventListeners": {
  "myTransformEvent": {
     "chains": [{
       "chainId": "myTransformChain",
       "parameters": {
          "myPrevious": "{{ $previous }}",
          "myEvent": "{{ $event }}
       }
     }]
},
"chains": {
   "myTransformChain" : {
     "variables": {
        "myEvent": {
          "type": {
             "foo": "string"
          }
        },
        "myPrevious": {
           "type": " {
             "bar": "string"
           }
        }
     },
     "actions": { ... },
     "returnType": {
        "bar": "string"
      }
   },
   "fireIt": {
      "root": "fire",
      "actions": {
         "fire": {
            "module": "vb/action/builtin/fireCustomEventAction",
            "parameters": {
              "name": "{{ $chain.variables.name }}",
              "payload": "who cares?"
            },
            "outcomes": {
              "success": "getResult",
            }
         },
         "getResult": {
            "module": "....",
            "parameters": {
              "name": "{{ $chain.results.fire.result }}",
            }
         }
      }
   }
}
Dynamic component

The "dynamicComponent" behavior type is usable only in the context of an action chain invoked directly from a dynamic component. You'll need to choose this behavior type if you want to use a component in a layout to trigger action chains defined in a page, for example, to use a link in a layout to navigate to another page. This behavior is the only way a page can listen to a layout event. The event listener is defined on the component in the layout, and it must be lowercase (example: "on-myeventname"), like other Oracle JET custom event listeners.

Use Events Defined in the Base App

The base app might define some events that you can use in your app extension to start action chains. In the Events tab of your page or layout, you can see which base app events are Triggerable and/or Listenable by your app extension. When you select an event in the Events tab, you can see details about the event in the Properties pane, such as the where it is defined, what triggers the event and the event's behavior type.

Description of designer-custom-events.png follows
Description of the illustration designer-custom-events.png

In this image you can see that the event defined in the base app (clickBack) is badge with base, and that it's designated as listenable by the app extension, meaning you could add an event listener to your app extension that listens for the clickBack event. You can't change the designation of custom events defined in the base app, but you can use them to start action chains defined in the base app or in your app extension.

Event Designation Description
Triggerable

Triggerable events are used to start action chains defined in the base app. If an event is designated as Triggerable, you can call the event from an action chain in your app extension using the Fire Event action.

For example, the base app might define an action chain that opens a popup window, and define a custom event (for example, openPopup) and event listener to trigger the action chain. If the custom event is Triggerable, you can call the event from your app extension. So if you want to use that action chain when a user selects a specific option, you can add the Fire Event action to the action chain in your app extension that is triggered when the option is selected. In the Actions editor, you would choose the openPopup event when you configure the Fire Event action.

Listenable

Listenable events are used to start action chains defined in your app extension. If an event in the base app is designated as Listenable, you can add an event listener to your app extension and configure it to trigger your action chain when the listenable event occurs.

For example, you can use listenable events to:

  • execute an app extension action chain asynchronously or synchronously

  • cancel an event in the app extension action chain

  • transform a return value that is passed between the layers of event listeners

Call Custom JavaScript Functions

You use a JavaScript editor to add custom JavaScript functions that can be called from within pages, components, action chains and fields in your app extension. Any JavaScript code that you add will have a defined scope based on the editor where you write the code. If your code will only be called from within a specific layout artifact, for example, to assign data to a variable, you can write your code in the layout's JavaScript editor.

Each page and layout has a separate JavaScript file that you open in the artifact's JavaScript editor. For example, you open the JavaScript file for the Leads layout by opening it in the Designer and clicking the JavaScript tab, or by locating the layout's JavaScript file (layout-x.js) in the Source view in the Navigator. You can then call the functions from the layout's action chains and components.



Layouts also have a JavaScript file for custom functions for the layout's field properties. You can edit this file by selecting a field in a layout's Fields tab and then selecting the JavaScript tab in the Properties pane, or by locating the artifact's JavaScript file (data-description-x.js) in the Source View in the Navigator.



The editor provides code validation and identifies the lines that contain syntax warnings and errors in the right margin of the editor. A lightbulb in the left margin indicates a hint for correcting invalid JavaScript code.

Note:

The auto-save function will not save a JavaScript file that has invalid code.

You can use custom JavaScript functions in your app extension:

Add Custom Resources

You can add custom resources such as images or CSS files to your app extension to replace or override resources if the base app allows it. For example, if a component uses a constant to define the path to an image, you could edit the constant to point to your custom image instead.

To add a custom image resource:

  1. Open the Source View pane in the Navigator and expand the resources folder (your path to the folder might look like sources/ui/extension1/self/resources).
  2. Click Import Image Files to open the Import Resources dialog box.
  3. Drag the resource into the drop area in the dialog box, or click the area and locate the resource on your local system. Click Import.
    The new resource is added to the folder and visible in Source View if you expand the folder.
  4. Open the artifact containing the constant you want to edit, then open the Variables tab and select the constant that stores the path to the image.
  5. Edit the constant's Default Value field in the Properties pane.

    You can click Expression editor to open the Expression Editor, and build the path to the image (for example, $extension.path + 'resources/images/myNewImage.png').



    You could also click Variables to open the Variables picker and select the extension path, then type the location in the Default Value field.



.

Add Pages To an Oracle Cloud Application

While you can't add native pages to an Oracle Cloud Application created by Oracle, you can create an App UI, then link to that App UI from your Oracle Cloud Application.

An App UI is simply an application that includes user interface components in the form of Visual Builder pages and flows. As long as your version of Oracle Cloud Applications is running 22B or later, you can build your own App UI within an extension and deploy the App UI as a peer to your Oracle Cloud Applications ecosystem.

Using Build an App UI or Fragment as a guide, you can create an App UI to contain your own pages with data from Oracle Cloud Application REST APIs, or even from custom business objects. By default your App UI will be available from Oracle's new Ask Oracle menu, but you might also choose to make it available from the Oracle Cloud Application itself. From a customizable component on your original Oracle Cloud Application page, like a dynamic container, you might add a link to the new App UI in the form of an icon or hyperlink, or create a button to navigate to the new content when it's clicked.