We’ve looked at composites from a very high level and then we built a very simple composite. Now we’ll have a look at interfaces. What are interfaces? Very simply put, they are methods, events and properties that are exposed to the app. The composite itself is self-contained and these interface objects allow it to interact with the app.
Composites are self-contained and portable. You can take any composite and drop it right into any app. This is possible, because the composite and the apps hosting it do not share a common scope. Scope is programmer-speak for the collection of variables, properties, functions, etc that are visible at any one time. When you create a composite, you can create global properties and functions. These “global” properties and functions are global within the composite, but are not visible outside it. So if you added a global property called foo to a composite, a host app would not be able to see it. They are private to the composite. Conversely, the global properties and functions of the host app are not visible within the composite. You can think of composites as flower pots, that can be moved around.
Interfaces, simply put, are “public” bits visible to both the composite and the host app.
Any properties defined in the interface show up in the properties pane of the composite, when it is in the application. These are properties that are globally visible within the composite, but are seen as a property of the composite from the outside.
Example: Our self-contained chart tile, from the last exercise, has an unwieldy name. Perhaps we want to allow the app designer to define the title of the chart tile in the properties pane, when they are editing the app.
As with properties, these are the functions that a composite can offer to the host application. You define a function, attach a script, which runs inside the composite and then this function can be called from the host app.
Example: Perhaps instead of setting it in the properties pane, you would like to have a function, which allowed you to set the title of the chart tile. When designing the composite, you would write the script that did this. Then, whenever your app needed to change the title of the tile, you’d call this function.
Functionally, these are like methods, but go in the opposite direction. They allow the app designer to write scripts, which are called by the composite.
Example: Suppose your chart tile composite could toggle between showing a chart and table. It contains a chart, a table as a toggle switch that would allow the user to make one visible and the other invisible at any time. If wanted to be able to execute a script in the host app whenever this toggle was used, you’d create an event for it.
Our Example App (Starting Point)
We’ll start with a modified variant of the app that we built in the last part. It features a grid layout with a header region and a body. The header contains a text element, TEXT_1. This is the title of the tile. The body element contains a chart, CHART_1 and a spreadsheet, SPREADSHEET_1. Both display the same data source. SPREADSHEET_1 is hidden by default. Clicking on CHART_1 will hide it and set SPREADSHEET_1 visible. Clicking on SPREADSHEET_1 sets it invisible and CHART_1 visible. In effect, the title is always visible and clicking within the body toggles between chart and spreadsheet display.
In the next three posts, we will do the following:
- We’ll expose the content of TEXT_1 as a composite property, so that the designer used this composite in an app, she can edit it in the properties pane. To do this, we’ll create a composite interface property and bind the value of TEXT_1 to it.
- We’ll make this property editable via script, so that the designer can also dynamically alter the text at runtime. To do this, we’ll create an interface function that will do this.
- We’ll create an event, which will be triggered whenever the user toggles the chart type. This will allow the designer to fire a script in the app whenever this happens.