Currently I am building a site with a Facebook Open Graph integration.
One complication I have is since user can do seemingly similar actions to different objects on our site, it is easy for us to define different action for each similar actions. However, it seems like Facebook is not allowing ( or at least not liking ) for one site to have multiple similarly looking actions.
For instance, let's assume that user can both 'buy' a car, and 'buy' an insurance in our site.
Although, on surface, these two action look similar, because their context is different we want to show different content - more specifically different caption - for each action that is postsed.
Simple way to implement this will be defining two actions,
'BuyCar' <---> associated with Car
'BuyInsurance' <---> associated with Insurance
and let them have distinctive caption template.
However, as I mentioned earlier, since Facebook does not allow multiple similar actions to be defined within a site, I should be defining.
'Buy' <----> associated with [Car, Insurance]
where this action always have only one property defined. (either Car or Insurance)
Downside of having these type of action is, due to limitation in current cation's template language (lacks conditional statement), I am not able to produce different caption effectively without knowing which property is set.
How should I be handling this issue?
Your help will be greatly appreciated.
Thanks
I think the captions do need to be something generic that will work for all connected object types. But you could use filters to defined separate aggregations for each object type.
Just add an additional parameter to all of your objects and set the value of that parameter as an aggregation filter?
Related
I'm building a CRUD for users in my rest API, and currently my GET route looks like this:
get("/api/users/:id")
But this just occured to me: what if a users tries to search for other users via their username?
So I thought about implementing another route, like so:
get("api/users/username/:id")
But this just looks a bit reduntant to me. Even more so if ever my app should allow searching for actual names as well. Would I then need 3 routes?
So in this wonderful community, are there any experienced web developers that could tell me how they would handle having to search for a user via their username?
Obs: if you need more details, just comment about it and I'll promptly update my question 🙃
how they would handle having to search for a user via their username?
How would you support this on a web site?
You would probably have a form; that form would have an input control that would allow the user to provide a user name. When the user submit the form, the browser would copy the form input controls into an application/x-www-form-urlencoded document (as described by the HTTP standard), then substitute that document as the query_part of the form action, and submit the query.
So the resulting request would perhaps look like
GET /api/users?username=GuiMendel HTTP/x.y
You could, of course, have as many different forms as you like, with different combinations of input controls. Some of those forms might share actions, but not necessarily.
so I could just have my controller for GET "/api/users" redirect to an action based on the inputs?
REST doesn't care about "controllers" -- that's an implementation detail; the whole point is that the client doesn't need to know how the server produces a representation of the resource, we just need to know how to ask for it (via the "uniform interface").
Your routing framework might care a great deal, but again that's just another implementation detail hiding behind the facade.
for example, there were no inputs, it would return all users (index), but with the input you suggested, it would filter out only users whose usernames matched the input? Did I get it right?
Yup, that's fine.
From the point of view of a REST client
/api/users
/api/users?username=GuiMendel
These identify different resources; the two resources don't have to have any meaningful relationship with each other at all. The machines don't care (human beings do care, so we normally design our identifiers in such a way that at least some human beings have an easy time of it -- for example, we might optimize our identifiers to make things easy when operators are reading the access logs).
I've been studying Dialogflow and have now started studying Actions on Google with the desire to build assistant actions. As I read about the system data types found in the Actions on Google Actions Builder I seem to see only a few types:
Date
Time
Date/Time
Number
while when I look in Dialogflow and look at System Entities I seem to see many more than those exposed by Actions on Google.
Currently, I have a need to recognize a person's name. An example phrase would be:
I'd like to book the class taught by Brandon
In Dialogflow, I'd define the intent parameter as being of #sys.person. I don't seem to have that option in Actions on Google and would appear to have to build my own data type.
Is there a reason that the rich set of system defined data types for Dialogflow aren't exposed for Actions on Google using the Actions Builder? What is the recommended approach to define a type that would otherwise be a system type in Dialogflow?
The biggest reason, likely, is that they were either sparsely used or too complicated to be effective. For example, #sys.person is documented as
Common given names, last names or their combinations
(Emphasis mine.) But there are plenty of people with "uncommon" names, that would not be captured, so it is not actually useful in a number of cases. A surprisingly large number of cases in reality.
Under Actions Builder, you can create a custom type that either enumerates the possible values (which would be best for your example) or free-form text. (Or combine the two.)
If you are concerned with needing to update your Action with new names, it may make sense to make a generic type and then have the values for that type updated at runtime. This can make for a much more dynamic and flexible Action.
We are working on a micro-service that interacts with Watson.
I was presented with the following argument: "There is no need to use dialogs in a Conversation project on Watson. Declaring the intents and entities is just enough to get the work done"
Based on the documentation, I have the impression that using dialogs is a requirement in order to train Watson correctly on how to interpret the combination of intents and entities. Plus, in the Dialog section, you have the chat that allows you to make corrections.
Is there a way that I can confirm that Dialogs are or are not a requirement?
If you plan to just use intents and entities programmatically then you don’t need dialog.
You will need to create one blank dialog, with a condition of true. This is to avoid SPEL errors relating to no node found.
From a programming point of view (and ignoring conversation for a minute), if you need to take action on intents, entities, or change context variables. The recommendation is to do that in dialog. This way your code is not split across two systems, making it easier to maintain.
Probably in this phrase above, the author wants to say that you only need to create #intents and #entities for your Conversation and defining the purpose for your bot, this is true, depends on what you want to do in your bot, cause after it you can just create your dialog flow!
The Dialog section is for you create your Dialog flow, is absolutely needed when you want to create one conversation flow, e.g: one chatbot.
A workspace contains the following types of artifacts:
Intents: An intent represents the purpose of a user's input, such as a
question about business locations or a bill payment. You define an
intent for each type of user request you want your application to
support. In the tool, the name of an intent is always prefixed with
the # character. To train the workspace to recognize your intents, you
supply lots of examples of user input and indicate which intents they
map to.
Entities; An entity represents a term or object that is relevant to
your intents and that provides a specific context for an intent. For
example, an entity might represent a city where the user wants to find
a business location, or the amount of a bill payment. In the tool, the
name of an entity is always prefixed with the # character. To train
the workspace to recognize your entities, you list the possible values
for each entity and synonyms that users might enter.
Dialog: A dialog is a branching conversation flow that defines how
your application responds when it recognizes the defined intents and
entities. You use the dialog builder in the tool to create
conversations with users, providing responses based on the intents and
entities that you recognize in their input.
EDIT:
Likes #Simon O'Doherty said, if your purpose is to just use the Intents and Entities programmatically, then you don't need the Dialog. His answer is complete.
See the documentation for Building a Dialog.
Yes Intents and Entities may seem to be just enough for you, and you can generate the answer - programmatically - based on them. But you should keep in mind that Dialog does not mean Response. I know it's hard to find this clearly in Watson documentation.
If you need to get access to context variables in the next node or dialog, you should define them in slots. Without defining dialogs for each intent, context variables will not be accessible or conveyed in the next dialog.
You need Dialog portion of Watson Conversation service if you want to respond to the user queries.
The Intents and entities are the understanding piece, and the Dialog portion is the response side of the conversation.
I'm working upon a small-scale enterprise database application. It works with such business objects as Vendors, Device types, Devices, Suppliers, Invoices, Departments, Employees etc., so I need to let users view and edit data from all these tables.
My first approach was to create a pair of forms for each type of business object:
a table to view and select an object
an editing form for this type of object
But now I find it hard to maintain all these forms, because e.g. if I want to change the look of all view forms, of course I have to edit each one of them.
So I want to replace all my view forms with a single one "template" form and to call it with some kind of parameters. The problem is, I don't know the right approach to perform it. Maybe there could be some example in some book or somewhere else?
I think the best way is by using Visual Form Inheritance .
Actually we use this kind of programming a lot, it keeps maintenance pretty simple. Stick your base functionality in the parent form, and specific behaviour in the child forms.
I have Lotus Notes application, deployed only as modifications (new forms, views, and adding a button to one of the "standard" views) in the main mail template (R7).
All these "new" forms and views are inherited in turn from my main application template.
Now, for one of these forms to function properly, it have to have a field, which is different from customer (not end user, but organization) to customer.
I do not want to break the inheritance from our template, so we can update the application easily by just sending a new template. So, I can't ask the client admin just to break the inheritance for this particular form, as it will stop all updates (or they have to be done manually).
So, let's say I have MainAppForm, which has a calculated field ClientCustomData. I'd like to have another form, which only has only one "default" field ClientCustomData. I can break the inheritance for this second form, as it has no really design elements which may change, and then the client can modify this default value to whatever they need w/o fearing that it'll be overwritten.
The question is - how from MainAppForm I can read the value from the other form?
Or - is there a way to store 2 data elements only in a mail template (I dunno, shared file, or something), so it becomes available to each user, and MainAppForm can get them, w/o a need to remove the inheritance dependency of MainAppForm from our template.
I can envision even a class library with just to functions to return this (I don't know why this approach smells to me).
Any best practices or advices?
I'm not sure if I have understood your querstion correctly, but it sounds like you want to have a small part of a larger form configurable per client. If this is the case, I think computed subforms could do the trick.
Consider the following scenario: Your application ships with the subform ClientCustomData that contains just sensible defaults for the client settings. The form MainAppForm includes this as a computed subform. It is then possible for the local admin to disable inheritance on the subform and changing the custom data without affecting inheritance on MainAppForm.
The obvious drawback is that you cannot update the ClientCustomData subform automatically once inheritance is disabled; Keep this subform as small as possible. If you find that you need more client-custom values, you can always add another subform in the same manner.
First a clarification: In Lotus Notes, you don't have forms reading from other forms. Forms are just UI objects. However, you do have back-end and front-end documents that get created with the help of Forms.
When you create a new document based on a form (for instance, a new email), you are creating a front-end document that hasn't been saved yet. That document can access other parts of itself or it can access any back-end document that has been saved.
If I'm following you correctly, you need some bit of data that is different per client/customer to be brought into documents based on MainAppForm. There are a few ways to do that. My suggestion is to use Database Profiles, which are special documents that can easily be accessed from anywhere in your database via Notes Formula language or LotusScript. Granted, you can't push data within those documents out via a template, but if you use a database profile to store your database settings your client admin can set options once and they won't get altered when the template changes.
Have a look at the #SetProfileField and #GetProfileField functions.
To answer my own question (still I do not know if I'm right in terms of Notes way of thinking, but looks promising):
I found the "Shared fields". So, I create 2 such a fields with a computed values (the ones I want to pass on), and make my MainAppForm use them. Upon installation, the admin will change the values and mark them to not refresh with the template.
I'd respect any pros and cons, provided from a Notes expert.
Thanks