I'm building a LuisDialog and have LUIS integration working well.
In the cases where LUIS doesnt fill in all the gaps I need, what is the best approach for disambiguation?
Right now, I use PromptDialog callbacks - So inside a Dialog method (decorated with the LuisIntent attribute), when I need to get more details/disambiguate i'd have:
PromptDialog.Choice<string>(context, EnsureTimeOfDayChosen, new[] { "Morning (AM)", "Afternoon (PM)", "Any" }, "What time of day would you like us to book the appointment? (AM/PM/Any)", "Please choose AM or PM. Alternatively, if you don't mind which, just say Any.");
And the delegate's body (EnsureTimeOfDayChosen):
string AmPmOrAny = await result;
context.PerUserInConversationData.SetValue<string>("TimeOfDay", AmPmOrAny);
BookAppointment(context);
The problem with this approach is the last line of the delegate - it doesn't feel right. I can't easily call back into the place I was in the initially called, LuisIntent decorated method and resume.
Instead, I have to deal with the LUIS info up front, and call the BookAppointment method after gathering more info, and storing it in PerUserInConversationData.
Am I doing it wrong?
Any help would be greatly appreciated - Kind Regards,
Matt.
Given current implementation of the Dialog model, I cannot think of a better way of implementing your logic. Currently anytime that you are waiting on an async response from the user, your code will be resumed on the callback you provided upon response. You can think of it as Begin/End model for async programing
Related
I have an intent called intent_yes which is shared in several different conversational flows. When the user says "Yes" or "Yeah" etc., it will call my webhook / Rasa action. I need to know what they've said yes to. How can we get the previous intent name from a Rasa webhook action?
I think I agree with the OP.
There are times, when an intent is activated for whole different reasons.
For instance, you have words like "Why?" "How?" for some specific intents, and their corresponding actions get triggered without discrimination.
How do you prevent such basic expressions from being triggered in the most unlikely scenarios?
Surely it is not efficient to write stories for each conceivable conversational turns for "Why" & "How".
This is why I wanted a solution that checks the state of the conversation and determine if a particular intent has been triggered before running.
And Tom's solution above makes sense.
I will try that.
UPDATE:
This was my solution:
def get_latest_event(events)
latest_actions = []
for e in events:
if e['event'] == 'action':
latest_actions.append(e)
return latest_actions[-2:][0]['name']
get_latest_event(tracker.events)
I thought it best to wrap it in a function for portability.
I init an empty list.
Go through all the given events.
If the event is an action event, I push it into the empty list above.
I then return with the last two objects, pick the name of the first one.
The assumption is that we are looking for the last action that was triggered.
Again, my use-case is, I want a way to control my response to a generic follow-up question.
For instance, a user asks why?
I want to know the last thing the bot said (action) that triggers that why.
If it is an edge-case that I am interested in, I handle it differently.
If not, I respond generically.
Is this hacky?
Maybe.
But until I can figure out a way to prevent myself from writing stories for all possible ways a user can ask 'why?', this will do.
I am open to better suggestions.
This is probably not good design - you're better off writing individual stories for each flow and then having a corresponding action for each circumstance, however within the custom action's run method you can access the tracker. This object holds all the events of the conversation in a list called tracker.events, which
will look something like this:
[{'event': 'action', 'timestamp': 1558688062.7624729, 'name': 'action_listen', 'policy': None, 'confidence': None},
{'event': 'user', 'timestamp': 1558688062.7628329, 'text': '/joke', 'parse_data': {'text': '/joke', 'intent': {'name': 'joke', 'confidence': 1.0}, 'intent_ranking': [{'name': 'joke', 'confidence': 1.0}], 'entities': []}, 'input_channel': 'rest'}]
To get the user messages just iterate backwards over this list until you find "event":"user" and the intent is given inside "parse_data"["intent"]
The UI is decoupled from the domain, but the UI should try its best to never allow the user to issue commands that are sure to fail.
Consider the following example (pseudo-code):
DiscussionController
#Security(is_logged)
#Method('POST')
#Route('addPost')
addPostToDiscussionAction(request)
discussionService.postToDiscussion(
new PostToDiscussionCommand(request.discussionId, session.myUserId, request.bodyText)
)
#Method('GET')
#Route('showDiscussion/{discussionId}')
showDiscussionAction(request)
discussionWithAllThePosts = discussionFinder.findById(request.discussionId)
canAddPostToThisDiscussion = ???
// render the discussion to the user, and use `canAddPostToThisDiscussion` to show/hide the form
// from which the user can send a request to `addPostToDiscussionAction`.
renderDiscussion(discussionWithAllThePosts, canAddPostToThisDiscussion)
PostToDiscussionCommand
constructor(discussionId, authorId, bodyText)
DiscussionApplicationService
postToDiscussion(command)
discussion = discussionRepository.get(command.discussionId)
author = collaboratorService.authorFrom(discussion.Id, command.authorId)
post = discussion.createPost(postRepository.nextIdentity(), author, command.bodyText)
postRepository.add(post)
DiscussionAggregate
// originalPoster is the Author that started the discussion
constructor(discussionId, originalPoster)
// if the discussion is closed, you can't create a post.
// *unless* if you're the author (OP) that started the discussion
createPost(postId, author, bodyText)
if (this.close && !this.originalPoster.equals(author))
throw "Discussion is closed."
return new Post(this.discussionId, postId, author, bodyText)
close()
if (this.close)
throw "Discussion already closed."
this.close = true
isClosed()
return this.close
The user goes to /showDiscussion/123 and he see the discussion with the <form> from which he can submit a new post, but only if the discussion is not closed or the current user is who started that discussion.
Or, the user goes to /showDiscussion/123 where it's presented as a REST-as-in-HATEOAS API. A hypermedia link to /addPost will be provided, only if the discussion is not closed or the authenticated user is who started that discussion.
How can I provide that knowledge into the UI?
I could code that into the read model,
canAddPostToThisDiscussion = !discussionWithAllThePosts.discussion.isClosed
&& discussionWithAllThePosts.discussion.originalPoster.id == session.currentUserId
but then I need to maintain that logic and keep it in sync with the write model. This is a fairly simple example, but as the states transitions of an aggregate become more complex, it may become really hard to do. I'd like to image my aggregates as state machines, with their workflows (like the RESTBucks example). But I don't like the idea to move that business logic outside my domain model, and put it in a service that both the read side and write side can use.
Maybe this isn't the best example, but as an aggregate root is basically a consistency boundary, we know that we need to prevent invalid state transitions in its life cycle, and in each transitions to a new state some operations may become illegal and vice versa. So, how can the user interface know what is allowed or not? What are my alternative? How should I approach to this problem? Do you have any example to provide?
How can I provide that knowledge into the UI?
The easiest way is probably to share the domain model's understanding of what is possible with the UI. Ta Da.
Here's a way to think about it -- in the abstract, all of the write model logic has a fairly simple looking shape.
{
// Notice that these statements are queries
State currentState = bookOfRecord.getState()
State nextState = model.computeNextState(currentState, command)
// This statement is a command
bookOfRecord.replace(currentState, nextState)
}
Key ideas here: the book of record is the authority of state; everybody else (including the "write model") is working with a stale copy.
What the model represents is a collection of constraints that ensure that the business invariant is satisfied. Over the lifetime of a system, there might be many different sets of constraints, as the understanding of the business changes.
The write model is the authority for which collection of constraints is currently enforced when replacing the state in the book of record. Everybody else is working with a stale copy.
The staleness is something to keep in mind; in a distributed system, any validation you perform is provisional -- unless you have a lock on the state and a lock on the model, either could be changed while your messages are in flight.
This means that your validation is approximate anyway, so you don't need to be too concerned that you have all of the fiddly details right. You assume that your stale copy of the state is approximately right, and your current understanding of the model is approximately right, and if the command is valid given those pre-conditions, then it is checked enough to send.
I don't like the idea to move that business logic outside my domain model, and put it in a service that both the read side and write side can use.
I think the best answer here is "get over it". I get it; because having the business logic inside the aggregate root is what the literature is telling us to do. But if you continue to refactor, identifying common patterns and separating concerns, you'll see that entities are really just plumbing around a reference to state and a functional core.
AggregateRoot {
final Reference<State> bookOfRecord;
final Model<State,Command> theModel;
onCommand(Command command) {
State currentState = bookOfRecord.getState()
State nextState = model.computeNextState(currentState, command)
bookOfRecord.replace(currentState, nextState)
}
}
All we've done here is taken the "construct the next state" logic, which we used to have scattered through out the AggregateRoot, and encapsulated it into a separate responsibility boundary. Here, its specific to the root itself, but an equivalent refactoring it so pass it as an argument.
AggregateRoot {
final Reference<State> bookOfRecord;
onCommand(Model<State,Command> theModel, Command command) {
State currentState = bookOfRecord.getState()
State nextState = model.computeNextState(currentState, command)
bookOfRecord.replace(currentState, nextState)
}
}
In other words, the model, teased out from the plumbing of tracking state, is a domain service. The domain logic within the domain service is just as much a part of the domain model as the domain logic within the aggregate -- the two implementations are dual to one another.
And there's no reason that a read model of your domain shouldn't have access to a domain service.
I don't like the idea of sharing domain knowlegde (code) between the write and the read models as you will have to continously keep them in sync and that'd really a chalenge even if you are the only developer in your company.
But the good knews is that you don't have to duplicate anything. If you designed your Aggregate to be pure, with no side effect as you should do (!), you can simply send it the command but without persisting the changes. If the command throws an exception then the command would not succeed, otherwise the command would succeed. In case of CQRS this is even better as you have a 3rd outcome: idempotent command detection in which case the command succeeds but it has no effect (no events are raised but no exception is thrown either) and the UI might find this interesting.
So, as an example you could have something like this:
DiscussionController
#Security(is_logged)
#Method('POST')
#Route('addPost')
addPostToDiscussionAction(request)
discussionService.postToDiscussion(
new PostToDiscussionCommand(request.discussionId, session.myUserId, request.bodyText)
)
#Method('GET')
#Route('showDiscussion/{discussionId}')
showDiscussionAction(request)
discussionWithAllThePosts = discussionFinder.findById(request.discussionId)
canAddPostToThisDiscussion = discussionService.canPostToDiscussion(request.discussionId, session.myUserId, "some sample body")
// render the discussion to the user, and use `canAddPostToThisDiscussion` to show/hide the form
// from which the user can send a request to `addPostToDiscussionAction`.
renderDiscussion(discussionWithAllThePosts, canAddPostToThisDiscussion)
DiscussionApplicationService
postToDiscussion(command)
discussion = discussionRepository.get(command.discussionId)
author = collaboratorService.authorFrom(discussion.Id, command.authorId)
post = discussion.createPost(postRepository.nextIdentity(), author, command.bodyText)
postRepository.add(post)
canPostToDiscussion(discussionId, authorId, bodyText)
discussion = discussionRepository.get(discussionId)
author = collaboratorService.authorFrom(discussion.Id, authorId)
try
{
post = discussion.createPost(postRepository.nextIdentity(), author, bodyText)
return true
}
catch (exception)
{
return false
}
You could even have a method named whyCantPostToDiscussion that would return the exception or the exception message and display it in the UI.
There is only one issue with the code: the call to postRepository.nextIdentity() because it would increase the next ID every time but you could replace it with something like postRepository.getBiggestIdentity() that should have no side effect.
I find it is rare that authorization is actually part of the domain. If it isn't, it makes sense to move that logic out into its own service which the UI and the domain can make use of.
I like to build up a set of rules using the specification pattern. I find it to be a fairly elegant way to build up the rules.
This also plays very well in a CQRS context as you can run each command through the 'rules engine' before they get issued to your AR's. If you push queries through a message routeing system you can do the same for queries. I've had a lot of success with this approach.
The response you are looking for is HATEOAS, look no further. You must implement your rest api as really restful (level 3) adhering to hypertext to model the state transitions and return links to the clients (being the UI one of those). These links represent the actions the user can execute in its context according to the model state. It´s simple. If you return a link from the server then you bind it to a button in the UI, if you don´t return the link because of business invariants then you do not show the button on the UI. There is a lot more of concepts behind it such as designing a good API supporting a well designed domain model behind but this is the general idea around it and fits exactly what you want.
I am creating my first project that uses ui-router.
My project has about 10 views, each with their own controller and state. I am trying to modularise/encapsulate/decouple as best as possible but I am having trouble working out where to put the onExit and onEnter state callbacks.
The first option is to put it in app.js which is currently defining all of my states, however I feel that this would not be a good place as it could cause this file to blow up and become hard to read as more states are introduced and the logic gets more complex.
The second option I looked into was to put it into a controller (I have one for each state), however from researching it doesn't seem to be best practice to do this.
The third option is to create a service that is resolved, however with this option I would end up with either a giant service full of state change functions for each of the states (not decoupled) or an additional service per state which would contain the state change functionality, and I worry that would increase project complexity.
What is the standard way to achieve this?
Are there any other options that I am missing?
Our strategy for this has been to disregard the onEnter and onExit on the state object, because as you are discovering, they feel like they are in the wrong place in terms of separation of concerns (app.js).
For onEnter: we handle setup in an activate() function in each controller, which we manually execute inside the controller. This happens to also match the callback that will get executed in Angular 2.0, which was not an accident ;).
function activate() {
// your setup code here
}
// execute it. this line can be removed in Angular 2.0
activate();
For onExit: We rarely need an exit callback, but when we do, we listen for the $scope $destroy event.
$scope.$on("$destroy", function() {
if (timer) {
$timeout.cancel(timer);
}
});
Mark Dalgleish wrote a nice little article about how to use promises in AngularJS views.
Some people asked questions about this in the comments, but Mark didn't answer them (yet). Because I'm asking me the same question, I will ask on StackOverflow instead to get an answer:
If you use promises in views, how do I handle "loading"/"waiting" indication, because they are async? Does a promise have something like a "resolved" or "withinRequest" property?
How do I handle errors? Normally they would arise in the second callback, but if I use a promise directly in the view I don't handle this case. Is there another way?
Thank you.
EDIT: as of angular v1.2 the resolution of promise in views is not activated by default.
The automatic resolution of promises in a view looks like a handy tool at first but it has number of limitations that need to be understood and evaluated carefully. The biggest issue with this approach is that it is AngularJS who will add callbacks to a promise and we've got little control over it.
Answering your questions:
1) As indicated, it is ultimately AngularJS who will add a success / error callbacks so we don't have much control here. What you could do is to wrap the original promise into a custom one that would track resolution. But this kind of deft the whole purpose of saving few keystrokes. And no, there is no things like 'resolved'. In short - there is no universal mechanism for tracking progress that would work for all promises. If your promises are $http-based you might use interceptors or pendingRequests property to track request in progress.
2) You can't. Once again, it is AngularJS that adds a handler inside the $parse service and it looks like this: promise.then(function(val) { promise.$$v = val; }); (see code here). You can see that only a success callback are added so all the failures are going to be silently ignored.
Those are not the only limitations of the automatic promise resolution in the view. The other problem is that promises returned by a function won't be resolved correctly. For example, if you would rewrite an example like so:
myModule.controller('HelloCtrl', function($scope, HelloWorld) {
$scope.messages = function() {
return HelloWorld.getMessages();
}
});
and try to use the following markup:
<li ng-repeat="message in messages()"></li>
things would work as expected, which might come as a surprise.
In short: while the automatic resolution of promises might seem like a handy shortcut it has number of limitations and non-obvious behaviors. Evaluate those carefully and decide if saving few keystrokes are worth it.
Does anyone here have experience doing a Webtrends implementation? According to their documentation, their asynchronous event tracking call is made by sending key-value string pairs into their tracking method, like this:
dcsMultiTrack('DCS.dcsuri', 'page.html', 'WT.ti', 'NameOfPage');
However, that model does not lend well to supporting dynamic data. What I would like to do is something like this, so that I can dynamically create the key-value pairs based on the user interaction I am capturing:
var wtString = "'DCS.dcsuri', 'page.html', 'WT.ti', 'NameOfPage'";
dcsMultiTrack(wtString);
In my proof of concept, though, that does not work. The actual webtrends JS mangles the data and the call is not made. (Sifting through their code, it looks like something breaks when assigning the arguments to the Webtrends object. Anyway, I can't edit their code because then they won't support it, so I stopped investigating that end of things.)
So the question is, how can I pass the JS variable as its value? I've done a lot of searching and tried things that I thought would both work and not work: String(), .toString(), .value(), closures, and even the dreaded eval(), but to no avail.
Any help would be MUCH appreciated. I'm at my wits end with this one.
It looks like JavaScript's apply function could help here:
var wtArguments = ['DCS.dcsuri', 'page.html', 'WT.ti', 'NameOfPage'];
dcsMultiTrack.apply(this, wtArguments);
This is effectively the same as calling:
dcsMultiTrack('DCS.dcsuri', 'page.html', 'WT.ti', 'NameOfPage');