Custom Slots

[ghost]

Important: English (US) skills using the AMAZON.LITERAL slot type should be updated to use custom slots. Starting February 6, 2017, you will no longer be able to use AMAZON.LITERAL when saving a new or updated skill. Existing skills that already use AMAZON.LITERAL will continue to work, but you will be unable to make any changes to the skill configuration until you remove AMAZON.LITERAL.

Amazon's docs say that LITERAL is deprecated - what is the effort required to update this gem to use custom slots instead? I was thinking something along the lines of adding a custom_slots method, similar to intent_schema that lists the custom slots that were created, and a custom_slot(name) to print all the values for it

[sidoh]

I kinda sorta added support in a sneaky release here. Haven't updated the documentation yet because I'm not sure I'll keep the interface.

I didn't actually remove support for LITERAL, but I added support for custom slots. Right now, the syntax is something like:

    model = AlexaGenerator::InteractionModel.build do |model|
      model.add_intent(:IntentName) do |intent|
        intent.add_slot(:SlotName, :SlotType) do |slot|
          slot.add_bindings('value1', 'value2', 'value3')
        end
    end

You can add bindings at any point -- should be cumulative. To collect them at the end, you can use model.custom_slot_types to collect all custom slot types, and model.slot_type_values(type) to get values for a particular slot type.

I think I might prefer to have a model.add_custom_slot_type(type, &block) where you define your slot type in one place, and then reference it later (would remove support to add bindings when adding a slot to an intent).

Any thoughts?

[ghost]

Firstly, thanks for showing me that it's already possible! There's ups and downs to both approaches. If you leave the ability to add slot bindings by intent, it would break up all the possible slot type values that are needed, depending on the intent where they are used. On the other hand, by defining the slot type in one place with it's values, it would provide a more clear picture of the custom type at a glance of the code without running the generator.

I am indifferent on either approach - the current one works fine for my use cases. However since custom slot attributes may be shared by multiple intents, it would need to be clear that you can reuse the same slot :SlotType several times without it being replaced, and instead being added to.

[sidoh]

Good listing of the tradeoffs.

A big disadvantage to the current approach is that it's less robust to typos. If a referenced slot type isn't defined, it could throw an error, which is probably easier to debug than tracking down the missing type.

[ghost]

That's also a great point. I think that and the fact that custom slots are independent of intents tilts the scale towards defining it on the model a single time and using it where needed.