Extending Built-In Types
Suppose that instead of space travel, you were building a more conventional travel application for scheduling travel to international cities. In that case, you’d probably be fine with the built-in AMAZON.City type for most cases.
But what if you offered travel to cities that aren’t covered by the AMAZON.City type? For example, suppose that you’d like to include travel to some of the smaller towns in southeastern New Mexico, including Jal, Eunice, and Hobbs. These towns aren’t covered by Amazon’s built-in AMAZON.City type. But we can change that by extending AMAZON.City with a few custom values.
To extend a built-in type, simply declare it in the interaction model as if it were a completely custom type. For example, the following excerpt shows how to extend AMAZON.City to include a few of New Mexico’s smaller towns:
| | "types": [ |
| | { |
| | "name": "AMAZON.City", |
| | "values": [ |
| | { |
| | "id": "JAL", |
| | "name": { |
| | "value": "Jal" |
| | } |
| | }, |
| | { |
| | "id": "EUNICE", |
| | "name": { |
| | "value": "Eunice" |
| | } |
| | }, |
| | { |
| | "id": "HOBBS", |
| | "name": { |
| | "value": "Hobbs" |
| | } |
| | } |
| | ] |
| | } |
| | ] |
Here, the type’s name is the same as the built-in type, and includes three custom values. But, unlike a completely custom type, which will only include the values declared in the interaction model, this type will include all of the values that already come with AMAZON.City as well as the new values.
The Star Port 75 Travel skill doesn’t have a need for a type that’s an extension to a built-in type, so there’s no need to work it into the interaction model.
But we will use the custom PLANETS type for scheduling trips. Let’s see how to make it even more flexible by handling alternative names for the type’s values.