-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve @ForIntent Annotation #31
Comments
Hi @cbeaujoin, Thank you for your feature request! We are always looking on ways to improve our client libraries, so we appreciate feedback and suggestions for the community. |
Should it only check for 1 parameter? Or should it also be able to take in a list of parameters? |
Also, as a follow up for this, maybe at some point, add another annotation for |
If you do support a list of parameters, would your annotation support a comma-separated list of args or an array primitive?
or
|
It could probably go either way on the array formatting. I think that an actual array would be more explicit. Also, to get which parameters to check,how should we pick which name from the outputContext to choose? Or do we look at the parameters for all of them? I provided the snippet below to show the output contexts and their names.
|
You mean between "category" and "category.original"? |
Oh, sorry, I should've explained better. The @ForIntent("Intent Name") matches the top level intent name. |
You mean the parameter names, or the names of the context? |
Name of the context
…On Mon, Oct 14, 2019 at 11:33 AM Nick ***@***.***> wrote:
You mean the parameter names, or the names of the context?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#31?email_source=notifications&email_token=AF7GLLLDTRHXWP2UVUZATTLQOSNMDA5CNFSM4IUY6AWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBFPEQY#issuecomment-541782595>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF7GLLM725JVBW5ZTU7IPYTQOSNMDANCNFSM4IUY6AWA>
.
|
I guess choosing either the first (exit early) or the last (replace) would be the primary expected way to do it. Or maybe throw an exception if not specific enough. There are many different ways to do it which could all be potentially valid. |
Would the user also need to specify the context type name then (just the last part)? And if they didn't care which it hit, leave it empty and it will default to match the first one that has all the parameters, if any? |
Well I don't know whether they'd need to specify the context always. Certainly it's something you may need. But what do you think the expected behavior should be if it's empty? |
Hi, I don't think we need to support a list of parameters. First let me add my understanding of the contexts names : With actions we have a context at conversation level :
For a given intent "intent" whatever the number of filled params there is parent context :
For a given intent "intent" with a required parameter "cellphone" not filled and in first position in the required parameters sorted list. There is a context :
If there is no context that contains "dialog_params" it means we have reach the intent's end. If we apply this to the annotation : @ForIntent("Intent Name", "cellphone")
@ForIntent("Intent Name") => with an empty/null second parameters
or there is a dialog_params but it does not match any @ForIntent("Intent Name", "param") |
Hi,
for the moment we can easily handle Intent by their name:
@ForIntent("Intent Name")
As we often use webhook call for slot filling, it could be interesting to add a second parameter to the annotation that would handle the corresponding slot filling.
For example :
@ForIntent("Intent Name", "Parameter Name")
For the moment as a workaround I do like this :
The text was updated successfully, but these errors were encountered: