How does one handle a user confirmation when using MVP/MVC in a Web environment?
Presenter:
if (_view.AskUserForConfirmation())
{
// do something
}
In a winforms project this won't be any problem but in a web environment the confirmation answear will come one postback after the preseter code, how does one handle such a thing?
Basically you don't...
Asking confirmation is in pure MVP not a responsibility of the Presenter. The logic in the presenter is called after the confirmation. I can understand what you are trying to achieve here but it is not possible to go back to the user during a Postback, request confirmation (or some other data) and use the result on the point where you left the routine.
Either accept that it is not presenter logic and that the logic of the view asked the confirmation, or redesign your application to use multiple views of which one asks for confirmation (Wizard style).
Related
I am following the MS documentation for sequential conversations
https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-dialog-manage-conversation-flow?view=azure-bot-service-4.0
This is working fine, but I want to be able to run more than one of these.
For example to ask the following:
"I want to open a technical support case"
"I want to update my technical support case"
"I want to close my technical support case"
The example just revolves around just running one conversation so I don't know how to cater for multiple conversations.
Your help is much appreciated.
Thanks
Steve
Consider looking over using component dialogs, described here. Component dialogs offer a means to branch conversations to handle specific portions of conversation and then return the user back to the main dialog.
In your case, you would query the user to what they are seeking as part of the main dialog. Then, once determined ("I want to close my technical case"), the dialog would branch to handle that specific conversation. After the case is closed, the component dialog would end and return the user back to the main dialog to determine if they want to perform any other actions.
This sample, 43.complex-dialog, demonstrates how to setup a bot to utilize using component dialogs.
If you couple that with LUIS to handle user intents, you should easily be able to manage a user's path while they navigate thru your bot. "I want to open a case" and "I want to close a case" would return either an "case open" or a "case close" intent which, when the intent is returned to the bot, would trigger the associated component dialog to open.
Hope of help!
Been moving into some task oriented UI as a part of my CQRS implementation.
The problem is I have come across the need to update additional properties in my UI as a result of a change made by an initial command sent from the same UI.
My case is different but here's an example...
eg. CommandA Add item to cart resulted in the following events (which all need to be reflected on the UI)
change to store inventory
add item to shopping cart
change total with sales tax
What's the best way to handle this without baking my business logic into my UI?
return a list of resulting events that were performed as a result to the initial command?
return a DTO that reflects changes
other ideas?
I haven't completed it yet, but my idea is to use a Hub from the SignalR framework and subscribe to events and act on them. As long as you can correlate user guids with the connected user guids in SignalR, you can send updates to the correct client and even detect if they still are there.
SignalR isn't that mature yet but the tests I have done works pretty good.
I use it with Knockoutjs and I just update my view models and call functions.
Do those events really need to be reflected in the UI? Consider Amazon, who display "you just added foo to your cart", but don't show any of those other details. That might save you from the problem by redefining it away.
Otherwise, why are you afraid of business logic in the "UI" - specifically, why not include some components from the service that owns each part of that system in your client, and give them the responsibility of doing whatever local updates are appropriate?
In other words, having part of the logic from your sales tax service running in the UI is fine. You (obviously) don't trust it with the billing calculations for tax, but you can totally trust it to do the right thing for the client.
The other advantage of that model is that you get instant feedback for the user, or at least the option of showing instant feedback, without baking more business process knowledge into the client.
For example, recalculating shipping takes time to do - if your client shows a spinner over that, something needs to know to trigger that showing up, right?
If your UI knows that, it has embedded business process around the process. On the other hand, if you have code that is part of the "shipping" service, you can change what response occurs in the client by changing only the one service...
I am building an MVC application (using the Zend Framework).
When users first register, the applicaiton sends them an email. My question is, where should I trigger this email from? The model or the controller? My thoughts are as follows:
In some ways, the model makes sense, since sending a registration email is part of my business logic. Users must click the link in the mail to validate their email address.
But by putting it in the model, I am 'encumbering' the model. The model's registerUser action is then only useful within the context of an application that needs emails sent for every registration.
Instead, by triggering the email from within the controller, my controller would be a litter 'fatter', but my model a little more 'fine grained'.
I have written an email service which actually configures and sends the email, and I think this is a good design decision. I am really just asking where I should be calling this service from.
Your thoughts are most appreciated!
According to Zend Framework's definition of MVC, you should put send the email from the controller:
Controllers...decide which view to display based on the user's request.
Models, on the other hand, contain:
...basic functionality behind a set of abstractions.
An email may be considered a "view" in that it displays information to the user. It is the controller's job to activate this "view."
In my opinion, I would want this in the model, as I would consider this an assumed process of the create user method, rather than any specific interaction with the user making the request.
In other words, since I would always want this email sent, regardless of the source of the request, I would identify this as a natural byproduct of the create user action, similar to a record being saved in a database.
You might want to look into using something like NServiceBus to queue messages to be sent to your Email Service.
This way you can have NServiceBus subscribe to an event that occurs and omit any manual firing of the email service etc.
Ultimately you want a failsafe way of ensuring your messages get to the intended people. This kind of framework will greatly help you ensure that this happens.
Alternatively you could store the emails to be sent inside your database and have your email service check the database queue every x minutes for new emails to send and omit the need for triggering the email sending.
Again, doing it this way will ensure at the least that the emails get sent. Should the network go down or some other disruption occur during the sending of each email you can simply leave them in the queue until the network comes back up.
We are writing an application hosted in Excel 2002 (groan). One requirement is that, during certain operations, we submit progress messages to the user from the business layer. However, these messages can be displayed at multiple sites, one being the Excel status bar, and another being a label on a form, and possibly others in the future. In some situations, we desire to only post the message to the Excel status bar, in others, just the label on the form, and in others, both.
Currently, we have a message "hub" to which business logic can post status messages. The Excel status bar and also the form label both observe this hub, and if any messages are posted, both intercept the messages and display them- similar to mass mailings via a post office, where the sender is unconcerned with the destination.
First: Is this a generally accepted pattern?
Second: Would it be prudent for the business layer to have knowledge of the destination to which it needs to post a message? Even though the business layer is relatively decoupled from the UI through the use of the post office, what is your opinion of imbuing the business layer with, essentially, address/target/destination information?
Thanks.
If you want to stick with the conventional pattern for this type of problem then you will want to look into the Model-View-Controller (MVC) design pattern. The purpose of the pattern is to decouple business logic from the GUI(s). It allows for one model (business logic) to drive multiple different GUIs.
How would you handle calling a user confirmation dialog before continuing with a task in a web-based MVP pattern implementation? It'll have to do a postback in between and the confirmation would go out of the scope of the presenter function that called it. I'd prefer to keep to a pure MVP implementation but is it even possible?
You can't implement this logic in one single server-side function. I believe the standard approach to tackle this is either to
Have multiple steps that each involve one postback to the server. One of these steps would be the confirmation dialog you mentioned
or
Show the confirmation dialog via Javascript