Let's say I have a dynamic list of items which I upload from a webhook at a certain step of a scenario. This list is not a list of some type of pre-defined entities, this is just a list of something.
So,
$session.params.items = ["item_1", "item_2"]
Now, at the next step user can either choose one of the options provided in this list or make something else. It seems that the best way to check whether the next user query has something to do with our list of items, I need to declare a non-required parameter. But if I do this way, they necessarily require an entity type.
So, the question is:
Is is possible to use any list or dict from session parameters as an entity type?
What is the best way to implement checking whether user query falls into one of the session variables like list taking into account that user query may as well go to other intent and so on. I supposed the best way is to have routes for filling in unnecessary parameters and for intents, but still I can't do the first part.
Related
I am currently building an Alexa application that analyzes a user's name. I currently have a slot (called name) that uses the built in AMAZON.US_FIRST_NAME slot type. I want to validate the name by comparing it against amazon's list of US_FIRST_NAMES, instead of having to download a list of names somewhere and comparing the user's name against the list. Is there any way to do this through the Amazon Developer Console?
Note: In Amazon's docs (https://developer.amazon.com/docs/custom-skills/validate-slot-values.html) I have read that there are ways to validate built in slots. However, on the development console, the validation tab for my name slot only allows me to accept or reject the user's input from a list of names that I have provided, not Amazon's built US_FIRST_NAME list. Have I missed something?
In the Alexa console, you have three options:
You can define a custom list of values to accept or reject, or you can choose to accept only the slot type's values and synonyms.
If you see the option to accept the slot type's values and synonyms, I imagine this will do what you are looking for.
If for some reason it doesn't give you that option, then you could actually create a custom slot type and copy and paste the entire list of US names from Amazon into the proper place in your JSON file, though this would make for quite a large file.
I hope this helps.
When we design Rest apis, it is said that use Path Variable when you need to identify a resource and Request Parameters when you need to do operations like sorting, filtering, searching, pagination. Let us take a scenario of Employee:
Employee has three fields like name, companyName, socialSecurityNo.
Now i want an Employee with a socialSecurityNo = ABC.
It seems fine to have endpoint with path variable like /employees/{socialSecurtityNo}, since we are identifying a resource.
Also it seems intuitive that we are filtering on the basis of socialSecurityNo and have an endpoint like /employees?socialSecurityNo=ABC
What will be the right way as i am confused and think that both apply.
It's a good question.
/employees?socialSecurityNo=ABC
is filtering all employees on socialSecurityNo. If socialSecurityNo is unique to an employee, there's no point in this endpoint existing and a client should use /employees/{socialSecurtityNo}.
There's nothing wrong with filtering on a unique field value (socialSecurtityNo) and if a client finds it easier to use this version (for whatever technical reason) then that's fine. There is no 'right' way. The ultimate reason APIs exist is to allow valuable work to be done by a client. Work with the client to allow that to happen but keep best practice in mind and know when the solution isn't the best but is the most practical in the situation.
I would expect to see:
/employees?surname=Smith
as this is filtering on a non unique field value and should return a collection of Employee objects.
The 'right' thing to do is keep the results consistent. If you have both ways of finding an employee, make sure the returned result is the same in each case.
I am using a filter to apply object level permissions to a collection. Resources in a second collection have a many-to-many relationship with the first. On the browsable API, when creating resources in the second collection, the user is presented with a list of resources from the first to link it to. However, this list is not filtered, so the user can see values that they should not be able to see.
I've poked around the documentation and source a bit and I cannot see a way to add filtering to the queryset that generates the choices without overloading or modifying a bunch of code to pass the request data down (probably removing some of the collection specific data on the way) and then apply the filters.
Is there a better way to achieve this?
Currently there's nothing to support this out of the box. Pull requests are always welcome. If it's something you want to work on you may want to either open a ticket on GitHub or hit up the mailing list to discuss it first.
Is there a field_load() function equivalent to node_load()? I want to get information about the type of a field and other validation constraints without going to the database myself.
Better yet, is there any function that will validate it for me, like is_valid_for_field(field_name, input), that would take a field name and a potential input and return a boolean indicating whether or not the potential input is valid (within min/max, etc) for the specified field?
There is the content_fields() function, which will get you the meta data for a field. In terms of validation, IIRC, you can call content_field() with the operation set to validate, and the relevant data. However, by calling node_save with your completed node, the cck module will take care of all the relevant validation hooks for the entire node structure, so you may be better off taking that route.
I've been having a look at several MVC frameworks (like rails, merb, cakephp, codeignitier, and similars...)
All the samples I've seen are basically plain and simple CRUD pages, carrying all the infr needed in the querystring and the posted field values.
I've got a couple of apps made with some sort of framework built with classic asp.
This framework handles some CRUD stuff a little more complex than the examples I found.
Something like master-detail, filtering by example, paging, sorting and similars.
I have a controller class that it's just a finite state machine, that goes thru diferent states (like new, browse, filter, show, etc.), then performs the appropiate action depending on the event raised and finally retrieves the neede info to the calling page.
To achieve this I have several hidden inputs to keep the state of the web page (like current id, filter criterias, order criterias, previous state, previous event, well, you get the idea)
What do you think would be the finnest approach to achieve this kind of funcionality?
hidden inputs built in the view and used from the controller??? (I guess that would be the equivalent of what I'm doing right now in classi asp)
--
(added in response to tvanfosson)
basically, my question refers to the third category, the context-dependent setting (in respect to the other two categories I agree with you) the info I was storing in hidden fields to store them on the querystring, I guess that when you click on the "next page" you include everything you need to save in the querystring, right? so that piece of query string gets appended in each and every link that performns some kind of action...
I'm not sure, what are the advantages and disadvantages of using the querystring instead of hidden inputs???
I use different strategies depending on the character of the actual data. Things that are preferences, like default page size, I keep in a Preferences object (table) that is associated with the current logged in user and retrieve from there when needed.
Persistent settings associated with the current logon, like filter settings for a page, are stored in the user's session. Generally these are things that if a user sets them in the current session they should remain sticky. I think filter settings and visibility are like this. If I filter a list, navigate away from it to drill down into a particular item, then come back to the list, I want my filter settings to be reapplied -- so I make it part of the session.
Context-dependent settings -- like the current sort column or page number, are controlled using query parameters. Paging and sort controls (links) are built with the appropriate query parameters to "do the right thing" when clicked and pass any necessary query parameters to maintain or update the current context of the control. Using the query parameters allows you to use an HTTP GET, which is bookmarkable, rather than a POST. Using hidden form parameters makes it much harder for the user to save or enter a URL that takes them directly where they want to go. This is probably more useful for sorting than it is for paging, but the principle applies equally.